Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Goran Mahovlic
    @goran-mahovlic
    changed.png
    I have changed resistors to 1mm 2x4 connector - will be easier with that one
    emard
    @emard
    If space allows, middle BTN could be placed some mm lower, it will allow bit more fingerspace to push
    Goran Mahovlic
    @goran-mahovlic
    I think it can be pushed little bit down - will check
    splinedrive
    @splinedrive

    I have done new cpu single cycle rv32i https://twitter.com/splinedrive/status/1577734635307651073

    Should be the base for pipelined version as next

    vivado told me 124MHz on kintex7 with lutram pseudo havard memory. Next days I will try :) 124Mips :)
    Goran Mahovlic
    @goran-mahovlic
    maybe one day we can have this on DDR3 version of ULX4M
    Paul Ruiz
    @pnru_gitlab

    Hi all - after a long pause I am thinking about FPGA projects again. I have not had much hobby time in the interim period, but what time I had went to working with System III Unix and the Sipeed Riscv board ( see here ). That is working now.

    For that I am using the Plan 9 C compilers by Ken Thompson and Rob Pike, the Riscv backend was done by Richard Miller. It compiles both RV32 and RV64 code and the compilers are small enough (~200KB) that they can run native easily. They can be found here: https://gitlab.com/pnru/riscv-kencc
    It is actually a family of compilers, that can also do x86, ARM and M68K (and several more).

    I was looking at ways to run SysIII on the ULX3S as well and came across the RVSoc project, which can be found here: https://www.arch.cs.titech.ac.jp/wk/rvsoc/doku.php
    It is only some 5,000 lines of plain Verilog and Linux ('buildroot') capable - but undoubtedly it will be slow, because I don't think it has a memory cache. The CPU is RV32IMAC with a 32 bit MMU.

    Has anybody tried to get RVSoc running on an ULX3S board?

    I was thinking about adding the cache that I did for Oberon and never got quite working. How has Yosys/NextPNR improved over the past two years in this area (large, dual port block ram usage)?? Pre-pandemic it was 'being worked on' I remember.

    I noticed that Orangecrab is no longer doing nightly builds. Is YosysHQ now the preferred source for those? (I mean https://github.com/YosysHQ/oss-cad-suite-build).

    e2kgh
    @e2kgh
    @pnru_gitlab : yosys got better, the Dual-Port issue, please check the logs, there is a solution to that,
    Yes, I think the YosysHQ is still the best source
    Using Plan9 C-Compilers sound like an interesting approach ...
    The RVSoc, I'm not sure about, as 12 stage multicycle? Did you have a look @splinedrive implementation?
    And SYSIII running on a decent FPGA, sound like fun too :)
    e2kgh
    @e2kgh
    Here is the link to the dual-port issue we encountered:
    Paul Ruiz
    @pnru_gitlab

    @e2kgh: Thanks for the feedback.

    I only started looking around yesterday evening. Yeah, I agree that "12 stage multicycle" doesn't read well. What I find cool is that the CPU is just 1,200 lines and the MMU 800 lines. Plain Verilog code of that simplicity is easy to read. (There seems to be a more traditional 5 stage pipelined cousin, the RVCoreP, but I have not looked at that one).

    My context for this are the CPU's of the early 80's and I think that this CPU may be competitive with a VAX, a M68010 or a Bellmac-32 -- all running at about 10Mhz at the time. However, I've only just read the paper and had a quick glance at the code; maybe I will be disappointed when I look deeper.

    The @splinedrive implementation looks cool too. From the .sv extensions I think it is System Verilog? Does Yosys cover that now? I maybe able to get around not having the atomic instructions, but having the compressed ones is important to me (with these, the generated code is similar in size to the ancient VAX, etc. binaries which gives me more room for compare & contrast). Also, having a paged MMU is needed for my projects.

    Paul Ruiz
    @pnru_gitlab

    I would have to revisit my old Oberon code, but I think my issue was different; maybe the fix gives me another path to try.

    See https://gitlab.com/pnru/ulx3s-misc/-/blob/master/oberon_pnr/cache.v

    I'm using a single clock, single port BRAM for cache. Maybe I went that way because I could not get dual ported working, I don't remember at this remove.

    To compensate I used multiplexers and partial writes to simulate a 16b x 8K port and a 32b x 4K port (https://gitlab.com/pnru/ulx3s-misc/-/blob/master/oberon_pnr/cache.v#L142-165) This never worked, no matter how much I pipelined or tweaked clocks, it would always have one unreliable nibble (4 bits). Always a nibble, although which one varied from attempt to attempt.

    Either I never quite understood what the real timing constraint was, or NextPNR would always route one nibble with impossibly long lines. More likely the first.

    Maybe I should give a simple dual-ported design another go with the current Yosys.

    Paul Ruiz
    @pnru_gitlab

    Looked a bit more at the RVSoC source. It does have a 32b x 1K directly mapped cache, with a 4 word (128 bit) cache line. It is a bit hard to follow, as it was generated and then wrapped to match it to the rest. The way it is implemented requires more BRAM than there is on a ULX3S.

    Running at 100MHz, it is claimed to be about 7 times faster than a 1980 VAX (i.e. a model 11/780), and similar to a 486DX (but unclear at what clock). Buildroot Linux boots in 12 seconds from a ramdisk it is claimed.

    e2kgh
    @e2kgh
    @pnru_gitlab : did you get the RVSoC working? I downloaded it, and it didn't compile on Vivado 2022.1 out of the box ... (tried the arty7 version)
    Paul Ruiz
    @pnru_gitlab

    @e2kgh: Did not try that. I only work with Yosys/ECP5, I do not have the vendor tools installed for any vendor.

    I did spend a lot more time reading the code yesterday. It makes a bit more sense now. The main CPU operates in 8-12 clocks per instruction (mostly 8, more for load/store/atomic etc.; div and mul take >30 clocks and pause the main state engine whilst doing the calc). The MMU is integrated in the main CPU state engine. One could say it is like a Linux-capable picoRV (but not a derivative, of course).

    Also tried to compile the C code for its I/O controller with the Plan 9 tool chain: that worked without issue. The code is slightly larger than with gcc (~5%), both are around 3KB.

    Next weekend I will probably try to run a "hello world" in Icarus, I think. Porting to Yosys/ULX3S comes after that.

    Paul Ruiz
    @pnru_gitlab

    Actually, @michaelengel 's port of xv6 to RV32 would be a nice first target for this SoC:

    Quote from 9 Oct 2020 on this Gitter:
    @lawrie I ported xv6 to RV32 - https://github.com/michaelengel/xv6-rv32

    I have already ported regular xv6 to the Plan9 tool chain, so repeating that for the 32 bit version should not be a lot of work. The cool bit is that stock xv6 expects a virtio disk, and this SoC presents a virtio disk.

    e2kgh
    @e2kgh
    @pnru_gitlab : I see in your gitlab, that you also made a 68k design with the fx68k core. Did you ever tried the tg68k core? That's the one we had problems with, using the dual-ported RAM ...
    Paul Ruiz
    @pnru_gitlab
    @e2kgh: no, sorry, did not try that. Here too I have forgotten the details, maybe lawrie or emard remembers better. I think the considerations were:
    • tg68k is in VHDL and Yosys did not support VHDL at that time.
    • tg68k is not cycle accurate and a cycle accurate version seemed easier when doing retro computers
    • the fx68k worked on first try and we did not look further; at the original speed, it does not need a cache.
    • I think the main goal was the Sinclair QL, for which machine I have a soft spot. I remember spending a lot of time going down the rabbit hole for its micro-disks and sound system that summer.
      If I remember well, lawrie did a 1984 Macintosh next. I'm not currently working on M68K stuff, although an FPGA version of the Blit terminal remains on my long term want-to-do list.
    Michael Engel
    @michaelengel
    Read my name in the log sent by email :). I'm happy to help with porting xv6-rv32. In addition, our RISC-V Oberon port might also be interesting? https://github.com/solbjorg/oberon-riscv
    Michael Engel
    @michaelengel
    It seems that rvsoc uses a separate RISC-V core to implement virtio, however, disk (SD?) read/write does not seem to be supported in the core's firmware (rvsoc_src_ver053/ucimage/main.c:138)
    But it's definitely a nice idea :)
    Michael Engel
    @michaelengel
    Ah, stop, I misread the code. In fact, it uses a RAM disk at address 0x90000000 (main.c:367)
    emard
    @emard
    @pnru_gitlab HI great to hear again, yosys is constantly improving, vhdl compiling is now quite useful so I think for first attempt we can just recompile old code and see if something got fixed by itself. All your mentioned retro computing projects are very interesting. Lawrie made a working QL implementation and supported microdrive over ESP32 SD card. I think it's read-only no writing to microdrive. Most software runs somehow, there are issues on some, probable cause can be CPU not cycle-exact and I/O chips implementation also not exact
    Paul Ruiz
    @pnru_gitlab

    Ah, stop, I misread the code. In fact, it uses a RAM disk at address 0x90000000 (main.c:367)

    @michaelengel: yes, it uses ram disk, which is okay for test setup. I was thinking that a simple SPI interface to the SD card could be added (in the style of Oberon's RISC5 spi controller: https://gitlab.com/pnru/ulx3s-misc/-/blob/master/oberon_pnr/SPI.v) and that main.c could be modified to use that interface instead of a ram disk :^)

    With that out of the way, the full 32MB sdram on the ULX3S board can be allocated to Linux.

    Michael Engel
    @michaelengel
    Btw., implementing a real SD card driver for xv6 in addition to the existing ramdisk (or virtio) driver is more overhead than I thought since xv6 is "cheating" - it hardwires all block device accesses and doesn't implement a real block device interface (though there's a simple version of a device switch for character devices). I'm wondering if adding a real block dev interface for xv6 (and then mount functionality and perhaps different file systems) is worth the effort...
    Paul Ruiz
    @pnru_gitlab
    I have Icarus running the simulation (top.v). It will probably need all night to reach the login prompt, bu so far it seems to work as advertised. The simulation does not simulate ddr2/3 and a cache, but uses a very large array.
    Paul Ruiz
    @pnru_gitlab

    I'm wondering if adding a real block dev interface for xv6 (and then mount functionality and perhaps different file systems) is worth the effort...

    @michaelengel: I already have 64-bit SysIII Unix running on the D1 board. Kernel is ~60KB, and it works with the SD card for disk. Richard's compiler runs native, and it can self-compile. Kernel is about 7,000 lines, excluding the SD Card driver which is ~1,000 lines (from the Allwinner SDK).

    Michael Engel
    @michaelengel
    @pnru_gitlab Ah, nice! I was thinking about a port of LiteBSD (https://github.com/sergev/LiteBSD) but didn't find enough time so far... this is 4.4BSD-based and currently runs on the PIC32 MIPS SoCs.
    Paul Ruiz
    @pnru_gitlab
    Icarus was still chugging away this morning, about halfway through the boot. I've aborted it, I'm already satisfied that the Verilog source package appears to work. If anybody can replicate the original work on an Artix board, I'd be glad to hear. Otherwise, porting to ULX3S is next.
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I have not worked on 68k projects for the Ulx3s for some time now. I did get the QL working but never did microdrive writing. The sound support was limited.
    The Mac Plus version worked, but I did not implement floppy disk writing and the keyboard implementation didn't quite work.
    There are quite a few other 68k computers that I might get round to trying sometime.
    Lawrie Griffiths
    @lawrie
    The risc-v lcc compiler that we got going for SaxonSoc Linux seemed to have some problems with later builds of SaxonSoc, and I should probably look at that sometime. It may be due to changes to the linux kernel API.
    @Dolu1990 has a new Risc-V implementation now, NaxRiscv, and that supports out of order execution and both rv32 and rv64. I would like to try that on Ulx3s or Ulx4m sometime.
    The stuff you are doing with Sys III Unix and RVSoc and I will give that a go when you have it working on the Ulx3s.
    Goran Mahovlic
    @goran-mahovlic
    I have opened repository for PXIe board, if someone have some idea what to add please open issue - I will probably send v01 into production next week
    beta_v2.png
    Paul Ruiz
    @pnru_gitlab

    @lawrie @michaelengel @emard @e2kgh:

    I have a basic build of RVSoC working on the ULX3S. I have not done much testing yet, but the SoC runs code and the SDRAM+Cache appears to be working:
    https://gitlab.com/r1809/rvsoc

    • As e2kgh already observed, the original code does not compile out of the box; it seems that the simulation is ready to run, but the synthesis top file is slightly out of sync with its modules. Minor stuff though.
    • The new cache design is basically the same as for Oberon, although the ram & cpu clocks are now linked in a 2:1 ratio.
    • The original RVSoC code seems to have had two inferred latches that NextPNR did not like.
    • I am not sure the compressed code extension is working correctly, have to test more.
    • It now runs at 25/50MHz, just to be very safe. It should run at 40/80MHz in its current state, and I think 50/100MHz is within reach with some optimisation.
    splinedrive
    @splinedrive
    pipelining is not a crime, I am really excited :) https://twitter.com/splinedrive/status/1581576464780386304
    Ties Stuij
    @stuij
    re dual port: yea, I tried to synthesize the bram module here (very top) and it does convert into DP16KD now :)
    https://github.com/jamesbowman/swapforth/blob/master/j1b/verilog/xilinx-top.v
    Ties Stuij
    @stuij
    I just did ULX3S support for the J1b Forth CPU btw:
    https://github.com/stuij/swapforth/tree/master/j1b/ulx3s
    Stas
    @stas:mainframe.lv
    [m]
    sweet! No more excuses to unsolder buffer chips on my Colorlight anymore :D