CarlFK has quit [Read error: Connection reset by peer]
levi has quit [Ping timeout: 246 seconds]
mithro has quit [Ping timeout: 244 seconds]
guan has quit [Ping timeout: 272 seconds]
jaseg has quit [Ping timeout: 246 seconds]
jaseg has joined #litex
rohitksingh has quit [Ping timeout: 244 seconds]
bubble_buster has quit [Ping timeout: 256 seconds]
rohitksingh has joined #litex
bubble_buster has joined #litex
rohitksingh has quit [Ping timeout: 244 seconds]
bubble_buster has quit [Ping timeout: 244 seconds]
rohitksingh has joined #litex
bubble_buster has joined #litex
guan has joined #litex
mithro has joined #litex
levi has joined #litex
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Ping timeout: 260 seconds]
davidcorrigan714 has joined #litex
_whitelogger has joined #litex
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 240 seconds]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 240 seconds]
CarlFK has joined #litex
kgugala has quit [Quit: -a- Connection Timed Out]
kgugala has joined #litex
tcal has quit [Quit: Connection closed for inactivity]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 256 seconds]
<lkcl>
that's interesting. nextpnr-ecp5 compiling microwatt didn't complete (overnight!) and has locked up solid after 15 hours, with 4,000 / 140,000 routes left.
<daveshah>
the routeability of large ecp5 designs isn't great
<lkcl>
annoying as i need it in order to test DDR3 memtest with 64-bit
<daveshah>
you can try Rocket, it isn't POWER but in the default, non-Linux-ready config, I think it should fit slightly better
<lkcl>
ah that's rocket-chip (written in chisel3). yeah
<lkcl>
arg probably need an updated rv cross compiler... hm there should be debian packages
<lkcl>
ah interesting, upgrading to gcc-9 didn't help
<lkcl>
Warning: Max frequency for clock '$glbnet$sys_clk': 23.36 MHz (FAIL at 55.01 MHz)
<lkcl>
aaa i just want something to work! :)
<lkcl>
the axi4 to tilelink converter creates a morass of critical path dependencies
* lkcl
is trying 50mhz nextpnr-ecp5 builds and that seems to work (picorv32)
<lkcl>
i suspect that the libresoc build, at 55mhz, is just too close to the limit estimated by nextpnr... nope. arse. a 50mhz libresoc build gets the same UART corruption.
<lkcl>
ahh interesting
<lkcl>
_florent_: when i re-added kwargs["integrated_main_ram_size"] = 0x1000 the UART corruption (black square "?" being the predominant char) went away
proteusguy has quit [Ping timeout: 240 seconds]
proteusguy has joined #litex
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 265 seconds]
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Read error: Connection reset by peer]
<somlo>
lkcl: I'm probably late to this party, but I managed to get 30 "official" MHz timing for my 5g-versa board with this command line:
<somlo>
I can't test it right now, but the "advertised" fmax is usually *way* lower than what one can get away with (nextpnr is typically overly conservative w.r.t. timing)
<somlo>
I think I'm going to revert litex commit 6c298cb7 and make abc9 optional via a command line flag
<somlo>
and if you have a non-5g versa board, you'll probably need to make additional tweaks to the litex build environment (but if you've already been building stuff for your versa board, you've likely already figured that part out)
<somlo>
once I free up my (currently busy) usb port, I can actually test the bitstream I built and see if it actually works, and if it manages to pass memtest, but that'll have to wait for a couple of hours :)
<lkcl>
somlo: ah thank you
<lkcl>
ahh interesting. csr data width normally defaults to 8 bit
<lkcl>
i wonder if that has any impact, here.
<somlo>
lkcl: historically, I don't think csr-data-width has had a major impact on timing, placement, or utilization
<lkcl>
ok appreciated
<lkcl>
aw poop, forgot the --device=LFE5UM :)
<somlo>
oh, so you do have a non-5g versa, then :)
<lkcl>
somlo: for lack of being able to purchase a 5g version via mouser 3 months ago... yes
<somlo>
I'm still ripping a multi-cd audiobook to mp3 for my daughter, and the one usb port I could use to hook up my dev board is currently occupied by the cd drive -- so I can't test myself for a while :)
<somlo>
lkcl: I initially ordered a 5g versa, they shipped me a non-5g one, daveshah helped me figure out why it wasn't working the way I thought it should have -- long story short, it took another month or so to sort out the mess :)
<lkcl>
doh
<somlo>
eventually they sent me the right one (this was via the lattice web store from the US)
<lkcl>
Warning: Max frequency for clock '$glbnet$sys_clk': 20.58 MHz (FAIL at 50.00 MHz)
<somlo>
aaah, that
<somlo>
try pushing the bitstream to the board anyway, see what happens
<lkcl>
because of the massive combinatorial chain between tilelink and axi-lite
<lkcl>
nope, fail
<somlo>
I consistently get "fails at 30 (or 40) MHz" on a trellisboard (after requesting 60MHz) and it works fine :)
<lkcl>
i mean: it loads successfully, it just doesn't report anything on the USB console
<lkcl>
:)
<daveshah>
somlo: I remember Rocket giving 50MHz+ once upon a time
<somlo>
right, so then it *really* fails
<daveshah>
did we ever figure out why that changed?
<somlo>
daveshah: not sure if it was rocket, or yosys/trellis/nextpnr, or some interaction between the changes made to each of them
<somlo>
I remember a point in time when bumping the rocket chip git version caused utilization to go up by 6-7 %
<daveshah>
yeah, seems likely
<daveshah>
that was probably almost a year ago that I remember that number from
<somlo>
but I didn't pay as much attention to timing. I think at some point (before that) I had been complaining about no longer meeting timing, and litex switched to "--timing-allow-fail" based on the "looseness" of that calculation in nextpnr...
<somlo>
these days I can get 60MHz working on the trellisboard most of the time, and the "linux" version of rocket will no longer fit on the versa no matter what (105+ % utilization), so I haven't tried with that board in the last several months
<lkcl>
somlo: do you happen to have _anything_ that has a 64 bit bus, that you know (last time you tried it) "works"?
<lkcl>
nextpnr-ecp5 on microwatt took 16 hours to fail to complete routing (locked up with 5% nets left)
<tpb>
Title: A Trustworthy, Free (Libre), Linux Capable, Self-Hosting 64bit RISC-V Computer (at www.contrib.andrew.cmu.edu)
<somlo>
some git versions of things I used back a while ago. sadly, I don't remember which litex commit that was at the time
<lkcl>
cpu-variant "linuxd"? what's that one?
<somlo>
lkcl: there's several versions of rocket with different mem-axi port widths, matching the native width of litedram on various dev boards
<somlo>
so we can hook rocket's memory port directly to litedram, point-to-point, and bypass the wishbone bus used for MMIO
<somlo>
but if we're looking for something we know used to work, I'd check out litex cca. 1 year ago, e.g. commit 4cc40aad
<somlo>
also check out one of the earlier (earliest) versions of pythondata-cpu-rocket to match
<somlo>
lkcl: there's another trick I remember from a while back: using `--nextpnr-timingstrict` with `versa_ecp5.py`, so that it *properly* fails when not meeting timing
<somlo>
then running that in a `for` loop in the shell, until you get lucky and it succeeds :)
<somlo>
but that might take a while (days)
<somlo>
and it's not guaranteed to work
<lkcl>
yyeah
<lkcl>
and i'd have to then try to get libresoc working against that version of litex, to be able to make a fair comparison
<lkcl>
i think... i am tempted to track down a nmigen 64-to-32-bit converter and throw that in front, before the data requests reach litex
<lkcl>
hey i got the LUT4s down from 20,000 to around 16,000 by adding in sync delays into the regfile reads, that gave nextpnr a chance to to "hey i can use BRAMS now"
<lkcl>
yaay
<daveshah>
it's yosys that does that not nextpnr, jfyi
<lkcl>
daveshah: oh, ta :)
<daveshah>
and yeah, that will definitely help :)
<lkcl>
i'm very happy. it was... a small but hair-raising change
<daveshah>
this is the kind of interesting difference between what is efficient on ASIC vs FPGA
<lkcl>
i'm doing an out-of-order design, which (for now) has a FSM, however all the infrastructure is there to add the dependency matrices in
<lkcl>
which means that there are *combinatorial* "Pipeline Managers" that expect operands to come in with a "operand is ok" plus "actual operand" in the *same* cycle
<lkcl>
not, as things are done in regfiles, on the *next* cycle (after the read-enable)
<lkcl>
so, of course, to make life easier, i made the regfile combinatorial as well...
<lkcl>
baad move
<lkcl>
daveshah: well, it's more that i've never done this before.
<lkcl>
i had:
<lkcl>
* an instruction decoder that was combinatorial and
<lkcl>
* a regfile read likewise and
<lkcl>
* a pipeline manager likewise...
<lkcl>
no wonder i was only getting 20 mhz, a couple days ago :)
<lkcl>
nuts to it, i'm going to try libresoc @ 75mhz
<lkcl>
what's a DPR16X4?
<somlo>
lkcl: just tried that bitstream on the 5g versa, and it works (requested 50MHz, "passed" at 24-and-change, works fine, including passing memtest, at 50 when programmed)
<daveshah>
lkcl: 16x4 bit distributed RAM
<daveshah>
ie a cluser of 4 LUTs can be used as RAM instead of ROM
<lkcl>
daveshah: thx
<lkcl>
somlo: hmm interesting.
<lkcl>
what versions of... "stuff" are you using?
<lkcl>
because if you use latest rocket-chip, they're removed mtval
<lkcl>
so it's guaranteed that the litex bios won't compile