Project

General

Profile

[logo] 
 
Home
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  IPC::Locker
  Parallel::Forker
  Voneline
General Info
  Papers

Suggestions on how to debug -x-assign issues

Added by Don Owen almost 7 years ago

I've recently added Verilator as an experimental simulator for a research project that I and several others have been working on. In summary, this part of the project involves a homegrown pipelined microprocessor and some custom-developed software running on it. It's fully synthesizable (Both Xilinx and Synopsys toolflows) and we've been successfully running it in both hardware (FPGA) and on the Icarus simulator for several years now. I added Verilator support as a third simulator in addition to ISim and Icarus because we wanted more speed while developing software. The good news is Verilator is significantly faster, on the order of several million simulated cycles per second, compared to a few thousand with Icarus or ISim. The bad news is we get different results between Icarus and Verilator. In summary, Icarus, ISim, and synthesized hardware all agree with each other on the cycle count for a particular algorithm and Verilator disagrees. More detail below.

In particular, what I've observed is that, so far, Verilator always returns a cycle count significantly higher than our other results. Verilator is on the order of 53.9M cycles, whereas our other results all say 47.9M. The testbenches for Icarus and Verilator should be functionally identical and the cycle count measurement is made by the hardware being simulated, not by a testbench. I tracked down every last warning that Verilator generates that could possibly have to do with correctness; the only warnings that remain are UNUSED, PINNOCONNECT, WIDTHCONCAT, UNDRIVEN, DECLFILENAME, PINNOCONNECT, BLKSEQ, SYNCASYNCNET, and CASEINCOMPLETE. All of these, I believe, are still guaranteed to simulate correctly.

What I have noticed is that, when I specify -x-assign {0,fast,unique} I repeatably get the same 53.9 M cycle count, but when I specify -x-assign 1, I get 49.7 (repeatably), which is closer to the expected value, but still not there yet. -x-initial-edge has no effect that I have observed.

My question then is, does anyone have guidance on what to look for that this may be influencing? Or what other constructs in a large design may be affected that would give such a drastically different cycle count? My understanding of -x-assign is that it mostly affects reset signals. However, I haven't observed resets being triggered in the simulation.

Thanks in advance.


Replies (3)

RE: Suggestions on how to debug -x-assign issues - Added by Wilson Snyder almost 7 years ago

Sorry you're having troubles. From the -x-assign it seems like there's a problem with uninitialized resets or initial edges, though it is strange that x-initial-edge had no effect.

One thing to check is conditional clocking; Verilator has special requirements there - see the manual.

Have you tried the obvious of running waves with both simulators and seeing where they start to differ?

RE: Suggestions on how to debug -x-assign issues - Added by Don Owen almost 7 years ago

Well, after some extensive debug, it seems like a large part of our problems were, in fact, a coding bug that only now manifested. The particular signal in question was being output of a module as a 1'bx, negated, and then fed into another module where a condition was depending on it of the form "if relevant_signal && other_signal && another_signal..." so the 1'bx was propagating and messing with the logic there. When the signal was 0 it was causing pipeline stalls that didn't need to be there. Both Icarus and verilator were correct; it was just the difference between 2-value and 4-value simulation that finally triggered this bug that had been in the source for a long time. Fixing this has brought the cycle count significantly down but hasn't reduced it all the way to the level that I expect quite yet, so I wouldn't be surprised if there are more bugs of this type.

That's the latest news for now; I'll update again if I can get everything totally resolved so that Icarus and Verilator are in complete agreement. Hopefully my commentary here will help someone else! (Maybe the devs would consider this example as something to add a note on in the -x-assign documentation because it triggered a bug that had nothing to do with resets/initialization? Just a thought.)

RE: Suggestions on how to debug -x-assign issues - Added by Don Owen almost 7 years ago

Further testing shows that Icarus and Verilator now 100% agree. No further bugs worth mentioning. Thanks for the response!

    (1-3/3)