xenador77 has quit [Remote host closed the connection]
FabM has quit [Ping timeout: 240 seconds]
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
xenador77 has joined #litex
FabM has quit [Ping timeout: 240 seconds]
FabM has joined #litex
FabM has quit [Changing host]
FabM has joined #litex
<MoeIcenowy>
_florent_: I am not familiar with ECP5, what is its "init" clock domain?
<MoeIcenowy>
(I am trying to port ECP5DDRPHY to GW2A
<_florent_>
MoeIcenowy: This is a slow clock (25MHz IIRC) that we are using during the initialization of some Lattice primitives
<_florent_>
MoeIcenowy: Not sure this will be required on GW2A, this is specific to ECP5 primitives.
geertu has quit [Ping timeout: 260 seconds]
geertu has joined #litex
davebee has joined #litex
peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #litex
<MoeIcenowy>
_florent_: I think GW2A has quite similar DLL with ECP5
<MoeIcenowy>
The DLL is module DLL (output [7:0]STEP, output LOCK, input UPDNCNTL, input STOP, input CLKIN, input RESET);
<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
<pepijndevos[m]>
Every single time I try a new LiteX thing it finds a new way to not upload code
<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)
<_florent_>
pepijndevos[m]: try to add --safe to litex_term command
<pepijndevos[m]>
Ahhh forgot about that one
<pepijndevos[m]>
Will try later. Normal uart works
<_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)
<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?
<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?
<_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)
<DerekKozel[m]>
Got it! Thanks. I did see the AXI work and did think it was a nice, related bit of work
<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?
<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.
<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
<_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...)
<leons>
(Even wrote my arch-nemesis, the Packetizer, for AXI4-Stream and struggled significantly less with that :D)
<_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).
<_florent_>
leons: once we'll have good support, it could make sense to switch some cores to it.
<leons>
_florent_: exactly. That's pretty cool!
<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.
<_florent_>
we could also do something similar for AXI-Stream
<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?
<_florent_>
leons: it's verilog, so you don't have this level of abstraction :)
<leons>
If I get permission from work I'm going to try and upstream some of these components
<_florent_>
leons: that would be great!
<leons>
_florent_: Well, you do have the tuser signal to supply a header to be inserted, and that works already
<leons>
The LiteX shim around that would just need to convert from individual fields to the packed header signal supllied as tuser
<_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
<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)
<leons>
Typical Verilog nonsense
ilia__s0 has joined #litex
xenador77 has quit [Remote host closed the connection]
xenador77 has joined #litex
Shatur95 has joined #litex
<Shatur95>
Hi all! Is there anyone using litex on ArchLinux? Running litex_sim results in "unrecognized opcode csrr" error.
<leons>
Shatur95: huh, csrr is a RISC-V pseudo instruction, should be supported by essentially all RISC-V assemblers
<leons>
What tool is throwing that error specifically? Is it the assembler?
<leons>
My guess would be toolchain mismatch (system gcc and/or assembler used)
<Shatur95>
I use riscv64-elf-gcc
<Shatur95>
From my distro repository.
<leons>
That sounds about right. Can you paste more of said error?
<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?
<Shatur95>
Not sure how to get the assemble command it uses
<leons>
Not in front of my laptop right now, can look into it more in a bit
<Shatur95>
With strace I should just execute "strace litex_sim"?
<leons>
strace -f to follow forked child processes, then search through the haystack :)
<leons>
There’s probably better ways to do it, but that should work
<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)
<Shatur95>
So the preffered way would be download the unknown-gnu version of the toolchain?
<leons>
Do you have an riscv{32,64}-unknown-elf or riscv{32,64}-none-elf toolchain available in the repositories?
<leons>
Not gnu, just -unknown-elf or -none-elf IIRC
<leons>
I had this issue once as well, can you try building a `rv32i` or `rv32imc` target?
<leons>
I might just be that the `rv32im` arch is not supported…?
<Shatur95>
How can I build rv32i?
<Shatur95>
Sorry for the newbie question, I'm new here :)
<leons>
You can select `—cpu-variant minimal` IIRC
<leons>
At the litex_sim command line
<Shatur95>
Now I have Fatal error: invalid -march= option: `rv32i'
<Shatur95>
That's odd
<leons>
Okay, I’m out of ideas :D
<leons>
Can try to get it to work on my Arch Linux later
<Shatur95>
:D Would you suggest to download the toolchain from the script?
<Shatur95>
I tried using things from repo because I found litex in my repo
<Shatur95>
So I installed python-litex python-litex-boards python-pythondata-cpu-vexriscv python-pythondata-software-compiler_rt
<Shatur95>
But ran into the issue with running litex_sim
<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)
<Shatur95>
Same here :D
<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
<tpb>
Title: Arch Linux - Package Search (at archlinux.org)
<Shatur95>
But I realized that the packages just too old
<Shatur95>
I think this is the root of the issue
<Shatur95>
Thank you a lot, I will report it and use laster master as you did
<leons>
Crazy these are in the repo. Yeah, wouldn't use them tbh, seem quite ancient
<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.
smosanu has joined #litex
smosanu has quit [Ping timeout: 252 seconds]
pftbest has joined #litex
pftbest has quit [Client Quit]
davebee has quit [Quit: Leaving]
<MoeIcenowy>
_florent_: the primitives are in different documents
<MoeIcenowy>
DQS is at UG286 , memory-oriented serdes at UG289, where is DLL documented is not sure now
xenador77 has quit [Remote host closed the connection]
FabM has quit [Quit: Leaving]
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 268 seconds]
Shatur95 has quit [Ping timeout: 264 seconds]
geertu has quit [Ping timeout: 264 seconds]
geertu has joined #litex
<_florent_>
MoeIcenowy: Interesting, the primitives indeed seem to be the one from the ECP5 (just renamed and with some IO/params renamed).
<_florent_>
MoeIcenowy: In a first time, it would be interesting to study this and compare the primitives more closely
<_florent_>
MoeIcenowy: With gatecat, we implemented the ECP5DDRPHY a few years ago (2019 IIRC) by following TN1265 / Figure 31
<_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
<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
<jevinskie[m]>
MoeIcenowy: I can’t wait for the primer 20k, it’s going to be fun :)