_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
subthreshold has quit [Ping timeout: 252 seconds]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #litex
acathla_ is now known as acathla
xenador77 has joined #litex
xenador77 has quit [Remote host closed the connection]
esteves has joined #litex
esteves has quit [Quit: Client closed]
<acathla> _florent_, i've got another problem... you removed LTO option from CFLAGS (-flto) in a commit, but I can't build my code anymore without adding it. Bios is building fine, what a I missing?
<acathla> It fails with an error like : helpers.o: in function `command_dispatcher': [..]litex/soc/software/bios/helpers.c:125: undefined reference to `__bios_init_start'
<pepijndevos[m]> uh oh...
<pepijndevos[m]> what if I want more than 32 PWM controllers?
<pepijndevos[m]> ERROR:SoCCSRHandler:Not enough Locations.
<pepijndevos[m]> ERROR:SoCCSRHandler:32-bit CSR Bus, 32-bit Aligned, 16.0KiB Address Space, 2048B Paging, big Ordering (Up to 32 Locations).
<pepijndevos[m]> I want uhh 32 PWMs and 16 stepper motor drivers plus some misc ethernet stuff
<acathla> pepijndevos[m], add another PWM instance?
<acathla> _florent_, if I do add -flto it builds, but prints strange things and mem_test reports errors
<pepijndevos[m]> hmm seems like I just need to increas the csr address width maybe
<pepijndevos[m]> 64 elements should be just about enough I think
<_florent_> pepijndevos[m]: you can indeed increase csr_address_width for this (we should maybe handle this automatically)
<_florent_> acathla: You probably only need to do a clean build of your software, as it is now done automatically by LiteX for the BIOS when CPU/build parameters are changed.
<acathla> _florent_, I do that automatically too, it does not build... May be a bad usage of gnu-ar...
<acathla> _florent_, found the bug, there is a new section in linker.ld : .init
<pepijndevos[m]> hrm! what would be the most effective way to debug a vhdl peripheral? I simulated it by itself, and it appears to work fine, but when wrapped in litex auocsr stuff there is no output on the fpga
<tnt> no output ?
<tnt> And no warning during build ?
<_florent_> pepijndevos[m]: if it can be converted to verilog through GHDL or GHDL+Yosys, the most effective way to debug is probably to integrate it in a Verilator simulation and use Display (printf equivalent for logic) or look at the waveforms
<pepijndevos[m]> yea i synth to verilog
<pepijndevos[m]> so you'd synthesize the entire litex design in verilator?
<_florent_> this simulates a minimal SoC (CPU + peripherals)
<pepijndevos[m]> ohhh
<_florent_> and with the LiteX BIOS, just access your peripheral through mem_write/mem_read and observe things
<_florent_> or you can also just modify the LiteX BIOS, load your ROM binary and look at the waveform, this will give you more visibility, but you have to search things in the waveform while Display just display the information you want.
<pepijndevos[m]> meanwhile i was trying to bring out some debug signals on the actual fpga, but when I do that I get `ERROR: Cell port colorlight_5a_75b.stepper.step_out is driving constant bits: 1'0 <= \stepper.step_out` so that seems fishy
<_florent_> pepijndevos[m]: hmm, indeed, it seems your module is simplified, so probably an issue on the instance.
<pepijndevos[m]> what do you mean?
FabM has joined #litex
FabM has quit [Changing host]
FabM has joined #litex
<pepijndevos[m]> Can I display stuff directly from verilog/vhdl?
<_florent_> display is support in verilog, not sure in vhdl (or not sure if GHDL would convert vhdl equivalent to display)
cr1901_ has joined #litex
<pepijndevos[m]> hmmm
<pepijndevos[m]> how do I figure out the csr for the sim thing? It doesn't accept --csr-csv my.csv
<pepijndevos[m]> so I can mem_write to the thing
smosanu has joined #litex
cr1901 has quit [Ping timeout: 255 seconds]
<pepijndevos[m]> I just did the math in my head now...
<pepijndevos[m]> it actually works perfectly in the simulator
smosanu has quit [Ping timeout: 252 seconds]
<pepijndevos[m]> Am I doing anything obviously wrong with how I hook things up? The Modegen and PWM blocks do work as expected, but the Stepper modules don't output anything.
indy_ is now known as indy
<pepijndevos[m]> It's just completely weird. I can see the mode signal works. I can see the PWM signals on the same header. And it works in simulation. So it seems like everything is functional and hooked up correctly, but then there is just no output.
FabM has quit [Quit: Leaving]
peeps[zen] has quit [Ping timeout: 276 seconds]
peepsalot has joined #litex
RaYmAn has quit [Read error: Connection reset by peer]
<joseng> Hey, after a long time not playing with Litex, I ran "litex_sim --with-etherbone", can ping the 192.168.1.51 and connect with "litex_server --udp --udp-ip 192.168.1.51". But when I try to run "litex_cli --regs", I get only timeout errors.
<joseng> All runs on a Laptop with Ubuntu 22.04. Some rare times, I get the register content successfully. When I use --gui, I see the registers, but no values and also a timeout after some seconds
<joseng> Is there anything else I can test to get why this is happening?
<joseng> The ping times are below 1ms. When I run the udp scan with "litex_server --udp --udp-ip=192.168.1.x --udp-scan" multiple times, I get 75% of the runs no result
<jevinskie[m]> I made a few quality of life improvements: add verbose mode to sw and sim compile, suppress verilator and verilator module warnings, and the ability to only build sw once when running the sim. I’ll polish them up and post PRs for them once I get some time. https://github.com/jevinskie/litex/commits/jev/usbstream-usbbone/main
<jevinskie[m]> pepijndevos: sounds like it might be time to use litescope on the fpga (it works in simulator too over virtual Ethernet) https://github.com/enjoy-digital/litescope/blob/master/examples/arty.py
key2_ has joined #litex
oter_ has joined #litex
esden_ has joined #litex
_alice_ has joined #litex
_alice has quit [Ping timeout: 250 seconds]
key2 has quit [Ping timeout: 250 seconds]
esden has quit [Ping timeout: 250 seconds]
oter has quit [Ping timeout: 250 seconds]
x56 has quit [Ping timeout: 250 seconds]
oter_ is now known as oter
key2_ is now known as key2
esden_ is now known as esden
x56_ has joined #litex
<jevinskie[m]> joseng: I had timeout issues with the verilator tap Ethernet modules. One thing that helped was increasing buffer lengths (sorry I forget which ones specifically) in Ethernet modules and the other was macOS specific where the tap driver doesn’t support events and I had to change the module to use reads with timeouts