Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simple AND-gate not working in verilator, but works with modelsim/questa #836

Closed
veripoolbot opened this issue Nov 2, 2014 · 4 comments
Closed

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Nov 2, 2014


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?

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 2, 2014


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-11-02T02:07:32Z


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.

@veripoolbot veripoolbot closed this Nov 2, 2014
@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 2, 2014


Original Redmine Comment
Author Name: Jonathon Donaldson
Original Date: 2014-11-02T04:25:41Z


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.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 3, 2014


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-11-03T01:09:58Z


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.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 3, 2014


Original Redmine Comment
Author Name: Jonathon Donaldson
Original Date: 2014-11-03T01:15:21Z


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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.