_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
<jevinskie[m]> $100 XC7K325T from qmtech 👀
<tpb> Title: QMTECH Xilinx FPGA Kintex7 Kintex 7 XC7K325T DDR3 Core Board| | - AliExpress (at a.aliexpress.com)
Las[m] has joined #litex
<sajattack[m]> enticing, but I think those don't support the free version of vivado, do they?
<jevinskie[m]> Unfortunately not
<Wolf0> sajattack[m]: Do you need a license?
Degi_ has joined #litex
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
mc6808 has joined #litex
mc6808 has quit [Quit: Client closed]
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
cr1901 has quit [Quit: Leaving.]
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
<Melkhior> hello, linux-on-litex-vexriscv won't boot for me with the latest update (BIOS change?) in litex, the kernel hangs almost immediately, when identifying the memory
<Melkhior> is that a known issue ?
<_florent_> Melkhior: I tested it recently on Arty, it was still working, do you have a specific configuration;
<_florent_> ?
<Melkhior> it's a basic qmtech wukong configuration, no l2, single core, no changes except for #1053
<Melkhior> no ethernet, not sdcard configured
<Melkhior> only serial, framebuffer and icap_bistream
<Melkhior> ... and minor changes in platform/targets for my hand-built RGB222 VGA Pmod (VGA output with only 8 signals)
<Melkhior> I didn't clean / rebuild the buildroot and opensbi though from the previous version
<Melkhior> will try that
Coldberg has quit [Remote host closed the connection]
Coldberg has joined #litex
<Melkhior> (the qmtech has hdmi, i'm testing the pmod)
<Melkhior> well, false alarm ; cleaned up everything and started again, this time boot had no issue
<Melkhior> _florent_: all good :-)
<Melkhior> one HW question - what is the limit on sdram BW ? Running 16 bits at 800 MY/s I should have 1.6 GB/s peak, and probably 1-1.2 usable when overheads are removed
<Wolf0> Melkhior: ANY SDRAM? I'm getting 550GB/s sequential on HBM2 :3
<Melkhior> hehe :-)
<Wolf0> Sorry, had to. :3
<Melkhior> I don't dare used my VCU128 for non-work stuff :-)
<Wolf0> Melkhior: please, please do. I need more people doing interesting stuff with the HBM parts to chat with :P
<Wolf0> Also, related: I made a slightly snarky reddit thread which miiight irritate Xilinx a little: https://www.reddit.com/r/FPGA/comments/pxfuo5/completing_a_badly_incomplete_xilinx_answer/
<Melkhior> but the DMA stuff seems to be running in sys_clk, so would be limited to sys_clk_freq * mem_width - or only 200 MB/s for me (100 MHz, 16 bits)
<Wolf0> Sounds like you need a bigger bus.
<Melkhior> I'm limited by the HW :-)
<Melkhior> the memory is 16 bits
<Melkhior> the Wishbone is 32 bits
<Wolf0> ahhh, got it
<Melkhior> So I'm wondering how to improve BW usage between the FB and the SDRAM ... with my limited HW
<Wolf0> FB?
<Melkhior> a 1280x1024@60 Hz FB is only 150 / 300 MB/s in 16/32 bpp, that should work with the 800 MT/s 16-bits SDRAM ...
<Melkhior> FB == FrameBuffer
<Wolf0> ahh... well, mean, my first instinct is raising clock speed, if you require more bandwidth
<Wolf0> My second instinct is changing timings - particularly refresh rate tends to be nice
<Wolf0> But changing refresh rate tends to work best when you're maxing out your RAM usage
<Melkhior> timjngs are probably OK - raw bandwidth has room to spare
<Melkhior> sys_clk would help, but I'm kind of stuck because of FPGA and design limitations (some stuff in sysclk are practically limited to 100 MHz)
<Melkhior> so I guess there's only the bus width left ... I need to figure out how to read & display multiple pixels at once I guess
geertu has quit [Ping timeout: 240 seconds]
geertu has joined #litex
<Melkhior> Seems to me the LiteDRAMCrossbar is running in sysclk, and will limit the usable bandwidth going through it - _florent_: is that correct?
peepsalot has quit [Read error: Connection reset by peer]
somlo has quit [Remote host closed the connection]
cr1901 has joined #litex
somlo has joined #litex
<_florent_> Melkhior: LiteDRAMCrossbar is running in sys_clk yes, but with the native controller's data_width (ex 128-bit on 16-bit DDR3)
<Melkhior> _florent_: so for 128-bit (or multiple thereof) access it's fast, but for lower we get correspondingly lower bandwidth ?
<Melkhior> so the framebuffer should try to access many pixels at once ?
<Melkhior> (with e.g. a 128 bits native interface)
<Melkhior> clarification: 's/but for lower/but for narrower [than 128 bits]/'
<_florent_> Melkhior: the framebuffer in LiteX is doing the read in the native data-width, then down-convert it: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/video.py#L616-L648
<Melkhior> mmm, ok, I though that would be the native width of the memory (16 bits), I should have print()ed it
<Melkhior> so it _does_ read multiple pixels at once already?
<Melkhior> I have issue with higher-resolution display (1024x768 and more) even if timing closes fine, I though it might be lack of bandwidth...
<_florent_> you can maybe try to increase the framebuffer fifo depth: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/video.py#L609
<_florent_> you can also add LiteScope to probe video_pipe_source.valid
<_florent_> it should always be at 1 when the video is enable. If you see it at 0, there are indeed bandwidth issues
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<Melkhior> ok
<Melkhior> thanks
TMM_ has joined #litex
<Melkhior> I need to investigate further then
<Melkhior> (ultimate goal is to go from 16-bits to 8-bits and emulate an old IndexedColor framebuffer)
<Melkhior> 16 bits is in #1053
peepsalot has joined #litex
<Melkhior> _florent_: 1024x768@60Hz/16bpp (90MB/s required, I think) -> underflow comes up pretty strongly (just connected it to a LED)
<Melkhior> at least with the default FIFO depth of 65536B (4096 entries of 16B/128b)
<Melkhior> trying with a bigger FIFO (4x)
<Melkhior> which I really don't understand unless I messed up 16bpp badly, as 800x600@60Hz/32bpp did work and has higher BW requirements!
<Melkhior> I'm confused :-)
<_florent_> Melkhior: what's your sys_clk?
<Melkhior> 100 MHz
<_florent_> and your pix_clk? 65e6?
<Melkhior> yes, std 1024x768@60
<_florent_> can you share your modification to do 16bpp with the video code?
<Melkhior> with its own S7MMCM
<_florent_> video core
<Melkhior> #1053 :-)
<Melkhior> PR on github
<Melkhior> (trying again with 32bpp just in case)
<_florent_> ah sorry :)
<Melkhior> no problem :-)
<Melkhior> BTW, #1053 'works' with linux -> I get a picture, even though I'm not 100% certain about colors (my VGA output only use 2 bits per color...)
<Melkhior> I _think_ the led is a bit brighter with 32bpp, but it's hard to tell
<Melkhior> Also - screen is more distorted, and Linux doesn't seem to finish booting...
<Melkhior> Final update - it seems going to a 512 KiB FIFO (all available BRAM) doesn't help, while going back down to 32 KiB isn't much worse than 64 KiB
<_florent_> Melkhior: #1053 looks fine, I also don't understand why 32bpp work and not your 16bpp
<Melkhior> _florent_: they both work for low-resolution, and I might be an idiot with confirmation bias... I was looking at the wrong led!
<_florent_> ahah
<Melkhior> so to recap: 800x600 works fine in 16bpp and 32bpp ; 1024x768 has severe issue in 32bpp, much less severe in 16bpp
<Melkhior> (as in, Linux doesn't boot in 32bpp but does in 16bpp
<Melkhior> however, I still have no idea *why* it behaves that way (I _did_ think of checking timings, never had any issue)
<Melkhior> the screen gets a bit distorted in 1024x768/16bpp, slightly more severe in 1024x768/32bpp
<Melkhior> and I still need to check underflow by looking at the proper led (I've connected it to ALL user_leds now :-) )
<_florent_> Melkhior: BTW, this can be interesting: https://github.com/litex-hub/litex-boards/issues/239
<_florent_> modifications to the Video core to do 1280x720@16bpp from a SDRAM
<Melkhior> _florent_: similar to what I've done for 16bits, but I wonder why he gets rid of the data-width conversion - maybe he assumed like me that the dram_port.data_width was 16 ?was
<_florent_> ah yes, probably specific to this case
<_florent_> but the Converter should not add logic when doing a 1:1 conversion
ilia__s9 has joined #litex
<Melkhior> Mine is definitely 128 as you said, and I should have a lot more available bandwidth in 800 MT/s DDR3 than in 143 Mhz SDRAM ?!?
<Melkhior> Anyway - the leds seem to be off in the 1024x768 case, so it might not be a bandwidth issue
indy_ has joined #litex
Xesxen_ has joined #litex
cr1901 has quit [*.net *.split]
Coldberg has quit [*.net *.split]
FabM has quit [*.net *.split]
Xesxen has quit [*.net *.split]
ilia__s has quit [*.net *.split]
indy has quit [*.net *.split]
ilia__s9 is now known as ilia__s
<_florent_> Melkhior: How many CPU do you have? With VexRiscv SMP, each CPU has 2 direct LiteDRAM ports. This could also be an arbitration issue.
<Melkhior> just one cpu in this test
<Melkhior> completely standard, no fancy extension :-)
ilia__s5 has joined #litex
<_florent_> OK
FabM has joined #litex
cr1901 has joined #litex
Ikkepop has joined #litex
ilia__s has quit [Ping timeout: 265 seconds]
ilia__s5 is now known as ilia__s
<Melkhior> 1024x768/32bpp doesn't light up the 'overflow' leds, either (though I don't trust myself not to have messed up the Led connection...)
<Melkhior> let's try 1920x1080 and see what happens :-)
<Melkhior> 1920x1080@60Hz/16bpp: FPGA timings are fine, screen says 'out of range', kernel hangs when seeing the frambuffer, overflow leds are still off...
<Melkhior> I'm definitely out of my depth :-)
<Melkhior> need to sleep on it
<Melkhior> thanks for the help!
<Melkhior> bye
tpb_ has joined #litex
tpb has quit [Killed (NickServ (GHOST command used by tpb_))]
Xesxen has joined #litex
shorne_ has joined #litex
tpb_ is now known as tpb
lexano_ has joined #litex
Xesxen_ has quit [Ping timeout: 265 seconds]
shorne has quit [Ping timeout: 265 seconds]
lexano has quit [Ping timeout: 265 seconds]
kbeckmann has quit [Ping timeout: 265 seconds]
Degi has quit [Ping timeout: 265 seconds]
Degi has joined #litex
kbeckmann has joined #litex
FabM has quit [Quit: Leaving]
Las[m] is now known as Las[m]_
Wolf0 has quit [Quit: leaving]
Wolf0 has joined #litex
<jevinskie[m]> I’ve been thinking about how to speed up litescope downloads over JTAG and I came up with two ideas: 1) use another JTAG block to implement an IR while switching out the existing JTAG block between JTAGPHY acting as a DR vs a new JTAG DMA streamer as DR or 2) add another bit to the JTAGPHY wire protocol to indicate a variable length packet that can be decoded to switch subsequent TDO outputs to a packet response before switching back to the
<jevinskie[m]> wire protocol. The DMA streamer would take a wishbone addr and length and shift out that many bits. Thoughts?
Emantor has quit [Ping timeout: 252 seconds]
tpb has quit [Ping timeout: 260 seconds]
lambda has quit [Ping timeout: 252 seconds]
TMM_ has quit [Ping timeout: 260 seconds]
Stary has quit [Ping timeout: 260 seconds]
G33KatWork has quit [Ping timeout: 252 seconds]
G33KatWork has joined #litex
tpb has joined #litex
TMM_ has joined #litex
Emantor has joined #litex
Stary has joined #litex
Guest53 has quit [Ping timeout: 256 seconds]
lambda has joined #litex
Guest53 has joined #litex
<mm001> leons: I applied your patch: no more malformed packets, but still data loss and still duplicates and triplicates...
<mm001> How can I make the LiteEthUDPStreamer module to have data width 32, by the way? Do I have to change liteeth/frontend/stream.py on line 96?
<mm001> Sorry if I ask again, but is there any obvious error in my code snippet?: https://pastebin.com/U2DebcdB
<tpb> Title: self.submodules.udp_streamer = udp_streamer = LiteEthUDPStreamer( - Pastebin.com (at pastebin.com)
<mm001> (this code snippet is added to litex-boards/targets/linsn_rv901t.py below the "Leds" section, at line 92..), Leds secion commented out.
<mm001> *section
Ikkepop has quit [Quit: Leaving]
C-Man has joined #litex
geertu has quit [Ping timeout: 260 seconds]
<david-sawatzke[m> <mm001> "How can I make the LiteEthUDPStr..." <- There's no real obvious way, since the Streamer operates on continuus data. With 32 bit width you can have some that only have 24 bits of valid data
<david-sawatzke[m> There's no great way to process that in streaming fashion without potential data loss, I think a new udp2stream module where packets are separated with begin & end signal will probably make more sense (at least for the rx side)
geertu has joined #litex