user@machine:~/blink$ sudo ~/Downloads/fujprog/fujprog-v48-linux-x64 -j flash blink_12f.bit ULX2S / ULX3S JTAG programmer v4.8 (git 96ebb45 built Oct 7 2020 20:34:11) Copyright (C) Marko Zec, EMARD, gojimmypi, kost and contributors Using USB cable: ULX3S FPGA 12K v3.0.8 Erasing sectors, please wait. Programming: 100% Completed in 41.93 seconds. user@machine:~/blink$ sudo ~/Downloads/fujprog/fujprog-v46-linux-x64 -j flash blink_12f.bit ULX2S / ULX3S JTAG programmer v4.6 (git 0a4cc36 built Jul 22 2020 20:50:14) Copyright (C) Marko Zec, EMARD, gojimmypi, kost and contributors Using USB cable: ULX3S FPGA 12K v3.0.8 Erasing sectors, please wait. Programming: 100% Completed in 45.14 seconds.
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 ??