tpb has joined #litex
futarisIRCcloud has joined #litex
<bonzibuddy> hey gurus - im pluggin along, trying to get more utilities in my rootfs, but every time i customize the config the system hangs on 'waiting on /dev/ram0...'
<bonzibuddy> my hypothesis is that im trying to upload an image too big for the mem area? still need to confirm that. hoping someone's worked around this one before
<bonzibuddy> customize the buildroot config & upload via lxterm***
<futarisIRCcloud> bonzibuddy: What's the size of your ramdisk in .config and the image size?
freemint has quit [Ping timeout: 276 seconds]
_whitelogger has joined #litex
Guest124578 has joined #litex
freemint has joined #litex
Guest124578 has quit [Remote host closed the connection]
Guest124578 has joined #litex
<Guest124578> Hi,
Guest124578 has quit [Remote host closed the connection]
pc_inside has joined #litex
pc_inside has quit [Remote host closed the connection]
hello_pico has joined #litex
<hello_pico> Maybe a silly question : is it possible to make a Vivado project manually which would be similar to what LiteX scripts do ? (I was expecting for a simpier code when looking at the Verilog generated by LiteX)
hello_pico has quit [Remote host closed the connection]
CarlFK has quit [Quit: Leaving.]
<somlo> _florent_, daveshah: the litedram native port width on the trellisboard is indeed 256, so I'm inclined to bump the hard-coded mem_axi width on Rocket to 256, and downconvert for boards with narrower litedram ports (e.g., ecp5versa at 128, nexys4ddr at 64) but use full unimpeded width where available
<bonzibuddy> futarisIRCcloud: i'll check that this evening, that's likely the issue
<somlo> daveshah: trying to build litex+rocket for the trellisboard, and I usually get to 60MHz easily (no need for -nowidelut, plenty of room), but consistently fail to meet the 125MHz for '$glbnet$eth_clocks_rx' (getting in the neighborhood of 115MHz, typically)
<daveshah> Interesting
<daveshah> Possibly the larger chip makes placement worse
<daveshah> or just different Ethernet pin placement or something
<daveshah> I haven't noticed this with VexRiscv when I've tried previously though
<somlo> I am now trying with a lower (55MHz) cpu clock, to see if that has some second-order effect on the ethernet timing
<somlo> but I'm just basically throwing rocks at it :)
<somlo> if that doesn't immediately make a difference, I'm just going to let it loop
<somlo> not sure if it's worth trying with the "unmet" ethernet fmax, using --timing-allow-fail
<daveshah> Yes, definitely
<daveshah> Another thought is to remove abc9. I think I've seen it reduce Ethernet Fmax in the pat
<daveshah> *past
<somlo> ok, forgot about abc9, thanks for that.
<daveshah> Hmm, looking into this myself and I got 124.63MHz on a first try
<somlo> yeah, it's all probabilistic... asked for 58MHz, got 62.60 for main, 128.55 for eth... Wish I'd just asked for 60 like earlier :)
<somlo> I want to get to the good bits, where I use an unhindered point-to-point 256bit axi channel between litedram and the rocket chip :)
<somlo> find out what that does for my benchmark measurements...
<somlo> daveshah: any plans to add a trellisboard.cfg to /usr/share/trellis/misc/openocd (in prjtrellis) ?
<somlo> hmmm... memory initialization failed (
<tpb> Title: Imgur: The magic of the Internet (at
<daveshah> Done, I wasn't expecting anyone else to build one...
<daveshah> Ah, that's not so good
<daveshah> The board I have seemed fine, maybe try another board?
<somlo> so you think this is a hardware error, then
<daveshah> Probably, could be the litedram change of course
<daveshah> I'm also not sure if I've ever tested the trellisboard at frequencies other than 75MHz
<somlo> oh, so when it worked for you it was vexriscv, not rocket?
<daveshah> Yeah
<somlo> I should try that before I toss this one in the bin as "bad" :)
<daveshah> Can you give me the bitstream? I can test it here
<daveshah> Definitely don't bin it whatever - the FPGA is alright which is what really matters
<somlo> stand by...
<somlo> daveshah:
<somlo> http, that is...
<daveshah> Works fine on the board you sent me
<tpb> Title: Snippet | IRCCloud (at
<somlo> well, that makes me happy and sad, at the same time :D
<somlo> thanks for checking!
<daveshah> Hang on, hitting reset a couple of times I hit a failure like yours too
<daveshah> Maybe something is just a bit marginal
<somlo> maybe the clock is too low...
<somlo> let me kick it a few times on this end, see what happens
Dolu has quit [Ping timeout: 265 seconds]
<somlo> well, this one fails pretty consistently. Do you have a vexriscv bitstream I could just shove at it?
<daveshah> This one is pretty old but has always been reliable
<daveshah> FWIW, there seems to be some hardware variation too. On the other board you sent me, and a board from my own batch; the bitstream you sent seems to work 100% of the time
<somlo> ha
<somlo> "memtest ok" \o/
<daveshah> note there are two ways to try a reset - reloading the svf or pressing SW2, might be a difference between the two
<daveshah> Interesting
<daveshah> Possibly something a bit marginal in the controller then
<somlo> gets wobbly when the main clock gets too low
<daveshah> Tweaking the +1 and +2 to either +0 and +1 or +2 and +3 might increase reliability
<tpb> Title: litedram/ at master · enjoy-digital/litedram · GitHub (at
<daveshah> Or, just trying a different board...
<somlo> I'm not physically close to my stash of alternative boards, so I'll try the hacks first, see what shakes loose...
<somlo> daveshah: just for a sanity check: my reset switch is the leftmost of the group of four; if I hit the "standalone" one on the left of the board, I have to reload the svf
<daveshah> Yes, that's right
<somlo> can't read the labels on the pcb, my glasses are "tuned" for 20-inch focal distance, i.e. my computer monitor :D
<somlo> it *never* fails at 75MHz with the vexriscv bitstream
<daveshah> Yeah, I've never had issues with that bitstream or any other 75MHz bitstream on any board
<daveshah> OTOH, the same PHY works fine at 55MHz or 60MHz on a Versa
<somlo> yeah, rocket seems happy on a versa anywhere north of 55MHz
<daveshah> But, different PCB layouts, double chips might mean longer routing and less margin, ...
<daveshah> Let me just try a new 75MHz vex bitstream to make sure it isn't a regression
<somlo> ok, in the mean time I'll try getting a proper 60MHz rocket bitstream, maybe more if I turn off abc9...
<daveshah> New 75MHz bitstream seems fine too
<somlo> seems to pass memtest for me as well (there's a weird delay before I get the "ok" prompt, and "no boot medium found", but it *is* "memtest ok" nonetheless, each time I kick it...
<daveshah> That's because picorv32 is slow :)?
<daveshah> I was alarmed by it too at first
<somlo> ok, so I'll try to figure out how far I can tweak fmax and the litedram cl_sys_latency offsets
<daveshah> 65MHz seems alright here too, but that might be a bit ambitious for Rocket
<daveshah> seems to be 60MHz where it fails
<daveshah> As it seems to either work or not (either a lot of failures or none at all, never just one or two failures), it might be a problem with the startup FSM
<daveshah> is another magic number (probably to increase)
<tpb> Title: litedram/ at master · enjoy-digital/litedram · GitHub (at
<somlo> of course, if any of that tweaking actually turns out to help in a reliable way, we'd have to regression test on the versa, to make sure the modifications aren't mutualy exclusive between the two boards...
<daveshah> Yes, this is very true
<daveshah> Can you try this bitstream on your board (58MHz, with t=12)?
<tpb> Title: Imgur: The magic of the Internet (at
<daveshah> Hmm, no idea then
<somlo> was this with a modified 't' (guessing s/8/12/) in line #56 ?
<somlo> I'll eventually work my way up to trying the offsets on line #442, but I'm hoping I can push fmax a few MHz above 60, into "maybe works most of the time" territory :)
<daveshah> Yup
<daveshah> You could try an even higher 't' perhaps, it definitely improved reliability for me
Dolu has joined #litex
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<somlo> daveshah: used --timing-allow-fail, requested 65MHz, officially got 57, passed the ethernet clock timing
<somlo> running it at 65MHz now, booted linux just fine
<daveshah> Nice
<somlo> not sure whether *not* using abc9 helped, I'd have to test that a bit more thoroughly (right now I've been haphazardly trying whatever sticks)
futarisIRCcloud has joined #litex
<somlo> if that turns out to matter, I'll make it an optional build flag rather than a hardcoded thing
Dolu has quit [Ping timeout: 268 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined #litex
Dolu has joined #litex
Dolu has quit [Ping timeout: 240 seconds]
freemint has quit [Ping timeout: 264 seconds]
tpb has quit [Remote host closed the connection]