Performance Issue with Fdisplay

Before the issue, I am extremely happy with verilator. It far surpassed my expectations for a free simulator and would be comparable to commercial simulators with a few exceptions. I really congratulate the author on creating a great simulator.

I am simulating a large design (~8M gates) which contains parallel signal processing logic with wide buses. I am loading and dumping this data in binary using readmemb and fdisplay("%b.."). This is admittedly not the best way to deal with this, but I wanted to have a testbench which was portable to other simulators, even if it was suboptimal. This approach worked ok for smaller subblocks, but when I moved to the current block, the fdisplays were causing the compilation to not finish. An example of the fdisplays are shown in the statement below. The splitting to 1024 bits is required to avoid compilation errors.

$fdisplay(cd_input_optr,"%b%b%b%b",cd_input[4095:3072],cd_input[3071:2048],cd_input[2047:1024],cd_input[1023:0]);

My current plan is to move the data dumping to the c++ portion of the code, but before doing this I am hoping there might be another option as I have invested quite a bit of time in automating the test bench creation. Any suggestions would be appreciated.

Replies (3)

RE: Performance Issue with Fdisplay - Added by Wilson Snyder about 1 year ago

It's unlikely to help, but BTW there's nothing magic about the 1024 limit. You can change VL_VALUE_STRING_MAX_WIDTH 1024 in both the src and include directory and recompile. (It just makes the stack less efficient so isn't large by default.)

I'd also guess that putting the display in a task, and marking the task /* verilator no_inline_task */ would work around it.

I tried a small example and didn't see anything nasty, but as you say it's a large block. It's probably something easy enough to fix if you can reproduce it or run with --debug --gdb and hit control-C then "bt" to see the backtrace. Post a bug with the results.

RE: Performance Issue with Fdisplay - Added by Andy Wagner about 1 year ago

Thanks for the response.

The issues occurs in compilation rather than runtime. The compile without the fdisplays takes about 20 seconds, with never finishes. I am running this with debug now and can send the results of the compilation. With the current state of the design, I can actually send this as well if you are interested in potentially fixing a bug. As the owner of a software project myself, I could understand if this fits on the obscure bug list.

I am unhappy with the performance of my current approach and am leading towards moving this to c++. I read the documentation quickly and didn't see an easy way to get access to signals lower in the hierarchy. Is there a simple way to do this.

RE: Performance Issue with Fdisplay - Added by Andy Wagner about 1 year ago

I found the documentation on using the SV DPI and I think I am going to go to this approach.

(1-3/3)