<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.
<david-sawatzke[m>
Does that sound reasonable?
<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
<_florent_>
david-sawatzke[m, leons: this seems fine yes
<_florent_>
(BTW sorry I haven't been able to review your PRs yet, I'll do that soon)
alainlou has joined #litex
<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
<alainlou>
things I know work: boot menu functionality, sdram_test
<alainlou>
I'm running with vexriscv minimal, there seem to be no CRC errors when loading the code over UART
<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
<alainlou>
no matter what I try, the debugging led_write happens before boot_helper but not on the first line of main :(
<alainlou>
any tips/other ways I could look at this?
<_florent_>
and then try to use VexRiscv minimal variant
<_florent_>
Have you tried with standard VexRiscv on hardware?
FabM has quit [Quit: Leaving]
<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.
<alainlou>
and also unforunately standard doesn't fit on my board :(
<_florent_>
alainlou: sorry I'm leaving the office so won't be able to look at the lxsim issue now
<_florent_>
but I just tested in simulation on my machine with VexRiscv minimal and it's working fine
<_florent_>
so it can be an issue when loading over lxterm or an sdram issue
<_florent_>
which board are you using?
<alainlou>
rz_easyfpga, not something currently supported :D
<alainlou>
no worries! totally not urgent
<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 ....
pftbest has quit [Read error: Connection reset by peer]
pftbest has joined #litex
pftbest_ has quit [Read error: Connection reset by peer]
<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.
<_florent_>
kbeckmann: you can add a SDRAM port with self.sdram.get_port(...)
<kbeckmann>
thank you so much, this is exactly what i need.
<_florent_>
or grep get_port in the code (ex in soc/cores/video)
<kbeckmann>
ah yeah that seems like a good place to look at too.
C-Man has joined #litex
<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.
<kbeckmann>
would i save clock cycles if i perform direct commands and skip the wishbone conversion?
<_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
<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.
alainlou has joined #litex
<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.
<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?)
<kbeckmann>
thanks, i tried something like that and it helps but sometimes i get these longer stalls that i don't really understand
<kbeckmann>
notice how the cyc/stb signals at the cursor are longer than the others https://allg.one/d2e7
<kbeckmann>
this is with a separate wishbone port to the sdram, so there shouldn't be any stalls caused by the CPU.
<jevinskie[m]>
Refresher doing its thing, perhaps?
<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
<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.
<kbeckmann>
i see
pftbest has quit [Remote host closed the connection]
<jevinskie[m]>
Cool project btw!! I always wanted to do for gamegear with sram or something :)
pftbest has joined #litex
<kbeckmann>
thanks :). ah yeah, with dedicated SRAM things are easier for sure. unfortunately i need a couple of MB.
<kbeckmann>
managed to boot from BRAM so i know that the bus logic works
<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.