01:07 <Xesxen_> Heya! I'm trying to build litex for the fomu, but I keep running into this when yosys is being run: ERROR: Module `\IFS1P3BX' referenced in module `\fomu_pvt' in cell `\IFS1P3BX_1' is not part of the design. This is with running "python -m litex_boards.targets.fomu --cpu-type=serv --build" after running "python ./litex_setup.py init install --user" in a clean directory. Does anyone know why? I'm running yosys Yosys 0.9+3619 / c403c984 (which is the latest

01:07 <Xesxen_> commit on master currently)

07:01 <_florent_> Xesxen: hi, sorry, there is still a manual modification needed: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/fomu.py#L85

07:01 <tpb> Title: litex-boards/fomu.py at master · litex-hub/litex-boards · GitHub (at github.com)

07:14 <sajattack[m]> are there any example programs communicating with the cle215+ over litepcie? At a very basic level. I saw the UART issue and that's about the level of complexity I think I could handle

07:14 <sajattack[m]> the linux kernel driver is great, but I don't quite understand how to transfer data back and forth

09:46 <_florent_> sajattack[m]: the easiest is probably with litex_server: https://github.com/enjoy-digital/litex/wiki/Use-Host-Bridge-to-control-debug-a-SoC#add-a-pcie-bridge-to-your-soc

09:46 <tpb> Title: Use Host Bridge to control debug a SoC · enjoy-digital/litex Wiki · GitHub (at github.com)

09:46 <_florent_> at least to use the MMAP interface

09:48 <_florent_> i should improve the examples, but this will already allow you to access the registers of the SoC from python scripts

09:48 <_florent_> if you have a specific use-case on mind, i could try to give directions

09:49 <sajattack[m]> I was thinking about a pcie sha1 accelerator interfacing with a rust program running on linux

09:49 <sajattack[m]> python looks friendly but might slow things down a bit

09:52 <sajattack[m]> correct me if I'm wrong, but I thought mmap was for mapping a file into memory. How do you do transfers back and forth with it?

09:55 <_florent_> ok, the MMAP interface is use to access the main bus of the SoC, this can be used to do transfers, but it's indeed slow

09:55 <_florent_> for your case, you use the DMAs with minimal modification to the examples

09:56 <_florent_> for example, we create a DMA here: https://github.com/enjoy-digital/litepcie/blob/master/examples/kc705.py#L83-L87

09:56 <tpb> Title: litepcie/kc705.py at master · enjoy-digital/litepcie · GitHub (at github.com)

09:56 <_florent_> this DMA will have a source for the data coming from the Host and sink for the data going to the Host

09:57 <_florent_> on the software side

09:58 <sajattack[m]> what does that look like on the linux/software side?

09:58 <_florent_> with dma test, we are connecting the source to the sink internally and verifying that we can do a dma loopack in the FPGA: https://github.com/enjoy-digital/litepcie/blob/master/litepcie/software/user/litepcie_util.c#L303

09:58 <tpb> Title: litepcie/litepcie_util.c at master · enjoy-digital/litepcie · GitHub (at github.com)

09:59 <_florent_> and if you just want to use the source/sink to receive/send data, you can use litepcie_test: https://github.com/enjoy-digital/litepcie/blob/master/litepcie/software/user/litepcie_test.c

09:59 <tpb> Title: litepcie/litepcie_test.c at master · enjoy-digital/litepcie · GitHub (at github.com)

09:59 <_florent_> ./litepcie_test -c 0 play file.bin will generate file.bin on the source interface in the FPGA

10:00 <_florent_> ./litepcie_test -c 0 record file.bin 1024 will save the first 1024 bytes of the sink stream in the FPGA to file.bin

10:00 <_florent_> for more information on the streams: https://github.com/enjoy-digital/litex/wiki/Streams

10:00 <tpb> Title: Streams · enjoy-digital/litex Wiki · GitHub (at github.com)

10:03 <sajattack[m]> yeah I was looking at that litepcie_test but didn't quite understand it

10:04 <sajattack[m]> I thought it was for recording bus traffic and playing it back or something

10:06 <sajattack[m]> but it looks like maybe I can make my own program and just call litepcie_write and litepcie_read to do dma transfers?

10:07 <_florent_> yes sure, litepcie_test is just an example to exercise the DMAs

10:15 <sajattack[m]> it's not as simple as calling read and write on the file descriptor is it?

10:18 <sajattack[m]> if you could, a simpler example of sending a string and retrieving a response from the fpga would be helpful for my understanding

10:19 <sajattack[m]> * it's not as simple as calling linux open, read and write syscalls on /dev/litepcie0 or something is it?

10:24 <sajattack[m]> my naive plan is

10:24 <sajattack[m]> retrieve sha1 of string

10:24 <sajattack[m]> send string

10:34 <sajattack[m]> thinking of using this btw https://github.com/secworks/sha1

10:34 <tpb> Title: GitHub - secworks/sha1: Verilog implementation of the SHA-1 cryptgraphic hash function (at github.com)

11:07 <_florent_> sajattack[m]: it's almost as you are describing, but you still need to control the DMA. you could start by having a poll of strings you want to encode in strings.bin

11:07 <_florent_> and do ./litepcie_test -c 0 play string.bin

11:08 <_florent_> and in another terminal: ./litepcie_test -c record sha1.bin

11:08 <_florent_> -c 0

11:08 <sajattack[m]> ok

11:09 <_florent_> and in the FPGA integrate the sha1 module between the DMA source and sink

11:09 <sajattack[m]> yeah

11:09 <_florent_> DMA.source --> SHA1 --> DMA.sink

11:09 <_florent_> and you'll just receive the encoded data in sha1.bin

11:09 <sajattack[m]> thanks

11:13 <sajattack[m]> I wonder, is there a better solution for streaming data in and out than files though? I'm sending quite a lot of strings so I guess I would need to create many files

11:15 <sajattack[m]> it's workable but doesn't seem too elegant

11:19 <sajattack[m]> I think it's on the order of 10TB of strings 😅

11:58 <_florent_> sajattack[m]: yes sure, that's just a first example, you can customize litepcie_test for your need or use pipes

15:11 <st-gourichon-fid> Hi! We use the new CSRField feature here. In a design, when using registers holding several values, we typically need an "extract" function and an "inject" function.

15:12 <st-gourichon-fid> "extract" takes a 32bit word and provides a plain value extracted at offset and size.

15:12 <st-gourichon-fid> "inject" takes a 32bit word and modifies only the bit between offset (included) and offset+size (excluded) to reflect the value you want to inject.

15:14 <st-gourichon-fid> So far so good. I'm pondering whether it is best to generate per-field dedicated extract() and inject() functions in csr.h, or if it is best to create a C-level macro that calls a generic extract() and a generic inject() with preprocessor magic to use the correct FIELDNAME_OFFSET and FIELDNAME_SIZE.

15:15 <st-gourichon-fid> In the first case I would provide a PR because I changes litex/soc/integration/export.py . I the second case I can just not share the extract and inject functions and macro.

15:16 <st-gourichon-fid> All of this is plain old C-close-to-hardware-level bit handling, just I see the opportunity for litex to provide some convenience... or not?

15:30 <st-gourichon-fid> Generating them all has the benefit of autocompletion in IDEs.

20:05 <sajattack[m]> is a 512 bit CSR possible and/or a bad idea?

21:51 <sajattack[m]> I get this error when trying to build the acorn_cle_215 target `python acorn_cle_215.py --build` `litex.build.generic_platform.ConstraintError: Resource not found: serial:None`