*** tpb <[email protected]> has joined #litex | 00:00 | |
*** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Quit: Connection reset by peep) | 00:20 | |
*** Degi <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 00:21 | |
*** Degi_ <[email protected]> has joined #litex | 00:21 | |
*** Degi_ is now known as Degi | 00:21 | |
*** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #litex | 00:27 | |
*** awordnot <awordnot!~awordnot@user/awordnot> has quit IRC (Ping timeout: 245 seconds) | 01:32 | |
*** awordnot <awordnot!~awordnot@user/awordnot> has joined #litex | 01:33 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has quit IRC (Remote host closed the connection) | 01:53 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has joined #litex | 01:53 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has quit IRC (Ping timeout: 240 seconds) | 01:57 | |
*** esden <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 02:10 | |
*** esden <[email protected]> has joined #litex | 02:13 | |
*** msh_ <[email protected]> has quit IRC (Read error: Connection reset by peer) | 02:43 | |
*** msh <[email protected]> has joined #litex | 02:47 | |
*** alainlou42 <[email protected]> has joined #litex | 03:05 | |
*** alainlou42 <[email protected]> has quit IRC (Client Quit) | 03:05 | |
*** str1 <[email protected]> has quit IRC (*.net *.split) | 04:41 | |
*** hexagon5un <hexagon5un!~elliot@hackaday/elliot> has quit IRC (*.net *.split) | 04:41 | |
*** _whitelogger <[email protected]> has quit IRC (*.net *.split) | 04:41 | |
*** str1 <[email protected]> has joined #litex | 04:41 | |
*** _whitelogger <[email protected]> has joined #litex | 04:41 | |
*** hexagon5un <hexagon5un!~elliot@hackaday/elliot> has joined #litex | 04:42 | |
*** vup <[email protected]> has quit IRC (*.net *.split) | 04:45 | |
*** joseng <[email protected]> has quit IRC (*.net *.split) | 04:45 | |
*** lkcl <[email protected]> has quit IRC (*.net *.split) | 04:45 | |
*** mithro <[email protected]> has quit IRC (*.net *.split) | 04:45 | |
*** Wolf0 <Wolf0!~Wolf0@user/wolf0> has quit IRC (*.net *.split) | 04:45 | |
*** simeonm <[email protected]> has quit IRC (*.net *.split) | 04:45 | |
*** mithro <[email protected]> has joined #litex | 04:45 | |
*** vup <[email protected]> has joined #litex | 04:47 | |
*** lkcl <[email protected]> has joined #litex | 04:47 | |
*** Wolf0 <Wolf0!~Wolf0@user/wolf0> has joined #litex | 04:50 | |
*** simeonm <[email protected]> has joined #litex | 04:54 | |
*** joseng <[email protected]> has joined #litex | 04:56 | |
*** FabM <FabM!~FabM@2a03:d604:103:600:b2b5:25fd:cbea:403a> has joined #litex | 05:06 | |
*** C-Man <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 05:56 | |
*** alainlou <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 06:00 | |
*** pavelow <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 06:06 | |
*** pavelow <[email protected]> has joined #litex | 06:07 | |
*** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 240 seconds) | 06:11 | |
*** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has joined #litex | 06:11 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has joined #litex | 06:11 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has quit IRC (Ping timeout: 252 seconds) | 06:16 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has joined #litex | 06:31 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has quit IRC (Remote host closed the connection) | 06:42 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has joined #litex | 06:42 | |
*** pftbest_ <[email protected]> has joined #litex | 06:43 | |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has quit IRC (Ping timeout: 252 seconds) | 06:47 | |
*** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Quit: Connection reset by peep) | 07:24 | |
*** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #litex | 07:31 | |
*** C-Man <[email protected]> has joined #litex | 09:02 | |
*** C-Man <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 09:07 | |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 09:23 | |
*** TMM_ <[email protected]> has joined #litex | 09:23 | |
david-sawatzke[m | florent: When liteeth is ported to a wider bitwidth, I think the best course of action would be to keep everything in LE and only convert to BE in sram.py. | 11:00 |
---|---|---|
david-sawatzke[m | Does that sound reasonable? | 11:00 |
leons | Yeah, I’d also like to vouch for having everything LE and only converting in the wishbone interface, not even SRAM. That reduces a lot of the complexity and allows us to just use a reusable component for the Wishbone endianness conversion | 11:28 |
_florent_ | david-sawatzke[m, leons: this seems fine yes | 12:55 |
_florent_ | (BTW sorry I haven't been able to review your PRs yet, I'll do that soon) | 12:55 |
*** alainlou <[email protected]> has joined #litex | 13:10 | |
alainlou | hey everyone, I'm trying to get the bare_metal_demo app to run on my board, but boot_helper doesn't jump to the right place it seems. I'm debugging with led_write's before the call to boot helper and on the first line of main in the application | 13:48 |
alainlou | things I know work: boot menu functionality, sdram_test | 13:49 |
alainlou | I'm running with vexriscv minimal, there seem to be no CRC errors when loading the code over UART | 13:50 |
alainlou | things I've tried: `rm -rf build`, rm -rf all my litex stuff and running litex_setup.py all over again, `li x13, 0x40000000` before the `jr x13` in boot_helper | 13:52 |
alainlou | no matter what I try, the debugging led_write happens before boot_helper but not on the first line of main :( | 13:53 |
alainlou | any tips/other ways I could look at this? | 13:53 |
alainlou | would be highly appreciated! | 13:54 |
*** michalsieron <[email protected]> has joined #litex | 15:01 | |
*** michalsieron <[email protected]> has quit IRC (Quit: michalsieron) | 16:00 | |
_florent_ | alainlou: can you try in simulation? | 16:38 |
_florent_ | go to https://github.com/enjoy-digital/litex/tree/master/litex/soc/software/demo | 16:38 |
_florent_ | litex_sim | 16:38 |
_florent_ | python3 demo.py --build-path=build/sim | 16:38 |
_florent_ | litex_sim --ram-init=demo.bin | 16:38 |
_florent_ | and then try to use VexRiscv minimal variant | 16:38 |
_florent_ | Have you tried with standard VexRiscv on hardware? | 16:40 |
*** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 16:48 | |
kbeckmann | Is there an easy way to add a second BRAM-backed RW memory that can be used as application storage? I want to keep the SDRAM that I am using isolated from the application code, but still be able to use lxterm to upload and boot a custom application. | 17:00 |
_florent_ | kbeckmann: yes, you can do it like this: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/xilinx_alveo_u250.py#L87-L88 | 17:06 |
kbeckmann | thanks! | 17:06 |
kbeckmann | wow that is so simple. | 17:07 |
_florent_ | then just update your linker and litex_term command to use this base address | 17:07 |
kbeckmann | cool | 17:07 |
alainlou | hey _florent_ thanks for the tip! I'm trying to get lxsim to work but unfortunately have some issues running `lxsim` (https://pastebin.com/wsqWRCVV) and what I suspect is the problem command (https://pastebin.com/cggcDgj6) | 17:07 |
alainlou | and also unforunately standard doesn't fit on my board :( | 17:08 |
_florent_ | alainlou: sorry I'm leaving the office so won't be able to look at the lxsim issue now | 17:11 |
_florent_ | but I just tested in simulation on my machine with VexRiscv minimal and it's working fine | 17:11 |
_florent_ | so it can be an issue when loading over lxterm or an sdram issue | 17:11 |
_florent_ | which board are you using? | 17:11 |
alainlou | rz_easyfpga, not something currently supported :D | 17:12 |
alainlou | no worries! totally not urgent | 17:13 |
alainlou | what should I look for for lxterm or sdram issue? I don't see any CRC errors when loading the application code and `sdram_test` on BIOS says it's fine .... | 17:14 |
*** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has joined #litex | 18:04 | |
*** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has quit IRC (Ping timeout: 250 seconds) | 19:16 | |
*** pftbest_ <[email protected]> has quit IRC (Ping timeout: 244 seconds) | 19:29 | |
*** pftbest <[email protected]> has joined #litex | 19:31 | |
*** pftbest <[email protected]> has quit IRC (Ping timeout: 244 seconds) | 19:37 | |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 19:38 | |
*** TMM_ <[email protected]> has joined #litex | 19:38 | |
*** pftbest <[email protected]> has joined #litex | 19:41 | |
*** alainlou <[email protected]> has quit IRC (Quit: Client closed) | 20:08 | |
*** pftbest_ <[email protected]> has joined #litex | 20:18 | |
*** pftbest <[email protected]> has quit IRC (Read error: Connection reset by peer) | 20:18 | |
*** pftbest <[email protected]> has joined #litex | 20:43 | |
*** pftbest_ <[email protected]> has quit IRC (Read error: Connection reset by peer) | 20:43 | |
kbeckmann | Are there any examples that I can look at that uses multiple wishbone buses for SDRAM? I want to, at one specific time, access the SDRAM from the CPU, and then at a later time exclusively access the SDRAM from my gateware. However, when using a shared wishbone bus, I see that the request time sometimes becomes longer, probably because the CPU is performing bus accesses. | 20:55 |
_florent_ | kbeckmann: you can add a SDRAM port with self.sdram.get_port(...) | 21:03 |
_florent_ | you can find some examples here: https://github.com/enjoy-digital/litedram/blob/master/litedram/gen.py#L586-L718 | 21:04 |
kbeckmann | thank you so much, this is exactly what i need. | 21:04 |
_florent_ | or grep get_port in the code (ex in soc/cores/video) | 21:05 |
kbeckmann | ah yeah that seems like a good place to look at too. | 21:05 |
*** C-Man <[email protected]> has joined #litex | 21:19 | |
kbeckmann | so close.. most of the time the access is fast enough, but sometimes i miss the narrow latency window that i have. i think my sdram parameters are simply too slow for my application. | 21:28 |
kbeckmann | would i save clock cycles if i perform direct commands and skip the wishbone conversion? | 21:30 |
_florent_ | It will reduce latency yes. With a direct port you'll also avoid waiting for all the others SoC bus accesses that are not targeting the SDRAM | 21:36 |
kbeckmann | ok, great :). i am making sure that nothing else touches the SDRAM while i run the latency critical stuff, so that should be okay. | 21:40 |
*** alainlou <[email protected]> has joined #litex | 21:48 | |
jevinskie[m] | Speaking of latency, would disabling banks help or does the controller keep constant latency as N banks grows? I only need 32 mb or 1 bank of the 256 mb dram. | 21:59 |
jevinskie[m] | kbeckmann: you could try “overclocking” by reducing the CL cycle number. I was able to run the arty ram at CL8 which avoids another cycle latency of latency in the DFI PHY vs CL9 with a frequency ratio of 1:4 (but I guess the DFI isn’t applicable to SDRAM?) | 22:01 |
kbeckmann | thanks, i tried something like that and it helps but sometimes i get these longer stalls that i don't really understand | 22:02 |
kbeckmann | notice how the cyc/stb signals at the cursor are longer than the others https://allg.one/d2e7 | 22:02 |
kbeckmann | this is with a separate wishbone port to the sdram, so there shouldn't be any stalls caused by the CPU. | 22:05 |
jevinskie[m] | Refresher doing its thing, perhaps? | 23:47 |
jevinskie[m] | I still need to try this Refresher patch out that gives pending commands a chance before refresh begins https://github.com/jfng/litedram/commit/40d822df63d491289535c584646121fba40e8c04 | 23:50 |
kbeckmann | yeah that could be it. | 23:50 |
jevinskie[m] | Are you working on this right now? https://github.com/kbeckmann/ECPKart64 | 23:51 |
kbeckmann | yep | 23:51 |
kbeckmann | it's *very* much wip | 23:51 |
jevinskie[m] | I have similar tight dram latency constraints for SPI flash emulation at 50 MHz. I think I can do it with a 32 bit bus at 200/800 MHz but it will be with just a handful of sysclk to use vs the base DFI signal latencies | 23:53 |
kbeckmann | i had some issues writing data to the sdram using uartbone (got random skip zones with 0xffffffff), will try to isolate and report an issue for that unless i am doing something wrong. settled for a hacky uart loader instead for the time being. | 23:53 |
kbeckmann | i see | 23:53 |
*** pftbest <[email protected]> has quit IRC (Remote host closed the connection) | 23:54 | |
jevinskie[m] | Cool project btw!! I always wanted to do for gamegear with sram or something :) | 23:54 |
*** pftbest <pftbest!~pftbest@2a01:4f8:c17:6afc::1:2> has joined #litex | 23:54 | |
kbeckmann | thanks :). ah yeah, with dedicated SRAM things are easier for sure. unfortunately i need a couple of MB. | 23:55 |
kbeckmann | managed to boot from BRAM so i know that the bus logic works | 23:55 |
kbeckmann | there is a way to increase the read latency in the rom, will experiment with that and see if i can get it to boot at all with sdram. but now, i have to sleep :). thanks for all the help, it's really appreciated. | 23:56 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!