| *** tpb has joined #litex | 00:00 | |
| *** rohitksingh_work has joined #litex | 03:46 | |
| *** tweakoz has joined #litex | 05:31 | |
| _florent__ | sorear: hi, is there something wrong/missing in the topic? | 07:30 |
|---|---|---|
| sorear | _florent__: as of Saturday the topic did not mention the logs | 07:30 |
| _florent__ | sorear: indeed, i just added it to follow your suggestion :) | 07:31 |
| sorear | it occurred to me to check the chanserv op list, but not to check whether ops were even needed to set the topic | 07:32 |
| _florent__ | felix_: "param" is meant to be used as an equivalent of "user" in AXI stream, in can allow doing some optimization since you know it does not change for a packet duration | 07:40 |
| _florent__ | felix_: but looking at the LiteVideo code, it's indeed confusing, i want to rewrite that code | 07:41 |
| _florent__ | felix_: i would recommend just using payload except if you want to do some specific resource optimization knowing that a signal remain constant for a packet duration | 07:45 |
| *** futarisIRCcloud has quit IRC | 08:22 | |
| *** rohitksingh_work has quit IRC | 09:10 | |
| *** rohitksingh_work has joined #litex | 09:12 | |
| *** tweakoz has quit IRC | 09:35 | |
| *** tweakoz has joined #litex | 09:35 | |
| *** tweakoz has quit IRC | 09:35 | |
| keesj | _florent__: for the fast scope. I would like to add storate to ddr3 next. I think it would be very cool to have a larger bufer | 09:39 |
| keesj | buffer | 09:39 |
| keesj | storage | 09:39 |
| keesj | SSTL15 is now working btw | 09:40 |
| felix_ | _florent__: i was planning to use param for passing the timing parameters from the csr to the timing generator; that's something that shouldn't change when the output is active | 10:01 |
| felix_ | the photonsdi timing generator will likely end up being a superset of the one from litevideo, but i think developing this seperately and then integrating some parts back into litevideo is easier that trying to patch litevideo directly (and probably breaking some of the hdmi stuff in the process) | 10:09 |
| _florent__ | keesj: this is not in master yet, but could be useful for storage in ddr3: https://github.com/enjoy-digital/litedram/commit/ddef95bead21eb0b8afa60bcad1f24d7b10249de | 10:42 |
| tpb | Title: frontend: add initial fifo (to create large FIFOs in DRAM) · enjoy-digital/litedram@ddef95b · GitHub (at github.com) | 10:42 |
| _florent__ | felix_: yes, that's easier to develop it externally and then merge improvements | 10:45 |
| *** futarisIRCcloud has joined #litex | 12:46 | |
| futarisIRCcloud | Rocket in litex looks good. Anyone tested it yet? | 12:48 |
| *** rohitksingh_work has quit IRC | 12:48 | |
| _florent__ | futarisIRCcloud: somlo is working on it and tested it on hardware (on versa ecp5 IIRC), on my side i've only try simulating it with litex_sim | 14:03 |
| somlo | _florent__, futarisIRCcloud: the "standard" variant of rocket *barely* fits on the 45k ecp5versa (96% LUT utilization) | 15:07 |
| somlo | I just realized that enabling the MMU ("linux" variant) will require a board with an 85k ECP5 | 15:07 |
| somlo | in the simulator, the "linux" variant takes about 1 hour / MB to transfer via tftp, so adding a linux kernel payload to BBL (which loads fine) is very hard to debug | 15:10 |
| somlo | so I'm looking at switching (temporarily) to nexys4ddr and vivado, but there I could never get liteDRAM to work at 50MHz (which is where Rocket tops out) | 15:11 |
| daveshah | Have you tried PnR with Diamond? It has DSP inference so should save some LUTs | 15:11 |
| somlo | I never installed or used Diamond before | 15:12 |
| somlo | so at this point I'm split 50/50 between doing that and just (pestering Florent into) debugging liteDRAM on nexys4ddr | 15:13 |
| somlo | added bonus with plan B is that on the nexys I could probably run a *full* Rocket (with FPU also included) -- after all, lowRISC did manage it | 15:14 |
| somlo | ultimately though, I really need a TrellisBoard :) | 15:15 |
| *** futarisIRCcloud has quit IRC | 15:16 | |
| somlo | and, _florent__, you were right: threads didn't speed up Verilator sim much for me either :( | 15:22 |
| daveshah | Possibly the big always blocks are hard to parellelise? | 15:25 |
| somlo | I only have the highest level understanding about how a hardware simulator works, but I get the feeling that there's only a relatively limited opportunity for scheduling things in parallel before threads would have to synchronize ahead o the next time increment | 15:38 |
| somlo | no idea how Verilator does it, specifically | 15:39 |
| somlo | *ahead OF the next time increment | 15:39 |
| Dolu | Just did some MMC over SPI tests. | 15:52 |
| somlo | dumb question: is there a way, in simulation, to "side-load" a blob that'd otherwise be transfered via TFTP? | 15:53 |
| Dolu | With a 25 Mhz SPI, i got 1 MB/s of read bandwidth (linux) @ 100 Mhz VexRiscv | 15:53 |
| Dolu | somlo: Does rocket allow to disable many CSR ? For instance, performance counter and stuff like this ? What is the MMU configuration ? | 15:54 |
| Dolu | Also, what about the machine mode PMP ? | 15:54 |
| somlo | Dolu: there are a LOT of moving parts in the rocket config -- from small 32-bit versions to the fully loaded MMU+FPU ones | 15:59 |
| somlo | trouble is, they're all in Chisel :) | 15:59 |
| somlo | see https://github.com/freechipsproject/rocket-chip/blob/master/src/main/scala/subsystem/Configs.scala and https://github.com/freechipsproject/rocket-chip/blob/master/src/main/scala/system/Configs.scala | 15:59 |
| tpb | Title: rocket-chip/Configs.scala at master · freechipsproject/rocket-chip · GitHub (at github.com) | 15:59 |
| somlo | I've settled on their "small", "medium", and "big" 64-bit "standard" config options, since LiteX has the 32-bit space already pretty well covered | 16:00 |
| somlo | "small" is machine-mode only, no MMU, no FPU. "medium" has the mmu, but still no fpu. | 16:04 |
| somlo | can't tell you specifics about the rocket mmu -- it works out of the box with upstream linux is all I know right now, and I'm only likely to dig (or care) about more details if something somehow doesn't work for me -- too many other moving parts for me to deal with :) | 16:05 |
| _florent__ | somlo: i can try to see why it's LiteDRAM is not working at 50MHz if that's blocking you | 16:09 |
| _florent__ | somlo: was it not working only for Rocket or also with another CPU? | 16:10 |
| _florent__ | somlo: and just for info, you can avoid tftp in the simulation and load directly the ram | 16:12 |
| _florent__ | https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/sim.py#L102 | 16:12 |
| tpb | Title: linux-on-litex-vexriscv/sim.py at master · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com) | 16:12 |
| _florent__ | Dolu: nice for the MMC tests, are you doing bitbanging or do you have a simple SPI controller? | 16:15 |
| somlo | _florent__: last time I tried nexys4ddr, it wasn't passing memtest at 50MHZ with vexriscv either | 16:15 |
| _florent__ | ok i'll look at that then | 16:15 |
| somlo | I *thought* I managed to get vivado to build a 75MHz standard rocket that *still* failed memtest, but I'm fuzzy on that, will re-try a few combinations and let you know | 16:16 |
| somlo | pretty sure about failing memtest at 50MHz with vexriscv though | 16:16 |
| somlo | and thanks for the side-loading tip! | 16:17 |
| *** ambro718 has joined #litex | 16:50 | |
| Dolu | _florent__ : It was by using a SPI controller. The driver has no interrupts, but handle full 25 Mhz bandwidth | 18:02 |
| Dolu | Probably the software CRC calculation and is slowing down the transfer | 18:02 |
| Dolu | Tomorrow i will receive the SPI modules to do wifi, ethernet, and usb | 18:03 |
| *** Dolu has quit IRC | 18:29 | |
| *** Dolu has joined #litex | 19:38 | |
| *** futarisIRCcloud has joined #litex | 20:08 | |
| futarisIRCcloud | Dolu: Which SPI modules are you getting? | 20:12 |
| somlo | _florent__: just noticed, side-loading is built into litex_sim.py (--ram-init <file>); Only, it's mutually exclusive with --with-sdram | 21:09 |
| somlo | _florent__: on that note, https://github.com/enjoy-digital/litex/pull/201 | 21:10 |
| tpb | Title: tools/litex_sim: fix default endianness for mem_init by gsomlo · Pull Request #201 · enjoy-digital/litex · GitHub (at github.com) | 21:10 |
| somlo | not familiar enough with the code to estimate just how hard it would be to rework it so that memory side-loading is delayed until after the constructor has initialized the SoC's self.cpu.endianness | 21:11 |
| somlo | but under the current circumstances, this PR is better than nothing, IMHO :) | 21:12 |
| *** felix_ has quit IRC | 21:15 | |
| *** felix_ has joined #litex | 21:16 | |
| *** futarisIRCcloud has quit IRC | 22:18 | |
| *** _florent__ has quit IRC | 22:21 | |
| *** sorear has quit IRC | 22:26 | |
| *** sorear has joined #litex | 22:28 | |
| *** _florent__ has joined #litex | 22:28 | |
| *** synaption[m] has quit IRC | 22:50 | |
| *** futarisIRCcloud has joined #litex | 22:57 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!