04:13 <teknoman117> is there any sort of self calibration logic that can be turned on with litedram so you can do the calibration without an embedded soft core?

04:13 <teknoman117> or run calibration ahead of time and bake in the values?

04:14 <teknoman117> or is that generally considered a bad idea?

04:14 <teknoman117> reason I ask is that I've been working on writing description in LiteX for the various FPGA boards I have hanging around (Mojo V3, Alchitry Au, LiteFury)

04:16 <teknoman117> I've got it up on all of them, but the Mojo V3 is a XC6LX9 (so, second smallest FPGA from the 6-series) and not everything I'd want to do with it needs a soft CPU core.

08:31 <zyp> you could use a serv for it :)

19:35 <somlo> daveshah: tried upgrading my yosys/trellis/nextpnr toolchain; with the latest yosys (2116c58) I get no console output whatsoever after programming my trellisboard (with a litex+rocket bitstream)

19:36 <daveshah> Oh dear

19:36 <somlo> tried downgrading the components selectively, and things work with the latest trellis and nextpnr, and yosys c39ebe6 from way back, provided I don't use "nowidelut"

19:37 <daveshah> Sounds like a nondeterministic failure, tbh

19:37 <daveshah> Can you see if old Yosys with a different seed still passes?

19:37 <somlo> for the record, yosys was built with ABCEXTERNAL, using ABC 448f263 (trying to build the latest abc from github, see if I can shake anything loose that way)

19:38 <somlo> is there a hardcoded seed somewhere in LiteX? I built it multiple times (with the old yosys and new trellis/nextpnr) and it worked each time -- does that count?

19:39 <daveshah> Yes

19:40 <daveshah> When changing the seed, don't rerun litex or Yosys so you are sure you have exactly the same netlist

19:40 <somlo> the command I used to build the bitstream was `litex-boards/litex_boards/targets/trellisboard.py --sys-clk-freq 60e6 --with-ethernet --with-sdcard --cpu-type rocket --cpu-variant linuxq --integrated-rom-size 0x10000 --build`

19:41 <somlo> curious if it works for you

19:41 <somlo> "Yes" meaning "hardcoded seed", or "it counts for answering the diversity question" :) Sorry, lost that thread...

19:41 <daveshah> I'll try and check tomorrow

19:41 <daveshah> Yes the seed is hardcoded

19:41 <somlo> oh

19:42 <daveshah> Is it still passing timing?

19:43 <somlo> hasn't been passing timing in a long while, but kept working... That's another thing I could try, lower the requested frequency to 55 or 50 MHZ (lowest it's ever actually worked with the DRAM)

19:43 <daveshah> nowidelut will make the timing worse

19:44 <daveshah> If it is failing timing by more than 10% or so, then I can't guarantee it will work

19:44 <somlo> which is why it helped with new (trellis, nextpnr) + old yosys, I guess

19:44 <somlo> leaving it out, I mean

19:44 <somlo> but it

19:44 <somlo> is not helping when I upgrade yosys

19:44 <daveshah> Its only one possibility, other bugs are also possible

19:45 <daveshah> Does the timing failure get worse when you update Yosys?

19:45 <somlo> I think timing actually got better (by a very small amount), but I'd have to re-test before I have any confidence in that answer

19:46 <somlo> and leaving out ethernet and/or litesdcard definitely improves timing, so I'll have to try that too, see if console output comes back when timing fails by *less*...

19:47 <somlo> I'll throw some more things at the wall, try collecting some additional data points

19:48 <daveshah> Thanks

19:50 <somlo> weird thing is (I just remembered) -- the lights blink the same way as when the board is programmed with the "good" bitstream (built with the older yosys), so at least some things still work -- which I think supports the timing hypothesis

19:50 <daveshah> the lights are independent from the CPU

19:51 <daveshah> it's almost 100% going to be a complex failure in the CPU or core SoC stuff, timing or otherwise

20:20 <daveshah> tested here and it doesn't work, but it's failing timing catastrophically - only 23.04MHz on the 60MHz domain

20:21 <daveshah> as the logic/routing mix looks typical, I think something must be being very badly synthesised

20:22 <daveshah> something associated with ExampleRocketSystem.subsystem_mbus.coupler_to_memory_controller_port_named_axi4.tl2axi4._T_549_ looks to be the biggest part of the critical path

20:25 <somlo> I'm building now without --with-ethernet and --with-sdcard, that gives me a rather useless litex, but one that has much better timing than when sdcard and ethernet are thrown in

20:29 <daveshah> So it isn't just the timing failure that is the problem, as I've tried tweaking the PLL divider to run at a lower frequency and still no life (I did also change the terminal UART baud accordingly)

20:31 <daveshah> however, maybe the timing failure is a clue towards some other synthesis issue going on

20:40 <somlo> I wish I had time (or a way to trick my employer into ordering me) to get more in depth with yosys... As it is, I have only the vaguest of clues as to what it might be up to, in there :)

20:42 <somlo> daveshah: you're using yosys with the vendored abc, right? I still care about updating the stand-alone fedora package, but curious if it's on the critical path of this particular endeavor...

20:51 <daveshah> Yeah, vendored abc

20:51 <daveshah> can you remember what kind of Fmax the design used to get

20:54 <somlo> I remember getting actual 60MHz on the versa5g about a year and a half ago, with just ethernet (but that was a lot of LiteX changes ago, as well, not just toolchain changes)

20:55 <somlo> I used to see high 40s reported for the trellisboard (with ethernet, with *no* sdcard)

20:55 <somlo> adding the sdcard to the mix dropped fmax significantly, but things kept working fine, as of cca. 4-5 months ago

20:56 <somlo> for a very fuzzy, unscientific recollection :)

20:58 <somlo> but right now, dropping sdcard and ethernet only got me to 21.71 MHz (from the 19-and-change I get *with* both) -- and still no terminal output