azonenberg changed the topic of ##openfpga to: Open source tools for FPGAs, CPLDs, etc. Silicon RE, bitfile RE, synthesis, place-and-route, and JTAG are all on topic. Channel logs: https://libera.irclog.whitequark.org/~h~openfpga
Wolfvak has quit [Changing host]
Wolfvak has joined ##openfpga
Raito_Bezarius has quit [Ping timeout: 268 seconds]
Raito_Bezarius has joined ##openfpga
Raito_Bezarius has quit [Max SendQ exceeded]
Degi_ has joined ##openfpga
Degi has quit [Ping timeout: 250 seconds]
Degi_ is now known as Degi
Raito_Bezarius has joined ##openfpga
Raito_Bezarius has quit [Max SendQ exceeded]
Raito_Bezarius has joined ##openfpga
whitequark has quit [*.net *.split]
jevinskie[m] has quit [*.net *.split]
lkcl has quit [*.net *.split]
rektide has quit [*.net *.split]
hl has quit [*.net *.split]
christiaanb has quit [*.net *.split]
esden has quit [*.net *.split]
tnt has quit [*.net *.split]
_florent_ has quit [*.net *.split]
christiaanb has joined ##openfpga
_florent_ has joined ##openfpga
esden has joined ##openfpga
hl has joined ##openfpga
lkcl has joined ##openfpga
jevinskie[m] has joined ##openfpga
tnt has joined ##openfpga
whitequark has joined ##openfpga
rektide has joined ##openfpga
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined ##openfpga
enok has quit [Remote host closed the connection]
enok has joined ##openfpga
indy has quit [Ping timeout: 264 seconds]
indefini[m] has quit [Quit: You have been kicked for being idle]
indy has joined ##openfpga
mewt has quit [Read error: Connection reset by peer]
indy has quit [Ping timeout: 252 seconds]
indy has joined ##openfpga
Miyu has joined ##openfpga
hackkitten has quit [Ping timeout: 248 seconds]
Miyu has quit [Read error: Connection reset by peer]
<sensille>
i'm in a bit of a tight spot. i updated my OS, which broke the toolchain. after updating the toolchain my design doesn't meet the timing anymore. i'm inclined to blame nextpnr-ecp5, but i can't be 100% sure as i can't run the old version anymore.
<sensille>
i think the previous version was bb607913, roughly 1 1/2 years old
<sensille>
are there any significant changes regarding timing?
indy has quit [Ping timeout: 252 seconds]
<tpw_rules>
imho you're a bit hosed. the timing will depend on the seed which will depend on the exact program text and revision. maybe it was always that marginal
<tnt>
My guess : Add -no-rw-check to synth_ecp5 yosys command
<tnt>
This is probably the most (negatively) impactful change in the last 1.5y.
<sensille>
timing changed from 52mhz to 38mhz, quite significant
<sensille>
i tried with what i believe is the .json i used with the old nextpnr-ecp5
<sensille>
so a yosys change shouldn't impact this test
<sensille>
i can try with different seeds
<sensille>
37.04, 36.96, 40.18mhz. prev: 52.60mhz
<tnt>
"what i believe" is always suspect
<tnt>
You can use the oss-cad-suite builds to "go back in time" and try to find out where things went wrong.
<somlo>
sensille: in my (recent) experience with nextpnr-ecp5, placement (packing) is *much* better than before (year+ ago); timing is also better *on average*.
<somlo>
the trick (per gatecat's advice) is to use "flow3" (i.e., add 'scratchpad -copy abc9.script.flow3 abc9.script' before 'synth_ecp5 -abc9 -top <whatever>' to your yosys script)
<sensille>
okay, those are some nice pointers, will check in both directions
<somlo>
I then run `nextpnr-ecp5` in a loop with --seed $RANDOM until it passes timing -- which it eventually does in my case. With a year+ old nextpnr-ecp5 I didn't use to stand a chance, so there's an extra $0.02 worth of advice :)
<sensille>
tnt: i explicitly wrote "what i believe" because it is suspect to me, too :)
<sensille>
okay, with the abc9+flow3 it went up from 36 to 46mhz, close
<tnt>
sensille: did you use -no-rw-check ?
<sensille>
oops, no, trying
<sensille>
no significant change
<sensille>
stupid libboost stuff
<somlo>
sensille: if you re-run nextpnr-ecp5 (only) with a new $RANDOM seed a few times, you can get an idea of what your fmax "distribution" looks like, and if you stand a chance of getting lucky and meeting your target
<sensille>
yes, but it still irks me that the old toolchain seemed to have met the target easily. currently trying oss-cad-suite
<sensille>
58mhz
<sensille>
old json, old nextpnr-ecp5 (oldest available on oss-cad-suite)
<tnt>
Well now you get to bisect and find the culprit.
<sensille>
bisecting by downloading 700MB per step :)
<tnt>
Well you can build it if you want, but for me it's faster to download that build the toolchain ...
<sensille>
i'll probably just do it tomorrow as an idle task at work
<tnt>
Probably easy enough to script
indy has joined ##openfpga
<gatecat>
it might be a bad case with the split-slice stuff, however much I tested to make sure it didn't seriously pessimise anything there was always going to be one case when it did
<gatecat>
and it seems like you might have found it
<gatecat>
that was merged sometime around april if it helps with checking oss-cad-suite releases
<sensille>
20220401 - good. 20220501 - bad
<sensille>
gatecat: is there a switch i can try?
<sensille>
20220415 - bad
<sensille>
20220407 - good
<sensille>
is that close enough?
<sensille>
if it's e42e2257 (Merge pull request #972 from YosysHQ/gatecat/ecp5-split-slice-v2) it is dated Apr 7