@sylefeb One thing that I notice that you don't have with Silice is reading and writing flash memory. It can be more convenient to load risc-v programs into flash memory rather than having to write raw images to the sd card. Most risc-v implementations include the ability to run code in-place from flash memory (XIP).
Another feature which would be useful is a read-write spi memory slave that worked with @emard's micropython code for an on-screen display (OSD) and for remote ram access. That can be very convenient for loading programs from a formatted SD card. It is used by many of the retro computer implementations on the Ulx3s.
I have above strange issue with yosys
Good evening guys, is there any trick to speed up the yosys/nextpnr synthesis for the SaxonSoc project ? Everytime making a small change it takes a few minutes to complete. Do you iterate often or is there any performance tweak i am missing somewhere. Thanks and have a great day, Radu
Btw, i have notice the whole process uses only one CPU thread :-(
@radu_stoichita_gitlab Vivado has the feature synthesized Out-Of-Context (OOC) but it seems yosys hasn't such feature implemented. More infos under https://forums.xilinx.com/t5/Adaptable-Advantage-Blog/High-Impedance-and-Out-of-Context-OOC-Synthesis/ba-p/664110
You have to check diamond lattice has something similar - it is free. I have no idea, I have only a little bit experience with yosys.http://www.latticesemi.com/en/Products/FPGAandCPLD/ECP5
I wanted the 85F but made a mistake when ordering
Anyway I love thie board
With all the colourful LEDs it's so cute
Just expected a little more RAM onboard like 128MB
But for my lack of skills it is already a masterpiece
RAM had to be 32MB for cost about 3$. There's pin compatible 64MB but for around 12$
@lawrie agreed on spi-flash ; I have a bit banging version to boot my risc-v cores (https://github.com/sylefeb/Silice/blob/wip/projects/fire-v/smoke/mylibc/spiflash.c) and it is very convenient indeed. Doing a hardware version is on my TODO list! (also would like to investigate QSPI ...). Was not aware of @emard loader - sounds great - any recommended doc/example?
@sylefeb I am not sure that between us, @emard and I, have documented the OSD and rom loader very well. There are lots of versions of the code in different projects. This is the spi slave from my Z80 template project - https://github.com/lawrie/ulx3s_z80_template/blob/main/src/osd/spirw_slave_v.v
The rest of the code is in that osd directory.
This is a version of the micropython code that reads and writes memory and controls the cpu remotely from the esp32 - https://github.com/lawrie/ulx3s_z80_template/blob/main/esp32/spiram.py
The rest of the esp32 code including osd.py is in that directory.
Here is a youtube video that shows the osd and loader being used - https://www.youtube.com/watch?v=YE7pSuZiN9Y&t=8s
The latest version of the osd look a bit nicer.
This is my TRS 80 Model 1 implementation that has a short description on using the OSD - https://github.com/lawrie/ulx3s_z80_trs80
Perhaps @emard knows of a better description of all this.
This is a good video by @Speccery that shows the OSD used on the TI-99/4A - https://www.youtube.com/watch?v=zdST3wz00KU
I don't think there is a Risc-V implementation on the Ulx3s that uses the OSD yet.
@sylefeb @lawrie OSD loader behaves similar as SPI RAM using 32-bit byte address. FPGA behaves as SPI slave, ESP32 as SPI master. If slave needs to initiate transfer, there is additional IRQ line. Resources at SPI address space are memory mapped, RAM to upload for CPU, reset/halt control, buttons, OSD video chars, floppy disks etc. All is very simple and protocol is not too much standardized so it can be adapted to completely unusual usage. Generally for apple2 c64 vic20 mac trs80 etc we just copy-paste the same thing
But that is on an old version of SaxonSoc, and I have never run it on a Ulx3s board. It shouldn't be too hard to get working.
@radu_stoichita_gitlab I do not use migen, but I have played with nmigen a bit. But I thought LiteX was still actively maintained and documented. But I think there is an issue about whether it needs to be migrated to nmigen. SpinalHDL is well documented and SaxonSoc Linux is pretty well documented, but other uses of SaxonSoc are not currently well supported or documented.
VexRiscv is in most people's opinion the best 32-bit open source Risc-V implementation because of its speed, size and configurability. It is about the only one that supports Linux. It is written in SpinalHDL. If you are using a SoC, there are a few choices such as the older SpinalHDL ones like Murax and Briey, or LiteX. But I believe that SaxonSoc is the best one.
But I believe VexRiscv and SaxonSoc is the best. It just needs more people working on it, particularly the non-Linux versions.