*** tpb <[email protected]> has joined #litex | 00:00 | |
*** Degi <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 03:59 | |
*** Degi <[email protected]> has joined #litex | 04:02 | |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 06:59 | |
*** TMM_ <[email protected]> has joined #litex | 06:59 | |
*** FabM <[email protected]> has joined #litex | 07:01 | |
tnt | _florent_: btw, did you see https://github.com/enjoy-digital/litepcie/issues/104 ? Do you want a PR if you think that's a good fix ? | 08:37 |
---|---|---|
*** trabucayre <[email protected]> has quit IRC (Read error: Connection reset by peer) | 08:40 | |
*** trabucayre <[email protected]> has joined #litex | 08:40 | |
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 08:44 | |
*** Brinx <[email protected]> has joined #litex | 08:45 | |
*** Brinx <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 08:49 | |
*** Brinx <[email protected]> has joined #litex | 09:12 | |
_florent_ | tnt: Sorry, I had to disable Github notifications (IRQ) to switch to manual polling mode for PR/Issues :) | 09:30 |
_florent_ | tnt: I'll have a look today | 09:30 |
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 :) | 09:31 |
zyp | we had a similar issue in orbtrace, 4 is not deep enough for a CDC FIFO to go full speed | 10:08 |
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 | 10:10 |
tnt | Yeah possibly changing it generally in stream.ClockDomainCross would be better than just in the pcie module. | 10:15 |
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 | 10:20 |
minute | tpw_rules: i'm using litevideo framebuffer. some dma block copying would be nice | 11:14 |
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 ? | 11:15 |
minute | should l2_cache be used nowadays if one has DDR3? | 11:17 |
minute | so with 4 cores (vexriscv), the linux system basically works but then there are spurious bugs that crash processes | 11:45 |
minute | i wonder if it's a cache issue | 11:45 |
minute | > sh[96]: unhandled signal 11 code 0x1 at 0x00000000 in busybox[692c5000+df000] | 11:46 |
minute | > [ 13.630461] sh[95]: unhandled signal 7 code 0x1 at 0x95ad23a0 in libc.so.6[95a22000+155000] | 11:46 |
minute | clock table has no failing endpoints | 11:47 |
minute | is multicore vexriscv linux working for anyone at the moment with current litex? | 12:00 |
tnt | minute: did you run some extended memory test to make sure you don't have the occasionnal error on the memory ? | 12:01 |
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 | 12:02 |
*** Guest4346 <[email protected]> has joined #litex | 12:22 | |
*** Guest4346 <[email protected]> has quit IRC (Client Quit) | 12:23 | |
*** Crateus <[email protected]> has joined #litex | 12:23 | |
*** Crateus <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 12:33 | |
*** Crateus <[email protected]> has joined #litex | 12:44 | |
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 | 12:48 |
tnt | well chances your CPU has a bug ... | 12:49 |
*** Jarek <[email protected]> has joined #litex | 12:52 | |
Crateus | Is there some minimum requirements to have litex bios working ? | 12:53 |
tnt | rv32i :) | 12:55 |
*** Jarek <[email protected]> has quit IRC (Quit: Leaving) | 12:59 | |
*** Crateus <[email protected]> has quit IRC (Quit: Client closed) | 13:03 | |
*** Crateus <[email protected]> has joined #litex | 13:03 | |
*** Crateus <[email protected]> has quit IRC (Quit: Client closed) | 13:25 | |
_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. | 13:32 |
_florent_ | tnt: and thanks for upstreaming your fix, I imagine it's possible to spend a bit of time identifying this one... | 13:33 |
tnt | _florent_: ack, will open one tomorrow or tonight. I want to check if depth=8 is enough (atm I went with 16). | 13:33 |
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 ) | 13:34 |
_florent_ | tnt: Thanks, that's also possible we were using 8 before I switch from AsyncFIFO to ClockDomainCrossing module | 13:34 |
_florent_ | tnt: good! | 13:35 |
_florent_ | minute: You also stress the DRAM more by enabling BIST and using sdram_bist command in the BIOS: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1426 | 13:37 |
_florent_ | minute: It will use hardware generator/checker to stress the DRAM at maximum speed. | 13:37 |
minute | _florent_: interesting, thanks! | 13:38 |
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. | 13:47 |
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 ... | 13:47 |
_florent_ | For 1) not sure what it can be, I'm almost always rebooting the PC | 13:53 |
_florent_ | For 2) you can indeed have DMA gaps when the PCIe of the system is busy or when there are bus contentions. | 13:55 |
_florent_ | and especially at the speed you are running things. | 13:55 |
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 :) | 13:56 |
_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 | 13:57 |
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. | 13:58 |
tnt | Looks like you're been playing with some ADRV too btw :) | 13:59 |
tnt | Although the newer ones. | 14:00 |
_florent_ | On PCIe Gen2 X4 designs, I generally have buffering_depth set to 2**17 (128KB) | 14:00 |
_florent_ | Yes, I'm doing a design with the ADRV902X | 14:01 |
_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...) | 14:04 |
_florent_ | I have to admit that I haven't yet used that much bandwidth on a design. | 14:05 |
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 14:29 | |
*** Brinx <[email protected]> has joined #litex | 14:29 | |
*** Brinx <[email protected]> has quit IRC (Read error: Connection reset by peer) | 14:32 | |
*** Brinx <[email protected]> has joined #litex | 14:32 | |
tnt | _florent_: No, ATM I haven't put the DDR in there, I'm just using some URAMs. | 14:36 |
*** Brinx <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 14:37 | |
_florent_ | tnt: What's the DDR on your board? DDR4 / 64-bit? | 14:40 |
tnt | Yeah, DDR4 with 2 independent banks of 32 bits. | 14:42 |
*** Brinx <[email protected]> has joined #litex | 15:08 | |
*** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 15:17 | |
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...) | 15:29 |
*** Guest13 <[email protected]> has joined #litex | 15:42 | |
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 15:43 | |
*** Brinx <[email protected]> has joined #litex | 15:44 | |
_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. | 15:44 |
_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) | 15:45 |
_florent_ | This would not be fully open-source, but would at least allow using the max freqs. | 15:45 |
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 ? | 15:46 |
_florent_ | yes, it would be very similar to LitePCIe for example | 15:48 |
*** Brinx <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 15:48 | |
*** Guest13 <[email protected]> has quit IRC (Quit: Client closed) | 16:02 | |
*** Guest13 <[email protected]> has joined #litex | 16:03 | |
*** slagernate <[email protected]> has joined #litex | 16:09 | |
*** Guest13 <[email protected]> has quit IRC (Quit: Client closed) | 16:11 | |
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? | 16:28 |
_florent_ | slagernate: I haven't fully read 1441, but: | 16:29 |
_florent_ | do you have leds on your board? If so, is the led chaser working? | 16:30 |
_florent_ | first thing is to verify if you have a clock and it it's at the correct frequency | 16:31 |
slagernate | led chaser is working, yes | 16:31 |
_florent_ | OK | 16:31 |
_florent_ | do you have a reset button? | 16:31 |
_florent_ | If you press it, does the LedChaser stop? | 16:31 |
slagernate | yes | 16:31 |
slagernate | led chaser stops (all leds are lit) | 16:32 |
_florent_ | ok good | 16:32 |
_florent_ | So once you have this, you should be able to get a CPU working | 16:32 |
_florent_ | have you verified the UART pins? | 16:33 |
slagernate | re: uart pins: https://github.com/enjoy-digital/litex/issues/1441#issuecomment-1261516049 | 16:34 |
_florent_ | ok, and you also tested swapping RX/TX (a classic issue :))? | 16:34 |
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) | 16:36 |
_florent_ | ok, and so you don't see anything generated by the FPGA? | 16:37 |
slagernate | correct | 16:41 |
slagernate | re: checking the clock freq --the crosslinkNX has an on-chip oscillator (controlled by NXOSCA() in litex) | 16:43 |
*** Guest13 <[email protected]> has joined #litex | 16:45 | |
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. | 16:45 |
slagernate | here is the build script I am using (virtually the same as the one on github): https://github.com/enjoy-digital/litex/issues/1441#issuecomment-1259839657 | 16:47 |
slagernate | it seems likely that the bios code was updated and subsequently broke the crosslinknx eval board build file | 16:48 |
slagernate | maybe I will try an older version of litex which lines up with when lattice_crosslink_nx_evn.py was working | 16:48 |
_florent_ | I would recommend using VexRiscv for now | 16:53 |
_florent_ | (the default) | 16:53 |
_florent_ | and also try to remove this: kwargs["integrated_sram_size"] = 0 | 16:53 |
_florent_ | and comment the 128KB LRAM section | 16:53 |
_florent_ | sorry I have to go | 16:53 |
slagernate | np. thanks a lot for your advice! | 16:54 |
*** Brinx <[email protected]> has joined #litex | 16:56 | |
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 17:00 | |
*** Brinx <[email protected]> has joined #litex | 17:00 | |
gatecat | another thing to try if you haven't already is if litex_sim works | 17:04 |
gatecat | that would rule out toolchain issues | 17:04 |
gatecat | *software toolchain issues | 17:05 |
gatecat | on that note, which riscv*-gcc are you using? | 17:05 |
*** Guest13 <[email protected]> has quit IRC (Quit: Client closed) | 17:24 | |
*** giggiu16 <[email protected]> has joined #litex | 17:32 | |
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! | 17:35 |
*** giggiu16 <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 17:41 | |
*** nickoe1747 <[email protected]> has joined #litex | 17:41 | |
*** nickoe17 <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 17:45 | |
*** giggiu16 <[email protected]> has joined #litex | 17:47 | |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 18:48 | |
*** TMM_ <[email protected]> has joined #litex | 18:49 | |
*** giggiu16 <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 19:20 | |
*** Guest13 <[email protected]> has joined #litex | 19:33 | |
*** Guest13 <[email protected]> has quit IRC (Quit: Client closed) | 19:42 | |
*** slagernate <[email protected]> has quit IRC (Quit: Ping timeout (120 seconds)) | 19:48 | |
_florent_ | giggui16: you can have a look at https://github.com/enjoy-digital/litex/wiki/Reuse-a-(System)Verilog,-VHDL,-(n)Migen,-Spinal-HDL,-Chisel-core | 20:19 |
_florent_ | and https://github.com/enjoy-digital/litex_verilog_axi_test/blob/master/test_axi.py to have a concrete example | 20:19 |
_florent_ | tnt: I just shared what I initiated 3 years ago on LiteDRAM + PHY of the MIG for DDR4: https://github.com/enjoy-digital/litedram_ddr4_mig_phy_test | 20:24 |
_florent_ | tnt: I was not yet working, but probably not that far | 20:25 |
_florent_ | it would probably need to be updated to compile with upstream LiteX, I could have a look at this soon. | 20:26 |
_florent_ | then happy to collaborate on this if you are interested :) | 20:27 |
*** slagernate <[email protected]> has joined #litex | 23:57 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!