| *** tpb has joined #litex | 00:00 | |
| *** lf has quit IRC | 00:01 | |
| *** lf has joined #litex | 00:01 | |
| 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:02 |
| somlo | I'm done for today ($DAYJOB wearing me out :) ) but hopefully I can make some time to dig into it tomorrow | 00:03 |
| *** gregdavill has joined #litex | 00:05 | |
| *** Degi has quit IRC | 01:51 | |
| *** Degi has joined #litex | 01:53 | |
| *** proteusguy has quit IRC | 02:04 | |
| *** jaseg has quit IRC | 02:13 | |
| *** jaseg has joined #litex | 02:15 | |
| 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:53 |
| 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) | 02:57 |
| *** SwimmingCode has joined #litex | 03:12 | |
| *** gregdavill has quit IRC | 03:54 | |
| benh | _florent_: the user I mentioned with issues on genesys reported that litex with vexriscv on genesys also fails the memory test | 04:17 |
| *** _franck_5 has joined #litex | 05:07 | |
| *** _franck_ has quit IRC | 05:10 | |
| *** _franck_5 is now known as _franck_ | 05:10 | |
| *** FFY00 has quit IRC | 05:47 | |
| *** st-gourichon-fid has joined #litex | 05:57 | |
| *** st-gourichon-fid has quit IRC | 06:16 | |
| *** SwimmingCode has quit IRC | 06:18 | |
| _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:24 |
| _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:28 |
| benh | _florent_: i asked him to file an issue | 06:29 |
| _florent_ | benh: ok thanks | 06:29 |
| _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:45 |
| _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:47 |
| *** SwimmingCode has joined #litex | 06:48 | |
| 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:49 |
| 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:50 |
| 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:51 |
| _florent_ | benh: BTW, #580 is also interesting to speed up simulation with Microwatt + GHDL with litex_sim | 06:52 |
| _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:55 |
| 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:57 |
| 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:58 |
| SwimmingCode | mucking down below in the codebase, I convinced it to generate a instanced name for the uart SoC.submodule | 06:59 |
| _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:00 |
| 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:01 |
| 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:02 |
| _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:03 |
| _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:04 |
| 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:05 |
| SwimmingCode | but if I want to build a system that interfaces through standard file descriptors, they'll be treated the same | 07:06 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| _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:13 |
| SwimmingCode | well, I can confirm that at least for `add_uart` it doesn't. | 07:14 |
| _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:17 |
| _florent_ | in the future, we could allow add_method to support multiple instances, but for now it's not the case | 07:18 |
| 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:23 |
| SwimmingCode | well, thanks for at least pointing me in a direction | 07:24 |
| _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:27 |
| SwimmingCode | does migen/litex have the ability to group instances of a peripheral or is it just based on the order of declaration? | 07:32 |
| _florent_ | You could create a submodule with multiple instances, but each instances would still have its own CSRs | 07:35 |
| *** kgugala_ has joined #litex | 07:56 | |
| *** kgugala__ has joined #litex | 07:59 | |
| *** kgugala has quit IRC | 08:00 | |
| *** kgugala_ has quit IRC | 08:01 | |
| *** kgugala has joined #litex | 08:08 | |
| *** kgugala__ has quit IRC | 08:08 | |
| *** kgugala_ has joined #litex | 08:10 | |
| *** kgugala has quit IRC | 08:14 | |
| *** indy has joined #litex | 08:49 | |
| *** st-gourichon-fid has joined #litex | 08:57 | |
| *** gregdavill has joined #litex | 09:21 | |
| somlo | _florent_: I have to get in the habit of checking for shifting CSRs every time something seems to "break" :) | 09:39 |
| somlo | or maybe work on a building DTB into the bios automatically :) | 09:40 |
| *** proteusguy has joined #litex | 09:52 | |
| *** _whitelogger has quit IRC | 10:21 | |
| *** _whitelogger has joined #litex | 10:23 | |
| *** scanakci has quit IRC | 11:05 | |
| *** FFY00 has joined #litex | 12:16 | |
| *** trabucayre has joined #litex | 12:51 | |
| 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:05 |
| zyp | you could try serv if small and slow is suitable for your needs | 13:09 |
| 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:10 |
| 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:12 |
| * st-gourichon-fid browses http://fpga-guru.com/files/supercn.pdf | 13:13 | |
| st-gourichon-fid | It might be enough. | 13:20 |
| * st-gourichon-fid watches https://diode.zone/videos/watch/0230a518-e207-4cf6-b5e2-69cc09411013 | 13:20 | |
| *** gregdavill has quit IRC | 13:38 | |
| 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:51 |
| *** kgugala has joined #litex | 13:53 | |
| *** kgugala_ has quit IRC | 13:55 | |
| 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 | 13:56 |
| *** kgugala_ has joined #litex | 14:02 | |
| st-gourichon-fid | zyp, even when writing one byte, say, to drive a UARTbone? | 14:03 |
| zyp | yeah? | 14:04 |
| zyp | well, idk | 14:04 |
| 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:05 |
| 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 |
| *** kgugala has quit IRC | 14:06 | |
| zyp | and the difference in memtest speed is on the order of 40x | 14:06 |
| zyp | but then again the rocket is rv64 | 14:07 |
| *** FFY00 has quit IRC | 14:21 | |
| *** atommann6 has joined #litex | 15:15 | |
| atommann6 | Hi, I have a quick question: Does KC705 supports booting from a SDCard? I want to give it a try. | 15:16 |
| *** atommann6 has quit IRC | 15:26 | |
| *** FFY00 has joined #litex | 15:45 | |
| *** FFY00 has quit IRC | 15:46 | |
| *** FFY00 has joined #litex | 15:47 | |
| *** FFY00 has quit IRC | 15:48 | |
| _florent_ | atommann6: (if you read the logs) yes, it has been added and tested | 15:49 |
| *** FFY00 has joined #litex | 15:50 | |
| *** atommann91 has joined #litex | 15:58 | |
| atommann91 | _florent_ Thank you. I see your message in the log. My Internet connection is not stable. | 15:59 |
| atommann91 | I' thinking if I use a Wi-Fi enabled SDCard, that will be convenient to update the files. | 16:05 |
| *** atommann91 has quit IRC | 16:11 | |
| 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 | 16:42 |
| *** FFY00 has quit IRC | 16:44 | |
| *** FFY00 has joined #litex | 16:45 | |
| *** Skip has joined #litex | 16:59 | |
| *** scanakci has joined #litex | 17:07 | |
| *** daddesio has quit IRC | 17:15 | |
| *** zyp has quit IRC | 17:15 | |
| *** zyp has joined #litex | 17:18 | |
| *** Degi has quit IRC | 17:18 | |
| *** daddesio has joined #litex | 17:18 | |
| *** Degi has joined #litex | 17:25 | |
| *** zyp has quit IRC | 17:26 | |
| *** kgugala_ has quit IRC | 17:26 | |
| *** jordigw has quit IRC | 17:26 | |
| *** acathla has quit IRC | 17:26 | |
| *** somlo has quit IRC | 17:26 | |
| *** zyp has joined #litex | 17:29 | |
| *** kgugala_ has joined #litex | 17:29 | |
| *** jordigw has joined #litex | 17:29 | |
| *** acathla has joined #litex | 17:29 | |
| *** somlo has joined #litex | 17:29 | |
| scanakci | _florent_: sure. Does an email work for you? | 17:42 |
| st-gourichon-fid | zyp thanks for your reply about SERV and byte-size writes. We will probably try. | 18:10 |
| *** tcal has joined #litex | 18:20 | |
| *** kgugala has joined #litex | 18:44 | |
| *** kgugala_ has quit IRC | 18:46 | |
| *** kgugala has quit IRC | 18:56 | |
| *** kgugala has joined #litex | 18:56 | |
| *** Skip has quit IRC | 19:01 | |
| _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:09 |
| _florent_ | scanakci: yes sure | 19:11 |
| *** sajattack[m] has quit IRC | 19:45 | |
| *** disasm[m] has quit IRC | 19:45 | |
| *** nrossi has quit IRC | 19:45 | |
| *** disasm[m] has joined #litex | 19:47 | |
| *** nrossi has joined #litex | 19:47 | |
| *** sajattack[m] has joined #litex | 19:50 | |
| *** tcal has quit IRC | 20:02 | |
| *** tcal has joined #litex | 20:16 | |
| somlo | _florent_: hangs for me on trellisboard the same way as on nexys4ddr -- maybe it's a 32-vs-64-bit thing... | 20:24 |
| tcal | ...also, are there any examples of accessing the Litex timer (or other performance information) from the user side in Zephyr? | 20:35 |
| somlo | _florent_: doesn't seem to be a 32-vs-64-bit thing, at least not on nexys4ddr | 20:42 |
| _florent_ | somlo: ok thanks, there are still some changes i want to do, once done i'll do more tests on various boards/configurations | 20:47 |
| 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 :) | 21:08 |
| *** st-gourichon-fid has quit IRC | 21:09 | |
| *** Skip has joined #litex | 21:26 | |
| *** CarlFK has quit IRC | 22:04 | |
| *** Skip has quit IRC | 22:11 | |
| *** CarlFK has joined #litex | 22:16 | |
| *** gregdavill has joined #litex | 22:22 | |
| *** gregdavill has quit IRC | 22:36 | |
| *** tcal is now known as tcal-x | 23:06 | |
| *** tcal-x is now known as tcal | 23:08 | |
| *** gregdavill has joined #litex | 23:39 | |
| *** kgugala has quit IRC | 23:41 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!