Monday, 2022-06-20

*** tpb <[email protected]> has joined #litex00:00
*** Degi_ <[email protected]> has joined #litex02:42
*** Degi <[email protected]> has quit IRC (Ping timeout: 246 seconds)02:43
*** Degi_ is now known as Degi02:43
*** a3f <[email protected]: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 <[email protected]/shoragan> has quit IRC (*.net *.split)04:21
*** shoragan <[email protected]/shoragan> has joined #litex04:22
*** yootis <[email protected]> has joined #litex04:22
*** _whitelogger <[email protected]> has joined #litex04:22
*** cr1901 <[email protected]:8d:8600:911:c9e7:1eb4:69e9:b5f2> has quit IRC (*.net *.split)04:27
*** cr1901 <[email protected]:8d:8600:911:4526:1b81:d974:dab2> has joined #litex04:27
*** CarlFK <[email protected]:470:69fc:105::5d8> has quit IRC (*.net *.split)04:30
*** xobs[m] <xobs[m][email protected]: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 #litex04:30
*** sorear <[email protected]> has joined #litex04:30
*** guan <[email protected]> has joined #litex04:30
*** philpax_ <[email protected]> has joined #litex04:30
*** a3f <[email protected]:470:69fc:105::41d> has joined #litex04:31
*** xobs[m] <xobs[m][email protected]:470:69fc:105::6903> has joined #litex04:45
*** CarlFK <[email protected]:470:69fc:105::5d8> has joined #litex04:45
*** Abhishek__ <[email protected]> has joined #litex04:49
*** rektide_ <[email protected]> has joined #litex04:52
*** Abhishek_ <[email protected]> has quit IRC (Ping timeout: 272 seconds)04:53
*** xobs[m] <xobs[m][email protected]: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][email protected]: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][email protected]:470:69fc:105::9a7> has joined #litex05:15
*** xobs[m] <xobs[m][email protected]:470:69fc:105::6903> has joined #litex05:18
*** FabM <[email protected]:d604:103:600:5cef:dd29:3504:2580> has joined #litex05:28
*** xenador77 <[email protected]/xenador77> has quit IRC (Remote host closed the connection)06:46
*** FabM <[email protected]/team/FabM> has quit IRC (Ping timeout: 240 seconds)07:35
*** FabM <[email protected]:d604:103:600:63ec:2058:c1c1:37b8> has joined #litex07:48
*** xenador77 <[email protected]/xenador77> has joined #litex08:12
*** FabM <[email protected]/team/FabM> has quit IRC (Ping timeout: 240 seconds)08:31
*** FabM <[email protected]:d604:103:600:1356:9468:c7a0:bf5e> has joined #litex08: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 GW2A08:51
_florent_MoeIcenowy: This is  a slow clock (25MHz IIRC) that we are using during the initialization of some Lattice primitives09: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 #litex10:04
*** davebee <[email protected]> has joined #litex10:26
*** peepsalot <[email protected]/peepsalot> has quit IRC (Read error: Connection reset by peer)11:14
*** peepsalot <[email protected]/peepsalot> has joined #litex11:17
MoeIcenowy_florent_: I think GW2A has quite similar DLL with ECP511:17
MoeIcenowyThe DLL is module DLL (output [7:0]STEP, output LOCK, input UPDNCNTL, input STOP, input CLKIN, input RESET);11:19
MoeIcenowyand by checking the netlist generated with Gowin-provided DDR controller, I saw the usage of a clock gate and a divider with sys2x fed in11:21
pepijndevos[m]Every single time I try a new LiteX thing it finds a new way to not upload code11: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
_florent_pepijndevos[m]: try to add --safe to litex_term command12:25
pepijndevos[m]Ahhh forgot about that one12:27
pepijndevos[m]Will try later. Normal uart works12: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 work12: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 :D12: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
leonsIf 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
_florent_leons: if so, for AXI-Full, I've been reusing to have initial modules to play with13:07
_florent_leons: and creating LiteX wrappers around:
_florent_we could also do something similar for AXI-Stream13: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
leonsIf I get permission from work I'm going to try and upstream some of these components13: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 already13:10
leonsThe LiteX shim around that would just need to convert from individual fields to the packed header signal supllied as tuser13: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 capabilities13:11
leonsYes, 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
leonsTypical Verilog nonsense13:13
*** ilia__s0 <[email protected]> has joined #litex13:25
*** xenador77 <[email protected]/xenador77> has quit IRC (Remote host closed the connection)13:32
*** xenador77 <[email protected]/xenador77> has joined #litex13:32
*** Shatur95 <[email protected]> has joined #litex13:37
Shatur95Hi all! Is there anyone using litex on ArchLinux? Running litex_sim results in "unrecognized opcode csrr" error.13:38
leonsShatur95: huh, csrr is a RISC-V pseudo instruction, should be supported by essentially all RISC-V assemblers 13:42
leonsWhat tool is throwing that error specifically? Is it the assembler?13:43
leonsMy guess would be toolchain mismatch (system gcc and/or assembler used)13:44
Shatur95I use riscv64-elf-gcc13:44
Shatur95From my distro repository.13:44
leonsThat sounds about right. Can you paste more of said error?13:45
Shatur95Yes, the message is from assembler13:45
Shatur95usr/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
leonsDoes it show anywhere which assembler command it runs?13:46
tpbTitle: INFO:SoC:[1m __ _ __ _ __ [0mINFO:SoC:[1m / / (_) /_ - (at
Shatur95Here is the full log13:47
leonsHm. 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
Shatur95Not sure how to get the assemble command it uses13:50
leonsNot in front of my laptop right now, can look into it more in a bit13:50
Shatur95With strace I should just execute "strace litex_sim"?13:52
leonsstrace -f to follow forked child processes, then search through the haystack :)13:53
leonsThere’s probably better ways to do it, but that should work13:53
Shatur95Thanks! 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
Shatur95mabi=ilp32", "-misa-spec=20191213", "-o", "uart.o", "/tmp/cc2zzWHA.s"], 0x11229f0 /* 68 vars */ <unfinished ...>13:55
leonsHm, 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
Shatur95So the preffered way would be download the unknown-gnu version of the toolchain?13:58
leonsDo you have an riscv{32,64}-unknown-elf or riscv{32,64}-none-elf toolchain available in the repositories?13:58
leonsNot gnu, just -unknown-elf or -none-elf IIRC13:59
Shatur95There is a binary in AUR, let me try13:59
Shatur95Installed the following:
tpbTitle: AUR (en) - riscv-gnu-toolchain-bin (at
Shatur95Now I have riscv64-unknown-elf-gcc14:06
Shatur95But it fails with the following error: Fatal error: invalid -march= option: `rv32im'14:06
Shatur95I suspect it because I have riscv64 and riscv32 compilers in my path. Is there a way to specify a contrecte one?14:07
leonsThe 32 and 64 bit is not the issue here14:08
leonsGenerally RISC-V GCCs can target multiple different architecture, the name just indicates the default configuration14: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
Shatur95dD", "-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
Shatur95Here is what I have from strace14:09
leonsI had this issue once as well, can you try building a `rv32i` or `rv32imc` target? 14:09
leonsI might just be that the `rv32im` arch is not supported…?14:09
Shatur95How can I build rv32i?14:10
Shatur95Sorry for the newbie question, I'm new here :)14:10
leonsYou can select `—cpu-variant minimal` IIRC14:11
leonsAt the litex_sim command line14:11
Shatur95Now I have Fatal error: invalid -march= option: `rv32i'14:11
Shatur95That's odd14:11
leonsOkay, I’m out of ideas :D14:12
leonsCan try to get it to work on my Arch Linux later14:13
Shatur95:D Would you suggest to download the toolchain from the script?14:16
Shatur95I tried using things from repo because I found litex in my repo14:17
Shatur95So I installed python-litex python-litex-boards python-pythondata-cpu-vexriscv python-pythondata-software-compiler_rt14:17
Shatur95But ran into the issue with running litex_sim14:18
leonsIf 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
Shatur95Same here :D14:22
leonsUsers 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't14:23
Shatur95Wondering why riscv64-elf-gcc doesn't work...14:24
Shatur95In Arch we have riscv64-elf-gcc and riscv64-linux-gnu-gcc14:30
Shatur95Both results in the same error14:30
leonsCurrently trying to reproduce it on Arch, stuck at "ERROR: Neither directory contains a build file"14:33
leonsAh, well, screwup on my side14:33
Shatur95Great, looking forward to it. Are you using litex from the repo?14:35
leonsHuh, for me it just works(TM) with riscv64-elf-gcc14:35
leonsJust latest master of everything14:35
Shatur95Oh, so you downloaded litex from the repo?14:36
Shatur95I just installed python-litex python-litex-boards python-pythondata-cpu-vexriscv python-pythondata-software-compiler_rt14:36
leonsYes, just cloned the respective components myself.14:36
Shatur95Could you tried with the packages from the repo? Just to confirm that they doesn't work14:37
leonsThere's also a script for that:
leonsYou mean from PyPI?14:38
Shatur95No, from the archlinux repo:
tpbTitle: Arch Linux - Package Search (at
Shatur95But I realized that the packages just too old14:38
Shatur95I think this is the root of the issue14:38
Shatur95Thank you a lot, I will report it and use laster master as you did14:39
leonsCrazy these are in the repo. Yeah, wouldn't use them tbh, seem quite ancient14:39
Shatur95Am I understand correctly that 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 #litex15:22
*** smosanu <[email protected]> has quit IRC (Ping timeout: 252 seconds)15:28
*** pftbest <[email protected]:4f8:c17:6afc::1:13> has joined #litex15:42
*** pftbest <[email protected]: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 documents16:22
MoeIcenowyDQS is at UG286 , memory-oriented serdes at UG289, where is DLL documented is not sure now16:25
MoeIcenowyfor downloading documents, use${DOCUMENT_ID}E.pdf16:25
MoeIcenowy("E" is for English, if omitted it's Chinese document16:25
MoeIcenowyDLL is documented at an old version of SUG283 available at 16:29
*** xenador77 <[email protected]/xenador77> has quit IRC (Remote host closed the connection)17:24
*** FabM <[email protected]/team/FabM> has quit IRC (Quit: Leaving)19:17
*** peeps[zen] <peeps[zen][email protected]/peepsalot> has joined #litex19:44
*** peepsalot <[email protected]/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 #litex19: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 closely19:51
_florent_MoeIcenowy: With gatecat, we implemented the ECP5DDRPHY a few years ago (2019 IIRC) by following TN1265 / Figure 3119: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 GW2A19: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 pip19:59
jevinskie[m]MoeIcenowy: I can’t wait for the primer 20k, it’s going to be fun :)20:01
trabucayrejevinskie[m]: +120:04

Generated by 2.17.2 by Marius Gedminas - find it at!