@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.
emard
@emard
assign sd_d = R_prog_release[C_prog_release_timeout] ? 4'hz : { 3'b101, S_prog_out[0] }; // does NOT work
assign sd_d = R_prog_release[C_prog_release_timeout] == 0 ? { 3'b101, S_prog_out[0] } : 4'hz; // works
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 :-(
After changing other unrelated lines this yosys bug disappears and now works what before didnt work
Radu Stoichita
@radu_stoichita_gitlab
@splinedrive i come from Diamond and i used it for a few days but it really lacks ooen source tooling for building SOCs. Their IP cores and LatticeMico SOC doesn't fit with the board
splinedrive
@splinedrive
Which ulx3s you have?
Radu Stoichita
@radu_stoichita_gitlab
Euh... The 12F version from Mouser
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
emard
@emard
For practically all projects 12F is enough and it even accepts slightly faster clocks than 85F because of less routing, also projects compiles faster for 12F than 85F
RAM had to be 32MB for cost about 3$. There's pin compatible 64MB but for around 12$
sylefeb
@sylefeb
@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?
Perhaps @emard knows of a better description of all this.
Lawrie Griffiths
@lawrie
The OSD and loader is used by many Ulx3s projects including the Apple II, C64, ZX Spectrum, Mac Plus, QL, TI-99/4A, Amiga (OSD only), Vic 20, NES, SNES, Sega Master System, Orao, etc.
I don't think there is a Risc-V implementation on the Ulx3s that uses the OSD yet.
sylefeb
@sylefeb
@lawrie thanks for the links!
sylefeb
@sylefeb
(uart_echo is fixed in 'wip' branch)
Lawrie Griffiths
@lawrie
@sylefeb Yes, uart_echo now works for me
emard
@emard
@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
Radu Stoichita
@radu_stoichita_gitlab
Is it possible to run Zephyr on SaxonSoc instead of LiteX?
Lawrie Griffiths
@lawrie
Yes, I used to run Zephyr on SaxonSoc on a Blackice Mx ice40 board.
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
@radu_stoichita_gitlab
@lawrie thanks so much i will check this for sure. I am not really getting used to Migen on Python, the documentation is very light and it seems not maintained anymore
Lawrie Griffiths
@lawrie
@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.
Radu Stoichita
@radu_stoichita_gitlab
@lawrie very insteresting thoughts. I am a software developer in my daily life and it is true that SpinalHDL documentation is much easier for me to understand. What kind of features are you missing information for in SaxonSoc? Is there any better alternative?
Lawrie Griffiths
@lawrie
The issue with SaxonSoc is that it is fast-moving technology and very few people are working on it. Zephyr was implemented on an early version of it, but more recently all the emphasis has been on Linux.
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.
Lawrie Griffiths
@lawrie
There are lots of other choices for Risc-V like picorv32, ultraembedded/riscv, the Silice Risc-V implementations, and minerva and lambda-soc in nmigen.
But I believe VexRiscv and SaxonSoc is the best. It just needs more people working on it, particularly the non-Linux versions.