tpb has joined #litex
nrossi has joined #litex
m4ssi has joined #litex
<tpb> Title: litex-hyperram/ at master · gregdavill/litex-hyperram · GitHub (at
<keesj> Provides a standard HyperRAM core that works at 1:1 system clock speeds
_whitelogger has joined #litex
rohitksingh has quit [Ping timeout: 265 seconds]
rohitksingh has joined #litex
m4ssi has quit [Remote host closed the connection]
<somlo> _florent_: should probably get the same treatment versa_ecp5 got in commit d91458c (litex-boards)
<tpb> Title: litex-boards/ at master · litex-hub/litex-boards · GitHub (at
<_florent_> somlo: indeed, thanks. I'll do that
<somlo> _florent_: I think that was my mistake originally (sorry about that), so thank you for cleaning up after me :)
<_florent_> somlo: no problem, that's difficult to think about all cases when adding features
<_florent_> somlo: i just did a quick fix but will try to improve it
<somlo> I'm still somewhat amazed that I never had to install and use Diamond (so I have a bit of a blind spot when it comes to that)...
<somlo> _florent_: on an unrelated topic, I'm trying to write a universal "LiteX CSR bus" driver for Linux -- something that knows how to write 8, 16, 32, 64, and 128 bit registers from CPU to hardware preserving the right bit order from MSB to LSB, regardless of cpu endianness, 32 or 64bit alignment, and chunk-size(csr-data-width)
<somlo> for that, I want to test and double-check my assumptions using the simulator -- is there something there already where I can set up a dummy CSR that simply prints out the value it contains from the perspective of the "hardware" ?
<somlo> so I can actually test if what I'm writing ends up what the hardware thinks it is receiving, and again when I'm reading a register back into the CPU?
<somlo> I'll dig around and figure something out, but if there's a one-liner you can point me at for inspiration, that'd make the process MUCH faster :)
<_florent_> somlo: sure, you can just use Display with Verilator that is very useful since very similar to a hardware printf
<tpb> Title: usb3_pipe/ at master · enjoy-digital/usb3_pipe · GitHub (at
<somlo> ooh, thanks! (I think you showed this to me once before when I was trying to debug Rocket, back a while ago -- sorry for being thick and not remembering it :)
<somlo> I think I'll just create a bunch of ctrl_scratch like registers of various widths, and tinker with them from the bios prompt with mr and mw :)
<_florent_> the ctrl scratch register was there for this purpose (be sure for that the software was able to access the CSR correctly), if you think this is not enough we could change/improve it
<somlo> I don't expect anything worth upstreaming into LiteX, just me trying to confirm to myself that I understand how things are scattered/gathered across the register "slices", depending on data-width... I'm usually wrong when I try to guess without testing :)
rohitksingh has quit [Ping timeout: 250 seconds]
kc8apf has joined #litex
<kc8apf> _florent_: I see you added a method to add timing constraints for S7PCIEPHY
<kc8apf> That resolves the no_clocks issues. Need to see what my timing report looks like now
<_florent_> kc8apf: yes i was apply these timing constraints in the others designs but it was missing in the example design
nrossi has quit [Quit: Connection closed for inactivity]
<somlo> Any suggestions to what'd be the more "mature" Big-Endian CPU option to test with (mor1kx vs. lm32)?
<mithro> somlo: ppcbe?
<mithro> somlo: Or do you mean in LiteX?
rohitksingh has joined #litex
tpb has quit [Remote host closed the connection]