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
    @emard is suggesting SPDIF IN/OUT instead of GPDI - IN
    Goran Mahovlic
    @goran-mahovlic
    @lawrie I am also working on new LS version - I now have everything connected as on LD version and some spare pins - so I will try to connect all gpios
    And I also think on that version that I will go on cheaper and available 100BASE-TX chip
    SDRAM_v3.png
    Goran Mahovlic
    @goran-mahovlic
    I would say that it could be better if on CS campaign for LS we have 12F with 32MB SDRAM and 100BASE Ethernet.
    And for LD we can have 85UM with 1GB DDR3 and 1000BASE Ethernet.
    Martin Roukala (né Peres)
    @mupuf
    Out of curiosity, what are LD and LS standing for?
    Stas
    @stas:mainframe.lv
    [m]
    Does yosys and nextpnr support the SERDES blocks on upcoming board?
    e2kgh
    @e2kgh
    @mupuf : "D" double data rate DRAM, "S" single data rate DRAM?
    Martin Roukala (né Peres)
    @mupuf
    @e2kgh: Ah, SDRAM and DDRAM would indeed make sense!
    Goran Mahovlic
    @goran-mahovlic
    @stas:mainframe.lv yes we can use opensource toolchain for SERDES
    1 reply
    Manor Askenazi
    @manor
    It has to be said — setting up the ESP32 such that it is running (1) an ftp server and (2) a websocket interface, and then (3) using the python REPL to prog() the fpga or even flash() the .bit.gz files interactively over wifi is just fucking magical!
    Manor Askenazi
    @manor
    Is there an example project showing interaction between python code on the ESP32 and the fpga once the programming is completed?
    Goran Mahovlic
    @goran-mahovlic
    emard
    @emard
    just check your board version is it 3.0.x or 3.1.7, small pinout difference had to be done to fit bigger ESP32 WROVER. Most of @lawrie 's retrogaming consoles uses ESP32 interaction with internal SPI interface to load games from SD card to C64 spectrum etc hardware running on FPGA side. FPGA acts as SPI-RAM slave. ESP32 is master to SPI RAM. Protocol is similar to ordinary SPI RAM chips.
    Goran Mahovlic
    @goran-mahovlic
    There are some ULX3S boards available on Mouser...
    aishwarya418112
    @aishwarya418112
    I need a SERDES with a built in ADC and DAC. I am skeptical about 2 boards here. The ULX3S and ECP5 Evaluation board. The former can supposedly be programmed using an ARDUINO IDE. Any suggestions on which might be the best suited one?
    Goran Mahovlic
    @goran-mahovlic
    ULX4M-LS-back.png
    ULX4M-LS-front.png
    @lawrie now on SDRAM version we have all GPIO pins connected, also RUN_PG, GLOBAL_EN, nEXTRST
    7 replies
    I have added resistors to the left side of the board, if those are shorted then we can use GPIO for JTAG
    SD CARD sharing with HAT is removed on this version - will remain on DDR3
    on SDRAM version Ethernet chip is changed to LAN8720A
    Goran Mahovlic
    @goran-mahovlic
    DSI0 and DSI1 are connected to same pins on FPGA as it is hard to get both connected, so SerDes is moved to connector - but I think SDRAM version will be without SerDes
    CAM0 and CAM1 are now routed bit better, also all fixes that are on DDR3 version are now on SDRAM version
    I have left option for 4. psu but it does not need to be placed - if placed it can be used for BANK 7 voltage (camera)
    KiCad logo is also new :)
    Goran Mahovlic
    @goran-mahovlic
    I do not remember if we found some other issues
    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)