| *** tpb has joined #litex | 00:00 | |
| *** shenki has quit IRC | 00:11 | |
| *** lf has quit IRC | 00:19 | |
| *** lf has joined #litex | 00:19 | |
| *** martinraison has joined #litex | 00:24 | |
| *** martinraison has quit IRC | 00:28 | |
| *** Bertl_oO is now known as Bertl_zZ | 02:48 | |
| *** futarisIRCcloud has joined #litex | 03:53 | |
| *** martinraison has joined #litex | 04:12 | |
| *** martinraison has quit IRC | 04:17 | |
| *** Degi_ has joined #litex | 04:32 | |
| *** Degi has quit IRC | 04:33 | |
| *** Degi_ is now known as Degi | 04:33 | |
| 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:56 |
|---|---|---|
| acathla | The goal was to have a faster CPU, more RAM, and faster and directional infrared communication (some Kb/s for the kilobot). | 06:58 |
| 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:00 |
| 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:03 |
| acathla | What would be the best idea to speed things up? Using parts of liteeth? (the memory mapped part to wishbone?) | 07:05 |
| *** lkcl has quit IRC | 07:06 | |
| 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:08 |
| acathla | And a final question : are we doing it right? | 07:09 |
| *** lkcl has joined #litex | 07:20 | |
| 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:35 |
| keesj | What is a K210? | 07:36 |
| *** martinraison has joined #litex | 07:48 | |
| 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:01 |
| acathla | The K210 is a dual core 64 bits RISC-V MCU from Kendryte, with "IA" acceleration. | 09:03 |
| keesj | how fast is the core running? and what bitrare is the IR uart sending data? | 09:05 |
| 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:08 |
| keesj | so you kinda need a buffer on the uart side | 09:14 |
| keesj | or be able to pipe requests | 09:16 |
| acathla | About 8ms per byte. | 09:16 |
| 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:18 |
| acathla | And making the UART-wishbone interface more than 8 bits makes the design use too many LCs | 09:19 |
| 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:22 |
| *** Dolu has joined #litex | 09:27 | |
| 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:29 |
| keesj | acathla: (I am an interested user) with only limited knowledge. | 09:30 |
| *** Bertl_zZ is now known as Bertl | 09:34 | |
| 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:44 |
| acathla | So the teorical speed is low if we send byte per byte. The real speed now is even slower. | 09:46 |
| acathla | keesj, it's more 12MHz / 8 bits than a multiplication. | 09:48 |
| *** hansfbaier has joined #litex | 09:55 | |
| acathla | Thanks for the link keesj. I have limited knowledge too, we all have. Except _florent_ about litex :) | 10:00 |
| *** hansfbaier has quit IRC | 10:37 | |
| *** martinraison has quit IRC | 11:26 | |
| *** martinraison has joined #litex | 11:29 | |
| *** martinraison has quit IRC | 12:43 | |
| *** martinraison has joined #litex | 12:58 | |
| *** martinraison has quit IRC | 13:02 | |
| *** martinraison has joined #litex | 13:12 | |
| *** _whitelogger has quit IRC | 13:55 | |
| *** _whitelogger has joined #litex | 13:58 | |
| _florent_ | acathla: what's your target speed for the transfers between the CPU and the UARTs? | 14:30 |
| _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:32 |
| _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:34 |
| _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:35 |
| acathla | _florent_, I captured the transmission but it was a long time ago with probably a SERV CPU... | 14:38 |
| _florent_ | acathla: ah ok, with SERV it's also not helping | 14:39 |
| 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:40 |
| _florent_ | and what's your target speed vs achieved speed? | 14:44 |
| zyp | acathla, remote wishbone is gonna have a latency no matter what transport you pick, so you should probably consider doing a purpose-designed protocol instead | 14:45 |
| acathla | zyp, you mean avoid wishbone? | 14:45 |
| *** _whitelogger has quit IRC | 14:46 | |
| acathla | i thought of that, since it's UARTs and the K210 have UARTs available | 14:46 |
| zyp | what purpose is the fpga serving in the design when you've got a K210? | 14:46 |
| acathla | the k210 could probably not handle the signal of the TS4231 directly without bigbanging, so 4 at a time doesnt seem feasible. | 14:48 |
| *** _whitelogger_ has joined #litex | 14:48 | |
| acathla | But first we hoped we could do without a real MCU | 14:48 |
| acathla | I'm not sure the K210 will stay, it will probably be optionnal. | 14:49 |
| acathla | The goal is to build hundreds of robots, so the cost must stay as low as possible. | 14:50 |
| 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. | 14:59 |
| acathla | You think it's overkill to add a shared memory like it's done in liteeth? | 15:00 |
| *** lkcl has quit IRC | 15:16 | |
| _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:18 |
| _florent_ | just taking into account maximum bus efficiency and freq + 1/32 ratio of SERV: 12e6/(2*32*4) = 47KB/s max | 15:19 |
| acathla | I'll make some more tests now I got rid of USB and I have more room for everything. | 15:22 |
| 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:24 |
| 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:25 |
| *** lkcl has joined #litex | 15:30 | |
| _florent_ | somlo: Hi, ok thanks. I've not yet been able to do the P&R on the Genesys2, I'll try it soon | 15:31 |
| *** andrewb1999 has joined #litex | 17:44 | |
| *** martinraison has quit IRC | 18:56 | |
| 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:00 |
| *** Bertl is now known as Bertl_oO | 19:06 | |
| *** martinraison has joined #litex | 19:50 | |
| keesj | what is serv? | 19:54 |
| *** martinraison has quit IRC | 19:55 | |
| keesj | https://github.com/litex-hub/pythondata-cpu-serv ? | 19:55 |
| keesj | SERV is an award-winning bit-serial RISC-V core | 19:56 |
| Finde | there's your answer | 20:02 |
| Finde | always love Olof's "award winning" prefix | 20:03 |
| *** martinraison has joined #litex | 20:05 | |
| keesj | https://www.zerotoasic.com/contact/ | 20:31 |
| tpb | Title: Sign up | Zero to ASIC (at www.zerotoasic.com) | 20:31 |
| keesj | 500 Euro but it .. sounds very cool | 20:34 |
| *** _franck_ has joined #litex | 20:38 | |
| keesj | I have played a little with some of the parts but love the idea | 20:39 |
| *** kgugala has joined #litex | 20:40 | |
| 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)? | 21:14 |
| *** martinraison has quit IRC | 21:46 | |
| *** martinraison has joined #litex | 23:01 | |
| *** martinraison has quit IRC | 23:07 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!