trabucayre has quit [Read error: Connection reset by peer]
trabucayre has joined #litex
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
Brinx has quit [Ping timeout: 265 seconds]
Brinx has joined #litex
<_florent_>
tnt: Sorry, I had to disable Github notifications (IRQ) to switch to manual polling mode for PR/Issues :)
<_florent_>
tnt: I'll have a look today
<tnt>
_florent_: Sure, no worries and not urgent. Works here, but I always try to push what I can to minimaize my difference with upstream :)
<zyp>
we had a similar issue in orbtrace, 4 is not deep enough for a CDC FIFO to go full speed
<zyp>
IIRC the gray counters has three cycles latency in each direction, so there's around a six cycle latency from something goes into the fifo and increments the write pointer until you see it being read out reflected back in the read pointer
<tnt>
Yeah possibly changing it generally in stream.ClockDomainCross would be better than just in the pcie module.
<zyp>
for fast domains you don't want to make it too deep either, we've got a 250MHz domain on the ecp5 in the orbtrace, and that barely meets timing with a fifo depth of 8, with the gray counters being the critical path
<minute>
tpw_rules: i'm using litevideo framebuffer. some dma block copying would be nice
<tnt>
Quick Migen question. a = Signal(9); b = Signal(8); does a.eq(b+1) properly carry into the MSB of a when b==255 ?
<minute>
should l2_cache be used nowadays if one has DDR3?
<minute>
so with 4 cores (vexriscv), the linux system basically works but then there are spurious bugs that crash processes
<minute>
i wonder if it's a cache issue
<minute>
> sh[96]: unhandled signal 11 code 0x1 at 0x00000000 in busybox[692c5000+df000]
<minute>
> [ 13.630461] sh[95]: unhandled signal 7 code 0x1 at 0x95ad23a0 in libc.so.6[95a22000+155000]
<minute>
clock table has no failing endpoints
<minute>
is multicore vexriscv linux working for anyone at the moment with current litex?
<tnt>
minute: did you run some extended memory test to make sure you don't have the occasionnal error on the memory ?
<minute>
tnt: yes, i checked the whole 1GB in litex bios. i could do one in linux with single core though. also, i wonder why these problems would happen only in multicore configurations
Guest4346 has joined #litex
Guest4346 has quit [Client Quit]
Crateus has joined #litex
Crateus has quit [Ping timeout: 252 seconds]
Crateus has joined #litex
<Crateus>
Hello everyone, could someone help me with an error ? I implemented a custom rv32i cpu in litex. I can build it and boot it with litex_sim. But I evetime get a BIOS CRC failed and then the bios freeze. Anyone have an idea for this kind of error ? Thank you
<tnt>
well chances your CPU has a bug ...
Jarek has joined #litex
<Crateus>
Is there some minimum requirements to have litex bios working ?
<tnt>
rv32i :)
Jarek has quit [Quit: Leaving]
Crateus has quit [Quit: Client closed]
Crateus has joined #litex
Crateus has quit [Quit: Client closed]
<_florent_>
tnt: nice speed gain with your changes on the FIFO depth. A PR would make sense yes, I could then have a closer look and simulate things to see if it would also be useful to increase the default depth of ClockDomainCrossing module directly.
<_florent_>
tnt: and thanks for upstreaming your fix, I imagine it's possible to spend a bit of time identifying this one...
<tnt>
_florent_: ack, will open one tomorrow or tonight. I want to check if depth=8 is enough (atm I went with 16).
<tnt>
And 45.51Gbit is actually the max speed you can get with sys_clk at 200 MHz ( needs 9x256b to transfer 8x256b of payload with the header so 200M*256b/9*8 = 45.51G )
<_florent_>
tnt: Thanks, that's also possible we were using 8 before I switch from AsyncFIFO to ClockDomainCrossing module
<_florent_>
minute: It will use hardware generator/checker to stress the DRAM at maximum speed.
<minute>
_florent_: interesting, thanks!
<tnt>
_florent_: btw, just in case you have some idea, I'm trying to figure out two pcie related issues : (1) when dynamic reloading a bitstream, I can talk on pcie fine, except I sometime get huge latency spikes (i.e. a write will take 5 ms to complete). Reboot fixes it. and (2) I get long-ish period where the RQ from the phy is not ready (up to 10-15 us), causing gaps in the DMA stream.
<tnt>
TBH I'm not sure I can actually do anything about either of theses, but if you have any idea of something to try ...
<_florent_>
For 1) not sure what it can be, I'm almost always rebooting the PC
<_florent_>
For 2) you can indeed have DMA gaps when the PCIe of the system is busy or when there are bus contentions.
<_florent_>
and especially at the speed you are running things.
<tnt>
Yeah. ATM I just have a 4096 deep FIFO in front of the DMA but at 40Gbits/s, a 15us gap is a _long_ time to buffer :)
<_florent_>
Since the buffers are in the RAM of the PC, first make sure that you have Quad or Dual channel enabled for the RAM of your PC
<tnt>
Yup that's enabled. I actually have 2 different system (both intel, but one 10th gen, the other 11th gen, diferent chipset/mobo). The 11th gen is a bit better behaved in the sense there are more gaps but they are shorter which is a bit easier to deal with.
<tnt>
Looks like you're been playing with some ADRV too btw :)
<tnt>
Although the newer ones.
<_florent_>
On PCIe Gen2 X4 designs, I generally have buffering_depth set to 2**17 (128KB)
<_florent_>
Yes, I'm doing a design with the ADRV902X
<_florent_>
tnt: If I remember, you were buffering things in DDR between the PCIe and RFIC? (but I imagine that at 40Gbps, it will be difficult...)
<_florent_>
I have to admit that I haven't yet used that much bandwidth on a design.
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
Brinx has quit [Read error: Connection reset by peer]
Brinx has joined #litex
<tnt>
_florent_: No, ATM I haven't put the DDR in there, I'm just using some URAMs.
Brinx has quit [Ping timeout: 268 seconds]
<_florent_>
tnt: What's the DDR on your board? DDR4 / 64-bit?
<tnt>
Yeah, DDR4 with 2 independent banks of 32 bits.
Brinx has joined #litex
FabM has quit [Quit: Leaving]
<tnt>
_florent_: btw, wrt to DDR4, I could definitely contribute a couple kEUR to developping a native mode phy for litedram. (I know, not much wrt to the task, but if there is enough people willing to do the same...)
Guest13 has joined #litex
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
<_florent_>
tnt: I discussed this at some point with a client, but we haven't made this yet. Good to know you are also willing to potentially fund part of this work.
<_florent_>
tnt: another possibility, that would require less development and that I already started would be to use LiteDRAM + the Xilinx PHY of the MIG. (just the PHY, not the full controller)
<_florent_>
This would not be fully open-source, but would at least allow using the max freqs.
<tnt>
Ah yeah, I guess that could be generated as part of the flow like xci cores and then cherry pick the files needed and plug into it ?
<_florent_>
yes, it would be very similar to LitePCIe for example
Brinx has quit [Ping timeout: 265 seconds]
Guest13 has quit [Quit: Client closed]
Guest13 has joined #litex
slagernate has joined #litex
Guest13 has quit [Quit: Client closed]
<slagernate>
Hmm, still can't quite get a demo working on a crosslinkNX dev board (https://github.com/enjoy-digital/litex/issues/1441). Might try simulating it with e.g. cocotb. Is there a good starting point anyone is aware of for this?
<_florent_>
slagernate: I haven't fully read 1441, but:
<_florent_>
do you have leds on your board? If so, is the led chaser working?
<_florent_>
first thing is to verify if you have a clock and it it's at the correct frequency
<slagernate>
led chaser is working, yes
<_florent_>
OK
<_florent_>
do you have a reset button?
<_florent_>
If you press it, does the LedChaser stop?
<slagernate>
yes
<slagernate>
led chaser stops (all leds are lit)
<_florent_>
ok good
<_florent_>
So once you have this, you should be able to get a CPU working
<_florent_>
ok, and you also tested swapping RX/TX (a classic issue :))?
<slagernate>
Haha, yes (I am also using an o-scope to verify that my uart bytes are showing up on the RX pin of the FPGA when I send type in serial terminal)
<_florent_>
ok, and so you don't see anything generated by the FPGA?
<slagernate>
correct
<slagernate>
re: checking the clock freq --the crosslinkNX has an on-chip oscillator (controlled by NXOSCA() in litex)
Guest13 has joined #litex
<slagernate>
with a "pico" risc-v cpu (picorv32) it seems the cpu crashes on the call to init_uart(), as the LEDs can be controlled well via csr writes up until that func. call.
<slagernate>
it seems likely that the bios code was updated and subsequently broke the crosslinknx eval board build file
<slagernate>
maybe I will try an older version of litex which lines up with when lattice_crosslink_nx_evn.py was working
<_florent_>
I would recommend using VexRiscv for now
<_florent_>
(the default)
<_florent_>
and also try to remove this: kwargs["integrated_sram_size"] = 0
<_florent_>
and comment the 128KB LRAM section
<_florent_>
sorry I have to go
<slagernate>
np. thanks a lot for your advice!
Brinx has joined #litex
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
<gatecat>
another thing to try if you haven't already is if litex_sim works
<gatecat>
that would rule out toolchain issues
<gatecat>
*software toolchain issues
<gatecat>
on that note, which riscv*-gcc are you using?
Guest13 has quit [Quit: Client closed]
giggiu16 has joined #litex
<giggiu16>
Hi everyone, I would like to ask if is there any existing example of a litex simulation which includes existing verilog sources to look at. I have bridged a verilog code base to a litex module but I am struggling to simulate it and produce a vcd for gtkwave import.. any help would be very grateful, thanks!