Project

General

Profile

[logo] 
 
Home
News
Activity
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  BugVise
  CovVise
  Force-Gate-Sim
  Gspice
  IPC::Locker
  Rsvn
  SVN::S4
  Voneline
  WFH
General Info
  Papers

Issue #1314

Bad scaling, if there are nasty forests of generate statements

Added by John Coiner 10 months ago. Updated 10 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Performance
% Done:

0%


Description

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

diffs (6.12 KB) John Coiner, 05/31/2018 09:12 PM

History

#1 Updated by John Coiner 10 months ago

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 10 months 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