| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** Degi_ <[email protected]> has joined #litex | 02:42 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 02:43 | |
| *** Degi_ is now known as Degi | 02:43 | |
| *** a3f <a3f!~a3f@2001:470:69fc:105::41d> has quit IRC (*.net *.split) | 04:21 | |
| *** yootis <[email protected]> has quit IRC (*.net *.split) | 04:21 | |
| *** _whitelogger <[email protected]> has quit IRC (*.net *.split) | 04:21 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (*.net *.split) | 04:21 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex | 04:22 | |
| *** yootis <[email protected]> has joined #litex | 04:22 | |
| *** _whitelogger <[email protected]> has joined #litex | 04:22 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:911:c9e7:1eb4:69e9:b5f2> has quit IRC (*.net *.split) | 04:27 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:911:4526:1b81:d974:dab2> has joined #litex | 04:27 | |
| *** CarlFK <CarlFK!~carlfk@2001:470:69fc:105::5d8> has quit IRC (*.net *.split) | 04:30 | |
| *** xobs[m] <xobs[m]!~xobs@2001:470:69fc:105::6903> has quit IRC (*.net *.split) | 04:30 | |
| *** LoveMHz <[email protected]> has quit IRC (*.net *.split) | 04:30 | |
| *** guan <[email protected]> has quit IRC (*.net *.split) | 04:30 | |
| *** philpax_ <[email protected]> has quit IRC (*.net *.split) | 04:30 | |
| *** sorear <[email protected]> has quit IRC (*.net *.split) | 04:30 | |
| *** LoveMHz <[email protected]> has joined #litex | 04:30 | |
| *** sorear <[email protected]> has joined #litex | 04:30 | |
| *** guan <[email protected]> has joined #litex | 04:30 | |
| *** philpax_ <[email protected]> has joined #litex | 04:30 | |
| *** a3f <a3f!~a3f@2001:470:69fc:105::41d> has joined #litex | 04:31 | |
| *** xobs[m] <xobs[m]!~xobs@2001:470:69fc:105::6903> has joined #litex | 04:45 | |
| *** CarlFK <CarlFK!~carlfk@2001:470:69fc:105::5d8> has joined #litex | 04:45 | |
| *** Abhishek__ <[email protected]> has joined #litex | 04:49 | |
| *** rektide_ <[email protected]> has joined #litex | 04:52 | |
| *** Abhishek_ <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 04:53 | |
| *** xobs[m] <xobs[m]!~xobs@2001:470:69fc:105::6903> has quit IRC (Ping timeout: 272 seconds) | 04:53 | |
| *** Abhishek__ is now known as Abhishek_ | 04:53 | |
| *** Crofton[m] <Crofton[m]!~croftongn@2001:470:69fc:105::9a7> has quit IRC (Ping timeout: 272 seconds) | 04:53 | |
| *** rektide <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 04:53 | |
| *** Crofton[m] <Crofton[m]!~croftongn@2001:470:69fc:105::9a7> has joined #litex | 05:15 | |
| *** xobs[m] <xobs[m]!~xobs@2001:470:69fc:105::6903> has joined #litex | 05:18 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:5cef:dd29:3504:2580> has joined #litex | 05:28 | |
| *** xenador77 <xenador77!~xenador77@user/xenador77> has quit IRC (Remote host closed the connection) | 06:46 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 240 seconds) | 07:35 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:63ec:2058:c1c1:37b8> has joined #litex | 07:48 | |
| *** xenador77 <xenador77!~xenador77@user/xenador77> has joined #litex | 08:12 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 240 seconds) | 08:31 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:1356:9468:c7a0:bf5e> has joined #litex | 08:50 | |
| MoeIcenowy | _florent_: I am not familiar with ECP5, what is its "init" clock domain? | 08:51 |
|---|---|---|
| MoeIcenowy | (I am trying to port ECP5DDRPHY to GW2A | 08:51 |
| _florent_ | MoeIcenowy: This is a slow clock (25MHz IIRC) that we are using during the initialization of some Lattice primitives | 09:41 |
| _florent_ | MoeIcenowy: Not sure this will be required on GW2A, this is specific to ECP5 primitives. | 09:42 |
| *** geertu <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 09:58 | |
| *** geertu <[email protected]> has joined #litex | 10:04 | |
| *** davebee <[email protected]> has joined #litex | 10:26 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Read error: Connection reset by peer) | 11:14 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #litex | 11:17 | |
| MoeIcenowy | _florent_: I think GW2A has quite similar DLL with ECP5 | 11:17 |
| MoeIcenowy | The DLL is module DLL (output [7:0]STEP, output LOCK, input UPDNCNTL, input STOP, input CLKIN, input RESET); | 11:19 |
| MoeIcenowy | and by checking the netlist generated with Gowin-provided DDR controller, I saw the usage of a clock gate and a divider with sys2x fed in | 11:21 |
| pepijndevos[m] | Every single time I try a new LiteX thing it finds a new way to not upload code | 11:24 |
| pepijndevos[m] | I'm now building with `--uart-name=crossover+uartbone` and then I run `litex_server --uart --uart-port /dev/ttyUSB1` and then `litex_term --kernel target/riscv32imac-unknown-none-elf/release/litex-example.bin --csr-csv colorlight.csv crossover` and then I get the litex header, initialisation, boot, booting from... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/807eb198a69784f34b505b9f50689059ad92a72d) | 11:26 |
| _florent_ | pepijndevos[m]: try to add --safe to litex_term command | 12:25 |
| pepijndevos[m] | Ahhh forgot about that one | 12:27 |
| pepijndevos[m] | Will try later. Normal uart works | 12:28 |
| _florent_ | MoeIcenowy: Are you planning to interface with a DDR3? Do you have a link to Gowin documentation about the internal primitives used in the DDR controller? (I would just like to compare to ECP5) | 12:46 |
| DerekKozel[m] | _florent_: Sorry to be a broken record on this, and not active figuring it out myself, but have you had reason to make a minimal example of a LiteCompute system? | 12:50 |
| DerekKozel[m] | I'm very excited to see the LimeSDR Mini 2.0 has LiteX support as it's main gateware! Has there been any discussion of making that accessible from higher level applications? | 12:52 |
| _florent_ | DerekKozel[m]: not yet sorry, that's still in the pipeline but I'm working on others things in priority (but the work that is done will be useful for it, like current work to support AXI-Full) | 12:54 |
| DerekKozel[m] | Got it! Thanks. I did see the AXI work and did think it was a nice, related bit of work | 12:54 |
| leons | _florent_: I've been skimming over this chat and reading AXI a lot lately. Are there also plans to integrate / switch over to proper AXI4-Streams in the future, for some subsystems at least? | 12:55 |
| DerekKozel[m] | Also, re-reading the LimeSDR announcement I see the LiteX based gateware isn't the primary supported version yet, but I hope it will be eventually. | 12:55 |
| leons | _florent_: Context is, I've been working on Ethernet+AXI4-Stream at work and have really come to like the more strict interface specification w.r.t. ready/valid handshakes and I'm finally convinced tkeep is superior to last_be :D | 12:57 |
| _florent_ | DerekKozel[m]: The Lime gateware will still be the official one. The LiteX one is an experiment for now. We'll first do the top level integration with LiteX and could then progressively reuse some LiteX features (like switch to a RISC-V CPU, etc...) | 12:57 |
| leons | (Even wrote my arch-nemesis, the Packetizer, for AXI4-Stream and struggled significantly less with that :D) | 12:58 |
| _florent_ | leons: hehe, I'm indeed first trying to simplify AXI use in LiteX. First for AXI-Full (MMAP) and then also probably for AXI-Stream (which are very similar to LiteX-Stream but with strict interface). | 13:01 |
| _florent_ | leons: once we'll have good support, it could make sense to switch some cores to it. | 13:02 |
| leons | _florent_: exactly. That's pretty cool! | 13:02 |
| leons | If you need help with some of the AXI4-Stream infrastructure, I'd glady assist there assuming I find the time. Never really worked with the full AXI before though. | 13:03 |
| _florent_ | leons: thanks, have you been reusing https://github.com/alexforencich/verilog-axis? | 13:05 |
| _florent_ | leons: if so, for AXI-Full, I've been reusing https://github.com/alexforencich/verilog-axi to have initial modules to play with | 13:07 |
| _florent_ | leons: and creating LiteX wrappers around: https://github.com/enjoy-digital/litex_verilog_axi | 13:07 |
| _florent_ | we could also do something similar for AXI-Stream | 13:07 |
| leons | _florent_: yes and no. I'm using some simpler components from there, but AFAIK they don't yet have a Packetizer (header inserter) yet, right? | 13:09 |
| _florent_ | leons: it's verilog, so you don't have this level of abstraction :) | 13:09 |
| leons | If I get permission from work I'm going to try and upstream some of these components | 13:09 |
| _florent_ | leons: that would be great! | 13:10 |
| leons | _florent_: Well, you do have the tuser signal to supply a header to be inserted, and that works already | 13:10 |
| leons | The LiteX shim around that would just need to convert from individual fields to the packed header signal supllied as tuser | 13:10 |
| _florent_ | leons: yes sure, I'm just saying doing the equivalent of the Packetizer in plain Verilog would probably be painful due to the Verilog pre-processor capabilities | 13:11 |
| leons | Yes, it required a fair share of hacks. For instance, many of my signals are 1 bit wider than they ought to be, just to avoid handling the case when I'd have a zero-bit width signal otherwise (e.g. for header_width % data_width == 0) | 13:12 |
| leons | Typical Verilog nonsense | 13:13 |
| *** ilia__s0 <[email protected]> has joined #litex | 13:25 | |
| *** xenador77 <xenador77!~xenador77@user/xenador77> has quit IRC (Remote host closed the connection) | 13:32 | |
| *** xenador77 <xenador77!~xenador77@user/xenador77> has joined #litex | 13:32 | |
| *** Shatur95 <[email protected]> has joined #litex | 13:37 | |
| Shatur95 | Hi all! Is there anyone using litex on ArchLinux? Running litex_sim results in "unrecognized opcode csrr" error. | 13:38 |
| leons | Shatur95: huh, csrr is a RISC-V pseudo instruction, should be supported by essentially all RISC-V assemblers | 13:42 |
| leons | What tool is throwing that error specifically? Is it the assembler? | 13:43 |
| leons | My guess would be toolchain mismatch (system gcc and/or assembler used) | 13:44 |
| Shatur95 | I use riscv64-elf-gcc | 13:44 |
| Shatur95 | From my distro repository. | 13:44 |
| leons | That sounds about right. Can you paste more of said error? | 13:45 |
| Shatur95 | Yes, the message is from assembler | 13:45 |
| Shatur95 | usr/lib/python3.10/site-packages/litex/soc/cores/cpu/vexriscv/crt0.S: Assembler messages: | 13:45 |
| Shatur95 | /usr/lib/python3.10/site-packages/litex/soc/cores/cpu/vexriscv/crt0.S:59: Error: unrecognized opcode `csrw mtvec,a0' | 13:45 |
| leons | Does it show anywhere which assembler command it runs? | 13:46 |
| Shatur95 | https://pastebin.com/7aew3snE | 13:47 |
| tpb | Title: INFO:SoC:[1m __ _ __ _ __ [0mINFO:SoC:[1m / / (_) /_ - Pastebin.com (at pastebin.com) | 13:47 |
| Shatur95 | Here is the full log | 13:47 |
| leons | Hm. Are you comfortable using strace to tell which binary is invoked in that step specifically? Alternatively can you modify the Makefile to show what it invokes at that step? Do you have the `AS` environment variable set? | 13:50 |
| Shatur95 | Not sure how to get the assemble command it uses | 13:50 |
| leons | Not in front of my laptop right now, can look into it more in a bit | 13:50 |
| Shatur95 | With strace I should just execute "strace litex_sim"? | 13:52 |
| leons | strace -f to follow forked child processes, then search through the haystack :) | 13:53 |
| leons | There’s probably better ways to do it, but that should work | 13:53 |
| Shatur95 | Thanks! Discovered the following: [pid 97334] execve("/usr/lib/gcc/riscv64-elf/12.1.0/../../../../riscv64-elf/bin/as", ["/usr/lib/gcc/riscv64-elf/12.1.0/"..., "-I", "/usr/lib/python3.10/site-package"..., "-I", "/usr/lib/python3.10/site-package"..., "-I", "/usr/lib/python3.10/site-package"..., "-I", "/home/gena/build/sim/software/in"..., "-I", "/usr/lib/python3.10/site-package"..., "--gdwarf-5", "--traditional-format", "-march=rv32im", "-march=rv32im", "- | 13:55 |
| Shatur95 | mabi=ilp32", "-misa-spec=20191213", "-o", "uart.o", "/tmp/cc2zzWHA.s"], 0x11229f0 /* 68 vars */ <unfinished ...> | 13:55 |
| leons | Hm, okay. Really the only thing I remember from some other distribution is that the non-embedded tool chains showed some weird errors (i.e. -linux-gnu toolchains) | 13:57 |
| Shatur95 | So the preffered way would be download the unknown-gnu version of the toolchain? | 13:58 |
| leons | Do you have an riscv{32,64}-unknown-elf or riscv{32,64}-none-elf toolchain available in the repositories? | 13:58 |
| leons | Not gnu, just -unknown-elf or -none-elf IIRC | 13:59 |
| Shatur95 | There is a binary in AUR, let me try | 13:59 |
| Shatur95 | Installed the following: https://aur.archlinux.org/packages/riscv-gnu-toolchain-bin | 14:06 |
| tpb | Title: AUR (en) - riscv-gnu-toolchain-bin (at aur.archlinux.org) | 14:06 |
| Shatur95 | Now I have riscv64-unknown-elf-gcc | 14:06 |
| Shatur95 | But it fails with the following error: Fatal error: invalid -march= option: `rv32im' | 14:06 |
| Shatur95 | I suspect it because I have riscv64 and riscv32 compilers in my path. Is there a way to specify a contrecte one? | 14:07 |
| leons | The 32 and 64 bit is not the issue here | 14:08 |
| leons | Generally RISC-V GCCs can target multiple different architecture, the name just indicates the default configuration | 14:08 |
| Shatur95 | [pid 107403] execve("/usr/bin/../libexec/gcc/riscv64-unknown-elf/11.1.0/cc1", ["/usr/bin/../libexec/gcc/riscv64-"..., "-quiet", "-nostdinc", "-I", "/usr/lib/python3.10/site-package"..., "-I", "/usr/lib/python3.10/site-package"..., "-I", "/usr/lib/python3.10/site-package"..., "-I", "/home/gena/build/sim/software/in"..., "-I", "/usr/lib/python3.10/site-package"..., "-iprefix", "/usr/bin/../lib/gcc/riscv64-unkn"..., "-MD", "system.d", "-MP", "-MQ", "system.o", "- | 14:08 |
| Shatur95 | dD", "-D", "__vexriscv__", "/usr/lib/python3.10/site-package"..., "-quiet", "-dumpbase", "system.c", "-dumpbase-ext", ".c", "-march=rv32im", "-mabi=ilp32", "-mtune=rocket", ...], 0x2240b20 /* 70 vars */ <unfinished ...> | 14:09 |
| Shatur95 | Here is what I have from strace | 14:09 |
| leons | I had this issue once as well, can you try building a `rv32i` or `rv32imc` target? | 14:09 |
| leons | I might just be that the `rv32im` arch is not supported…? | 14:09 |
| Shatur95 | How can I build rv32i? | 14:10 |
| Shatur95 | Sorry for the newbie question, I'm new here :) | 14:10 |
| leons | You can select `—cpu-variant minimal` IIRC | 14:11 |
| leons | At the litex_sim command line | 14:11 |
| Shatur95 | Now I have Fatal error: invalid -march= option: `rv32i' | 14:11 |
| Shatur95 | That's odd | 14:11 |
| leons | Okay, I’m out of ideas :D | 14:12 |
| leons | Can try to get it to work on my Arch Linux later | 14:13 |
| Shatur95 | :D Would you suggest to download the toolchain from the script? | 14:16 |
| Shatur95 | I tried using things from repo because I found litex in my repo | 14:17 |
| Shatur95 | So I installed python-litex python-litex-boards python-pythondata-cpu-vexriscv python-pythondata-software-compiler_rt | 14:17 |
| Shatur95 | But ran into the issue with running litex_sim | 14:18 |
| leons | If you ask me personally, I'd refrain from automatically downloading toolchains, except if you have some strictly controlled envrionment (CI or prepared container / VM) | 14:21 |
| Shatur95 | Same here :D | 14:22 |
| leons | Users have the wildest system configurations, you'll never find a solution which works for everyone, and while the automatic approach might work for those 95% of users for who the distro-toolchain works as well, you're creating so so much more friction for those where it doesn't | 14:23 |
| Shatur95 | Wondering why riscv64-elf-gcc doesn't work... | 14:24 |
| Shatur95 | In Arch we have riscv64-elf-gcc and riscv64-linux-gnu-gcc | 14:30 |
| Shatur95 | Both results in the same error | 14:30 |
| leons | Currently trying to reproduce it on Arch, stuck at "ERROR: Neither directory contains a build file meson.build." | 14:33 |
| leons | Ah, well, screwup on my side | 14:33 |
| Shatur95 | Great, looking forward to it. Are you using litex from the repo? | 14:35 |
| leons | Huh, for me it just works(TM) with riscv64-elf-gcc | 14:35 |
| leons | Just latest master of everything | 14:35 |
| Shatur95 | Oh, so you downloaded litex from the repo? | 14:36 |
| Shatur95 | I just installed python-litex python-litex-boards python-pythondata-cpu-vexriscv python-pythondata-software-compiler_rt | 14:36 |
| leons | Yes, just cloned the respective components myself. | 14:36 |
| Shatur95 | Could you tried with the packages from the repo? Just to confirm that they doesn't work | 14:37 |
| leons | There's also a script for that: https://github.com/enjoy-digital/litex/blob/master/litex_setup.py | 14:37 |
| leons | You mean from PyPI? | 14:38 |
| Shatur95 | No, from the archlinux repo: https://archlinux.org/packages/?q=litex | 14:38 |
| tpb | Title: Arch Linux - Package Search (at archlinux.org) | 14:38 |
| Shatur95 | But I realized that the packages just too old | 14:38 |
| Shatur95 | I think this is the root of the issue | 14:38 |
| Shatur95 | Thank you a lot, I will report it and use laster master as you did | 14:39 |
| leons | Crazy these are in the repo. Yeah, wouldn't use them tbh, seem quite ancient | 14:39 |
| Shatur95 | Am I understand correctly that litex_setup.py doing the same as I would do using pip, but installs latest master version? Just trying to understand the installation process. | 15:02 |
| *** smosanu <[email protected]> has joined #litex | 15:22 | |
| *** smosanu <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 15:28 | |
| *** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:13> has joined #litex | 15:42 | |
| *** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:13> has quit IRC (Client Quit) | 15:45 | |
| *** davebee <[email protected]> has quit IRC (Quit: Leaving) | 15:49 | |
| MoeIcenowy | _florent_: the primitives are in different documents | 16:22 |
| MoeIcenowy | DQS is at UG286 , memory-oriented serdes at UG289, where is DLL documented is not sure now | 16:25 |
| MoeIcenowy | for downloading documents, use http://cdn.gowinsemi.com.cn/${DOCUMENT_ID}E.pdf | 16:25 |
| MoeIcenowy | ("E" is for English, if omitted it's Chinese document | 16:25 |
| MoeIcenowy | DLL is documented at an old version of SUG283 available at https://www.gowinsemi.com/upload/database_doc/39/document/5bfcff2ce0b72.pdf | 16:29 |
| *** xenador77 <xenador77!~xenador77@user/xenador77> has quit IRC (Remote host closed the connection) | 17:24 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 19:17 | |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #litex | 19:44 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 268 seconds) | 19:46 | |
| *** Shatur95 <[email protected]> has quit IRC (Ping timeout: 264 seconds) | 19:46 | |
| *** geertu <[email protected]> has quit IRC (Ping timeout: 264 seconds) | 19:46 | |
| *** geertu <[email protected]> has joined #litex | 19:48 | |
| _florent_ | MoeIcenowy: Interesting, the primitives indeed seem to be the one from the ECP5 (just renamed and with some IO/params renamed). | 19:50 |
| _florent_ | MoeIcenowy: In a first time, it would be interesting to study this and compare the primitives more closely | 19:51 |
| _florent_ | MoeIcenowy: With gatecat, we implemented the ECP5DDRPHY a few years ago (2019 IIRC) by following TN1265 / Figure 31 | 19:52 |
| _florent_ | MoeIcenowy: If you can have a first look at this and compare the primitives (and eventually list things in a document), I can then probably help adapting ECP5DRPHY to the GW2A | 19:54 |
| jevinskie[m] | <Shatur95> "Am I understand correctly that..." <- Yeah. litex_setup —install runs pip install and if you add —dev it runs install in editable mode so your changes are used immediately without reinstalling with pip | 19:59 |
| jevinskie[m] | MoeIcenowy: I can’t wait for the primer 20k, it’s going to be fun :) | 20:01 |
| trabucayre | jevinskie[m]: +1 | 20:04 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!