| *** tpb <[email protected]> has joined #litex | 00:00 | |
| jevinskie[m] | $100 XC7K325T from qmtech 👀 | 00:25 |
|---|---|---|
| jevinskie[m] | https://a.aliexpress.com/_mt8W9MW | 00:25 |
| tpb | Title: QMTECH Xilinx FPGA Kintex7 Kintex 7 XC7K325T DDR3 Core Board| | - AliExpress (at a.aliexpress.com) | 00:25 |
| *** Las[m] <Las[m]!~lasmatrix@2001:470:69fc:105::74e> has joined #litex | 00:25 | |
| sajattack[m] | enticing, but I think those don't support the free version of vivado, do they? | 00:58 |
| jevinskie[m] | Unfortunately not | 01:47 |
| Wolf0 | sajattack[m]: Do you need a license? | 02:02 |
| *** Degi_ <[email protected]> has joined #litex | 03:16 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 03:17 | |
| *** Degi_ is now known as Degi | 03:17 | |
| *** mc6808 <[email protected]> has joined #litex | 03:38 | |
| *** mc6808 <[email protected]> has quit IRC (Quit: Client closed) | 03:45 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 04:14 | |
| *** TMM_ <[email protected]> has joined #litex | 04:14 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:5120:3edd:7c22:3adb> has quit IRC (Quit: Leaving.) | 06:11 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:acbd:1bde:60b2:4890> has joined #litex | 06:13 | |
| 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 | 09:32 |
| Melkhior | is that a known issue ? | 09:32 |
| _florent_ | Melkhior: I tested it recently on Arty, it was still working, do you have a specific configuration; | 09:48 |
| _florent_ | ? | 09:48 |
| Melkhior | it's a basic qmtech wukong configuration, no l2, single core, no changes except for #1053 | 09:51 |
| Melkhior | no ethernet, not sdcard configured | 09:52 |
| Melkhior | only serial, framebuffer and icap_bistream | 09:52 |
| Melkhior | ... and minor changes in platform/targets for my hand-built RGB222 VGA Pmod (VGA output with only 8 signals) | 09:54 |
| Melkhior | I didn't clean / rebuild the buildroot and opensbi though from the previous version | 09:55 |
| Melkhior | will try that | 09:55 |
| *** Coldberg <[email protected]> has quit IRC (Remote host closed the connection) | 09:56 | |
| *** Coldberg <[email protected]> has joined #litex | 09:56 | |
| Melkhior | (the qmtech has hdmi, i'm testing the pmod) | 09:57 |
| Melkhior | well, false alarm ; cleaned up everything and started again, this time boot had no issue | 10:25 |
| Melkhior | _florent_: all good :-) | 10:25 |
| 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 | 10:26 |
| Wolf0 | Melkhior: ANY SDRAM? I'm getting 550GB/s sequential on HBM2 :3 | 10:26 |
| Melkhior | hehe :-) | 10:27 |
| Wolf0 | Sorry, had to. :3 | 10:27 |
| Melkhior | I don't dare used my VCU128 for non-work stuff :-) | 10:27 |
| Wolf0 | Melkhior: please, please do. I need more people doing interesting stuff with the HBM parts to chat with :P | 10:27 |
| 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/ | 10:28 |
| 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) | 10:28 |
| Wolf0 | Sounds like you need a bigger bus. | 10:28 |
| Melkhior | I'm limited by the HW :-) | 10:28 |
| Melkhior | the memory is 16 bits | 10:29 |
| Melkhior | the Wishbone is 32 bits | 10:29 |
| Wolf0 | ahhh, got it | 10:29 |
| Melkhior | So I'm wondering how to improve BW usage between the FB and the SDRAM ... with my limited HW | 10:29 |
| Wolf0 | FB? | 10:30 |
| 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 ... | 10:30 |
| Melkhior | FB == FrameBuffer | 10:30 |
| Wolf0 | ahh... well, mean, my first instinct is raising clock speed, if you require more bandwidth | 10:31 |
| Wolf0 | My second instinct is changing timings - particularly refresh rate tends to be nice | 10:31 |
| Wolf0 | But changing refresh rate tends to work best when you're maxing out your RAM usage | 10:33 |
| Melkhior | timjngs are probably OK - raw bandwidth has room to spare | 10:46 |
| 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) | 10:47 |
| 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 | 10:47 |
| *** geertu <[email protected]> has quit IRC (Ping timeout: 240 seconds) | 11:03 | |
| *** geertu <[email protected]> has joined #litex | 11:03 | |
| Melkhior | Seems to me the LiteDRAMCrossbar is running in sysclk, and will limit the usable bandwidth going through it - _florent_: is that correct? | 11:32 |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Read error: Connection reset by peer) | 11:48 | |
| *** somlo <[email protected]> has quit IRC (Remote host closed the connection) | 12:51 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:cc44:d504:102:aa84> has joined #litex | 12:53 | |
| *** somlo <[email protected]> has joined #litex | 13:12 | |
| _florent_ | Melkhior: LiteDRAMCrossbar is running in sys_clk yes, but with the native controller's data_width (ex 128-bit on 16-bit DDR3) | 14:11 |
| Melkhior | _florent_: so for 128-bit (or multiple thereof) access it's fast, but for lower we get correspondingly lower bandwidth ? | 14:23 |
| Melkhior | so the framebuffer should try to access many pixels at once ? | 14:23 |
| Melkhior | (with e.g. a 128 bits native interface) | 14:24 |
| Melkhior | clarification: 's/but for lower/but for narrower [than 128 bits]/' | 14:26 |
| _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 | 14:28 |
| Melkhior | mmm, ok, I though that would be the native width of the memory (16 bits), I should have print()ed it | 14:29 |
| Melkhior | so it _does_ read multiple pixels at once already? | 14:30 |
| Melkhior | I have issue with higher-resolution display (1024x768 and more) even if timing closes fine, I though it might be lack of bandwidth... | 14:31 |
| _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 | 14:38 |
| _florent_ | you can also add LiteScope to probe video_pipe_source.valid | 14:39 |
| _florent_ | it should always be at 1 when the video is enable. If you see it at 0, there are indeed bandwidth issues | 14:40 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 14:40 | |
| Melkhior | ok | 14:40 |
| Melkhior | thanks | 14:41 |
| *** TMM_ <[email protected]> has joined #litex | 14:41 | |
| Melkhior | I need to investigate further then | 14:41 |
| Melkhior | (ultimate goal is to go from 16-bits to 8-bits and emulate an old IndexedColor framebuffer) | 14:41 |
| Melkhior | 16 bits is in #1053 | 14:42 |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #litex | 15:18 | |
| Melkhior | _florent_: 1024x768@60Hz/16bpp (90MB/s required, I think) -> underflow comes up pretty strongly (just connected it to a LED) | 15:33 |
| Melkhior | at least with the default FIFO depth of 65536B (4096 entries of 16B/128b) | 15:33 |
| Melkhior | trying with a bigger FIFO (4x) | 15:33 |
| Melkhior | which I really don't understand unless I messed up 16bpp badly, as 800x600@60Hz/32bpp did work and has higher BW requirements! | 15:35 |
| Melkhior | I'm confused :-) | 15:36 |
| _florent_ | Melkhior: what's your sys_clk? | 15:36 |
| Melkhior | 100 MHz | 15:37 |
| _florent_ | and your pix_clk? 65e6? | 15:40 |
| Melkhior | yes, std 1024x768@60 | 15:40 |
| _florent_ | can you share your modification to do 16bpp with the video code? | 15:41 |
| Melkhior | with its own S7MMCM | 15:41 |
| _florent_ | video core | 15:41 |
| Melkhior | #1053 :-) | 15:41 |
| Melkhior | PR on github | 15:41 |
| Melkhior | (trying again with 32bpp just in case) | 15:41 |
| _florent_ | ah sorry :) | 15:42 |
| Melkhior | no problem :-) | 15:42 |
| 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...) | 15:46 |
| Melkhior | I _think_ the led is a bit brighter with 32bpp, but it's hard to tell | 15:49 |
| Melkhior | Also - screen is more distorted, and Linux doesn't seem to finish booting... | 15:50 |
| 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 | 16:24 |
| _florent_ | Melkhior: #1053 looks fine, I also don't understand why 32bpp work and not your 16bpp | 16:44 |
| Melkhior | _florent_: they both work for low-resolution, and I might be an idiot with confirmation bias... I was looking at the wrong led! | 16:46 |
| _florent_ | ahah | 16:46 |
| Melkhior | so to recap: 800x600 works fine in 16bpp and 32bpp ; 1024x768 has severe issue in 32bpp, much less severe in 16bpp | 16:46 |
| Melkhior | (as in, Linux doesn't boot in 32bpp but does in 16bpp | 16:47 |
| Melkhior | however, I still have no idea *why* it behaves that way (I _did_ think of checking timings, never had any issue) | 16:47 |
| Melkhior | the screen gets a bit distorted in 1024x768/16bpp, slightly more severe in 1024x768/32bpp | 16:48 |
| Melkhior | and I still need to check underflow by looking at the proper led (I've connected it to ALL user_leds now :-) ) | 16:50 |
| _florent_ | Melkhior: BTW, this can be interesting: https://github.com/litex-hub/litex-boards/issues/239 | 16:52 |
| _florent_ | modifications to the Video core to do 1280x720@16bpp from a SDRAM | 16:53 |
| 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 | 17:08 |
| _florent_ | ah yes, probably specific to this case | 17:09 |
| _florent_ | but the Converter should not add logic when doing a 1:1 conversion | 17:09 |
| *** ilia__s9 <[email protected]> has joined #litex | 17:09 | |
| 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 ?!? | 17:10 |
| Melkhior | Anyway - the leds seem to be off in the 1024x768 case, so it might not be a bandwidth issue | 17:10 |
| *** indy_ <[email protected]> has joined #litex | 17:11 | |
| *** Xesxen_ <Xesxen_!~cyber@hackalot/deelnemer/xesxen> has joined #litex | 17:12 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:cc44:d504:102:aa84> has quit IRC (*.net *.split) | 17:17 | |
| *** Coldberg <[email protected]> has quit IRC (*.net *.split) | 17:17 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (*.net *.split) | 17:17 | |
| *** Xesxen <Xesxen!~cyber@hackalot/deelnemer/xesxen> has quit IRC (*.net *.split) | 17:17 | |
| *** ilia__s <[email protected]> has quit IRC (*.net *.split) | 17:17 | |
| *** indy <[email protected]> has quit IRC (*.net *.split) | 17:17 | |
| *** ilia__s9 is now known as ilia__s | 17:17 | |
| _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. | 17:23 |
| Melkhior | just one cpu in this test | 17:23 |
| Melkhior | completely standard, no fancy extension :-) | 17:23 |
| *** ilia__s5 <[email protected]> has joined #litex | 17:23 | |
| _florent_ | OK | 17:23 |
| *** Ikkepop <[email protected]> has joined #litex | 17:23 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:cc44:d504:102:aa84> has joined #litex | 17:23 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has joined #litex | 17:23 | |
| *** ilia__s <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 17:23 | |
| *** ilia__s5 is now known as ilia__s | 17:23 | |
| 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...) | 17:26 |
| Melkhior | let's try 1920x1080 and see what happens :-) | 17:26 |
| Melkhior | 1920x1080@60Hz/16bpp: FPGA timings are fine, screen says 'out of range', kernel hangs when seeing the frambuffer, overflow leds are still off... | 17:33 |
| Melkhior | I'm definitely out of my depth :-) | 17:33 |
| Melkhior | need to sleep on it | 17:33 |
| Melkhior | thanks for the help! | 17:33 |
| Melkhior | bye | 17:33 |
| *** Xesxen_ <Xesxen_!~cyber@hackalot/deelnemer/xesxen> has quit IRC (Ping timeout: 265 seconds) | 17:42 | |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 17:42 | |
| *** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 265 seconds) | 17:42 | |
| *** tpb_ <[email protected]> has joined #litex | 17:42 | |
| *** tpb <[email protected]> has quit IRC (Killed (NickServ (GHOST command used by tpb_))) | 17:43 | |
| *** Xesxen <Xesxen!~cyber@hackalot/deelnemer/xesxen> has joined #litex | 17:43 | |
| *** shorne_ <[email protected]> has joined #litex | 17:43 | |
| *** tpb_ is now known as tpb | 17:43 | |
| *** lexano_ <lexano_!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has joined #litex | 17:44 | |
| *** Xesxen_ <Xesxen_!~cyber@hackalot/deelnemer/xesxen> has quit IRC (Ping timeout: 265 seconds) | 17:44 | |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 17:44 | |
| *** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 265 seconds) | 17:44 | |
| *** kbeckmann <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 17:44 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 17:44 | |
| *** Degi <[email protected]> has joined #litex | 17:45 | |
| *** kbeckmann <[email protected]> has joined #litex | 17:53 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 17:55 | |
| *** Las[m] is now known as Las[m]_ | 19:20 | |
| *** Wolf0 <Wolf0!~Wolf0@user/wolf0> has quit IRC (Quit: leaving) | 19:46 | |
| *** Wolf0 <Wolf0!~Wolf0@user/wolf0> has joined #litex | 19:46 | |
| *** tpb <[email protected]> has joined #litex | 20:06 | |
| *** TMM_ <[email protected]> has joined #litex | 20:06 | |
| *** Emantor <[email protected]> has joined #litex | 20:07 | |
| *** Stary <Stary!~Stary@hacksoc/infrastructure> has joined #litex | 20:08 | |
| *** Guest53 <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 20:08 | |
| *** lambda <[email protected]> has joined #litex | 20:18 | |
| *** Guest53 <[email protected]> has joined #litex | 20:46 | |
| mm001 | leons: I applied your patch: no more malformed packets, but still data loss and still duplicates and triplicates... | 22:22 |
| 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? | 22:24 |
| mm001 | Sorry if I ask again, but is there any obvious error in my code snippet?: https://pastebin.com/U2DebcdB | 22:26 |
| tpb | Title: self.submodules.udp_streamer = udp_streamer = LiteEthUDPStreamer( - Pastebin.com (at pastebin.com) | 22:26 |
| mm001 | (this code snippet is added to litex-boards/targets/linsn_rv901t.py below the "Leds" section, at line 92..), Leds secion commented out. | 22:30 |
| mm001 | *section | 22:32 |
| *** Ikkepop <[email protected]> has quit IRC (Quit: Leaving) | 22:41 | |
| *** C-Man <[email protected]> has joined #litex | 22:41 | |
| *** geertu <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 23:05 | |
| 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 | 23:17 |
| 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) | 23:19 |
| *** geertu <[email protected]> has joined #litex | 23:20 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!