Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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.
    emard
    @emard
    And for practical side of about some simple i2c (RTC) and SPI (display) things on saxonsoc, what are our other options - can micropython do it to properly intialize i2c and spi bus at saxonsoc. Micropython has "viper" options on some platforms that compiles integer-only python code to something that runs at near C speed
    Paul Ruiz
    @pnru_gitlab
    Wikipedia has some practical overview information:
    https://en.wikipedia.org/wiki/Executable_and_Linkable_Format
    Also this tool may provide a place to start when writing an a.out to ELF converter:
    http://elfdump.sourceforge.net
    And 42 is of course the Answer to the Ultimate Question of Life, the Universe, and Everything
    emard
    @emard
    Yes, yes making exe file size from 45 to 42 would require infinite amount of time and energy, something like accelerating from 99% speed of light to 100% :)
    Paul Ruiz
    @pnru_gitlab
    @emard if your goal is to provide an easy environment for working with i2c and SPI devices, why not add Lua to your pre-built Linux/Saxon system? Conceivably, you could also run Lua on bare metal nano Risc-V.
    emard
    @emard
    It is also good idea!
    Paul Ruiz
    @pnru_gitlab

    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?

    The Cortex was a traditional home computer with Basic in its day. Running Unix on it was my project some 6-7 years ago. It was a long journey: porting a C compiler and tool chain, building simple kernels with a linked in user program (downloaded to the H/W via something similar to S-records), etc. When the time for disk access came, I used a tool to create & manage disk images.

    For the original Unix, the file system was almost the first thing that was built, after the assembler (that is how a.out got its name: assembler output). An empty disk image was written by a custom format program. Files were then loaded from paper tape. Some 1969/1970 Unix code can be found here:
    https://www.tuhs.org/cgi-bin/utree.pl
    In its first incarnations it was all assembler, but many of the core ideas were already there. Some more background is here:
    https://www.bell-labs.com/usr/dmr/www/hist.html

    emard
    @emard
    Ahaaaa so unix was not all the time available on cortex hardware. Still I'd wanted to know how did you initially start with populated filesystem. Normally e.g. if we have linux on riscv, we can mount the same partition on x86 PC, copy files and and it will work on riscv, but how was this done on cortex?
    emard
    @emard
    So If I understood, you have a tool that from a directory creates disk image, but there's currently no support to actually mount cortex fs on linux for example. linux has some possibility to write a user-space fs driver like "fuse" but I ghess thats difficult and fragile
    Paul Ruiz
    @pnru_gitlab

    You can follow my journey here, in 315 commits:
    https://www.jslite.net/cgi-bin/9995/timeline?n=400&y=all&v=0

    I use a program ("ufs") which creates a disk image from scratch and then adds files to it. The source code is here:
    https://www.jslite.net/cgi-bin/9995/dir?ci=84b2a75947eb76db&name=fsutil

    Even on the mini Cortex hardware, the CF Card uses FAT formatting and has an image file on it. I make sure the image is contiguous and the boot loader lets the Unix disk driver know in which sector the image starts. This way I can simply copy disk images to the CF card without needing to use special tools.

    Actually, the card also has disk images for other OS's as well - MDEX and NOS, which are somewhat similar to CP/M and MS-DOS 3 respectively.