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
Missing initial positive edge when using --x-initial-edge #678
Comments
Original Redmine Comment Hi Charlie, Thanks for the report. I did the work on this some time ago and I'll investigate. I'll try to get this sorted (or at least understand why it broke) later today or tomorrow morning. Jeremy |
Original Redmine Comment Hi Charlie, I think the old behavior was wrong, and Bug 613 fixed it (very much as an unexpected side effect, which I still don't understand properly). If you define a signal with "initial", then it isn't X to start with, so it should not be affected by --x-initial-edge. I've tested against an event driven simulator (Icarus), and its behaviour is consistent with this. Do you see the same behavior with NC or VCS? However... It used to work for you, and now it is broken. I need to work out if there is a way to restore the behavior you want. You want initial to happen not at the very beginning, but after one cycle of checking for clock edges. Can you confirm this is the semantics you need? |
Original Redmine Comment Hi Jeremy So the issue we have is we would like to do the following
Except Verilator disregards the non-blocking write in the initial block. This sequence does work in Icarus. |
Original Redmine Comment Hi Charlie, OK that makes sense with a delayed assignment. I'll need to do a bit of digging into how Verilator transforms delayed assignments inside initial blocks to see what's possible. Give me a day or two. Jeremy |
Original Redmine Comment Our current workaround is rather crude:
|
Original Redmine Comment Hi Charlie, That's a fascinating approach. Marking all variable references in sensitivities as delayed. I need to think this through, to see how it will affect the overally ordering algorithm. Have you run a regression test to see what wider effects this has. The approach I am investigating was whether the change from Bug 613 could be restricted, so it did not apply to delayed variables in initial blocks. Jeremy |
Original Redmine Comment Hi Charlie, This is a little tricky, because by the time we get to @V3Order.cpp@, we don't know if an initial block used delayed assignments. However it is fairly easy to leave a marker around for that. We then need to add initial blocks to the order tree in @V3Order.cpp@, so we can then detect them in the @AstNodeVarRef@ visitor and if it is a delayed assignment in an initial block add a suitable vertex and edge. I've done all this, and it mostly works. See branch issue-678 at https://github.com/jeremybennett/verilator. But... This change breaks @processMove()@, and we don't get the correct @cfunc@ tree generated for initial blocks. The upshot is that you get dupliate declarations of @_initial__TOP@ functions in the generated code. I have partly ameliorated this, by eliminating unused initial logic vertices in @iterateNewStmt()@, but this is really just covering up the problem. There is still one regression error, @t_initial_dlyass.pl@ caused by this patch, but it is symptomatic of the problem. It's getting late tonight, but I hope either you or Wilson might see what the final part of the patch is. I'll take another look in a day or two. |
Original Redmine Comment Hi, so Just testing this patch on our designs we are getting multiple definitions of _initial__TOP:
I will investigate a little, but any help would be appreciated. |
Original Redmine Comment Hi Charlie, OK - so we need to fix that processMove() problem. I'll continue to work on it. |
Original Redmine Comment Not currently being worked on. |
No longer being worked & the general need for x-initial-edge will eventually be replaced by better event scheduling. |
Bump Surelog and uhdm-integration
Author Name: Charlie Brej
Original Redmine Issue: 678 from https://www.veripool.org
If --x-initial-edge is set, the __Vclklast of clock values is set to 1 to trigger the negedge action. If the initialization routine sets the value to 1, then neither the positive nor negative edge of that signal are triggered.
The bug was introduced in "Fix ordering of clock enables with delayed assigns, #�" patch (b277bc8).
Attached file demonstrates the fault.
The text was updated successfully, but these errors were encountered: