| *** tpb has joined #litex | 00:00 | |
| *** futarisIRCcloud has joined #litex | 00: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 fine | 07:38 |
|---|---|---|
| _florent__ | even with the MT41K128M16JT-15E (1333MT/s) it would be fine | 07: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 correct | 07:40 |
| *** keesj has quit IRC | 10:16 | |
| *** keesj has joined #litex | 10:16 | |
| *** keesj has quit IRC | 11:01 | |
| *** keesj has joined #litex | 11:02 | |
| keesj | Hi | 11:02 |
| _florent__ | Hi | 11:07 |
| Dolu | Hi | 11:08 |
| _florent__ | Dolu: sorry, i haven't yet regenerated VexRiscv to test the IRQs (busy with something else...) | 11:22 |
| Dolu | I think i did | 11:24 |
| Dolu | I updated the VexRiscv-verilog repository | 11:24 |
| Dolu | But i'm not sure how exactly the flow is done, so i don't know if there another manual step to do to propagate it | 11:25 |
| Dolu | (https://github.com/m-labs/VexRiscv-verilog/blob/master/VexRiscv_Linux.v#L6701) => The CSR interrupt adaptation is upstream | 11:28 |
| tpb | Title: VexRiscv-verilog/VexRiscv_Linux.v at master · m-labs/VexRiscv-verilog · GitHub (at github.com) | 11:28 |
| _florent__ | ah ok, then i'll just need to test :) | 11:34 |
| Dolu | Just adapting the CSR number used by the interrupt driver should be fine | 11:40 |
| *** futarisIRCcloud has quit IRC | 12:19 | |
| Dolu | It look like the glibc compilation is currently broken | 15:18 |
| Dolu | This kind of funny stuff : ../sysdeps/unix/sysv/linux/riscv/sysdep.h:120:31: error: '__NR_futex' undeclared (first use in this function); | 15:19 |
| Dolu | Probably the best would be to fix the Linux version in the https://github.com/enjoy-digital/linux-on-litex-vexriscv/blob/master/buildroot/configs/litex_vexriscv_defconfig ? | 15:19 |
| tpb | Title: linux-on-litex-vexriscv/litex_vexriscv_defconfig at master · enjoy-digital/linux-on-litex-vexriscv · GitHub (at github.com) | 15:19 |
| Dolu | Fixing the linux version to 5.0.9 is currently compiling and running fine | 15:20 |
| *** ambro718 has joined #litex | 16:20 | |
| ambro718 | Hi. Does Litex support access from peripheral to main memory? | 16:21 |
| ambro718 | I want to implement a proper DMA frontend for the Ethernet core. | 16:22 |
| keesj | What do you mean by proper DMA? | 16:24 |
| keesj | I think that a "normal" architecure is using something like a DMA master (litex supports multi-master) | 16:25 |
| ambro718 | keesj: DMA for Rx and Tx using circular buffers that allows efficient data exchange with the SW (in particular Linux). | 16:25 |
| ambro718 | Not 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 |
| ambro718 | I think this usually goes through the caches, to avoid cache issues? | 16:27 |
| ambro718 | Anyway what I mean is that the Ethernet core does DMA, not some kind of separate DMA thing. | 16:28 |
| ambro718 | It just needs an interface to access the system memory directly. | 16:28 |
| ambro718 | What I am interested in is whether/how Litex/Migen can provide such an interface. | 16:29 |
| ambro718 | Is there some Litex/Migen architectural document that will tell me these things? | 16:30 |
| keesj | I see .. like as described in bus mastering https://en.wikipedia.org/wiki/Direct_memory_access#Bus_mastering . | 16:30 |
| tpb | Title: Direct memory access - Wikipedia (at en.wikipedia.org) | 16:30 |
| ambro718 | Yes 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 |
| ambro718 | I am specifically interested in VexRiscv, if that matters. | 16:32 |
| keesj | I just found this I know _florent__ also has some presentation https://osda.gitlab.io/19/1.1.pdf | 16:32 |
| ambro718 | thanks | 16:32 |
| keesj | it 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 engine | 16:34 |
| ambro718 | Ethernet cores on microcontrollers most commonly do DMA themselves. | 16:34 |
| keesj | e.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 |
| keesj | ambro718: it does not sound very safe :P | 16:35 |
| ambro718 | I understand, but I think this is harder to achieve and harder to implement SW for. | 16:35 |
| ambro718 | and probably has more overhead | 16:35 |
| ambro718 | what does not sound very safe? | 16:35 |
| ambro718 | Bus mastering? | 16:36 |
| _florent__ | Hi ambro718, for the question you had yesterday: | 16:36 |
| keesj | I mean in terms of security | 16:36 |
| ambro718 | That'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 fine | 16:36 |
| keesj | 0xf00d time | 16:36 |
| _florent__ | even with the MT41K128M16JT-15E (1333MT/s) it would be fine | 16: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 correct | 16:37 |
| ambro718 | Agree about the tCK. | 16:37 |
| ambro718 | _florent__: https://reference.digilentinc.com/reference/programmable-logic/arty-a7/reference-manual clearly says: Mac clock period 3000ps (667Mbps data rate) | 16:38 |
| tpb | Title: Arty A7 Reference Manual [Reference.Digilentinc] (at reference.digilentinc.com) | 16:38 |
| ambro718 | In 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: https://github.com/enjoy-digital/linux-on-litex-vexriscv/issues/13 | 16:41 |
| tpb | Title: Integrate LiteEth · Issue #13 · enjoy-digital/linux-on-litex-vexriscv · GitHub (at github.com) | 16:41 |
| _florent__ | i could gives direction for that is you are interested | 16:41 |
| ambro718 | _florent__: That's the capability of the chip, it doesn't make Arty reference wrong. | 16:41 |
| ambro718 | I remember a forum post about this, let me find it. | 16:42 |
| _florent__ | ambro718: that's maybe a limitation with MIG/Vivado then | 16:43 |
| ambro718 | _florent__: https://forums.xilinx.com/t5/Memory-Interfaces/Slow-DDR3-SDRAM-on-an-Arty/td-p/719645 | 16:43 |
| tpb | Title: Solved: Slow DDR3 SDRAM on an Arty - Community Forums3rd Party Header & Footer (at forums.xilinx.com) | 16:43 |
| ambro718 | See the very first answer. | 16:43 |
| ambro718 | And if one follows this tutorial, https://reference.digilentinc.com/learn/programmable-logic/tutorials/arty-getting-started-with-microblaze-servers/start 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 |
| tpb | Title: Arty - Getting Started with Microblaze Servers [Reference.Digilentinc] (at reference.digilentinc.com) | 16:48 |
| ambro718 | So 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 https://www.xilinx.com/support/documentation/data_sheets/ds181_Artix_7_Data_Sheet.pdf, page 15 | 16:51 |
| tpb | Title: Support (at www.xilinx.com) | 16:51 |
| _florent__ | it seems to be a limitation of the MIG | 16:51 |
| _florent__ | here in LiteDRAM, we are using ISERDESE2/OSERDESE2 | 16:51 |
| _florent__ | so the limitation is 950Mbps, so the 800Mbps we are using is below that | 16:52 |
| ambro718 | _florent__: Where are you getting this? | 16:53 |
| ambro718 | it's 667 | 16:54 |
| ambro718 | 4:1 memory controllers, DDR3L, speed grade -1 => 667 Mb/s | 16:54 |
| _florent__ | the thing is that we are not using the Xilinx MIG | 16:57 |
| _florent__ | but standard primitives | 16:57 |
| ambro718 | But you're reading the table for "Networking Applications Interface Performances", and specifically "DDR LVDS receiver (SPI-4.2)" | 16:59 |
| ambro718 | Don't see how this applies more than the data specifically for memory interfaces. | 17:00 |
| ambro718 | Would you think the MIG doesn't use the same primitives? | 17:00 |
| _florent__ | "Networking Applications Interface Performances" is the performance of the OSERDESE2/ISERDESE2 | 17:01 |
| _florent__ | i know the MIG use undocumented primitives on 7-series | 17:01 |
| _florent__ | but the Arty example design allow lowering the clock if you are more confortable with a lower frequency clock | 17:02 |
| _florent__ | you can just change sys_clk_freq here: https://github.com/enjoy-digital/litex/blob/master/litex/boards/targets/arty.py#L54 | 17:03 |
| tpb | Title: litex/arty.py at master · enjoy-digital/litex · GitHub (at github.com) | 17:03 |
| ambro718 | Yeah 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 PLL | 17: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 issues | 17:10 |
| ambro718 | Not sure what this BUFG is for, would it still be needed? | 17:11 |
| ambro718 | okay that's good to know :) | 17:11 |
| ambro718 | Anyway, I think tRFC here is wrong https://github.com/enjoy-digital/litedram/blob/master/litedram/modules.py#L269 | 17:13 |
| tpb | Title: litedram/modules.py at master · enjoy-digital/litedram · GitHub (at github.com) | 17:13 |
| keesj | I have also been looking at this app note https://www.xilinx.com/support/documentation/application_notes/xapp1017-lvds-ddr-deserial.pdf this also states limitations to the BUFIO to 600Mhz | 17:13 |
| _florent__ | the clocking was done differently before (there was no S7PLL module), i'll try to use the PLL to generate the ethernet clock | 17:13 |
| ambro718 | these 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 here | 17:19 |
| ambro718 | Sorry 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 |
| ambro718 | FWIW, my Arty A7 100T has a completely different memory chip (IS43TR16128B). | 17:23 |
| _florent__ | yes i think the issue is here: https://github.com/enjoy-digital/litedram/blob/master/litedram/modules.py#L40 | 17:26 |
| tpb | Title: litedram/modules.py at master · enjoy-digital/litedram · GitHub (at github.com) | 17:26 |
| _florent__ | which should be ck to cycles | 17:26 |
| _florent__ | i'll have a closer look | 17:27 |
| ambro718 | great, thanks | 17:27 |
| ambro718 | Anyway 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 it | 17:28 |
| ambro718 | It'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 |
| ambro718 | Is it the 100T variant only or did they just change it without notice? | 17:30 |
| ambro718 | Btw, I did have to alsp patch https://github.com/enjoy-digital/litex/blob/master/litex/boards/platforms/arty.py for the 100T FPGA. Is there a proper way to make it configurable? | 17:31 |
| tpb | Title: litex/arty.py at master · enjoy-digital/litex · GitHub (at github.com) | 17:31 |
| ambro718 | "xc7a35ticsg324-1L" -> "xc7a100tcsg324-1" | 17:32 |
| ambro718 | There's really no place to expose it, with BaseSoC and EthernetSoC not having (obvious) extension options. | 17:33 |
| ambro718 | There's also the issue that some timings that depend on the speed grade are in _TechnologyTimings | 17:36 |
| ambro718 | So 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 100t | 17:40 |
| _florent__ | as done on the minispartan6 for example | 17:40 |
| ambro718 | it this right/wrong? https://github.com/enjoy-digital/linux-on-litex-vexriscv/blob/master/buildroot/board/litex_vexriscv/litex_vexriscv_arty.dts#L18 | 17:55 |
| tpb | Title: linux-on-litex-vexriscv/litex_vexriscv_arty.dts at master · enjoy-digital/linux-on-litex-vexriscv · GitHub (at github.com) | 17:55 |
| ambro718 | 0x47868C0 = 75000000 | 17:56 |
| ambro718 | is this supposed to be MHz? Then it should be 100 MHz. | 17:56 |
| ambro718 | I'm guessing that should be the system clock frequency, because it does not seem to be specified anywhere else. | 17:57 |
| *** key2 has quit IRC | 19:33 | |
| *** key2 has joined #litex | 19:53 | |
| ambro718 | How to I build the emulator.bin in linux-on-litex-vexriscv? | 21:22 |
| ambro718 | images.json refers to it but it was not built as part of --build. | 21:22 |
| ambro718 | Running make in the emulator directory gives me a very strange error: Makefile:4: /software/common.mak: No such file or directory | 21:26 |
| ambro718 | Looking at the makefile, I can't see how this happens. The included variables.mak in fact exists and defines SOC_DIRECTORY. | 21:26 |
| Dolu | ambro718, Right, the frequancy in the DTS aren't updated | 21:28 |
| ambro718 | Dolu: It is supposed to be what I think (CPU clock requency)? | 21:28 |
| Dolu | yes | 21:29 |
| Dolu | For the emulator.bin, i don't know if _florent__ did some changes to the VexRiscv repository one. | 21:29 |
| Dolu | Likely | 21:30 |
| ambro718 | Linux booted on Arty A7 100T :) https://paste.ubuntu.com/p/fcDQNsXnx3/ | 22:22 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 22:22 |
| Dolu | Cool :D | 22:32 |
| ambro718 | Flashing doesn't work though. https://paste.ubuntu.com/p/R2jQqY5cC2/ | 22:33 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 22:33 |
| ambro718 | Where does prog/bscan_spi_xc7a35t.bit come from? I need it for a different FPGA. | 23:04 |
| ambro718 | (xc7a100tcsg324) | 23:04 |
| Dolu | Hoo about flashing i also had issue | 23:08 |
| Dolu | Basicaly, between revision of the board, they mount different flash chips, that's maybe the issue here | 23:08 |
| ambro718 | No the issue is the flash proxy thing | 23:08 |
| ambro718 | I have a different FPGA (Arty 100T) | 23:08 |
| ambro718 | needs a compatible flash proxy bstream | 23:08 |
| ambro718 | The scripts currently use this https://github.com/enjoy-digital/linux-on-litex-vexriscv/blob/master/prog/bscan_spi_xc7a35t.bit | 23:09 |
| tpb | Title: linux-on-litex-vexriscv/bscan_spi_xc7a35t.bit at master · enjoy-digital/linux-on-litex-vexriscv · GitHub (at github.com) | 23:09 |
| ambro718 | Clearly 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 IRC | 23:43 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!