@sthornington I've not built from scratch for a while, so no recent experience. However, some 12 months ago I was building from scratch on Catalina and it took some time to get right (at that time the issue was with the boost libraries). In general, it seems to me that the Trellis build for OSX can be troubled from time to time.
The daily builds over at https://github.com/open-tool-forge/fpga-toolchain may be your best source of clues: they will probably be the first to notice something going wrong in the build. Their build scripts may also provide an answer for your issue.
@emard Maybe indeed there is a total failure of sdram, although I would surprised that it would get as far as leds=0x84 in that case. I am running tests with the sdram model that @edbordin found and that has already identified some issues (like my refresh commands being spaced too closely together).
Maybe the HEX interface can track the commands that are sent to the sd card? This way we can check that the sequence prior to leds=0x84 runs as expected or not.
@edbordin Point taken. However, I also have an older ulx3s board with the micron chip. In general, I guess I'd like to write it such that a wide range of chips are covered.
Further tests bring up no other issues, and inspection of the sdram and cache ram contents after a short run show the expected results.
@emard The sdram controller can work alone, but it is designed to read/write 128 (16 bit) word bursts. Not so easy to interface to a host that expects single words. The cache can really only work together with the sdram controller, because it expects signals and data to arrive in precise order (like: "if this signal is asserted, data will be available 2 clocks later", etc.). It could be possible to connect the cache/sdram combo a simple system with a monitor program.
Maybe the least effort is to write a simple RISC5 assembler and put some short test programs in the rom and test that way. Heresy, as in the minds of the Oberoners there is no such thing as RISC5 assembler, it seems. The Oberon system has a UART that is easy to use: write to a register and a character gets send, etc.
I am probably not seeing the forrest for the trees. I think I will leave this for a week and then have a fresh look.
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).