Tuesday, 2019-06-18

*** tpb has joined #litex00:00
*** rohitksingh_work has joined #litex03:46
*** tweakoz has joined #litex05: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 logs07:30
_florent__sorear: indeed, i just added it to follow your suggestion :)07:31
sorearit occurred to me to check the chanserv op list, but not to check whether ops were even needed to set the topic07: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 duration07:40
_florent__felix_: but looking at the LiteVideo code, it's indeed confusing, i want to rewrite that code07: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 duration07:45
*** futarisIRCcloud has quit IRC08:22
*** rohitksingh_work has quit IRC09:10
*** rohitksingh_work has joined #litex09:12
*** tweakoz has quit IRC09:35
*** tweakoz has joined #litex09:35
*** tweakoz has quit IRC09: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 bufer09:39
keesjbuffer09:39
keesjstorage09:39
keesj SSTL15 is now working btw09: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 active10: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/ddef95bead21eb0b8afa60bcad1f24d7b10249de10:42
tpbTitle: frontend: add initial fifo (to create large FIFOs in DRAM) · enjoy-digital/[email protected] · GitHub (at github.com)10:42
_florent__felix_: yes, that's easier to develop it externally and then merge improvements10:45
*** futarisIRCcloud has joined #litex12:46
futarisIRCcloudRocket in litex looks good. Anyone tested it yet?12:48
*** rohitksingh_work has quit IRC12: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_sim14:03
somlo_florent__, futarisIRCcloud: the "standard" variant of rocket *barely* fits on the 45k ecp5versa (96% LUT utilization)15:07
somloI just realized that enabling the MMU ("linux" variant) will require a board with an 85k ECP515:07
somloin 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 debug15:10
somloso 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
daveshahHave you tried PnR with Diamond? It has DSP inference so should save some LUTs15:11
somloI never installed or used Diamond before15:12
somloso at this point I'm split 50/50 between doing that and just (pestering Florent into) debugging liteDRAM on nexys4ddr15:13
somloadded 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 it15:14
somloultimately though, I really need a TrellisBoard :)15:15
*** futarisIRCcloud has quit IRC15:16
somloand, _florent__, you were right: threads didn't speed up Verilator sim much for me either :(15:22
daveshahPossibly the big always blocks are hard to parellelise?15:25
somloI 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 increment15:38
somlono idea how Verilator does it, specifically15:39
somlo*ahead OF the next time increment15:39
DoluJust did some MMC over SPI tests.15:52
somlodumb question: is there a way, in simulation, to "side-load" a blob that'd otherwise be transfered via TFTP?15:53
DoluWith a 25 Mhz SPI, i got 1 MB/s of read bandwidth (linux) @ 100 Mhz VexRiscv15:53
Dolusomlo: Does rocket allow to disable many CSR ? For instance, performance counter and stuff like this ? What is the MMU configuration ?15:54
DoluAlso, what about the machine mode PMP ?15:54
somloDolu: there are a LOT of moving parts in the rocket config -- from small 32-bit versions to the fully loaded MMU+FPU ones15:59
somlotrouble is, they're all in Chisel :)15:59
somlosee 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.scala15:59
tpbTitle: rocket-chip/Configs.scala at master · freechipsproject/rocket-chip · GitHub (at github.com)15:59
somloI've settled on their "small", "medium", and "big" 64-bit "standard" config options, since LiteX has the 32-bit space already pretty well covered16:00
somlo"small" is machine-mode only, no MMU, no FPU. "medium" has the mmu, but still no fpu.16:04
somlocan'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 you16: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 ram16:12
_florent__https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/sim.py#L10216:12
tpbTitle: 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 either16:15
_florent__ok i'll look at that then16:15
somloI *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 know16:16
somlopretty sure about failing memtest at 50MHz with vexriscv though16:16
somloand thanks for the side-loading tip!16:17
*** ambro718 has joined #litex16:50
Dolu_florent__ : It was by using a SPI controller. The driver has no interrupts, but handle full 25 Mhz bandwidth18:02
DoluProbably the software CRC calculation and is slowing down the transfer18:02
DoluTomorrow i will receive the SPI modules to do wifi, ethernet, and usb18:03
*** Dolu has quit IRC18:29
*** Dolu has joined #litex19:38
*** futarisIRCcloud has joined #litex20:08
futarisIRCcloudDolu: 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-sdram21:09
somlo_florent__: on that note, https://github.com/enjoy-digital/litex/pull/20121:10
tpbTitle: tools/litex_sim: fix default endianness for mem_init by gsomlo · Pull Request #201 · enjoy-digital/litex · GitHub (at github.com)21:10
somlonot 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.endianness21:11
somlobut under the current circumstances, this PR is better than nothing, IMHO :)21:12
*** felix_ has quit IRC21:15
*** felix_ has joined #litex21:16
*** futarisIRCcloud has quit IRC22:18
*** _florent__ has quit IRC22:21
*** sorear has quit IRC22:26
*** sorear has joined #litex22:28
*** _florent__ has joined #litex22:28
*** synaption[m] has quit IRC22:50
*** futarisIRCcloud has joined #litex22:57

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!