this is the sort of code that FPGA vendors provide in their technotes as the code you are expected to write. yes, with the mixed blocking and non-blocking assignment... (Lattice TN1250)pic.twitter.com/HtOjjiw3Qp
-
I don’t see a problem (no sarcasm).
It's a race condition in simulation. You need to use a non-blocking assignment (<=) or other "always @(posedge clk)" blocks will see either the old or the new dout value in that same cycle, depending on the implementation defined order the simulator runs those blocks in.
-
-
oh, so it is even more buggy than I thought.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Except that it's worse than "implementation defined" things in C because an implementation may choose to run different blocks in different threads, yielding a situation where multiple runs of the same simulator may return different results.
-
Personal experience: these types of bugs (blocking assignments to a register referenced in multiple always blocks) are very difficult to chase down. Avoid them at all cost if possible.
- Show replies
New conversation -
-
-
Oh dear. Am I correct in understanding that using any blocking assignment in a clocked always block, where the value is used outside the block, can always lead to a race condition, because the simulation order of triggered clocked always blocks is unknown?
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.