03:56 <ChuckM> Has anyone else tried building 'scarabminispartan6+' from targets recently? I'm getting a bunch of warnings and this error is fatal:

03:56 <ChuckM> WARNING:HDLCompiler:1499 - "/home/cmcmanis/litex-boards/litex_boards/targets/build/scarabhardware_minispartan6/gateware/scarabhardware_minispartan6.v" Line 4: Empty module <scarabhardware_minispartan6> remains a black box.

03:56 <ChuckM> Sorry that is from this: ERROR:HDLCompiler:267 - "/home/cmcmanis/litex-boards/litex_boards/targets/build/scarabhardware_minispartan6/gateware/scarabhardware_minispartan6.v" Line 5287: Cannot find port PWRDWN on this module

06:27 <_florent_> ChuckM: This was probably your issue: https://github.com/enjoy-digital/litex/pull/962 Updating LiteX should fix it

06:39 <sajattack[m]> I saw liteeth made it to upstream linux. Any hopes for litepcie too?

06:41 <sajattack[m]> I still gotta find a project for my acorn

09:34 <mc6808> I started simulating a design with a fsm today and noticed that the fsm state variable bit width was way off, more than 70 bits for a design that uses 3 bits in the FPGA. Anyone else have this issue?

09:35 <tnt> 70 seems a bit much ... but synthesis tool will often re-encode state variable to be one-hot for instance.

09:36 <_florent_> sajattack[m]: For now we are trying to upstream the driver for peripherals that are directly attached to the CPU, LitePCIe is a bit different since run on the Host and is used as a kernel module

09:38 <mc6808> TNT: I tried simulating corefsm here https://github.com/litex-hub/fpga_101/blob/master/lab002/solutions/core.py

09:39 <mc6808> And got a similar huge bit width. My design only has 3 states so is 1 bit hot as you referenced

09:46 <tnt> Oh, isn't migen sim encoding the state _name_ (as ascii) in the signal ?

09:49 <mc6808> TNT: I have no idea. I'm new to this, but I thought the enumerations would be mapped not literal strings in the signal

09:53 <mc6808> Gtkwave doesn't like the output much either way and I thought it supported enumerators for numeric values

10:14 <sajattack[m]> I can't for the life of me get linux vexriscv to work on pcie

10:16 <sajattack[m]> when I flash the bitstream which I've modified to have pcie turned on, I get no "FPGA identification" from litepcie_util info

10:17 <sajattack[m]> and then I have to reflash the litex_boards bitstream over spi

10:21 <sajattack[m]> vivado warnings

12:20 <leons> florent: I'm now stuck working on the last_be issues for the Packetizer and Depacketizer for multiple days. It's a really hard problem. What makes it so much more complex is that last_be is an optional signal for the Packetizer and Depacketizer.

12:21 <leons> Would you be accepting a fix for the last_be handling in these constructs, which internally always has a last_be signal? As far as I understand, we could simply add one internally to the sink and remove it from the exposed source

12:23 <leons> So the external interface wouldn't change, but it would have last_be handling internally. I would expect this to be optimized, though I'm not sure

13:21 <a3f> sajattack: I can't recall if it was the same warnings you have, but try commenting out the SATA parts

13:55 <_florent_> sajattack[m]: Sorry I haven't tested Linux on the Acorn with the PCIe enabled. You can try to check the CSR mapping between the version with and without PCIe to be sure it's not different

14:05 <bluecmd> sajattack: maybe too basic question, but do you see the card listed in lspci? People sometimes forget that you can't just hotplug PCIe devices (which effectively uploading a new FPGA bitstream is).

15:15 <leons> florent: Actually, regarding Packetizer/Depacketizer, with some debugging help of david-sawatzke I've figured it out. Will update the PR and also add tests soon

15:15 <leons> It's really hard to know whether it works in every edge case, but I'm somewhat confident for now

15:44 <_florent_> leons: perfect, thanks. That's indeed why I'd like these edge case to be integrated in the test, this way we'll be sure to not break them with future modifications

15:45 <_florent_> leons: This module is maybe now trying to do too much things, it can eventually be worth handling some cases separately. I'll have a look at this while reviewing

15:46 <leons> I'll have to see how we can integrate them. I think the `test_packet` tests do a pretty good job of testing edge cases already, one particular issue I might see with that is that the Packetizer is directly connected to the Depacketizer and so we can't really introspect what's going on between them. It might just work coincidentally because both an error is tolerated by either one of them or they might both be wrong.

15:47 <leons> florent: feel free to take a look. I've got to say, this was a tough nut to crack. If you have any ideas how it could be improved that'd be great, but I'm just happy to see it seems to at least work now :)

15:54 <_florent_> leons: Thanks for looking at this

17:25 <sajattack[m]> <bluecmd> "sajattack: maybe too basic..." <- I see it in lspci and I rebooted

17:26 <sajattack[m]> <a3f> "sajattack: I can't recall if..." <- I did already

18:45 <tpw_rules> _florent_: can i PM you a link for the build?

19:10 <tpw_rules> is there a good overview of zynq dev boards anywhere? i am looking for something that has SATA or USB3 attached to the PS and can do MIPI in the PL

19:18 <_florent_> tpw_rules: yes sure for the build

19:22 <_florent_> tpw_rules: the Kria KV260 has USB3 and MIPI and is cheap: https://www.xilinx.com/products/som/kria/kv260-vision-starter-kit.html

20:34 <tpw_rules> _florent_: ah, that looks nice. has anyone tried litex on it?

20:46 <tpw_rules> not sure i want to deal with vitis, etc.

21:16 <ChuckM> Have you looked at the Ultra96 board? https://www.avnet.com/wps/portal/us/products/new-product-introductions/npi/aes-ultra96-v2/

21:16 <tpb> Title: Avnet: Quality Electronic Components & Services (at www.avnet.com)

21:18 <tpw_rules> i did come across that one, but it seems the Kria board is better in essentially every way, no?

21:18 <tpw_rules> except size

22:11 <tpw_rules> bah, it seems there is some nondeterminism in the jtag_uart build with the nitefury. if i set the mode to anything other than cle-215+, or use a different version of vivado than 2018.2, or modify the code, it doesn't work. the uart doesn't echo as if the cpu has crashed once the console comes up

23:14 <sajattack[m]> <_florent_> "sajattack: Sorry I haven't..." <- I'm not really sure what I should be looking for...

23:40 <mc6808> TNT: you were correct about simulation writing acsii to the VCD file. thanks for the tip!