Monday, 2019-05-27

*** tpb has joined #litex00:00
*** futarisIRCcloud has joined #litex00:57
_florent__(just as a reminder when ambro718 will be back): Arty is mounted with MT41K128M16JT-125, so 1600MT/s capable, we are using it at 800MT/s, so that's fine07:38
_florent__even with the MT41K128M16JT-15E (1333MT/s) it would be fine07:38
_florent__it seems there are some inconsistency in the Digilent documentation, 1333MT/s = the 667MHz they mention (but which is not 667Mbps data rate they mention in another document)07:39
_florent__tCK = the DDRAM clock period, not the half clock period. So the 1:4 multiplication is correct07:40
*** keesj has quit IRC10:16
*** keesj has joined #litex10:16
*** keesj has quit IRC11:01
*** keesj has joined #litex11:02
_florent__Dolu: sorry, i haven't yet regenerated VexRiscv to test the IRQs (busy with something else...)11:22
DoluI think i did11:24
DoluI updated the VexRiscv-verilog repository11:24
DoluBut i'm not sure how exactly the flow is done, so i don't know if there another manual step to do to propagate it11:25
Dolu( => The CSR interrupt adaptation is upstream11:28
tpbTitle: VexRiscv-verilog/VexRiscv_Linux.v at master · m-labs/VexRiscv-verilog · GitHub (at
_florent__ah ok, then i'll just need to test :)11:34
DoluJust adapting the CSR number used by the interrupt driver should be fine11:40
*** futarisIRCcloud has quit IRC12:19
DoluIt look like the glibc compilation is currently broken15:18
DoluThis kind of funny stuff : ../sysdeps/unix/sysv/linux/riscv/sysdep.h:120:31: error: '__NR_futex' undeclared (first use in this function);15:19
DoluProbably the best would be to fix the Linux version in the ?15:19
tpbTitle: linux-on-litex-vexriscv/litex_vexriscv_defconfig at master · enjoy-digital/linux-on-litex-vexriscv · GitHub (at
DoluFixing the linux version to 5.0.9 is currently compiling and running fine15:20
*** ambro718 has joined #litex16:20
ambro718Hi. Does Litex support access from peripheral to main memory?16:21
ambro718I want to implement a proper DMA frontend for the Ethernet core.16:22
keesjWhat do you mean by proper DMA?16:24
keesjI think that a "normal" architecure is using something like a DMA master (litex supports multi-master)16:25
ambro718keesj: DMA for Rx and Tx using circular buffers that allows efficient data exchange with the SW (in particular Linux).16:25
ambro718Not sure what you mean by DMA master. I think the peripheral should have a master->slave interface that it uses to read and write system memory.16:26
ambro718I think this usually goes through the caches, to avoid cache issues?16:27
ambro718Anyway what I mean is that the Ethernet core does DMA, not some kind of separate DMA thing.16:28
ambro718It just needs an interface to access the system memory directly.16:28
ambro718What I am interested in is whether/how Litex/Migen can provide such an interface.16:29
ambro718Is there some Litex/Migen architectural document that will tell me these things?16:30
keesjI see .. like as described in bus mastering .16:30
tpbTitle: Direct memory access - Wikipedia (at
ambro718Yes that is what I want. One variable here is whether the peripheral accesses the memory directly or CPU caches are in between. The latter would be preferred.16:31
ambro718I am specifically interested in VexRiscv, if that matters.16:32
keesjI just found this I know _florent__ also has some presentation
keesjit mentions litePCIe that is apparently DMA capable (or similiar) I don't really know. The embedded systems I have worked with (and also on linux) have a separate DMA engine16:34
ambro718Ethernet cores on microcontrollers most commonly do DMA themselves.16:34
keesje.g. you send some meta-data to the DMA engine and let it perform the transfer (over a buffer indeed, sometimes based on an interrupt)16:35
keesjambro718: it does not sound very safe :P16:35
ambro718I understand, but I think this is harder to achieve and harder to implement SW for.16:35
ambro718and probably has more overhead16:35
ambro718what does not sound very safe?16:35
ambro718Bus mastering?16:36
_florent__Hi ambro718, for the question you had yesterday:16:36
keesjI mean in terms of security16:36
ambro718That's how DMA is done in most modern systems, including PCIe.16:36
_florent__Arty is mounted with MT41K128M16JT-125, so 1600MT/s capable, we are using it at 800MT/s, so that's fine16:36
keesj0xf00d time16:36
_florent__even with the MT41K128M16JT-15E (1333MT/s) it would be fine16:36
_florent__it seems there are some inconsistency in the Digilent documentation, 1333MT/s = the 667MHz they mention (but which is not 667Mbps data rate they mention in another document)16:36
_florent__tCK = the DDRAM clock period, not the half clock period. So the 1:4 multiplication is correct16:37
ambro718Agree about the tCK.16:37
ambro718_florent__: clearly says:  Mac clock period   3000ps (667Mbps data rate)16:38
tpbTitle: Arty A7 Reference Manual [Reference.Digilentinc] (at
ambro718In fact if you try to configure MIG in Vivado then it wants you to use 3000ps by default and gives a narrow window of options, something like 2700-3300ps.16:39
_florent__ambro718: yes that's why i say it seems incoherent, with a MT41K128M16JT-15E, max DDR clock is 667MHz not 667Mbps (333MHz)16:40
_florent__ambro718: just for information, we also want to add DMA to LiteEth:
tpbTitle: Integrate LiteEth · Issue #13 · enjoy-digital/linux-on-litex-vexriscv · GitHub (at
_florent__i could gives direction for that is you are interested16:41
ambro718_florent__: That's the capability of the chip, it doesn't make Arty reference wrong.16:41
ambro718I remember a forum post about this, let me find it.16:42
_florent__ambro718: that's maybe a limitation with MIG/Vivado then16:43
tpbTitle: Solved: Slow DDR3 SDRAM on an Arty - Community Forums3rd Party Header & Footer (at
ambro718See the very first answer.16:43
ambro718And if one follows this tutorial, one gets a system with 333 MHz memory clock and 83.333 MHz system clock (it's not easy to see by reading it though).16:48
tpbTitle: Arty - Getting Started with Microblaze Servers [Reference.Digilentinc] (at
ambro718So I am truly convinced that the Litex config is inappropriate, it should be using system clock 83.333 MHz to fix that.16:48
_florent__looking at, page 1516:51
tpbTitle: Support (at
_florent__it seems to be a limitation of the MIG16:51
_florent__here in LiteDRAM, we are using ISERDESE2/OSERDESE216:51
_florent__so the limitation is 950Mbps, so the 800Mbps we are using is below that16:52
ambro718_florent__: Where are you getting this?16:53
ambro718it's 66716:54
ambro7184:1 memory controllers, DDR3L, speed grade -1  => 667 Mb/s16:54
_florent__the thing is that we are not using the Xilinx MIG16:57
_florent__but standard primitives16:57
ambro718But you're reading the table for "Networking Applications Interface Performances", and specifically "DDR LVDS receiver (SPI-4.2)"16:59
ambro718Don't see how this applies more than the data specifically for memory interfaces.17:00
ambro718Would you think the MIG doesn't use the same primitives?17:00
_florent__"Networking Applications Interface Performances" is the performance of the OSERDESE2/ISERDESE217:01
_florent__i know the MIG use undocumented primitives on 7-series17:01
_florent__but the Arty example design allow lowering the clock if you are more confortable with a lower frequency clock17:02
_florent__you can just change sys_clk_freq here:
tpbTitle: litex/ at master · enjoy-digital/litex · GitHub (at
ambro718Yeah I've already been fiddling with this, but I had to change the ethernet 25 MHz clock to be generated by the PLL (it't can't be sys_clk/4 then)17:06
_florent__indeed, maybe we should generate the ethernet clock directly with the PLL17:08
_florent__but just for info, i've been running the DDR3 at 800Mbps on Arty since 2015 and on several others Artix7 designs without issues17:10
ambro718Not sure what this BUFG is for, would it still be needed?17:11
ambro718okay that's good to know :)17:11
ambro718Anyway, I think tRFC here is wrong
tpbTitle: litedram/ at master · enjoy-digital/litedram · GitHub (at
keesjI have also been looking at this app note  this also states limitations to the BUFIO to 600Mhz17:13
_florent__the clocking was done differently before (there was no S7PLL module), i'll try to use the PLL to generate the ethernet clock17:13
ambro718these values come from the memory data sheet and they're in CK, not ns, but it's supposed to be in ns.17:13
_florent__thanks, indeed, there is maybe something wrong here17:19
ambro718Sorry pointed to the wrong one (which also seems to have problems), the Arty one is MT41J128M16 and yes it also seems to have a problem.17:23
ambro718FWIW, my Arty A7 100T has a completely different memory chip (IS43TR16128B).17:23
_florent__yes i think the issue is here:
tpbTitle: litedram/ at master · enjoy-digital/litedram · GitHub (at
_florent__which should be ck to cycles17:26
_florent__i'll have a closer look17:27
ambro718great, thanks17:27
ambro718Anyway I'm still not sure what the timings should be because the DS lists two tables, one with CK and one with ns values.17:27
_florent__if you create a SDRAMModule for the Arty A7 100T, you can create a pull request on LiteDRAM and i'll merge it17:28
ambro718It's a strange situation because the Arty reference says the chip is MT41K128M16JT-125. I don't know which board actually have the ISSI chip.17:29
ambro718Is it the 100T variant only or did they just change it without notice?17:30
ambro718Btw, I did have to alsp patch for the 100T FPGA. Is there a proper way to make it configurable?17:31
tpbTitle: litex/ at master · enjoy-digital/litex · GitHub (at
ambro718"xc7a35ticsg324-1L" -> "xc7a100tcsg324-1"17:32
ambro718There's really no place to expose it, with BaseSoC and EthernetSoC not having (obvious) extension options.17:33
ambro718There's also the issue that some timings that depend on the speed grade are in _TechnologyTimings17:36
ambro718So I'm just going to had that specific speed grade as a class.17:36
_florent__we could expose the fpga device as a parameter if that's the only thing different on the arty a7 100t17:40
_florent__as done on the minispartan6 for example17:40
ambro718it this right/wrong?
tpbTitle: linux-on-litex-vexriscv/litex_vexriscv_arty.dts at master · enjoy-digital/linux-on-litex-vexriscv · GitHub (at
ambro7180x47868C0 = 7500000017:56
ambro718is this supposed to be MHz? Then it should be 100 MHz.17:56
ambro718I'm guessing that should be the system clock frequency, because it does not seem to be specified anywhere else.17:57
*** key2 has quit IRC19:33
*** key2 has joined #litex19:53
ambro718How to I build the emulator.bin in linux-on-litex-vexriscv?21:22
ambro718images.json refers to it but it was not built as part of --build.21:22
ambro718Running make in the emulator directory gives me a very strange error:  Makefile:4: /software/common.mak: No such file or directory21:26
ambro718Looking at the makefile, I can't see how this happens. The included variables.mak in fact exists and defines SOC_DIRECTORY.21:26
Doluambro718, Right, the frequancy in the DTS aren't updated21:28
ambro718Dolu: It is supposed  to be what I think (CPU clock requency)?21:28
DoluFor the emulator.bin, i don't know if _florent__ did some changes to the VexRiscv repository one.21:29
ambro718Linux booted on Arty A7 100T :)
tpbTitle: Ubuntu Pastebin (at
DoluCool :D22:32
ambro718Flashing doesn't work though.
tpbTitle: Ubuntu Pastebin (at
ambro718Where does prog/bscan_spi_xc7a35t.bit come from? I need it for a different FPGA.23:04
DoluHoo about flashing i also had issue23:08
DoluBasicaly, between revision of the board, they mount different flash chips, that's maybe the issue here23:08
ambro718No the issue is the flash proxy thing23:08
ambro718I have a different FPGA (Arty 100T)23:08
ambro718needs a compatible flash proxy bstream23:08
ambro718The scripts currently use this
tpbTitle: linux-on-litex-vexriscv/bscan_spi_xc7a35t.bit at master · enjoy-digital/linux-on-litex-vexriscv · GitHub (at
ambro718Clearly it will not work for a different FPGA. But I have no idea where these files come from, where I can get the one for my FPGA.23:09
*** ambro718 has quit IRC23:43

Generated by 2.13.1 by Marius Gedminas - find it at!