| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 01:27 | |
| *** Degi <[email protected]> has joined #litex | 01:31 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 05:09 | |
| *** TMM_ <[email protected]> has joined #litex | 05:10 | |
| _florent_ | cr1901: The cached/uncached regions based on the MSB was from MiSoC, it was a simple way to define cached/uncached regions but not flexible enough and limiting address space to 2GB, so this has been removed: we now define cached/uncached regions explicitly | 06:20 |
|---|---|---|
| _florent_ | cr1901: regarding VexRiscv-SMP/UART_POLLING: I know we started with it since it simplifies bringing up a new core but don't remember if there was a reason so keep it. I'll have a look | 06:23 |
| _florent_ | cr1901: That's probably to avoid developing specific IRQ code just for the LiteX BIOS / VexRiscv-SMP: The interrupt controller is different from the non-SMP and already supported by Linux, so we just switched the BIOS to polling mode to avoid extra developments. | 06:32 |
| *** analognoise <[email protected]> has quit IRC (Remote host closed the connection) | 07:07 | |
| *** michalsieron <[email protected]> has joined #litex | 07:16 | |
| *** Coldberg <[email protected]> has quit IRC (Ping timeout: 255 seconds) | 09:02 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 12:29 | |
| *** TMM_ <[email protected]> has joined #litex | 12:29 | |
| promach[m] | for litedram on xilinx platform, does it use any tuneable PLL dynamic phase shift mechanism to achieve DQS centering purpose ? | 12:42 |
| promach[m] | https://www.xilinx.com/support/documentation/user_guides/ug382.pdf#page=65 | 12:42 |
| * promach[m] uploaded an image: (175KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/NqjvKtCaWYBbDDOqvyreYhiW/image.png > | 12:42 | |
| chiefwigms | hey _florent_ - ever get a chance to look at ultrascale+ eth? | 12:48 |
| _florent_ | chiefwigms: sorry, I'm not able to spend the time required to investigate currently, in case you want to speed this up and want to fund this work, I could maybe ask a colleague to look at it | 13:15 |
| _florent_ | promach[m]: On Artix7, we are using a fixed phase shift (for write DQS) and ignoring DQS on read (by centering data window). On Kintex7/Ultrascale(+) we use the ODELAY primitives to configure the write DQS and are also ignoring the DQS on read. | 13:24 |
| *** Coldberg <[email protected]> has joined #litex | 13:59 | |
| *** _whitelogger <[email protected]> has quit IRC (Remote host closed the connection) | 14:45 | |
| *** _whitelogger <[email protected]> has joined #litex | 14:46 | |
| DerekKozel[m] | _florent_: I'm back doing some packaging and testing with the CLE-215 and the litepcie kernel/user libraries, and I think I've forgotten some of my lessons learned from last time. | 15:01 |
| DerekKozel[m] | The csr.h and soc.h from the latest litex build of the sqrl_acorn target seem reasonable, but the litepcie/software/kernel/Makefile is expecting csr.h and generated/soc.h paths, then fails because it can't find stdint.h, which certainly exists | 15:06 |
| promach[m] | <_florent_ "promach: On Artix7, we are using"> _florent_: what do you exactly mean by **ignoring DQS on read (by centering data window).** ? | 15:07 |
| promach[m] | and what about spartan-6 ? | 15:07 |
| _florent_ | promach[m]: I mean we are not sampling the read data directly with DQS but just centering the sampling window with IDELAYs | 15:23 |
| _florent_ | DerekKozel[m]: for the | 15:25 |
| _florent_ | DerekKozel[m]: sorry, for the Acorn, the way I'm testing it: | 15:26 |
| _florent_ | ./sqrl_acorn.py --with-pcie --build --load --driver | 15:26 |
| *** rom <rom!~rom@2405:4802:9013:d6d0:c0c5:1666:6558:caa6> has joined #litex | 15:26 | |
| _florent_ | the copy the driver directory to the machine with the Acorn | 15:26 |
| rom | hi, I'm currently working with vexriscv-smp, and I'm looking for a way to export the dram bus | 15:27 |
| _florent_ | the/then | 15:27 |
| _florent_ | cd kernel | 15:27 |
| _florent_ | make | 15:28 |
| _florent_ | sudo ./init.sh | 15:28 |
| DerekKozel[m] | Thanks. I'll try that right now. | 15:28 |
| _florent_ | you can then do a dmesg and should see the litepcie traces | 15:28 |
| _florent_ | once it's ok, go to user directory | 15:28 |
| _florent_ | make | 15:28 |
| DerekKozel[m] | I'm building on the machine with the Acorn installed, trying to set it up for a masters student who's going to do a project with it | 15:28 |
| rom | basically, I'm doing a test chip, and we don't have the DRAM IP yet, so I'm trying to export the memory bus (AXI, wishbone, whatever) and connect the test chip to the FPGA to use the FPGA's DRAM IP | 15:28 |
| _florent_ | litepcie_util info | 15:28 |
| _florent_ | litepcie_util dma_test | 15:29 |
| _florent_ | litepcie_util help for the available commands | 15:29 |
| DerekKozel[m] | Thanks | 15:30 |
| DerekKozel[m] | I was missing --driver | 15:30 |
| _florent_ | rom: Hi, if you can to use LiteX for this, you could have the LiteX SoC with it's DRAM running on the FPGA and just expose the main bus of the SoC or a LiteDRAM interface | 15:31 |
| _florent_ | to expose a Wishbone or AXI-Lite interface, you can look at: https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_gen.py#L133-L150 | 15:32 |
| rom | _florent_: well, basically, we want the LiteX SoC on a chip, but we don't have the DRAM IP for chip fabrication (yet), so we're doing a workaround using FPGA's DRAM IP | 15:33 |
| _florent_ | this will work, but will probably be a bit slow compared the the speed that can handle LiteDRAM | 15:33 |
| rom | expose a bus is our last option though | 15:33 |
| _florent_ | if you want more speed, you can expose a port from LiteDRAM | 15:33 |
| _florent_ | for a Native port: https://github.com/enjoy-digital/litedram/blob/master/litedram/gen.py#L592-L616 | 15:34 |
| _florent_ | for an AXI port: https://github.com/enjoy-digital/litedram/blob/master/litedram/gen.py#L640-L693 | 15:34 |
| _florent_ | rom: ah sorry, so you want to have a LiteX SoC and connect it the the vendor's FPGA's DRAM IP? | 15:35 |
| _florent_ | so get rid of LiteDRAM if I understand correctly? | 15:36 |
| rom | _florent_ please let me explain more on the matter :D | 15:36 |
| _florent_ | rom: sure | 15:36 |
| rom | the LiteX SoC is a chip (VLSI design), fabricate using TSMC 180nm, which will serve as a test chip | 15:37 |
| rom | original plan is for it to use SDRAM | 15:37 |
| rom | due to pandemic (guh...), we can't finish the SDRAM test on time | 15:37 |
| rom | so we switch to use DDR | 15:37 |
| rom | but we don't have the IP core for DRAM (in VLSI), so we need to design a LiteX SoC with exposed memory bus, to be used with an external memory controller + PHY (which is our FPGA) | 15:38 |
| rom | "exposed", as in real GPIO pins on the chip | 15:38 |
| rom | I hope the explaination is clear enough | 15:39 |
| rom | the use case is... rather unusual though | 15:39 |
| rom | [Chip] <-- AXI/Wishbone --> [DRAM controller on FPGA] | 15:41 |
| rom | something like this | 15:41 |
| rom | and the thing I'm asking is how can I export the AXI/Wishbone/BMB (or whatever) bus, to use my own configuration like that? | 15:42 |
| rom | (btw, I like LiteX, a lot easier to use than other stuffs like Chipyard or Rocketchip) | 15:43 |
| _florent_ | rom: ok I see, but exposing a full bus will consume quite a bit of IOs, won't it be an issue? You'll probably want to do some adaptation to it to reduce the number of IOs (ex bidir data) | 15:43 |
| rom | if LiteX support the adaption, I'd be more delight to hear it | 15:43 |
| rom | otherwise, I think I have around 50 IO? or 100? to work with | 15:44 |
| promach[m] | <_florent_ "promach: I mean we are not sampl"> what about spartan-6 ? | 15:44 |
| rom | I'd love to reduce the number of IO down though | 15:44 |
| _florent_ | promach[m]: For Spartan6 we were using a fixed bitslip/delay which required manual adjustments by the user. We should update the Spartan6 PHY to make it similar to 7-series (but Spartan6 is a bit old... so not sure it's very useful to spend time improving it) | 15:48 |
| _florent_ | rom: The default integration of VexRiscv-SMP in LiteX is tighly coupled to LiteDRAM: each CPU has two direct interface to LiteDRAM (ibus and dbus): | 15:51 |
| _florent_ | https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/vexriscv_smp/core.py#L424-L456 | 15:51 |
| _florent_ | So this will consume even more IOs for your case | 15:52 |
| _florent_ | You will then have to use the Wishbone Memory interface | 15:52 |
| _florent_ | which connects VexRiscv-SMP to the main bus of the SoC, and then connects to LiteDRAM through the L2 cache | 15:53 |
| rom | oh, access speed doesn't really matter in this case btw | 15:53 |
| _florent_ | this is slower, but will be better for your case | 15:53 |
| rom | we just want a proof that it worked as a chip | 15:53 |
| _florent_ | to do what you can, you can then configure VexRiscv-SMP to use the Wishbone interface | 15:55 |
| _florent_ | and then modify add_sdram here: | 15:55 |
| _florent_ | https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1342-L1382 | 15:55 |
| _florent_ | and instead of connecting to the L2 Cache to LiteDRAM, connect it to an exposed interface | 15:56 |
| _florent_ | to expose a Wishbone interface, you can use code similar to: https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_gen.py#L133-L139 | 15:58 |
| promach[m] | <_florent_ "promach: For Spartan6 we were us"> what do you exactly mean by **fixed bitslip/delay which required manual adjustments** ? | 16:01 |
| _florent_ | On 7-Series/Ultrascale, the adjustment is done automatically by software, on Spartan6 it was not the case and had to be done manually by the user | 16:02 |
| *** futarisIRCcloud <[email protected]> has quit IRC (Quit: Connection closed for inactivity) | 16:03 | |
| promach[m] | <_florent_ "On 7-Series/Ultrascale, the adju"> _florent_: ok, but how **manually** ? | 16:03 |
| _florent_ | https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/saanlima_pipistrello.py#L174-L176 | 16:04 |
| promach[m] | _florent_: why `rd_bitslip = 1` while `wr_bitslip = 3` ? | 16:05 |
| rom | _florent_: could you elaborate more on the code? I did not get this parts yet | 16:10 |
| _florent_ | promach[m]: that's the manual adjustement :) (found by testing on hardware) | 16:10 |
| _florent_ | rom: This code is creating a bridge between the main bus of the SoC and LiteDRAM, so that's where you'll want to deconnect LiteDRAM and instead expose it | 16:11 |
| promach[m] | _florent_: you mean on spartan-6, there is no IDELAY primitive involved during read operation ? | 16:11 |
| promach[m] | because I suppose bitslip is a feature specific to ISERDES2 primitive | 16:11 |
| _florent_ | promach[m]: I don't remember exacly why the IDELAY was not used in the Spartan6 PHY (I however remember that Spartan6 IDELAY had limitation, like only capable of storing one transition, so this was maybe the reason) | 16:13 |
| rom | _florent_: thanks, I got the part that it connect LiteDRAM, but didn't quite get how to expose the bus yet | 16:20 |
| _florent_ | promach[m]: Also bistlip from Xilinx primitives can be tricky to get working correctly/understand since not well documented. For 7-Series/Ultrascale I moved it to the fabric to simplify things | 16:21 |
| _florent_ | rom: that's the second link :) | 16:22 |
| _florent_ | rom: with this: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1354-L1356 you can create a Wishbone Slave on the main bus | 16:24 |
| _florent_ | and you will then have to expose it | 16:24 |
| _florent_ | with something like: | 16:25 |
| _florent_ | platform.add_extension(wb_sdram.get_ios("wb")) | 16:25 |
| _florent_ | wb_pads = platform.request("wb") | 16:25 |
| _florent_ | self.comb += wb_sdram.connect_to_pads(wb_pads, mode="slave") | 16:26 |
| _florent_ | (and maybe adapt mode to "master") | 16:26 |
| promach[m] | _florent_: but still `wr_bitslip = 3` is a bit strange to me | 16:28 |
| rom | _florent_: thank you. The explanation is very clear | 16:29 |
| rom | :D | 16:29 |
| rom | I'll run along and generate a design to test on my board | 16:29 |
| promach[m] | _florent_: and what do you mean by **storing one transition** ? | 16:29 |
| _florent_ | IIRC the delay line was only able to store an edge/transition | 16:30 |
| rom | _florent_: is there any way to generate a litedram controller with the exposed wishbone bus too? For use with this SoC. | 16:30 |
| _florent_ | This can be an issue if the period of the input signal is shorter than the delay line | 16:31 |
| rom | I'll have to connect the 2 of them manually for testing now | 16:31 |
| promach[m] | <_florent_ "IIRC the delay line was only abl"> I am confused with your sentence | 16:31 |
| promach[m] | <_florent_ "This can be an issue if the peri"> why would this be the case for spartan-6 only ? | 16:33 |
| _florent_ | Probably related to a hardware issue, that's also one of the reason to avoid Spartan6 :) | 16:35 |
| _florent_ | https://www.xilinx.com/support/answers/38408.html | 16:35 |
| _florent_ | 7-series is much better | 16:36 |
| promach[m] | _florent_: any reason why you not choose to use PLL dynamic phase shift feature in lieu of IODELAY2 primitive ? | 16:41 |
| promach[m] | https://www.xilinx.com/support/documentation/user_guides/ug382.pdf#page=65 | 16:41 |
| _florent_ | On Spartan6 we are using a fixed phase shift for DQS generation | 16:45 |
| _florent_ | dynamic add flexibility, but we were doing it manually | 16:46 |
| _florent_ | adds | 16:46 |
| promach[m] | _florent_: you could do this manually for write operation, but for read operation, it seems not feasible given that the incoming read DQS and read DQ signals are not really in phase with the FPGA's PLL clock | 16:47 |
| *** rom <rom!~rom@2405:4802:9013:d6d0:c0c5:1666:6558:caa6> has quit IRC (Quit: Ping timeout (120 seconds)) | 18:15 | |
| *** chiefwigms <[email protected]> has quit IRC (Quit: Client closed) | 19:05 | |
| *** rom <rom!~rom@2405:4802:9013:d6d0:c0c5:1666:6558:caa6> has joined #litex | 19:34 | |
| gatecat | one of the problems with AXI or Wishbone externally is they are synchronous to one side only | 21:08 |
| gatecat | whereas for external busses you ideally want source synchronous - ie clocks in either direction | 21:08 |
| *** michalsieron <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 22:14 | |
| *** pftbest <[email protected]> has joined #litex | 23:43 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
