Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

Channel non-blocking write semantics.

EDIT: The following is most probably a result of a bug in my code.

Hi.

I noticed that - in emulation - a non-blocking write may also send data to a channel when it reports a failure.

There is one blocking read on the other side that receives more than it should.

Is "at least once" the intended behavior?

A fundamental or temporary problem with emulation?

Or just a bug in

Version 17.0.0 Build 290?

Regards

Julius

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    Hi Julius,

    Do you seeing this behavior also in 16.1 SDK?

    Regards,

    CloseCL

    (This message was posted on behalf of Intel Corporation)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    I can not confirm the mentioned behaviour in 16.1, mostly because none of my nonblocking writes fail.

    I remember something about the channel depth not being strict in the 16.X SDK.

    Is there a way to force channel depth reliably in 16.1?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    There is no way to force channel depth in 16.1 for emulation. You can only change channel depth emulation behavior in v17.0. The only cases I have encountered where a receiving channel received more data than it should in emulator were when I had made a mistake in my code, resulting in two writing points to the same channel; unfortunately, at least in v16.1, the emulator does NOT fail when you have more than one writing point to a channel and it does in fact write data to that channel from both points. Chances are this has not been fixed in v17.0 either. Just to make sure, I recommend trying a trial standard compilation on your kernel to make sure you do not have more than one writing point to your channel (in which case the standard compilation will fail, telling you about the problem).

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    Okay.

    After some more testing and a rewrite in which I forgot to commit the problematic code I could not reproduce the problem I had.

    A couple of other bugs suggest there it really was an issue with my code.

    Thank you.