<_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
<_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
<_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.
analognoise has quit [Remote host closed the connection]
<chiefwigms>
hey _florent_ - ever get a chance to look at ultrascale+ eth?
<_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
<_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.
Coldberg has joined #litex
_whitelogger has joined #litex
<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.
<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
<promach[m]>
<_florent_ "promach: On Artix7, we are using"> _florent_: what do you exactly mean by **ignoring DQS on read (by centering data window).** ?
<promach[m]>
and what about spartan-6 ?
<_florent_>
promach[m]: I mean we are not sampling the read data directly with DQS but just centering the sampling window with IDELAYs
<_florent_>
DerekKozel[m]: for the
<_florent_>
DerekKozel[m]: sorry, for the Acorn, the way I'm testing it:
<_florent_>
the copy the driver directory to the machine with the Acorn
<rom>
hi, I'm currently working with vexriscv-smp, and I'm looking for a way to export the dram bus
<_florent_>
the/then
<_florent_>
cd kernel
<_florent_>
make
<_florent_>
sudo ./init.sh
<DerekKozel[m]>
Thanks. I'll try that right now.
<_florent_>
you can then do a dmesg and should see the litepcie traces
<_florent_>
once it's ok, go to user directory
<_florent_>
make
<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
<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
<_florent_>
litepcie_util info
<_florent_>
litepcie_util dma_test
<_florent_>
litepcie_util help for the available commands
<DerekKozel[m]>
Thanks
<DerekKozel[m]>
I was missing --driver
<_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
<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
<_florent_>
this will work, but will probably be a bit slow compared the the speed that can handle LiteDRAM
<rom>
expose a bus is our last option though
<_florent_>
if you want more speed, you can expose a port from LiteDRAM
<_florent_>
rom: ah sorry, so you want to have a LiteX SoC and connect it the the vendor's FPGA's DRAM IP?
<_florent_>
so get rid of LiteDRAM if I understand correctly?
<rom>
_florent_ please let me explain more on the matter :D
<_florent_>
rom: sure
<rom>
the LiteX SoC is a chip (VLSI design), fabricate using TSMC 180nm, which will serve as a test chip
<rom>
original plan is for it to use SDRAM
<rom>
due to pandemic (guh...), we can't finish the SDRAM test on time
<rom>
so we switch to use DDR
<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)
<rom>
"exposed", as in real GPIO pins on the chip
<rom>
I hope the explaination is clear enough
<rom>
the use case is... rather unusual though
<rom>
[Chip] <-- AXI/Wishbone --> [DRAM controller on FPGA]
<rom>
something like this
<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?
<rom>
(btw, I like LiteX, a lot easier to use than other stuffs like Chipyard or Rocketchip)
<_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)
<rom>
if LiteX support the adaption, I'd be more delight to hear it
<rom>
otherwise, I think I have around 50 IO? or 100? to work with
<promach[m]>
<_florent_ "promach: I mean we are not sampl"> what about spartan-6 ?
<rom>
I'd love to reduce the number of IO down though
<_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)
<_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):
<promach[m]>
<_florent_ "promach: For Spartan6 we were us"> what do you exactly mean by **fixed bitslip/delay which required manual adjustments** ?
<_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
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<promach[m]>
<_florent_ "On 7-Series/Ultrascale, the adju"> _florent_: ok, but how **manually** ?
<rom>
_florent_: could you elaborate more on the code? I did not get this parts yet
<_florent_>
promach[m]: that's the manual adjustement :) (found by testing on hardware)
<_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
<promach[m]>
_florent_: you mean on spartan-6, there is no IDELAY primitive involved during read operation ?
<promach[m]>
because I suppose bitslip is a feature specific to ISERDES2 primitive
<_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)
<rom>
_florent_: thanks, I got the part that it connect LiteDRAM, but didn't quite get how to expose the bus yet
<_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
<_florent_>
On Spartan6 we are using a fixed phase shift for DQS generation
<_florent_>
dynamic add flexibility, but we were doing it manually
<_florent_>
adds
<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
rom has quit [Quit: Ping timeout (120 seconds)]
chiefwigms has quit [Quit: Client closed]
rom has joined #litex
<gatecat>
one of the problems with AXI or Wishbone externally is they are synchronous to one side only
<gatecat>
whereas for external busses you ideally want source synchronous - ie clocks in either direction