linear_cannon has quit [Remote host closed the connection]
geertu has quit [Ping timeout: 250 seconds]
geertu has joined #litex
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
_whitelogger has joined #litex
<cr1901>
If I were to buy a litex-supported FPGA board that can go into a PCIe slot and is capable of e.g. running Linux/Litex, what is my (cheapest) option? Looking for a Christmas gift to myself
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #litex
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #litex
cr1901 has quit [Read error: Connection reset by peer]
cr1901_ has joined #litex
cr1901_ has quit [Client Quit]
cr1901 has joined #litex
<yootis>
Sqrl acorn / lite fury is the cheapest. You can get a cheap card to mount it in pcie slots
<yootis>
Cheap Carrier card
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
<cr1901>
Cool, I'll look into it
<tnt>
yootis: it's an argument to litex_server
<tnt>
you specify which transport to use. And then the litescope_clip connects to litex_server which will relay stuff.
<yootis>
tnt: yeah, but in the HDL, I just put a LiteScopeAnalyzer. Do I need to tell it where to connect? The arty.py example doesn't, so I assumed I didn't need to.
<tnt>
It should add itself to the SoC main wishbone bus. You should see it in the CSR report and in the csr csv that's generated.
<tnt>
In the csv you pass as the --csr-csv argument there should be some analyzer_xxxx entries in there.
<tnt>
and then the pcie core must be setup as a master for that wishbone bus.
<_florent_>
yootis: as tnt just said, LiteScope is just connected to the CSR bus (itself connected to the main bus). To use use it, you then just need a bridge between your Host and the main bus, which can be over UART/JTAG/Ethernet/PCIe
<yootis>
ok, then I don't know what's causing the problems. I still get errors when litescope_cli causes lxserver to do anything
<_florent_>
This is related to the remapping done only exposes the CSR to BAR0 with PCIe (and also related to https://github.com/enjoy-digital/litex/issues/1127), I'll have a closer look to properly fix it
<yootis>
--regs works as long as it is the first thing to connect to the server. Once litescope_cli runs, the server needs to be killed and restarted. Trying the above mods now.
<yootis>
BTW, as I dig through this, it looks like the stuff installed in ~/.local just points to the source directories. Is that right?
<tnt>
if you installed with litex_setup.sh then the install is made in 'develop' mode by default for all the repos.
<tnt>
_florent_: btw, on another subject: In the liteiclink test, is there a requirement for the sys_clk to be related to the linerate / reference clock ? When I use a 122.88 MHz clock (2.4576G linerate w 245.76M mgt reference), it works fine. But when I try to use an unrelated 300 MHz clock as my sys clock. Nothing.
<_florent_>
yootis: good, I'll also fix it while fixing #1127
<tnt>
( that 122.88M clock is generated by the same clock chip as all the other jesd clocks so it's a bit annoying to use as sys clock because as soon as I try to reconfigure the JESD clockinc ... I loose it and that's bad for a sys_clk ).
<_florent_>
Are you also using the UART bridge to control the test?
<_florent_>
tnt: Sorry, I have to go, will be back this afternoon
<tnt>
yup, I'm using the UART bridge. And I used the kcu105 file as reference but seems very similar.
<yootis>
Unfortunately, the server won't run while the litepci kernel module is loaded, so it will be hard to debug anything. Is that a separate issue or is it related?
geertu has quit [Read error: Connection reset by peer]
<tnt>
What's the error ? I would have thought the mmap through /sys would still work even with a driver loaded
geertu has joined #litex
<yootis>
I have to start the server with the module not installed. Once it is running, if I insmod the driver and run litescope I get a Bus Error on the server.
<tnt>
Mmm ok. I don't really know the sharing rules for the /sys mapping tbh. But if that's not supported then, you'd need another transport for the Remote clien that goes though the IOCTL of the litepcie /dev/litepcie0 char device to execute the CSR read/writes.
<tnt>
Another alternative might be to use a second bar dedicated to litescope but tbh that sounds more complicated.
linear_cannon has joined #litex
shenki has quit [Ping timeout: 240 seconds]
shenki has joined #litex
essele has quit [Read error: Connection reset by peer]
essele_ has joined #litex
lexano has quit [Ping timeout: 250 seconds]
lexano has joined #litex
<tnt>
Mmm ... loopback test works with CPLL but not QPLL.
lexano has quit [Ping timeout: 256 seconds]
lexano has joined #litex
<_florent_>
tnt: Arf... I imagine CPLL support is enough for the JESD but that while you are looking at this, you would also like to get QPLL working just to be able to flush all this from your head :)
<tnt>
The fact RXPLLCLKSEL is fixed to 0b00 seems surpicious to me.
<tnt>
_florent_: yeah, CPLL might do just fine but I was trying to find "broken" things to try and narrow down possible issues in general.
<tnt>
I don't have a physical loopback yet. I tried to configure the Talise framer in PRBS7 test mode, but that doesn't work with the prbs_test python script. I'm not sure if it's supposed to or not.
<tnt>
yeah, setting RXPLLCLKSEL appropropriately fixed the QPLL issue. But I'm not sure how that ever worked on GTH3 without it because AFAICT this is not GTH4 specific.
<_florent_>
tnt: it seems KCU105 testbench only uses CPLL (while XCU1525 can select CPLL/QPLL) so it's possible RXPLLCLKSEL is not correct for QPLL on GTHE3.
<_florent_>
tnt: I'm sure both have been tested on XCU1525 but don't remember for KCU105, I'll open an issue to also look at it.
<_florent_>
tnt: I was able to use the PRBS from LiteICLink with the AD937X's PRBS mode, on RX and TX, so it should also work with your chip.
<tnt>
Ok, good to know. So I guess something is wrong somewhere.
<_florent_>
tnt: But I remember having difficulty knowing if the AD937X was correctly configured, so added debug traces in the AD937X init code (at least to know the configured linerate on the chip)
<tnt>
Yeah, I might need to do that because you don't actually configure the line rate itself, just a bunch of params and it "derives" it ...
<_florent_>
tnt: and I imagine you also just have the software lib and no register map/register descriptions...
<tnt>
hehe, yeah of course.
<tnt>
I mean, I'm kind of grateful there is a "no-OS" driver you can easily integrate because it looks like a b*** to configure. But I would still ahve appreciated a register map for debugging.
<_florent_>
yes exactly, it's not simplifying integration
<tnt>
yootis: did you ever work with the Talise (ADRV9000 series) ?
<_florent_>
tnt: for the JESD bringup, I would recommend first validating PRBS in both direction (as you are doing now) then for JESD, first validate RX. This way if it's not working, you'll be able to put a LiteScope instance in the FPGA to observe the ILAS generated by the chip and make sure it matches the FPGA configuration (IIRC I had some surprises on this), once RX is working, validate TX (but the chip will probably not provide you
<_florent_>
that much info if failing... and not being able to look at the registers does not help...).
<_florent_>
Then when both RX/TX are up, enable the digital loopback in the chip and stress a bit the digital chain with dma_test/PCIe :)
<tnt>
Seems I never go through TALISE_setupSerializers() which is probably a bad sign my init sequence isn't complete lol.
<_florent_>
hehe, it will not help no :)
<tnt>
\o/
<tnt>
It works, I get the PRBS sequence from the Talise. BER 0 and when I shut it down, it reports errors.
<_florent_>
Great!
<tnt>
I'll work on seting up the PRBS checker inside the Talise to check the other direction.
lexano has quit [Ping timeout: 260 seconds]
lexano has joined #litex
<tnt>
_florent_: btw, the prbs error checker counter is 32 bits only and doesn't roll over, so the prbs_test can be misleading since when it saturates, it reports 0 errors ... (I patched it here to roll over because at 5 gbits, a 32 bit error counter saturates pretty fast).
<_florent_>
tnt: is it the counter from test_prbs or the hardware checker?
<tnt>
_florent_: yeah, I know, I patched that out to let it overflow here.
<tnt>
So I can keep the test_prbs running and it will reports 0 only if there is truly no error. And it can detect the ovrflow and correct the BER estimate localy.
<_florent_>
tnt: ah ok, I see, that's the two behaviour combined that generate 0 errors.
<_florent_>
tnt: do you want that I had a saturation mode? (to allow you to disable it)
<tnt>
_florent_: I can make a PR for that, add it as a build option. And then add that option in the liteiclink test examples and add overflow handling in test_prbs.
<_florent_>
tnt: if you don't mind, it's even better, thanks.