*** tpb <[email protected]> has joined #litex | 00:00 | |
*** cr1901_ is now known as cr1901 | 01:57 | |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 04:06 | |
*** TMM_ <[email protected]> has joined #litex | 04:06 | |
*** gregd <[email protected]> has joined #litex | 05:02 | |
*** gregd <[email protected]> has quit IRC (Client Quit) | 05:07 | |
pepijndevos[m] | jevinskie: Ohh maybe! Although I'm not sure it'll allow me to probe inside the vhdl block | 05:14 |
---|---|---|
MoeIcenowy | _florent_: what should I learn if I want to add a new FPGA family support to litedram? | 05:18 |
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 | 05:47 |
MoeIcenowy | http://cdn.gowinsemi.com.cn/UG286E.pdf I think the DQS here looks like DQSBUFM in ECP5, right? | 06:03 |
*** FabM <FabM!~FabM@armadeus/team/FabM> has joined #litex | 07:02 | |
*** RaYmAn <[email protected]> has joined #litex | 07:14 | |
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% | 07:40 |
gatecat | MoeIcenowy: yeah, i'd say it looks very similar | 08:13 |
*** Degi <[email protected]> has joined #litex | 08:17 | |
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? | 08:30 |
*** somlo_ <[email protected]> has joined #litex | 08:31 | |
*** somlo <[email protected]> has quit IRC (Read error: Connection reset by peer) | 08:32 | |
pepijndevos[m] | uh this seems completely borked | 09:32 |
pepijndevos[m] | when I reduce the stepper motor driver to just output the mode signal, the previously working mode signal now no longer works | 09:33 |
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 | 09:34 |
pepijndevos[m] | I can literally break the output of one module by removing another module | 10:11 |
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) | 10:39 |
pepijndevos[m] | with the sync line I see it on the output, but with the comb I see nothing at all | 10:40 |
tnt | what do you see in the output veriog when comparing the two versions ? | 10:52 |
tnt | it's kinda hard to comment without seeing the whole code. | 10:53 |
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 | 11:38 |
pepijndevos[m] | Haven't looked at the final final total verilog yet lemme see | 11:38 |
pepijndevos[m] | Looking at the final code it does translate to `assign H1[4] = (~main_mode[0]);` if I do the comb thing | 11:48 |
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) | 11:53 |
pepijndevos[m] | Maybe... the reset is messing it up?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/e94be6a1b10705049762bf964a4a0a65004a75c6) | 11:55 |
pepijndevos[m] | If I do that kind of thing in GHDL it yells at me that the wire has multiple drivers | 11:56 |
tnt | can you post the full .v ? | 12:00 |
pepijndevos[m] | trying with reset_less now, will post it in a bit | 12:01 |
* pepijndevos[m] posted a file: colorlight_5a_75b.v (298KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/hknStkEyXAjwEcxwSKlsEfbv > | 12:04 | |
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 | 12:08 |
pepijndevos[m] | tnt: ^ | 12:11 |
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. | 12:12 |
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 | 12:15 |
tnt | Also not sure if you can drive one bit of a signal from sync and others from comb. | 12:15 |
pepijndevos[m] | hayyyyy | 12:19 |
pepijndevos[m] | reset_less actually solved it | 12:19 |
pepijndevos[m] | but yea probably because the pwm module is migen it got reset logic on the signal | 12:24 |
pepijndevos[m] | so probably another solution would be to split the header in multiple signals | 12:25 |
pepijndevos[m] | is there a way to see what modules are taking up resources? | 13:47 |
tnt | Depends on the target fpga | 13:50 |
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. | 13:51 |
jevinskie[m] | Unfortunately not, amaranth is needed for hierarchy generation | 13:52 |
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 | 13:53 |
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 | 13:58 |
pepijndevos[m] | So far it seems completely frozen on `Info: Running main analytical placer.` | 13:58 |
pepijndevos[m] | yeah... I reduced the luts of my stepper generator to <300 and it's still 85% and not progressing | 14:29 |
*** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 14:45 | |
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 | 14:48 |
tnt | probably depends on a lot of other factors. | 14:54 |
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. | 14:58 |
pepijndevos[m] | Another reason to have a single PWM controller that controls multiple outputs | 15:16 |
pepijndevos[m] | I would think 20% free space should be quite a lot but apparently not | 15:18 |
pepijndevos[m] | but yea if it can only use half of every slice then that's not going to work very well | 15:18 |
*** somlo_ is now known as somlo | 15:36 | |
*** mlaga97_ <mlaga97_!~quassel@user/mlaga97> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 15:53 | |
*** mlaga97 <mlaga97!~quassel@user/mlaga97> has joined #litex | 15:53 | |
pepijndevos[m] | hrm in a migen signal, what is the lsb and msb? Or like... how would I get the N most significant bits? | 15:57 |
pepijndevos[m] | `sig[len(sig)-N:-1]`?? | 15:58 |
tnt | sig[-N-1:-1] | 16:02 |
*** lukas[m]123 <lukas[m]123!~lukasself@2001:470:69fc:105::2:2f4f> has joined #litex | 20:24 | |
*** leons[m] <leons[m]!~leonsself@2001:470:69fc:105::2:2f50> has joined #litex | 20:27 | |
*** leons[m] <leons[m]!~leonsself@2001:470:69fc:105::2:2f50> has left #litex | 20:30 | |
*** lukas[m]123 <lukas[m]123!~lukasself@2001:470:69fc:105::2:2f4f> has left #litex | 21:17 | |
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 | 22:42 |
tpb | Title: Formal extensions to Verilog (at yosyshq.readthedocs.io) | 22:42 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!