As described in a previous blog post on playing with the ECP5 under Linux, I’ve ported a IoT and networking proven concept to the Versa ECP5G developer kit from Lattice. As we don’t want to use up the entire RAM for program code or data that is rarely used, another attempt was made on this platform to recreate the SPI cache trick implemented on Xilinx Spartan[3,6] hardware (Virtual ROM on small FPGAs).
The first blind run without reading the docs threw me an error: the SPI MCLK dedicated pin can not be used in “user mode”, i.e. after the FPGA has booted. Well, not as user pin, that is. However, the ECP5 has a specific primitive called USRMCLK which obviously allows to mux in a user defined clock to the MCLK pin. However, this requires you to turn off the MASTER_SPI_PORT option in the SYSCONFIG line of your preference *.lpf:
SYSCONFIG SLAVE_SPI_PORT=DISABLE CONFIG_MODE=JTAG CONFIG_SECURE=OFF TRANSFR=OFF MASTER_SPI_PORT=DISABLE SLAVE_PARALLEL_PORT=DISABLE MCCLK_FREQ=38.8 BACKGROUND_RECONFIG=OFF ;
The other SPI pins (MISO/MOSI/CS) again are accessed as normal user pins specified in the LPF. The SPI clock from the custom SPI IP core (there’s no hard IP as in the MachXO* platforms) is silently routed through the USRMCLK primitive to the MCLK pin after the boot process has finished. The USRMCLK also requires a tristate input signal (‘1’ = SPI clock not active). If you are tempted to use this as a clock enable: Don’t. Just feed the gated SPI clock to the usrmclki pin of the USRMCLK primitive and use the /CS signal of the SPI core for the usrmclkts pin.
The disadvantage of this solution: When MASTER_SPI_PORT is disabled, background programming of the SPI flash through the Diamond Programmer will no longer work. Every time you update, you will have to load another bit file with enabled MSPI before you can update the flash. Or alternatively, mess with the boot mode so that you have a default configuration allowing background programming.
On the other hand, we can now update the flash “in system” using a simple UART boot loader so we don’t have to wait for the somewhat painfully slow Programmer to finish.
Program layout
Using the linker script has already been described in (Virtual ROM on small FPGAs). Using this technique again, we relocate all seldom used programm code such as initialization code into the external program memory. We then end up with the boot ROM code in a pure HDL file (RAM initialization bit vectors) and a binary image containing the program/data overlay code. This image is created by a simple objcopy call from the Firmware Makefile:
zpu-elf-objcopy \ -j .ext.text \ -j .ext.rodata \ -O binary main.elf flashdata.bin
This is assembled using the Deployment Tool of the Diamond Programmer, found in the Utilities menu. This tool creates an intel hex file (*.mcs) from the BIT file and an attached flashdata.bin that you can select under the “User Data Files” tap in the Advanced SPI flash creation wizard. Finally, this MCS file can be burned into the SPI flash using the boot loader command:
# bl > Waiting for data..
Then simply upload the mcs file to the target inside your terminal program. Then you can hit the PROG button (not the global reset) to load the new image. Note that there are no safety checks at this moment, an illegal image will not boot and you will have to use the Programmer again.
SPI flash filesystems
A nice way to store files (such as default settings) on the target is by using the OpenSource spiffs tools. It may not fit into the standard configuration though, the library itself is roughly 36k in size. You could try to put parts of it into “overlay”, but it is probably safer to keep it in L1 memory and increase that by another power of two.
This is the repo we use:
https://github.com/pellepl/spiffs.git