| *** tpb has joined #litex | 00:00 | |
| *** futarisIRCcloud has joined #litex | 03:27 | |
| *** futarisIRCcloud has quit IRC | 09:17 | |
| *** futarisIRCcloud has joined #litex | 10:54 | |
| *** futarisIRCcloud has quit IRC | 13:54 | |
| somlo | There's "litex/boards/targets/versa_ecp5.py" in the litex repo, and then there's the enjoy-digital/versa_ecp5 repo with its own versa_ecp5.py generator. What's the relevant difference? How about from the perspective of studying the board-specific DDR3 (litedram) controller? | 13:54 |
|---|---|---|
| somlo | also, the dedicated enjoy-digital/versa_ecp5 repo errors out here: https://github.com/enjoy-digital/versa_ecp5/blob/master/versa_ecp5.py#L122 with AttributeError: 'ECP5DDRPHY' object has no attribute 'burstdet' | 14:32 |
| tpb | Title: versa_ecp5/versa_ecp5.py at master · enjoy-digital/versa_ecp5 · GitHub (at github.com) | 14:32 |
| somlo | but builds ok if I comment out that line | 14:32 |
| *** cedric_ has joined #litex | 14:41 | |
| cedric_ | Hi Florent ! How are you ? I have a small question regarding firmware compilation and usage of firmware.bin with litex_term.py. I took example at fpga_101/lab004 to build a SocCore containing my AES. I changed the firmware, in which I would like to include unistd.h (to realize a sleep(1)). I can't compile it, the compiler is telling me that the library is missing... | 15:13 |
| cedric_ | Is it because i can't use the library on the Nexys4, or should I move the library to a specific location ? | 15:14 |
| *** cedric_ has quit IRC | 15:53 | |
| _florent_ | somlo: the versa_ecp5 directory was use to develop the versa_ecp5 target that is integrated in LiteX (especially the Ethernet and DDR3 PHY) | 16:01 |
| _florent_ | somlo: it contains specific debug targets/scripts | 16:02 |
| somlo | _florent_: just got the LiteX integrated version to boot up and it says "Memtest OK" | 17:48 |
| somlo | \o/ | 17:48 |
| somlo | so, this means I can safely ignore the standalone test/debug repo, assuming its lessons have been integrated into LiteX proper? | 17:49 |
| somlo | So, let's see if I understand how litedram fits into the big scheme of things. | 18:54 |
| somlo | Basically, in addition to the user port(s) (native, axi, etc.) and the wires leading to the DRAM chip itself, plus clock and reset, the liteDRAM verilog module would need a set of wires that would end up as MMIO registers accessible to the SoC CPU (e.g. in the 0xE0004000 + range) which allow the CPU to drive the initialization FSM of the DRAM controller until it's ready, at which point it can start using the RAM range, which would then result in | 18:54 |
| somlo | interaction over the user port(s) only. | 18:54 |
| somlo | So, if I wanted a standalone liteDRAM controller for use with my own SoC, I'd need not just an AXI port for "regular" RAM access, but also all the MMIO "memory device" wires, and to follow the generated "recipe" for tickling the MMIO ports to get the controller through its initialization process. | 18:54 |
| somlo | Am I describing this accurately? | 18:54 |
| somlo | _florent_, daveshah: ^^ | 18:56 |
| somlo | also, presumably the firmware opcodes tickling the DRAM MMIO device for initialization would use a small portion of a BRAM, which should be more economical than implementing a real FSM in the "gateware" (i.e., using up CLBs via the generated verilog) | 19:03 |
| _florent_ | somlo: yes you got it. Just that for DDR3, the initialization is a bit more that a raw initialization sequence you'll still need to have a small FSM | 21:27 |
| somlo | _florent_: do you mean a small FSM implemented in software (i.e. the generated code that touches the MMIO memory device), or an FSM in "gateware" (which I then expect would be reflected in the generated Verilog, even for a standalone SoC-less liteDRAM controller)? | 21:42 |
| _florent_ | somlo: both would work | 22:53 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!