Skip to content
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

Jump to bottom

Compile Issue with Large Design with Large I/O Buswidth #337

Closed
veripoolbot opened this issue Mar 30, 2011 · 2 comments
Closed

Compile Issue with Large Design with Large I/O Buswidth #337

veripoolbot opened this issue Mar 30, 2011 · 2 comments
Assignees
@wsnyder
Labels
area: usability Issue involves general usability resolution: abandoned Closed; not enough information or otherwise never finished

Comments

@veripoolbot
Copy link
Contributor

Author Name: Andy Wagner (@andywag)
Original Redmine Issue: 337 from https://www.veripool.org
Original Date: 2011-03-30
Original Assignee: Wilson Snyder (@wsnyder)

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?
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-03-30T11:22:24Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-07-30T11:20:54Z

Closing due to inactivity.

@veripoolbot veripoolbot added area: usability Issue involves general usability resolution: abandoned Closed; not enough information or otherwise never finished labels Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@wsnyder wsnyder

Labels
area: usability Issue involves general usability resolution: abandoned Closed; not enough information or otherwise never finished
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@wsnyder @veripoolbot