06:56 <acathla> I have 2 questions. Context : we ( st-gourichon-fid and I ) are developping a replacement for the Kilobot (an ATMega328p with infrared and vibrating motors mostly).

06:58 <acathla> The goal was to have a faster CPU, more RAM, and faster and directional infrared communication (some Kb/s for the kilobot).

07:00 <acathla> We have a prototype board which is based on the fomu plus 4 infrared sensors (4 TS4231 chips to do basic analog to digital) and a K210 MCU.

07:03 <acathla> I modified the RS323PHYRX and TX modules for infrared and it works fine, but since it's an UART, writing 8 bits at a time makes it really slow.

07:05 <acathla> What would be the best idea to speed things up? Using parts of liteeth? (the memory mapped part to wishbone?)

07:08 <acathla> The first idea was to use a vexriscv as a main CPU, but it was too big at first so we added a K210 on the prototype. I don't know what's the best way to access the wishbone bus from an external MCU. It's using an UART now. SPIbone never passes the timings so I gave up.

07:09 <acathla> And a final question : are we doing it right?

07:35 <keesj> do I understand correctly that the bootleneck is the communication between the CPU and the infrared modules and that you have as many uarts as infrared sensors?

07:36 <keesj> What is a K210?

09:01 <acathla> 4 UARTs now as it was the most simple to do. And yes, the bottleneck is the communication between the SoftCore and the infrared UARTs. The second bottleneck is between the IR UARTs and the external MCU

09:03 <acathla> The K210 is a dual core 64 bits RISC-V MCU from Kendryte, with "IA" acceleration.

09:05 <keesj> how fast is the core running? and what bitrare is the IR uart sending data?

09:08 <acathla> Everything is now running @12MHz and the UARTs... I need to measure or calculate this, but that's the wait between each byte that is the worst

09:14 <keesj> so you kinda need a buffer on the uart side

09:16 <keesj> or be able to pipe requests

09:16 <acathla> About 8ms per byte.

09:18 <acathla> keesj, exactly. There is a FIFO, we tried to make it bigger than 16 bytes and it helps to send blindly bytes without losing them, but there are many writes to do on the bus for each byte

09:19 <acathla> And making the UART-wishbone interface more than 8 bits makes the design use too many LCs

09:22 <keesj> my understanding of withbone is mostly from reading https://zipcpu.com/zipcpu/2017/05/29/simple-wishbone.html is that wishbone itself would allow to send bytes every clock cycle

09:22 <tpb> Title: Building a simple wishbone slave (at zipcpu.com)

09:29 <keesj> so.. . would the bus bandwith not be like 12Mhz * 8 bits -> 96Mbis v.s. sending at 1 kbits.. it is like 3 order of magnitude faster ? so the fifo can't be a bottle neck right? if must be sendling logic e.g. while(!full) . push v.s. if (empty) push byte or possible the (!full itself that would cause wishbone interaction?)

09:30 <keesj> acathla: (I am an interested user) with only limited knowledge.

09:44 <acathla> The TS4231 receives signals from 1MHz to 10MHz, we chose to send 1 pulse (@ 6MHz, 80ns) and wait 240ns for a 0 and 480ns for a 1, plus a header.

09:46 <acathla> So the teorical speed is low if we send byte per byte. The real speed now is even slower.

09:48 <acathla> keesj, it's more 12MHz / 8 bits than a multiplication.

10:00 <acathla> Thanks for the link keesj. I have limited knowledge too, we all have. Except _florent_ about litex :)

14:30 <_florent_> acathla: what's your target speed for the transfers between the CPU and the UARTs?

14:32 <_florent_> UART is not very fast, not with lxterm we are already able to upload code at up to 500KB/s to the CPU with the USB FIFO (with a 75MHz CPU)

14:34 <_florent_> You are probably using a lite variant of CPU + 12MHz, so that's not helping, but not sure the bottleneck is really related to using UART

