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
-
Which leads me to wonder if some simulators, e.g. Modelsim, do some kind of basic dependency analysis and schedule blocks "in order" to (mostly) avoid this problem.
Yeah, that would be a very EDA-industry thing to do. I wouldn't be too surprised if this is the case. Btw, if you are using modelsim, -hazards can help you find this kind of race conditions.
-
-
Nice, but I've since switched to Verilator after
@zipcpu wrote his intro to it, and Xsim for client projects using X's IP. -
@zipcpu mentions (verilator) sim effects under 'Trace bias' https://zipcpu.com/tutorial/lsn-04-pipeline.pdf …
End of conversation
New conversation -
-
-
It just occured to me that a possible reason I have never seen a race condition is that I lay out my always() blocks in the order the data is processed in, so if the simulator simply schedules them in the order they are read, there would be no races.
-
I've been scratching my head on this all day. While I know I might be able to try this ides this generally, I know I can't do it consistently. That would then lead to the rare hair-raising bug search for something completely unexpected. Sorry, not for me
- Show replies
New conversation -
-
-
Is it an issue when synthesizing ? Or is that vendor / tool determined ?
-
At the core is an ambiguity that means different simulators and synthesizers are free to interpret differently. Needless to say, that can lead to difficult to debug bugs
- 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.