Compile Issue with Large Design with Large I/O Buswidth
|Assignee:||Wilson Snyder||% Done:||
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?
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