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
Support finitely recursive modules #659
Comments
Original Redmine Comment Interesting, first time I've seen this sort of recursion used for something that isn't just completely silly. To Verilator this is circular as unfortunately Verilator does several processing steps before the generates are resolved; someday this will be fixed, but this is not a minor undertaking and is unlikely to be within 2013, sorry. I added the test to the suite marked as unsupported so it isn't lost. |
Original Redmine Comment Is it possible to bump priority of this issue? I failed to use Verilator just because of this feature; in a project I tried to compile with Verilator all floating point (FPU) code is written using recursion. |
Original Redmine Comment Oh, "feature" just means adding support for something that isn't supported now, as opposed to something broken that was thought to work; there's no argument this is a bug. :) Unfortunately this changes fundamental assumptions, and there are simply other bugs which are blocking more projects. If you have significant time to invest in fixing this, we'd be very glad to have the help. |
Original Redmine Comment I can trace where check for recursion is made inside GraphAlgRank::vertexIterate, but then it is getting harder to understand fundamental assumptions from the code. May be you can outline here main steps along with references to the code as a guideline for a person who will undertake this work. |
Original Redmine Comment At present, verilator sorts the modules from top to bottom (modSortByLevel()) as the later stages require that ordering. In addition the visit routines assume that a module is not re-entered when processing (which is violated by loops). Also any userp()'s that are attached to a module assume that module is not referenced again. V3LinkCells, V3LinkParse, V3LinkDot, V3LinkResolve, V3LinkLValue, V3LinkJump, V3Param now mostly but not completely work on the entire netlist, e.g. all modules are LinkCell'ed, then all modules are LinkParsed, then all are LinkDot'ed, etc... This whole netlist assumption does not work with recursion as recursion is only broken by doing parameterization. The new algorithm is to do these steps module by module top-to-bottom; which is what the 'design' of the more recent SystemVerilog unfortunately assumes. This solves the problem because the first hit of the recursive module will elaborate (parameterize) which will result in a different version of (what verilator now thinks it a duplicate) recursive module, therefore it really is no longer recursive, and it will all work. In brief:
This also fixes an outstanding bug related to parsing modules that do not need to really exist due to being "generate if'ed out". |
Original Redmine Comment Any news regarding this? I'm trying to write a finitely-recursive tree adder. I then tried rewriting this as a recursive module, but this also fails due to the bug above :-( |
Original Redmine Comment Sorry, I don't have any progress on this. You can of course disable the UNOPTFLAT warning. |
Original Redmine Comment (Finally) fixed in git towards 3.915. |
Original Redmine Comment In 3.916. |
Set DEBIAN_FRONTEND to noninteractive
Author Name: Sean Moore
Original Redmine Issue: 659 from https://www.veripool.org
I'm getting an error thrown when trying to create recursively instantiated modules in Verilog.
@-Info-Loop: 0x92f9f40 VERTEX=PriorityChoice r2@
@-Info-Loop: 0x92f9f40 VERTEX=PriorityChoice r2@
@%Error: PriorityEncoder.v:9: Recursive module (module instantiates itself): PriorityChoice@
@%Error: Exiting due to 1 error(s)@
@%Error: Command Failed /usr/bin/verilator_bin --cc PriorityEncoder.v@
I would expect it to fail for modules with non-terminating instantiation (or one which passes some settable threshold due to the halting problem). I've included a test which fails in Verilator but passes in Icarus Verilog.
The text was updated successfully, but these errors were encountered: