this might show my lack of verilog knowledge, but still. In the example https://github.com/lawrie/ulx3s_cpm_z80 in the file Microcomputer.v I find this little snippet:
// =============================================================== // System Clock generation // =============================================================== wire clk125, clk; pll pll_i ( .clkin(clk25_mhz), .clkout0(clk125), .clkout1(clk) );
But no further definition in any file related to this project. Is this some kind of built in primitive for verilog? (I couldn't find a description in Lattice ecp5 documents, so I don't think it comes from there). How is one supposed to figure out what 'clk125' and 'clk' are? (ok, I might guess that clk125 is 125 MHz, but that is just a guess).
I've now got the cache to work reliably for the 99K system:
NextPNR reports an Fmax of ~65MHz, but this seems wrong: I've tested with the cache/sdram running at 90MHz and 130MHz (CPU clocked at 25MHz) and both work just fine. I've not drilled down to the bottom of this, but probably NextPNR sees a limit on a signal that is stable for more than one clock.
I was stuck for a long time on something that appears to be a Yosys/NextPNR bug. If I'm not mistaken, this does not work:
reg [0:SETS-1] dirty[0:WAYS-1]; dirty[<= dirty[way][set] | wr;][ ]
(appears to always set bit 15 regardless of the value of 'set') and this does work as expected:
reg [SETS-1:0] dirty[0:WAYS-1]; dirty[<= dirty[way][set] | wr;][ ]
(note reversal of bit range).
@daveshah1 The problematic line appears to be:
If I change that to a
posedge the calculated Fmax goes up to ~130MHz. Originally that line was just an assign, but that left occasional data corruption. If I just register sdr_ctr on negedge, Fmax is also calculated to about 130MHz.
Maybe the circuit is helped by the block ram being sequentially accessed and staying in a single row; this may lead to an access time well less than 10ns ??
self.gpio_csn = Const(17)but in top_st7789.v
lcd_clk = wifi_gpio17;