<_florent_>
tpw_rules: it's setting a false path between the sys_clk and pcie_clk, it will work without it but will take more time for P&R
<_florent_>
somlo: I started porting LiteSATA to ECP5, but haven't really put that much efforts in it for now so it's not yet working. I was planning to put more efforts into it while working on the Acorn base board (since it also has an ECP5 with 2 SATA connectors)
<_florent_>
Melkhior: LiteSATA only implement a minimal subset of SATA commands and has a simple interface, we tried to avoid AHCI when designing the core to keep things simple
<_florent_>
Melkhior: The Linux driver should be really easy since the core is handling a lot internally and the data interface is very similar to LiteSDCard
<_florent_>
Melkhior: but otherwise I agree with you on the fact to reuse standard driver for Linux systems, just not sure how complex it would be for SATA
pftbest has quit [Ping timeout: 252 seconds]
<Melkhior>
_florent_: I'm biased, with my design I need the drive in NetBSD rather than Linux :-)
<Melkhior>
And OHCI was 'miraculous': just needed a very small SBus -> OHCI shim (*very* similar to the existing PCI -> OHCI shim)
<Melkhior>
But of course, being standard-compliant is a lot more work, in particular with recent "feature-rich" standards...
<Melkhior>
Your SATA code looks reasonably easy; I already have a driver to DMA blocks to/from the SDRAM controller, I'm guessing a single-port SATA driver would be somewhat similar
<Melkhior>
Darn, another box ticked on the 'should i do a high-speed version' checklist :-)
<_florent_>
Melkhior: For LiteSATA, the initial aim was to be able to write/read data at maximum speed directly from the FPGA without CPU/driver, so we naturally avoided AHCI :)
<tpb>
Title: Iwan Smith on LinkedIn: #learning #hackathon (at www.linkedin.com)
pftbest has joined #litex
pftbest has quit [Ping timeout: 240 seconds]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
<tnt>
I'm considering trying out litex (litepcie + litejesd specifically) on a ZU11EG (and talking to an ADVRV9009). Anyone got experience with that ? I'm wondering what kind of gotcha I can expect.
<_florent_>
tnt: I'm using LiteX with LitePCIe/LiteJESD on 7-series with AD937X chips. Both LitePCIe and LiteJESD already support Ultrascale+, so if you are using a JESD configuration close to the one I already validated, I don't expect too much troubles
<_florent_>
I'm also interested to explore the ADRV9009, so could provide help setting up the infrastructure/cores
Martoni42 has quit [Ping timeout: 252 seconds]
C-Man has joined #litex
<_florent_>
With the AD937X/ADVRV9009, ADI no longer provide the full register map of the chip (as it was the case for the AD9361 for example) but only the software lib that has to be used as a reference. I found that a bit painful while working on the AD937X since it was difficult to get a clear status of the JESD link. But the JESD block is probably very similar between the AD937X/ADRV9009
<tnt>
_florent_: yeah, I've seen this "HAL" thing :/ But good to know this should be mostly supported. I'll get working on the "boring" part of writing the platform file with all the pins this afternoon or tomorrow.
<_florent_>
which JESD config are you planning to use?
<_florent_>
I'm not sure there are that much example provided with LiteJESD but I can provide you some
<_florent_>
I would first recommend getting LitePCIe working (with the DMA loopback)
<_florent_>
Then setup the SPI link for the ADRV9009 clocking/configuration
<tnt>
_florent_: ATM this is really more tech exploration more than anything, so I'll start by using whatever config is supported :)
<_florent_>
adapt the HAL for this
<tnt>
And yeah, getting litepcie working first, then litedram was the plan.
<_florent_>
then get the JESD lanes up and test with the PRBS
<tnt>
And finally tackle the ADRV and JESD.
<_florent_>
and once PRBS is validated, get the JESD link up
<_florent_>
and then connect everything :)
<tnt>
Sounds so easy :)
<_florent_>
yeah :) (I spent quite some time on it for the AD937X since I was also developing the JESD RX part...)
<tnt>
Oh yeah, this is RX only btw, not TX.
<_florent_>
OK, it will probably be easier to also setup the TX path
<_florent_>
This way you can use the internal loopback of the ADRV9009 for tests of the digital chain
<tnt>
oh right, that makes sense.
<_florent_>
LitePCIe has a DMA loopback test that can be useful for this
<_florent_>
with just LitePCIe, you can enable the loopback in the DMA and do: Host --> LitePCIe (loopback) --> Host
<_florent_>
but you can then extend this to the digital chain of your design
<_florent_>
but yeah, the cores are here, but integration can still require some time/work
michalsieron has joined #litex
<_florent_>
tnt: BTW for this, if you don't want to use LiteX for the integration it's possible to generate the cores as standalone verilog cores. LitePCIe/LiteDRAM already have their generators but LiteJESD204B's generator hasn't been created yet (probably not too complicated to do but I haven't had a use case for it now).
<tnt>
_florent_: Good to know it's an option. But I was actually planning to also use this to give LiteX a better try. A lot of the time I work on pre-existing stuff that already has a code base/build system, or on stuff for the ice40 where every lut count and I want to control every little detail. Here since it's a bit exploration and on a giant FPGA, I want to give the "plug and play" thing a try :)
FabM has joined #litex
FabM has quit [Changing host]
FabM has joined #litex
cr1901 has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
<_florent_>
tnt: I see, i'm a big fan of your optimizations. In LiteX the approach is a indeed bit different, we first try to favor simplicity/portability and then optimize when really useful/required (and we have the opportunity/budget :)) This is sometimes less optimal (but should still not be too bad) but gives a higher level of abstractions and can simplify creating more complex systems
<acathla>
Don't you still need an expensive licence to program big FPGAs?
<tnt>
Yes
<_florent_>
gatecat: That's indeed a good deal! I was going to also buy one when I saw the tweet yesterday just to study it, but too late...
<gatecat>
yeah they went quickly :/
<Wolf0>
acathla: If you need one, DM me :P
<Wolf0>
(for linux)
alainlou has joined #litex
<Wolf0>
also, the Alveo ones don't require a license
<Wolf0>
fun fact
<promach[m]>
<_florent_> "fine delay was done using..." <- _florent_: for litedram on spartan-6, how do you exactly bypass single clock restriction for IDDR/ODDR ?
<acathla>
Wolf0, thank you, may be one day. I have some virtex4 on PCI boards and some virtex5 unsoldered (I'll probably never build anything with them).
Martoni42 has joined #litex
<kbeckmann>
sorry if this is covered in the documentation (couldn't find it) but what is the proper way to partition and format an sdcard so it works well with litesdcard and the code included in the bios?
<kbeckmann>
good to know. i am having some trouble actually and had to comment out SDCARD_CMD18_SUPPORT and SDCARD_CMD25_SUPPORT, and also lower the frequency (might be because i use a PMOD)
<kbeckmann>
boot.json is so useful! it lets me load a big rom into SDRAM and boot my application from my second BRAM location. really cool stuff :)
<_florent_>
which PMOD are you using?
<kbeckmann>
the digilent one, it doesn't have any level shifters.
<_florent_>
ok, I also have this one, it was fine on Arty with the default LiteX settings. I could do more tests on an ECP5
michalsieron has quit [Ping timeout: 252 seconds]
<kbeckmann>
it could also be my fpga board that has a bad ground plane or so
<kbeckmann>
actually now that i lowered the frequency by a lot, i don't need to disable CMD18/CMD25
bluecmd has joined #litex
michalsieron has joined #litex
acathla has quit [Ping timeout: 248 seconds]
<bluecmd>
Hello! I have an itch to reboot a gigantic FPGA project I started a few years back but use LiteX to build it this time to not be so bound to one vendor and use the nice IPs that it seem to have. The board I have is a DE5-Net so that means I would have to help contribute board files etc. Does this sound like a plan? Any gotchas with using LiteX with
<bluecmd>
Stratix V?
<bluecmd>
The project is https://github.com/bluecmd/fejkon - basically a thing that shoves Fibre Channel packets to a host over PCIe.
<bluecmd>
brb, trying to join via matrix instead
bluecmd has quit [Quit: Client closed]
bluecmd has joined #litex
bluecmd_ has joined #litex
bluecmd has quit [Quit: Reconnecting]
bluecmd has joined #litex
<_florent_>
Hi bluecmd, interesting projet. LiteX will work on Stratix V but the cores clearly have better support for now on Xilinx/Lattice devices (just because most of the current projects uses Xilinx/Lattice devices).
<_florent_>
LitePCIe can probably be adapted for Stratix V without too much troubles. I ported it to Cyclone V a few years ago as an experiment and it was not too much work.
<bluecmd>
I also have a Kintex 7 board I could use I suppose, it's not as fancy if that's a huge deal
<bluecmd>
Yeah, I looked at the Cyclone V PCIe and it looked pretty nice - requires some manual generation of the hard IP stuff I guess but that's acceptable