_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
cr1901_ is now known as cr1901
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
gregd has joined #litex
gregd has quit [Client Quit]
<pepijndevos[m]> jevinskie: Ohh maybe! Although I'm not sure it'll allow me to probe inside the vhdl block
<MoeIcenowy> _florent_: what should I learn if I want to add a new FPGA family support to litedram?
<jevinskie[m]> <pepijndevos[m]> "jevinskie: Ohh maybe! Although I..." <- Yes but you will have to fish those signals out to the top level of vhdl
<MoeIcenowy> http://cdn.gowinsemi.com.cn/UG286E.pdf I think the DQS here looks like DQSBUFM in ECP5, right?
FabM has joined #litex
RaYmAn has joined #litex
<pepijndevos[m]> wow my super basic peripherals take up 25% of the FPGA? If I do 1 it's 45% COMBs and with 8 of them it's 76%
<gatecat> MoeIcenowy: yeah, i'd say it looks very similar
Degi has joined #litex
<pepijndevos[m]> when I have a crossover server running and the thing that connects to it gives a socket timeout, is that a problem with the server, the client, or the uart?
somlo_ has joined #litex
somlo has quit [Read error: Connection reset by peer]
<pepijndevos[m]> uh this seems completely borked
<pepijndevos[m]> when I reduce the stepper motor driver to just output the mode signal, the previously working mode signal now no longer works
<pepijndevos[m]> it's a seperate verilog file that generates the mode signal, and outputs it on a pin that I have hooked up to a logic analyser. It works great
<pepijndevos[m]> I can literally break the output of one module by removing another module
<pepijndevos[m]> I have completely removed the verilog.... and even this comb doesn't work... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/5b71e3bc92433e0a9327ca59294ea7e06cc48ec6)
<pepijndevos[m]> with the sync line I see it on the output, but with the comb I see nothing at all
<tnt> what do you see in the output veriog when comparing the two versions ?
<tnt> it's kinda hard to comment without seeing the whole code.
<pepijndevos[m]> tnt: this is the entire code, which uses ghdl in the stepper folder to make verilog, simsoc.py to run a simulation, and colorlight*.py to compile for FPGA https://github.com/pepijndevos/rust-litex-example/tree/colorlight
<pepijndevos[m]> Haven't looked at the final final total verilog yet lemme see
<pepijndevos[m]> Looking at the final code it does translate to `assign H1[4] = (~main_mode[0]);` if I do the comb thing
<pepijndevos[m]> but somewhere in synthesis it decides it's just not there... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/39b8187fe2585965c7b69a72c57958d501bfd478)
<pepijndevos[m]> Maybe... the reset is messing it up?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/e94be6a1b10705049762bf964a4a0a65004a75c6)
<pepijndevos[m]> If I do that kind of thing in GHDL it yells at me that the wire has multiple drivers
<tnt> can you post the full .v ?
<pepijndevos[m]> trying with reset_less now, will post it in a bit
* pepijndevos[m] posted a file: colorlight_5a_75b.v (298KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/hknStkEyXAjwEcxwSKlsEfbv >
<pepijndevos[m]> ok yea so I think the problem is that litex is generating reset logic for stuff that is driven from vhdl or comb
<pepijndevos[m]> tnt: ^
<tnt> Not sure if it's related but I know that if you signal() is a vector, you can't connector some bits to verilog instance and then drive some other bits from migen logic.
<pepijndevos[m]> making some progres... made all ports reset less and now i can at least pass the mode signal through vhdl without messing other stuff up
<tnt> Also not sure if you can drive one bit of a signal from sync and others from comb.
<pepijndevos[m]> hayyyyy
<pepijndevos[m]> reset_less actually solved it
<pepijndevos[m]> but yea probably because the pwm module is migen it got reset logic on the signal
<pepijndevos[m]> so probably another solution would be to split the header in multiple signals
<pepijndevos[m]> is there a way to see what modules are taking up resources?
<tnt> Depends on the target fpga
<tnt> Although for litex actually that won't help because you get one flat verilog file so even if the toolchain does hierachical resource report, you wouldn't see anything.
<jevinskie[m]> Unfortunately not, amaranth is needed for hierarchy generation
<pepijndevos[m]> I'm at like 88% TRELLIS_COMB with picorv32 and 97% with vexrisc. So the bulk is probably my 60 PWM and stepper motor drivers hehe
<pepijndevos[m]> I have 16 stepper motor drivers and 32 PWM generators. The stepper motor driver VHDL by itself is like 432 LUTs, plus a bunch of CSR stuff on the LiteX side. I could maybe optimize that a bit, but can't do much about the CSR and PWM part. So I'm not sure if it's worth optimizing my VHDL, write a custom "bulk PWM" driver, or just hope nextpnr will eventually progress
<pepijndevos[m]> So far it seems completely frozen on `Info: Running main analytical placer.`
<pepijndevos[m]> yeah... I reduced the luts of my stepper generator to <300 and it's still 85% and not progressing
FabM has quit [Quit: Leaving]
<pepijndevos[m]> Hmmm what is the realistic maximum utilisation you can get out of an ECP5 with nextpnr? I'm now at 81% and it's not even made a single analytical placer step
<tnt> probably depends on a lot of other factors.
<tnt> Like, I would assume some control signal (CE/RST) are shared between slices in a PFU so if you have lots of different control groups, that could mess with the placer.
<pepijndevos[m]> Another reason to have a single PWM controller that controls multiple outputs
<pepijndevos[m]> I would think 20% free space should be quite a lot but apparently not
<pepijndevos[m]> but yea if it can only use half of every slice then that's not going to work very well
somlo_ is now known as somlo
mlaga97_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
mlaga97 has joined #litex
<pepijndevos[m]> hrm in a migen signal, what is the lsb and msb? Or like... how would I get the N most significant bits?
<pepijndevos[m]> `sig[len(sig)-N:-1]`??
<tnt> sig[-N-1:-1]
lukas[m]123 has joined #litex
leons[m] has joined #litex
leons[m] has left #litex [#litex]
lukas[m]123 has left #litex [#litex]
<jevinskie[m]> Uh oh, I’m looking at this page and thinking how relatively simple it would be to add support for the test statements to migen/litex and allow for formal verification tests written in Python as normal https://yosyshq.readthedocs.io/projects/sby/en/latest/verilog.html
<tpb> Title: Formal extensions to Verilog (at yosyshq.readthedocs.io)