Bad scaling, if there are nasty forests of generate statements
This patch adds two tests:
One is a tree of modules, defined recursively, each of which contains a generate statement with several leaves. Each leaf has a submodule, and only one of the leaves should ever be active at a time. So each module really only has one submodule, post-generate, and the module hierarchy is a simple vine. This test passes.
The other is a tree of modules, defined non-recursively. Otherwise it's very similar. This causes verilator to spin and consume all memory on the host. The reason is, it doesn't appear that verilator can prune its analysis to only the active leaves of the generate statement, instead it fans out exponentially across unreachable generate paths.
I was a little surprised that the basic case is broken, while the "tricky" case of a recursive module works well. I'm also a little surprised that verilator handles recursive modules as a special case internally. I'll dive in and see if it's possible to clean that up and get to a single general case that passes both tests...
#1 Updated by John Coiner about 1 year ago
- File diffs added
Here's the patch with the tests. It should apply to the develop-v4 branch.
The exponential search explosion happens very early, in V3LinkDot. V3LinkDot also has special cases to delay its resolution of recursive cell instances. That's not called for by the IEEE standard, is it? Assuming this special case handling isn't required by the standard, maybe we can avoid the special cases. I'll look into it.
#2 Updated by Wilson Snyder about 1 year ago
- Status changed from New to Confirmed
The diffs had only a V3Ast dynamic cast fix (which shouldn't go into master and is already fixed in develop-v4).
The handling of generates is currently unfortunately handled very late after much linking, ideally it should be much closer to the parser, as the present approach this causes the recursion and other minor problems and a lot of V3LinkDot mess, but to fix this is beyond the pain I'd like to suffer to fix; we can discuss how to approach that if you're interested.
That general problem said, the fix for this exact failure keeping the existing framework probably is relatively small.
Also available in: Atom