| *** tpb has joined #litex | 00:00 | |
| *** futarisIRCcloud has joined #litex | 01:37 | |
| *** sb0 has joined #litex | 05:53 | |
| sb0 | _florent__: https://github.com/enjoy-digital/litedram/blob/master/test/test_upconverter.py#L94 | 05:53 |
|---|---|---|
| tpb | Title: litedram/test_upconverter.py at master · enjoy-digital/litedram · GitHub (at github.com) | 05:53 |
| sb0 | when there is a single clock domain you can omit this; also, "generators" can be a simple list | 05:53 |
| sb0 | same in test_downconverter.py | 05:54 |
| _florent__ | sb0: thanks, yes that's what i'm doing in others simulations, i'll fix | 07:18 |
| *** sb0 has quit IRC | 10:54 | |
| *** ambro718 has joined #litex | 15:32 | |
| ambro718 | How do I write a non-linux program to run on linux-on-litex-vexriscv for test purposes? | 15:37 |
| _florent__ | ambro718: here is a minimal firmware (you can remove the sdram_bist part): https://github.com/enjoy-digital/chubby75/tree/master/firmware | 15:52 |
| tpb | Title: chubby75/firmware at master · enjoy-digital/chubby75 · GitHub (at github.com) | 15:52 |
| _florent__ | once compiled, you can load it over serial with : lxterm /dev/ttyUSBX --kernel=firmware.bin | 15:52 |
| ambro718 | Thanks! | 15:52 |
| ambro718 | _florent__: For transmission with DMA, I think I would need to delay emptying the FIFO until either the FIFO is full or the entire packet is in the FIFO. Can probably be done by adding something between the FIFO sink and the following Ethernet pipeline. | 16:10 |
| ambro718 | s/sink/source/ | 16:10 |
| ambro718 | So it doesn't happen that just when the DMA starts giving data, transmission starts and runs out of data. | 16:11 |
| ambro718 | I suppose it would help to keep track of how many "last" data are in the FIFO. | 16:17 |
| _florent__ | ambro718: yes, that's why i was suggesting adding packet FIFO when we first discussed that | 16:24 |
| _florent__ | ambro718: i think i already needed a such fifo, i'll try to find some code | 16:28 |
| ambro718 | If you don't find it I can just code it as a wrapper around a normal FIFO though. | 16:32 |
| _florent__ | i'm not able to find it right now, but yes that was a wrapper around SyncFIFO | 16:40 |
| somlo | anyone using verilator v4 (curious about multithreaded support)? | 17:14 |
| _florent__ | somlo: i tried it but multithreading was slower with litex_sim | 17:33 |
| somlo | simulating a MMU-enabled rocket is rather slow, so I was hoping to speed it up a bit :) | 17:40 |
| somlo | _florent__, what did you have to change in litex_sim to specify multithreading in verilator ? (I'm still kinda hoping threading speedup will kick in with "bigger" designs) | 17:43 |
| _florent__ | somlo: add --threads=n to your litex_sim command | 17:44 |
| somlo | oh, that simple -- nice, thanks! | 17:44 |
| _florent__ | also, i recently added --opt-level command to select speeding up compilation time or execution time | 17:46 |
| _florent__ | command/parameter | 17:46 |
| somlo | yeah, I see that now (finally occurred to me to run "litex_sim.py --help") :) | 17:47 |
| somlo | I'll go ahead and install v4, and see if/what it does for me (as soon as my 8MB tftp of BBL+Linux either completes, dies, or I get tired of waiting for it) :) | 17:49 |
| somlo | as it turns out, the "standard" rocket variant we have in LiteX has no MMU; so I created a MMU-enabled variant, but that's too big (128%) for my 45K ecp5 on the versa board | 17:51 |
| somlo | and I never got litedram working at 50MHz on the nexys4ddr... | 17:51 |
| somlo | so I'm stuck with the simulator for now... | 17:52 |
| somlo | _florent__: somewhat unrelated, what's the bigger picture behind the naming convention of allowed variant names? | 18:00 |
| somlo | is "linux" bigger than "full", or are they orthogonal? | 18:00 |
| somlo | I was considering adding an FPU-enabled variant (which will never fit on an ecp5, but does fit comfortably on the artix7 on nexys4ddr) | 18:00 |
| somlo | and apparently "linuxfp" (linux capable *plus* floating-point) is not a good variant name | 18:01 |
| somlo | so I'm thinking "full", but is that assumed to be "lesser" than linux for other cpu types? | 18:02 |
| _florent__ | somlo: you can still give it a specific name if you want | 18:02 |
| _florent__ | if you are calling the others linux, you can call it linux-fpu | 18:02 |
| somlo | ok, but just doing that in .../rocket/core.py is not enough, I'd have to add an entry in CPU_VARIANTS in soc_core.py, so that InvalidCPUVariantError won't yell at me when I actually try and build one | 18:04 |
| somlo | which I'm ok doing, I was just trying to understand the convention before I went blundering in and screwing something up :) | 18:05 |
| _florent__ | mithro tried to standardized the variants' names but we should still be able to give specific name if needed | 18:07 |
| _florent__ | we should probably be able to disable the InvalidCPUVariantError | 18:07 |
| somlo | well, "full (alias: everything)" does fit a MMU *and* FPU enabled "Big" rocket core configuration | 18:11 |
| somlo | so I'm inclined to just go with that, unless it's specifically assumed to be "worse" or "lesser" than the "linux" variant :) | 18:12 |
| *** mnr has joined #litex | 18:54 | |
| somlo | to follow up on the numbers we were passing around the other day, a LiteX SoC with a full MMU+FPU Rocket core would need a mythical 140Kcell ecp5 FPGA :) | 18:57 |
| mnr | somlo: <tongue-in-cheek> Doing it the 68020 way with the FPU in a separate chip? }:-> </tongue-in-cheek> | 18:59 |
| mnr | somlo: and of course with the PMMU in another separate chip ;-) | 19:00 |
| somlo | mnr: there's some research on P&R across multiple physical FPGAs, but I'm really not ready to go there :) | 19:00 |
| daveshah | somlo: I think that will drop significantly once we have DSP inference in Yosys working | 19:03 |
| daveshah | Between that and the area reduction from improved ABC integration (e.g. proper costs for using muxes to combine LUTs) it may well fit comfortably in 85k | 19:05 |
| mnr | daveshah: I've seen that you had mentioned on twitter that you were thinking about doing a small-to-medium production run for your TrellisBoard design. Do you already have specifc plans for that? | 19:09 |
| daveshah | No time line yet unfortunately, discussing with colleagues how we will go forward | 19:09 |
| daveshah | But I imagine we will do a run of 20 boards at some point | 19:10 |
| mnr | If I can somehow afford it, I'd be definitely interested in one. | 19:10 |
| daveshah | Sure, I'll note that | 19:10 |
| daveshah | Not sure what pricing will be | 19:11 |
| ambro718 | Is there a way, other than FSM, to combine sync and comb logic? I want to write things like If(condition, a.eq(1), NextValue(b, 1)). | 19:58 |
| ambro718 | Annoyingly FSM throws an exception if you only define one state. | 19:59 |
| ambro718 | _florent__: Does this look sensible to you? https://paste.ubuntu.com/p/NTdykdFCQP/ | 20:38 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 20:38 |
| _florent__ | ambro718: sorry, it's the end of the day here, not sure my mind is fresh enough to understand your code :) | 20:58 |
| _florent__ | ambro718: i found something: https://github.com/enjoy-digital/litex/commit/8497f6b9063a92c313a1735d4e8f9dab3494c21d | 20:59 |
| tpb | Title: use PacketBuffer for udp loopback · enjoy-digital/litex@8497f6b · GitHub (at github.com) | 20:59 |
| ambro718 | No problem :) | 20:59 |
| ambro718 | Seems more complicated. | 20:59 |
| _florent__ | i think i was storing if packet information in a fifo and data in another fifo and just using the information fifo to read the data fifo | 21:00 |
| ambro718 | All I do is delay the output of a packet until either the entire packet is inside the fifo (i.e. number of last values in fifo is >0) or the fifo is full. Once the start of a packet is outputted then the entire packet is outputted without delay. | 21:01 |
| _florent__ | ok i see, it should work yes | 21:03 |
| ambro718 | I hope so, next step is to write some C code to see what actually works. I got the full TX logic done now. | 21:04 |
| _florent__ | have you done some simulation of the code? i would recommend doing some if not, it will be a lot faster to debug | 21:06 |
| ambro718 | Wasn't planning to, how would I do that? With the verilator? | 21:06 |
| _florent__ | yes you can do a simulation with the migen simulator (slow but useful for doing unit-test) or with litex_sim (fast and useful for higher level simulation) | 21:07 |
| _florent__ | if you share your TX code, i can prepare a testbench skeleton for you tomorrow | 21:09 |
| ambro718 | Here, https://github.com/ambrop72/liteeth/blob/dma/liteeth/core/mac/__init__.py#L35 | 21:16 |
| tpb | Title: liteeth/__init__.py at dma · ambrop72/liteeth · GitHub (at github.com) | 21:16 |
| ambro718 | This branch has my DMA code, you instantiate LiteEthMAC with interface="wishbone_dma" | 21:17 |
| ambro718 | Here's how I integrated it into EthernetSoc: https://paste.ubuntu.com/p/DF3nKjR2HD/ | 21:18 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 21:18 |
| ambro718 | Basically, uses two WB master interfaces and needs interrupts. | 21:18 |
| ambro718 | Just the DMA (no Ethernet) is here if you think it's enough to focus on this: https://github.com/ambrop72/liteeth/blob/dma/liteeth/core/mac/wishbone_dma.py#L440 | 21:20 |
| tpb | Title: liteeth/wishbone_dma.py at dma · ambrop72/liteeth · GitHub (at github.com) | 21:20 |
| *** ambro718 has quit IRC | 22:18 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!