@lawrie super! btw is there "elite" for QL? I see here some dome https://www.youtube.com/watch?v=eYoTSGvWf78
I've done a bit more of the QL sound, but I don't know if I have it correct as I can't get any QL emulators to produce sound. uqlx on Linux runs but produces no sound. qemulator on Windows doesn't start for me. They seem the best of the emulators. Older ones for Windows didn't run correctly.
@Dolu1990 has the new SMP version of SaxonSoc Linux running now and I am trying to build it. Only one core fits on his 12F (when using the open source tools). With Diamond it uses a lot less LUTs.
well when sound analysys is already done it's ok to try something, I thought you already applied it. I'd like to try new saxonsoc! For me it only matters that it boots. if we can dig out some simple K&R style C compiler and cross-comple it to work on saxonsoc and there compile hello world in few seconds, that's wow! no need for gcc/clang, they would compile hello.c for hours :). Super for it's multiplatform compatibility for both diamond and trellis can be tested. I often make code for trellis and diamond and in the process many errors appear. Before I did the same for xilinx and altera also, even more bugs revealed
The problem with using an older Unix compiler is that it would need a risc-v backend.
@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
thanks ^^
@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.
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.
@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.
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.
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
The images and bitstream are here - https://github.com/lawrie/saxonsoc-ulx3s-bin/tree/master/Smp
There is no sdcard image at the moment, but all the files are there for you to build your own.
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"
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"
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.
Nice thanks :)
So this test controle the shift of the clock sent to the DRAM ?
(it doesn't use the programable input delay ?)
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
@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.
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
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.
Basicaly, trying to nail down the ressource usage
@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).
@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.
@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).