Simple AND-gate not working in verilator, but works with modelsim/questa #836
Comments
|
Original Redmine Comment This is a clock gater, see the section in the manual on clock gaters. FWIW we all agree this is an unfortunate limitation/bug, but it's not going to change any time soon. |
|
Original Redmine Comment Can you provide some more details... First, I looked in the verilator manual (http://www.veripool.org/projects/verilator/wiki/Manual-verilator) and only found one instance of "clock gate" in the manual in relation to /verilator clock_enable/ and it didn't really explain the issue. Is there another webpage where you actually explain what the problem is and how to avoid it? Second, I think what you're talking about is the fact that I'm using "always_ff @(posedge mysig_rise)". Is that specifically where the problem is? If I comment out that always block then I see that the pulse then occurs as it should. However, I don't understand why an always block that simply "reads" or "looks at" the mysig_rise signal prevents that signal from being driven? Third, I have another version of the file that also causes the pulse to not occur and in that scenario I'm not using posedge on mysig_rise. So what is the problem there? I have attached the new version of the file. |
|
Original Redmine Comment Verilator statically schedules all clocks. If a clock is generated by logic, it can't determine which branch of the input cone may change and trigger the flop - in the case of an AND it doesn't know which side is the input clock and which the gater. If you think about synthesis this is sort of the same as saying either side of a clock gate can race - which is true - you need to give additional information to resolve the race. As to your other example I think in this case you are setting a public input but the model does not know it has to reevaluate. This is a somewhat similar limitation - verilator needs to know what clocks things change on. Verilator will only reevaluate when some external input (non-public) changes, so public signals really only work perfectly when feeding into a flop. Using the public_flat with a clock is recommended as verilator can then determine what edge to reevaluate upon. |
|
Original Redmine Comment This is incredibly useful information! I will need to keep these two points in mind in the future when verilating. Thanks!!! :) P.S. Sorry if this is already explained elsewhere on the site but I couldn't find it... |
veripoolbot
added
area: wrong runtime result
Author Name: Jonathon Donaldson
Original Redmine Issue: 836 from https://www.veripool.org
Original Date: 2014-11-02
I have attached an example design that reproduces this problem on verilator v3.864. There's not much to say except for the fact that this is an extremely simple design where I am generating a signal that detects a rising edge on a signal using a simple combinatorial AND-gate. The design doesn't work in verilator. But it does work in modelsim and questa without modification. I even have verilator linting turned on and there is not a single warning message.
I have provided everything required to reproduce the issue including my exact build script. (But you will need to make changes to the file/library paths in _verilate.sh to match your system.) Just run "bash _verilate.sh".
I've also included screenshots of the trace from both verilator and modelsim so you can see the difference.
Clearly I'm doing something really wrong since if AND-gates didn't work in verilator then virtually no verilated design would ever work. Haha. Can you tell me what's going on?
The text was updated successfully, but these errors were encountered: