00:02 <somlo> _florent_: turns out "identifier" doesn't work on 64bit (I think I knew that and was planning to investigate, but I forgot)

00:02 <somlo> so with 6fe4994f booting with Rocket hangs after "Liftoff!"

00:03 <somlo> I'm done for today ($DAYJOB wearing me out :) ) but hopefully I can make some time to dig into it tomorrow

02:53 <scanakci> @_florent_, somlo: After I upgraded my LiteX version to the latest (and LiteDRAM as well), I also get fails in memtest when running BlackParrot on Genesys. I was using a LiteX version older than a month before upgrading to the most recent version (https://github.com/enjoy-digital/litex/commit/c136113a9b71cbcbdf525aaad38acb012f4a12f3). I do not remember which version of LiteDRAM I was using but most probably

02:53 <scanakci> (https://github.com/enjoy-digital/litedram/commit/fe478382e16ff3592e07774580c96bde0dc82da3).

02:53 <tpb> Title: Merge pull request #506 from scanakci/blackparrot_litex · enjoy-digital/litex@c136113 · GitHub (at github.com)

02:53 <tpb> Title: litedram_gen: expose a Bus Slave port instead of a CSR port. · enjoy-digital/litedram@fe47838 · GitHub (at github.com)

02:57 <scanakci> Simulating using an SDRAM module works fine (i.e. memtest pass, and some random memory writes/reads that I perform also works fine) I used this exact command (./litex_sim.py --cpu-type blackparrot --cpu-variant standard --csr-data-width=32 --sdram-module MT41J256M16 --with-sdram)

04:17 <benh> _florent_: the user I mentioned with issues on genesys reported that litex with vexriscv on genesys also fails the memory test

06:24 <_florent_> benh, scanakci: i will do more test on the Genesys2, it you could provide me logs of the initialization, verilog sources and/or bitstream to test, that could help.

06:28 <_florent_> somlo: that's strange the added identifier is preventing your from booting, even if not working, the issue is probably that adding the identifier has moved your CSRs. (the LiteX targets use dynamic CSR allocation, but it's possible to use fixed CSRs in your design if your Linux dts is generated manually).

06:29 <benh> _florent_: i asked him to file an issue

06:29 <_florent_> benh: ok thanks

06:45 <_florent_> somlo: it seems the identifier is also working fine on 64-bit: https://hastebin.com/urijowizeg.js

06:45 <tpb> Title: hastebin (at hastebin.com)

06:45 <_florent_> somlo: it could be related to the recent change we did on CSR/Wishbone DownConverter

06:47 <_florent_> somlo: BTW, with https://github.com/enjoy-digital/litex/pull/580, the compile time with verilator is a lot faster (~5x) which is convenient for simulating Rocket since needs to be compiled with O3 to have decent simulation speed

06:49 <SwimmingCode> Question: if I wanted to go about adding multiple UARTs/SPI/I2C instances, how would this be done within the Lite-X framework?

06:50 <SwimmingCode> As far as I can tell, with the exception of the Timer and perhaps the memory modules, everything assumes it's the only instance of that piece of hardware

06:51 <SwimmingCode> I've made it to the point of getting the migen to instantiate the modules, but then the generated interface code doesn't compile since the main system doesn't know anything about instanced methods

06:51 <_florent_> the identifier is also working fine with Microwatt: https://hastebin.com/iduhahowal.js

06:51 <tpb> Title: hastebin (at hastebin.com)

06:52 <_florent_> benh: BTW, #580 is also interesting to speed up simulation with Microwatt + GHDL with litex_sim

06:55 <_florent_> SwimmingCode: the BIOS indeed handles generally only one instance, but there is no restriction to add several instances to your SoC and handle it with a runtime software

06:55 <_florent_> SwimmingCode: from what i understand, you are not able to generate the SoC? Could you provide the errors you have?

06:57 <SwimmingCode> It's more that when instancing the peripherals, they should be logically grouped or numbered: i.e. uart0, uart1, uart2 or uart[3]

06:58 <SwimmingCode> if the module's registers can be grouped as well, then the driver can trivially convert from an index vale into the hardware addresses

06:59 <SwimmingCode> mucking down below in the codebase, I convinced it to generate a instanced name for the uart SoC.submodule

07:00 <_florent_> but it also depends the kind of system you want to build

07:00 <SwimmingCode> example error output:

07:00 <SwimmingCode> /home/dciliske/litex/litex/litex/soc/software/libbase/uart.c:48:4: warning: implicit declaration of function 'uart_rxtx_write'; did you mean 'uart0_rxtx_write'? [-Wimplicit-function-declaration]

07:00 <SwimmingCode> 48 | uart_rxtx_write(tx_buf[tx_consume]);

07:01 <SwimmingCode> | ^~~~~~~~~~~~~~~

07:01 <SwimmingCode> | uart0_rxtx_write

07:01 <SwimmingCode> /home/dciliske/litex/litex/litex/soc/software/libbase/uart.c: In function 'uart_write':

07:01 <SwimmingCode> /home/dciliske/litex/litex/litex/soc/software/libbase/uart.c:87:31: error: 'UART_INTERRUPT' undeclared (first use in this function); did you mean 'UART0_INTERRUPT'?

07:01 <SwimmingCode> 87 | irq_setmask(oldmask & ~(1 << UART_INTERRUPT));

07:01 <SwimmingCode> | ^~~~~~~~~~~~~~

07:01 <SwimmingCode> | UART0_INTERRUPT

07:02 <SwimmingCode> I'm fairly green with FPGAs, but my goal is to build a peripheral IC for adding essentially arbitrary numbers of low bandwidth peripherals to a main SoC

07:03 <_florent_> the default LiteX targets and BIOS only provide 1 instance of each peripheral and let user add others instances and handle them with runtime software

07:03 <SwimmingCode> can I inquire as to why they are treated differently?

07:04 <_florent_> because depending the system, you don't necessarily want to handle the multiple peripherals in a similar way

07:04 <benh> _florent_: ah nice, thanks

07:04 <SwimmingCode> hmm... true

07:05 <SwimmingCode> I'm coming at this from the land of rtoses, so perhaps my perspective here is a little different than most

07:05 <_florent_> for example, if you have a SoC with CPU + ROM + RAM + 2 UARTs, only one of these UART will be used for the console

07:05 <SwimmingCode> sure

07:06 <SwimmingCode> but if I want to build a system that interfaces through standard file descriptors, they'll be treated the same

07:08 <SwimmingCode> even if I'm *not* there's good odds that I'll want some sort of read8/write8/readn/writen/etc.

07:08 <SwimmingCode> and this same basic procedure will be repeated multiple times

07:09 <SwimmingCode> :/ sorry, I didn't mean to be complaining

07:09 <_florent_> SwimmingCode: but i see your points, just that LiteX keeps things simple in the default targets/BIOS

07:10 <SwimmingCode> so, question then: how am I expected to build out my more complex system?

07:10 <SwimmingCode> do I add a Target to litex-boards?

07:11 <SwimmingCode> or do I extract the guts of SoC and SoC-core and fork?

07:11 <SwimmingCode> or something else?

07:11 <_florent_> you can start from a target in litex-board

07:11 <SwimmingCode> ok, that's where I'm at now

07:13 <_florent_> and you can add your peripherals to the SoC, but not sure the add_ methods of LiteXSoC will allow you to easily add multiple instances of the same peripheral

07:14 <SwimmingCode> well, I can confirm that at least for `add_uart` it doesn't.

07:17 <_florent_> currently, you'll have to copy the code from add_uart: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L985-L1000

07:17 <tpb> Title: litex/soc.py at master · enjoy-digital/litex · GitHub (at github.com)

07:17 <_florent_> and rename your uart to uart1 , 2, 3 for example

07:18 <_florent_> in the future, we could allow add_method to support multiple instances, but for now it's not the case

07:23 <SwimmingCode> yeah, that's about where I was headed, I just know what it's like to write the software to handle this and it's less than ideal

07:24 <SwimmingCode> well, thanks for at least pointing me in a direction

07:27 <_florent_> SwimmingCode: i would be happy to see if we can improve this if this does not break things for previous designs, enabling multiple instances with add_uart would not be too complicated, you would still have uart0, uart1, uart2, etc.. submodules

07:32 <SwimmingCode> does migen/litex have the ability to group instances of a peripheral or is it just based on the order of declaration?

07:35 <_florent_> You could create a submodule with multiple instances, but each instances would still have its own CSRs

09:39 <somlo> _florent_: I have to get in the habit of checking for shifting CSRs every time something seems to "break" :)

09:40 <somlo> or maybe work on a building DTB into the bios automatically :)

13:05 <st-gourichon-fid> Hi all! Here using LiteX, design similar to FOMU, with an external more powerful CPU. FPGA becomes dedicated to I/O and real-time tasks. FOMU's VexRISCV softcore is FPGA-friendly, fully OSS workflow, yet still big. 32bit CPU not needed for such an I/O chip. OpenCores lists smaller CPU softcores. Would be fun to use e.g. A-Z80 which seems faithful to the battle-tested Z80, which I happen to know well. Also, we only

13:05 <st-gourichon-fid> use Linux here, and so far only FLOSS. Any recommandation for a CPU that would play well with LiteX inside an ICE40?

13:09 <zyp> you could try serv if small and slow is suitable for your needs

13:10 <st-gourichon-fid> https://www.librecores.org/olofk/serv ?

13:10 <tpb> Title: SERV - the SErial RISC-V CPU @ LibreCores: SERV - The SErial RISC-V CPU (at www.librecores.org)

13:10 <zyp> yes, it's already supported by litex

13:12 <st-gourichon-fid> bit-serial CPU... that reminds me of the Saturn CPU of the HP-48. 64bit registers, 4bit hardware bus. Kind of intermediate.

13:20 <st-gourichon-fid> It might be enough.

13:51 <st-gourichon-fid> Okay, the TinyFPGA Bx with its ICE40 has a Core Score of 16, which means it can host 16 RISC-V SERV processors. Continuing video for information about speed. Thanks zyp for the hint.

13:56 <st-gourichon-fid> No real hint about speed, but since SERV can power an I/O chip providing video interface for IR cameras used by mainstream FLIR company, it may be good enough for an I/O chip like ours.

13:56 <st-gourichon-fid> Including booting the main CPU as we discussed yesterday.

13:56 <zyp> I'd expect it to perform at about 1/32 of a non-serial rv32 implementation

14:03 <st-gourichon-fid> zyp, even when writing one byte, say, to drive a UARTbone?

14:04 <zyp> yeah?

14:04 <zyp> well, idk

14:05 <zyp> why not just test it with a real world usecase? litex already supports it, so if you already have a suitable platform, you just have to pass --cpu-type serv

14:06 <zyp> I ran some tests on a cle-215 a couple of weeks ago, with both rocket and serv: https://paste.jvnv.net/view/WFsom https://paste.jvnv.net/view/LewaN

14:06 <tpb> Title: JVnV Pastebin View paste – Untitled (at paste.jvnv.net)

14:06 <zyp> and the difference in memtest speed is on the order of 40x

14:07 <zyp> but then again the rocket is rv64

15:16 <atommann6> Hi, I have a quick question: Does KC705 supports booting from a SDCard? I want to give it a try.

15:49 <_florent_> atommann6: (if you read the logs) yes, it has been added and tested

15:59 <atommann91> _florent_ Thank you. I see your message in the log. My Internet connection is not stable.

16:05 <atommann91> I' thinking if I use a Wi-Fi enabled SDCard, that will be convenient to update the files.

16:42 <somlo> _florent_: what board are you using with the latest litesdcard changes? With nexys4ddr (and rocket), it hangs for me at "booting from sdcard in sd-mode / booting from boot.json...", with no fall-through to netboot or the bios command line

17:42 <scanakci> _florent_: sure. Does an email work for you?

18:10 <st-gourichon-fid> zyp thanks for your reply about SERV and byte-size writes. We will probably try.

19:09 <_florent_> somlo: i'll continue working on it tomorrow but upstream was working with litex_sim --with-sdcard and on trellisboard with 16MHz clock

19:11 <_florent_> scanakci: yes sure

20:24 <somlo> _florent_: hangs for me on trellisboard the same way as on nexys4ddr -- maybe it's a 32-vs-64-bit thing...

20:35 <tcal> ...also, are there any examples of accessing the Litex timer (or other performance information) from the user side in Zephyr?

20:42 <somlo> _florent_: doesn't seem to be a 32-vs-64-bit thing, at least not on nexys4ddr

20:47 <_florent_> somlo: ok thanks, there are still some changes i want to do, once done i'll do more tests on various boards/configurations

21:08 <somlo> in an unrelated train of thought, i wonder how many fpu-enabled rocket cores I can cram in on a genesys2 board... apparently it's getting delivered tomorrow, so I'll have to find out :)