Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Dolu1990
    @Dolu1990
    Notes, i havn't updated the opensource toolchain since a while, i have to try it
    Lawrie Griffiths
    @lawrie
    @emard buildroot seemed to have made a decision not to support a native compiler, so gcc and clang are not available as packages.
    The problem with using an older Unix compiler is that it would need a risc-v backend.
    emard
    @emard
    @Dolu1990 here's nigthly build for all platforms :) https://github.com/open-tool-forge/fpga-toolchain/releases
    @lawrie I see! OK if something "light" with backend appears, let's watch and take it when available
    Dolu1990
    @Dolu1990
    Hooo i didn't know this exist
    thanks ^^
    emard
    @emard
    There's also fresh openFPGALoader that supports our board too
    Paul Ruiz
    @pnru_gitlab
    @lawrie don't feel obliged to do anything with sound, just because I analyzed the ROM. As said, the QL is a sentimental journey for me and the analysis was its own reward. I've always been intrigued with the English micro-computer scene of the early 80's and how interesting hardware was built from two bits of string and a roll of sticky tape.
    Paul Ruiz
    @pnru_gitlab
    I am also intrigued by ULA's (Uncommitted Logic Arrays) which were - in my view - the FPGA's of the early 1980's. Outside of Texas Instruments in the US and Ferranti in the UK I did not see this concept - not sure why it did not catch on more. For those who are unfamiliar with ULA's, they are essentially chips with a "sea" of NAND gates and no metal layer. The customer specified a custom metal layer to complete the base chip; this was economic for runs of a few thousand units I think.
    Paul Ruiz
    @pnru_gitlab
    @emard, @lawrie: for a RISC_V compiler you could try to cross-compile this one:
    https://github.com/michg/riscv32_lcc
    LCC is only some 20,000 lines of source code (about 3 times the size of the PDP-11 C compiler) and there is a book that explains every line of it.
    emard
    @emard
    Ohoo, yes lcc compiler looks great, allows reasonably modern coding style. We can compile simple hardware examples like i2c RTC clock or SPI LCD displays.
    Lawrie Griffiths
    @lawrie
    I see that one of its targets is @Dolu1990's Murax SoC (as well as picorv32).
    Lawrie Griffiths
    @lawrie
    The new SaxonSoc is now working on a 12F for me. Here are the instructions to build from source - https://github.com/SpinalHDL/SaxonSoc/tree/dev-0.1/bsp/radiona/ulx3s/smp
    There is no sdcard image at the moment, but all the files are there for you to build your own.
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab @Dolu1990 asked these questions about using the SDRAM, which I thought you might know something about from all your recent work on SDRAM drivers:
    I'm thinking about the SDRAM
    currently, the soc is at 50 mhz, and the sdram run at 100 Mhz using DDR io
    but maybe we should quad pump the SDRAM, and doing some bootloader calibration to ajust read delays
    i'm just currently not sure what is the critical path of the SDRAM chip themself
    in other words "why they are specified to X frequancy and not more"
    Dolu1990
    @Dolu1990
    Moaaaar powaaaaaaaa
    emard
    @emard
    oooh yeea :)) if you want to push SDRAM near the edge and give it some heat, on selected designs it can push 133MHz chips to 180-200 MHz, fmax depends on each board. 12F performs better than 85F. Here's memtest https://github.com/emard/ulx3s-misc/tree/master/examples/sdram/memtest_mister shows results on DVI monitor and with BTNs can adjust phase shift dynamically and watch for errors.
    Dolu1990
    @Dolu1990
    <3
    Nice thanks :)
    So this test controle the shift of the clock sent to the DRAM ?
    (it doesn't use the programable input delay ?)
    emard
    @emard
    Yes this has a classic sdram driver that normally needs 90° phase offset to chip hardware, but as fmax is getting higher the actual phase shift which makes it really work moves. PLL is used to provide phase shift. Paul has made a better sdram driver with cool vendor-independent delay solution with a number of NOT gates.Only ns delay per NOT gate remains vendor dependent
    Dolu1990
    @Dolu1990
    ok :D
    Paul Ruiz
    @pnru_gitlab

    @lawrie @Dolu1990 I am not sure I understand the SDRAM questions. In any case, my latest version is here: https://gitlab.com/pnru/cortex/-/blob/master/sdram.v
    In particular note new lines 45-47 - I am not sure why, but this mod generally pushes Fmax up to about 200MHz (it depends a bit on the NextPNR seed).

    I am not sure what you mean by "using DDR io" - does the SDRAM chip on the ULX3S support DDR? Maybe you mean by DDR that it runs at twice the speed of the CPU or that it uses burst size 2?

    I don't know what the critical path in the SDRAM chip is, but I do have a hypothesis. When working with a CAS delay of 3 clocks, the data really arrives after 2 clocks plus 6-7ns (spending on the speed grade). If you clock a grade 6 chip (PC166) faster, a clock cycle will take less than 6ns and the data will only arrive after the third rising clock edge. My guess is that the 6-7ns is related to the speed of the sense amplifiers or something like that.

    Dolu1990
    @Dolu1990

    @pnru_gitlab

    Maybe you mean by DDR that it runs at twice the speed of the CPU or that it uses burst size 2?

    Yes that's it, currently in that soc, i'm using burst size of 2 with DDR io, so the sdram controller itself run at 50 Mhz, but has double data rate (via the DDR io)

    If you clock a grade 6 chip (PC166) faster, a clock cycle will take less than 6ns and the data will only arrive after the third rising clock edge.

    Hooo i see

    hmm
    enoying ^^
    This answer the question
    Dolu1990
    @Dolu1990
    thanks :)
    Lawrie Griffiths
    @lawrie
    I am looking at how many CPUs for the SMP SaxonSoc will fit on various Ulx3s devices. The single CPU version uses 21% of an 85F and fits on a 12F. The 2 CPU version uses 36% of the slices on an 85F and should fit on a 45F. It failed timing at 49.23 but will probably still work. The 4 CPU version took 63% of an 85F, took a long time to route and got a max frequency of 42.72 MHz.
    Dolu1990
    @Dolu1990
    Is somebody aware of a way to get hearchical ressource utilisation report out from yosys/next-pnr for ECP5 ?
    Basicaly, trying to nail down the ressource usage
    David Shah
    @daveshah1
    You can get a hierarchical report with Yosys by passing -noflatten to synth_ecp5
    Dolu1990
    @Dolu1990
    Thanks :D
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab @emard I looked at the lcc risc-v compiler a bit. The compiler generates as output a .s assembler file. The assembler (as) in binutils and ld produce a.out format files. This is now deprecated in Linux and not supported in 64-bit systems. I am not sure if it is supported in the 32-bit buildroot system that SaxonSoc uses. It probably needs configuration options to include it (CONFIG_HAVE_AOUT, CONFIG_BINFMT_AOUT).
    emard
    @emard
    For me, anything that native compiles to exe is good, I don't care for intermediate *.s files. I think also cortex compiler does the same
    Paul Ruiz
    @pnru_gitlab
    @lawrie There are a few routes that you could consider. One is to use the LCC compiler output with the GNU binutils (as, ld, etc.). This would give at least give you a quick way to check. However, probably the binutils are as fat as gcc itself. Your other route is to build an a.out to elf converter. For static binaries this is maybe not too hard a thing to do. Extracting a binary from a.out is very easy and wrapping that in a minimal elf header sounds doable as well. It does require diving into the details of elf, which might be very time consuming.
    Paul Ruiz
    @pnru_gitlab
    @emard The cortex compiler also goes via .s files. If you do cc -v hello.c you can see the individual steps. First it runs the pre-processor (turning .c into .i) and then the c0 pass. This pass essentially converts C source into parse trees. This is followed by the c1 pass, which uses a tile covering algorithm to convert the parse trees into assembler (i.e. generating a .s file). Optionally, there is a c2 pass which does peephole and a few other optimizations. Then it runs the assembler 'as' to generate a relocatable object file (an .o file). As a last step it invokes the linker ld to combine this object file with routines from the C library and generating a static binary (the a.out file).
    By the way, I got the compile time for hello.c down from 14s to 8s now, mainly through better sorting of the C library archive. The linker still takes half of total compilation time.
    emard
    @emard
    8s is super-comfortable! Btw I wonder how did cortex start, before it ever booted they need some filesystem to hold files. Is cortex filesystem mountable by modern linux? How did they made it in early times?
    Lawrie Griffiths
    @lawrie
    I suspect the GNU binutils will drag in a lot of stuff, so I am not too keen on that. a.out format may be supported, so that may still be an option, but Linux will probably not support it for a lot longer. I did consider an a.out to elf converter. I think there is a fairly simple subset of elf.
    emard
    @emard
    When linux drops a.out, some new riscv-friendly cc solution may appear. Most of riscv systems are small and I guess are looking for native compilers
    Paul Ruiz
    @pnru_gitlab
    @lawrie here is a fun post about wrapping an executable in a minimal elf shell: https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
    The middle part of the write up is the most interesting for the problem at hand, I think.
    Paul Ruiz
    @pnru_gitlab
    @emard Or they move to a leaner kernel than standard Linux - maybe uClinux, maybe Plan9, etc.
    emard
    @emard
    @pnru_gitlab ahahhaaa fantastic writeup this about elf stripper! It was thrilled text and I thought that it would make exe that returns 42 also 42 bytes long, but it turned out to have 45 bytes! Almost! Still amazing article :)
    Lawrie Griffiths
    @lawrie
    Yes, very amusing.