14:35 <_florent_> Have you tried using a simulation (litex_sim for example) to try to understand the real bottleneck?

14:35 <_florent_> You could also use a larger FPGA board (Arty for example) with your design + LiteScope to analyze the transfers on the wishbone bus

14:38 <acathla> _florent_, I captured the transmission but it was a long time ago with probably a SERV CPU...

14:39 <_florent_> acathla: ah ok, with SERV it's also not helping

14:40 <acathla> I just thought it could be better to send a frame of 1500 bytes like in ethernet, with header, CRC, etc

14:40 <_florent_> acathla: in fact I'm not sure to understand, are you still using SERV or switch to VexRiscv?

14:40 <_florent_> switch/switched

14:40 <acathla> I switch to SERV when the design is full but the goad is to use VexRiscv of course.

14:40 <acathla> goal*

14:48 <acathla> But first we hoped we could do without a real MCU

14:49 <acathla> I'm not sure the K210 will stay, it will probably be optionnal.

14:50 <acathla> The goal is to build hundreds of robots, so the cost must stay as low as possible.

14:59 <acathla> _florent_, probably 100KB/s would be enough, I don't remember how much we can achieve now, but much more less, around a 2KB/s probably.

15:00 <acathla> You think it's overkill to add a shared memory like it's done in liteeth?

15:18 <_florent_> acathla: I'm not sure I have all the info I need, but that's sure that 12MHz + SERV + 8-bit CSR is limiting the capabilities

15:19 <_florent_> just taking into account maximum bus efficiency and freq + 1/32 ratio of SERV: 12e6/(2*32*4) = 47KB/s max

15:22 <acathla> I'll make some more tests now I got rid of USB and I have more room for everything.

15:24 <somlo> _florent_: apparently the litesdcard linux driver *does* have a say in whether single- or multi-block transfers are used (cmd 17 vs. 18 for e.g., reading): https://github.com/litex-hub/linux/blob/litex-rebase/drivers/mmc/host/litex_mmc.c#L452

15:25 <somlo> right now the max block count is set to 1, which somehow percolates through the mmc subsystem and results in cmd17 being used exclusively :)

15:25 <somlo> if I try to bump max_blk_count I get data transfer errors, so debugging *that* will be my next goal

15:25 <somlo> that and figuring out why I can't meet timing in vivado for the genesys2 board...

15:31 <_florent_> somlo: Hi, ok thanks. I've not yet been able to do the P&R on the Genesys2, I'll try it soon

19:00 <mithro> _florent_: You might find https://ohwr.org/project/conv-ttl-blo-gw/wikis/xil-multiboot interesting....

19:00 <tpb> Title: Xil multiboot · Wiki · Projects / Conv TTL Blocking - Gateware · Open Hardware Repository (at ohwr.org)

19:54 <keesj> what is serv?

19:55 <keesj> https://github.com/litex-hub/pythondata-cpu-serv ?

19:56 <keesj> SERV is an award-winning bit-serial RISC-V core

20:02 <Finde> there's your answer

20:03 <Finde> always love Olof's "award winning" prefix

20:31 <keesj> https://www.zerotoasic.com/contact/

20:31 <tpb> Title: Sign up | Zero to ASIC (at www.zerotoasic.com)

20:34 <keesj> 500 Euro but it .. sounds very cool

20:39 <keesj> I have played a little with some of the parts but love the idea

21:14 <oter> joseng I haven't used LiteDRAMFIFO specifically. In my case, the solution to my difficulty in using LiteDRAMDMAReader (which LiteDRAMFIFO build upon) was that I botched the translation from the 32 bit memory map address to the 25 bit width for DMA. Solved now, but doesn't sound like it'll help in your case - the DMA etc is completely hidden inside LiteDRAMFIFO. My only thought is that perhaps there's something wrong with how the read and

21:14 <oter> write ports you pass into the FIFO module are obtained, or that the base is set wrong (since they are native, they will be very wide, e.g. 128 bit in case of my board)?