Cache performance will degrade in some simulator due to the implement of module "cache_lru" about nyuziprocessor HOT 5 CLOSED

Good catch! Nice write up of the issue too, thanks.

Since Verilator is only a two-state simulator (no x or z), it doesn't manifest this problem, but any four-state simulator probably will. Another solution might be to initialize the SRAMs to 0 at startup.

from nyuziprocessor.

This patch should address the issue, but feel free to let me know if not.

from nyuziprocessor.

Sadly, if a logic/reg variable is driven in an always_ff block, the "vlog" compiler in the latest Modelsim seems doesn't allow any other block drive that single again, even it's an initial block. So the patch 7780328 just can't pass the compile.

The following patch is ok with the help of macro SIMULATION, but not very beautiful...

--- sram_1r1w_ce221ff.sv        2017-03-23 23:05:54.677195800 +0800
+++ sram_1r1w_patched.sv        2017-05-05 16:32:46.063266600 +0800
@@ -100,7 +100,11 @@
     // Simulation
     logic[DATA_WIDTH - 1:0] data[SIZE];

+`ifdef SIMULATION
+    always @(posedge clk)
+`else
     always_ff @(posedge clk)
+`endif
     begin
         if (write_en)
             data[write_addr] <= write_data;
@@ -120,6 +124,11 @@

     initial
     begin
+`ifdef SIMULATION
+        for (int i = 0; i < SIZE; i++)
+            data[i] = '0;
+`endif
+
         if ($test$plusargs("dumpmems") != 0)
             $display("sram1r1w %d %d", DATA_WIDTH, SIZE);
     end

--- sram_2r1w_ce221ff.sv        2017-03-22 23:48:00.614532400 +0800
+++ sram_2r1w_patched.sv        2017-05-05 16:32:48.783422200 +0800
@@ -128,7 +128,11 @@
     // Simulation
     logic[DATA_WIDTH - 1:0] data[SIZE];

+`ifdef SIMULATION
+    always @(posedge clk)
+`else
     always_ff @(posedge clk)
+`endif
     begin
         if (write_en)
             data[write_addr] <= write_data;
@@ -160,6 +164,11 @@

     initial
     begin
+`ifdef SIMULATION
+        for (int i = 0; i < SIZE; i++)
+            data[i] = '0;
+`endif
+
         if ($test$plusargs("dumpmems") != 0)
             $display("sram2r1w %d %d", DATA_WIDTH, SIZE);
     end

from nyuziprocessor.

Yeah, a bit hacky, but I'm not sure of another way to do this cleanly now. Pushed another patch.

I didn't add the SIMULATION guards in this patch. Did you need that because you are inferring the SRAM for the Xilinx part in that block? I would have expected the last block to not infer SRAMs properly (with an area and clock speed hit), but perhaps this works okay on Xilinx. It definitely doesn't on Altera. I think it might be preferable to have a VENDOR_XILINX block and explicitly instantiate the block RAM, like how it is done in VENDOR_ALTERA, to avoid any issues.

from nyuziprocessor.

Problem solved with 77a50a8, thanks for the time!

Yes, currently the SRAM in my design is inferred from this block because it just works... Thanks for the advice. I will make a VENDOR_XILINX block and submit a pull request after finished.

from nyuziprocessor.