| *** tpb has joined #litex | 00:00 | |
| *** futarisIRCcloud has joined #litex | 03:35 | |
| *** futarisIRCcloud has quit IRC | 07:14 | |
| keesj | interesting problem | 07:46 |
|---|---|---|
| *** daveshah has quit IRC | 07:50 | |
| *** mithro has quit IRC | 07:53 | |
| *** mithro has joined #litex | 07:54 | |
| *** nrossi has quit IRC | 07:56 | |
| *** Finde has quit IRC | 07:56 | |
| *** nrossi has joined #litex | 08:01 | |
| *** Finde has joined #litex | 08:01 | |
| *** daveshah has joined #litex | 08:01 | |
| *** daveshah has quit IRC | 12:52 | |
| *** daveshah has joined #litex | 12:53 | |
| *** ambro718 has joined #litex | 15:54 | |
| ambro718 | Is it correct that CSRs can be 32-bit but it will not provide atomic access but 4 8-bit accesses? | 18:50 |
| daveshah | https://www.irccloud.com/pastebin/IYJarAAq/ | 19:11 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 19:11 |
| daveshah | Have the TrellisBoard (https://github.com/daveshah1/TrellisBoard) working with LiteX VexRiscv Linux | 19:12 |
| tpb | Title: GitHub - daveshah1/TrellisBoard: Ultimate ECP5 development board (at github.com) | 19:12 |
| daveshah | Had to do various hacks to get 1GB of RAM working (including shuffling address about and modifying the address decoding) | 19:12 |
| daveshah | Will try and submit something a bit neater in the next few days | 19:12 |
| _florent__ | ambro718: yes that's correct about CSRs | 19:39 |
| ambro718 | ok thanks | 19:39 |
| _florent__ | daveshah: nice :) there is indeed a limitation of 256MB that i should remove | 19:40 |
| _florent__ | daveshah: have you done the schematic/routing of the trellis board yourself? How much do you expect it to cost if you do a small batch? | 19:41 |
| ambro718 | _florent__: I have set out to implement DMA for liteeth by going via Wishbone through the L2 cache in SoCSDRAM, that is by calling soc.sdram.add_wb_sdram_if() twice (for RX and TX DMA). Does that make sense to you? | 19:41 |
| daveshah | _florent__: yup did it in KiCad | 19:42 |
| ambro718 | It's a 32-bit interface but should certainly be fast enough for 100mbit Ethernet, but questionable for 1gbit. | 19:42 |
| daveshah | Cost for the first prototype batch of 3 was $2142 total assembled from Elecrow | 19:42 |
| ambro718 | _florent__: it will be presented like a third "interconnect" option for LiteEthMAC, "withbone_dma" in addition to current "crossbar" and "wishbone". | 19:43 |
| sorear | neat board | 19:43 |
| sorear | curious what the breakdown is on that 2142 / what are the important cost drivers | 19:44 |
| _florent__ | daveshah: ok thanks, nice work! | 19:48 |
| _florent__ | ambro718: that seems fine yes, the only convert i can have is indeed the available bandwidth, maybe you'll have to add a packet buffer, this way for TX, you first store packets in the core, then do the DMA with the wishbone, and the opposite for RX | 19:50 |
| ambro718 | _florent__: LiteEthMACCore does not have any integrated buffers? | 19:51 |
| daveshah | sorear: about $525 for the bare board, $800 for parts and $790 for assembly | 19:51 |
| _florent__ | ambro718: there is a fifo, but not a packet buffer | 19:52 |
| _florent__ | ambro718: another option would be to reuse the sram writer/reader, and do a DMA on top of that | 19:52 |
| daveshah | FPGA about $70 each, no other massively expensive parts but they all add up in aggregate to the $267 per board | 19:53 |
| ambro718 | _florent__: I am planning to have the CPU configure the address in DRAM where addresses and lengths of memory buffers are, and push buffers (to be transmitted / available to be filled with received data) to the core by writing number to a register (how many buffers to push) | 19:54 |
| ambro718 | For Tx, the core would first read the memory address and buffer size from DRAM, then read the data from the referenced DRAM address and transmit it. | 19:54 |
| ambro718 | So there would be a circular buffer of buffers, for Rx and Tx separately. | 19:55 |
| ambro718 | there would be a status register telling you the number of buffers in each circular buffer, allowing the CPU to see how many buffers have already been transmitted / filled with received data. | 19:56 |
| ambro718 | I think all that's necessary is that the FIFOs are large enough to deal with the latency of reading/writing data from/to DRAM but also this bookkeeping to figure out the next buffer address. | 19:57 |
| _florent__ | ambro718: in fact, maybe you could just write a generic DMA for LiteX (read from wishbone, write to wishbone) and just use this for LiteEth with the current SRAM buffers | 19:57 |
| keesj | what kind of crazy projects are you doing ambro718 ? | 19:57 |
| _florent__ | ambro718: this way you already have the circular buffers | 19:57 |
| keesj | really cool | 19:58 |
| ambro718 | _florent__: You are completely correct, that's what I'll do. Write DMA core will read from stream and write to WB, and read DMA core will read from DRAM via WB and write to stream. | 19:59 |
| keesj | daveshah: also .. very uber cool | 20:00 |
| ambro718 | keesj: I'm just trying to get ethernet working properly for linux-on-litex-vexriscv, for fun :) | 20:00 |
| ambro718 | _florent__: the bandwidth problem could be addressed by making the WB interface of the L2 cache wider? | 20:01 |
| ambro718 | There is no simple way to expose a 16-bit status register on CSR atomically? | 20:05 |
| ambro718 | I need to expose a status for the current number of buffers the dma is responsible for, and that being read out incorrectly is not an option. | 20:07 |
| ambro718 | _florent__: wait I misunderstood you, why would I use the current SRAM buffers? | 20:09 |
| ambro718 | Data should go automatically to/from DRAM to the right places without the CPU having to start a DMA transfer for each packet (that's inefficient). | 20:11 |
| ambro718 | Seems a bit wasteful to transfer to SRAM first and then from SRAM to DRAM. | 20:13 |
| ambro718 | It should to straight from/to DRAM but have a large enough FIFO to work. | 20:14 |
| _florent__ | yes the generic DMA solution is less efficient | 20:21 |
| keesj | the next leap is litex on linux self hosting | 20:21 |
| _florent__ | with a large FIFO, your solution should work fine | 20:22 |
| ambro718 | It's still going to be generic but in the sense that it will allow you to write data from any stream into DRAM based on a circular buffer of buffers itself managed in DRAM (and similar for read). | 20:23 |
| _florent__ | ambro718: if that's not fast enough, we'll see how to improve the bandwidth | 20:23 |
| ambro718 | Also seems less fragile (less pieces). | 20:24 |
| ambro718 | How will inheriting an internal helper base class work in a class inheriting Module? I want to put some things common to Rx and Tx into a base class. | 20:42 |
| ambro718 | What's the best way to define a CSR that allows the CPU to send a simple signal to the core? | 20:56 |
| ambro718 | One write by CPU results in the core seeing the signal exactly one clock cycle. | 20:57 |
| ambro718 | Do litex cores need custom implementation of reset? | 21:06 |
| _florent__ | ambro718: for inheriting, you can create a common class and inheritate from it in your Rx/Tx classes, that's similar to how you would do it in others Python scripts | 21:19 |
| _florent__ | ambro718: If you can to trigger some logic on CPU writes, you can create a CSR() and then use .r/.re | 21:20 |
| _florent__ | ambro718: for the reset, no need to implement it, you can use ResetInserter on top of your module | 21:20 |
| ambro718 | I need a signal from the CPU to make the core update the value in a different 16-bit CSR so it can be read atomically. | 21:22 |
| ambro718 | 1-bit CSRStatus? Or will 0 bit work? | 21:22 |
| *** Dolu has quit IRC | 21:51 | |
| *** Dolu has joined #litex | 21:52 | |
| ambro718 | What happens if I assign to a signal multiple times in sync? In particular, I have some logic that conditionally increments it by some number, and some logic that conditionally decrements it by one. | 22:02 |
| *** futarisIRCcloud has joined #litex | 22:02 | |
| ambro718 | Will this magically work or do I need special handling? | 22:02 |
| *** Dolu has quit IRC | 22:15 | |
| *** Dolu has joined #litex | 22:18 | |
| *** ambro718 has quit IRC | 22:25 | |
| *** Dolu has quit IRC | 22:53 | |
| *** Dolu has joined #litex | 23:45 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!