soc verilator very slow

[alanvgreen]

The soc verilator executable is now too slow to test riscv executables that manipulate the display.

I believe that change that caused the reduced speed is the new 96MHz PSRAM controller. (Hooray for faster memory!)

If there's any amount of effort involved, verilator probably isn't worth fixing, but raising as issue in case there's a quick fix possible.

[smunaut]

You can try to revert the commit that changes the waveform format to FST and see if that helps.

[alanvgreen]

I commented tracing out entirely and it was still very slow.

[smunaut]

Ah well ... not sure then, I guess at least a 2x (or even 4x) slow down is expected because now since some logic runs at 96 MHz DDR there is evaluation at both twice the frequency and on both clock edges ... and I'm not sure how smart verilator is in detecting what's sensitive to which clock edge.

[alanvgreen]

Yeah, it seems Verilator thinks that there's a lot more work to do. I used to get about 5-10 seconds between frames: now it's many minutes.

I guess a way to fix it, if there were many weeks before supercon, would be to have two modes for verilator, a "full" mode which is what is checked in now, and a "fast" mode which substituted the PSRAM stack with something simpler and faster. But given the timeframe, I don't think it's worthwhile. Only nine days till we all get our hands on real hardware :)

[Spritetm]

Agreed, I also ran into this... it's a bit of a PITA and makes full-on Verilator harder. Alan, if you want to see if you can fix it, it's not a half bad idea: a lot of changes to the SoC will probably be simulated first, and it makes it a lot easier to do this if there's a full-system sim available... Not sure if me or smunaut have enough time to take a look at this.

[smunaut]

Try this :

(but this obviously disable all trace ...)
No idea how it compares to before, but it's at least much faster AFAICT.

diff --git a/soc/verilator_main.cpp b/soc/verilator_main.cpp
index fd0f008..98e0614 100644
--- a/soc/verilator_main.cpp
+++ b/soc/verilator_main.cpp
@@ -99,6 +99,14 @@ int main(int argc, char **argv) {
                if (ts > 10)
                        tb->rst = 0;
 
+               tb->uart_rx = rx;
+               tb->irda_rx = tb->irda_tx;
+               tb->flash_sin = ts & 0xf;
+
+               pixel_clk = !pixel_clk;
+               tb->vid_pixelclk=pixel_clk?1:0;
+               tb->adc4=tb->adcrefout?0:1;
+
                for (int c=0; c<4; c++)
                {
                        int v;
@@ -119,18 +127,11 @@ int main(int argc, char **argv) {
 
                        uart.eval(tb->clk48m, tb->uart_tx, &rx);
 
-                       tb->uart_rx = rx;
-                       tb->irda_rx = tb->irda_tx;
-                       tb->flash_sin = ts & 0xf;
-
-                       pixel_clk = !pixel_clk;
-                       tb->vid_pixelclk=pixel_clk?1:0;
-                       tb->adc4=tb->adcrefout?0:1;
                        tb->clk48m = (c >> 1) & 1;
                        tb->clk96m = (c     ) & 1;
                        tb->eval();
 
-                       if (do_trace) trace->dump(tracepos*20 + c*5);
+                       //if (do_trace) trace->dump(tracepos*20 + c*5);
                }
 
                do_trace = tb->trace_en;

[alanvgreen]

Yes, this patch helps a lot, frames are showing up at about 9s intervals for me, which is comparable to how they used to be.

I think that your patch might fix a bug to do with the pixel clock running too fast, and so the display doesn't update properly. When I run without the patch, I get the first and second frames (eventually), but the third frame never appears, even after leaving it for 10 minutes.

btw, I can get down to 6s per frame by commenting out the UART emulator.

Thanks! I'll turn your diff into a pull request tonight, if you haven't already.