[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
  SystemPerl
  Voneline
  WFH
General Info
  Papers

Issue #337

Compile Issue with Large Design with Large I/O Buswidth

Added by Andy Wagner about 2 years ago. Updated about 2 years ago.

Status:Feature Start date:03/30/2011
Priority:Normal Due date:
Assignee:Wilson Snyder % Done:

0%

Category:Usage
Target version:-

Description

This is a follow up to the issue with Fdisplay but the issue was not with Fdisplay so I created a new item. I have a large design with large parallel I/O. The compilation times for this design are extremely large and might not even finish. I though I isolated this issue to an fdisplay statement I was using in the testbench, but I am pretty sure that the fdisplay is not the issue. Since then I have tried the following :

1. Put the fdisplay in a task with the option not to inline 2. Made all the signals I wanted to dump I/O from the verilog section of the testbench. 3. Made all the signals public ie /*verilator public*/

All of these changes made the compile time increase from about 1 minute on an extremely fast brand new machine to not finishing.

I also attempted to use the DPI interface which didn't suffer from a compile issue but had a run time error that it couldn't find the dpi function from the c++ testbench.

Are there any extra options or make steps required to use the DPI functions from C++? I am pretty open to workarounds to make this work. Are there any other possibilities? Is there a way to split the design into smaller sections for compilation and run the composite design?

History

Updated by Wilson Snyder about 2 years ago

  • Category set to Usage
  • Status changed from New to Assigned
  • Assignee set to Wilson Snyder

For DPI, it should be something simple to fix. What specific error did you get? You indicated you're calling DPI from your testbench, is that correct or is it the other direction calling $my_display from verilog? (If you are failing on a scope lookup, then try using Verilated::scopesDump() to see how what your asking for matches up with what exists.)

For the speed issue, please run verilator with "--debug --gdb" and hit ctrl-c then "bt" to print out what it is doing and post/email the results. Set aside the files in obj_dir, as I'm likely to have follow up questions. Thanks.

Also available in: Atom