<agg>
does anyone know where i might find a bunch of svf files to test out a parser on?
<agg>
the more cursed the better I guess
lutsabound has joined ##openfpga
Degi_ has joined ##openfpga
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
Bike has quit [Quit: Lost terminal]
specing_ has joined ##openfpga
specing has quit [Ping timeout: 240 seconds]
specing_ is now known as specing
tokomak has joined ##openfpga
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
<_whitenotifier-5>
[libfx2] DurandA commented on issue #6: How to write a response in chunks (USB control read)? - https://git.io/JYP46
aquijoule_ has joined ##openfpga
richbridger has quit [Ping timeout: 252 seconds]
lutsabound has quit [Quit: Connection closed for inactivity]
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
mumptai has joined ##openfpga
m4ssi has joined ##openfpga
jeanthom has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
<_whitenotifier-5>
[libfx2] whitequark commented on issue #6: How to write a response in chunks (USB control read)? - https://git.io/JYXw8
<_whitenotifier-5>
[libfx2] whitequark closed issue #6: How to write a response in chunks (USB control read)? - https://git.io/JYluC
<_whitenotifier-5>
[libfx2] DurandA commented on issue #6: How to write a response in chunks (USB control read)? - https://git.io/JYXFk
mumptai has quit [Quit: Verlassend]
marcan has quit [Quit: Now where's my screwdriver...]
marcan has joined ##openfpga
mumptai has joined ##openfpga
specing_ has joined ##openfpga
specing has quit [Ping timeout: 240 seconds]
specing_ is now known as specing
srk has quit [Ping timeout: 240 seconds]
unkraut has quit [Remote host closed the connection]
sam210723__ has quit [Quit: Leaving]
sam210723 has joined ##openfpga
unkraut has joined ##openfpga
Hoernchen has quit [Remote host closed the connection]
Hoernchen has joined ##openfpga
emeb has joined ##openfpga
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
tokomak has quit [Ping timeout: 258 seconds]
<sensille>
i have been searching all day for a bug in my bug after porting it to nmigen. failed only in hardware, sometimes. now i double checked with the old code, also fails. for the move to nmigen i had to upgrade my system (newer python) and rebuild all tools. while being at it, i upgraded them also (yosys+nextpnr)
<sensille>
now i see in the nextpnr.log that the design runs at max 46.5 mhz, while the clock is 48mhz. just a simple info line among others ...
<agg>
you can tell nextpnr what your clock constraint is, and it will error the build if it's not met
<agg>
in nmigen you can use the Clock attribute on a Pin, or you can do platform.add_clock_constraint(signal, frequency)
<sensille>
it seems to already know what the clock is, "info: FAIL"
<agg>
ah...
<sensille>
but it continues nontheless
jeanthom has quit [Remote host closed the connection]
<agg>
that would normally also exit with an error state unless you have --timing-allow-fail
<sensille>
if there is a switch to make it abort the build i have to set it
jeanthom has joined ##openfpga
<agg>
the default behaviour is to abort, the switch allows it to continue
<agg>
that said, i'd be quite surprised if you were actually seeing failures due to timing at room temperature and normal voltage at 48MHz for an fmax of 46.5MHz
<agg>
I mean, I guess maybe, but it's really conservative
<sensille>
not sure if that's the problem. the board also heated up, but isn't hotter faster for semiconductors?
<sensille>
Info: Max frequency for clock '$glbnet$clk_48mhz$TRELLIS_IO_IN': 45.62 MHz (FAIL at 48.00 MHz)
<sensille>
no options
<agg>
what's the exit code from nextpnr? did it output a new .cfg?
<agg>
probably you'd notice if the board had heated up that much, i assume ambient conditions are room temp
<agg>
you could try with a few different --seed arguments until you get one that passes timing
<sensille>
board sensor said 80c, due to stepper drivers and missing fan control
<agg>
but yea, my instinct is that you're probably not violating timing and the bug might lie elsewhere (but it's probably still worth making sure your build command does error out on timing fail and also try a few seeds because it's likely very quick to find one that passes timing when you're that close)
<agg>
oh, that is pretty warm, maybe maybe then
<sensille>
it did output a new config
<agg>
:/
<agg>
uh
<sensille>
i'd really like it to fail if it sees timing problems
<agg>
there's two fmax outputs: one before routing, one after
<agg>
often afterwards is better
<agg>
check the end of the output
<agg>
perhaps the final output did actually pass timing
<sensille>
*phew*, yes
<sensille>
61MHz
<agg>
nice
<sensille>
the main point of this for me is: always check your baseline
<sensille>
after upgrading everything i should have built the design again before doing the port to nmigen
<sensille>
now i'm going to go back to the previous version of yosys
jeanthom has quit [Ping timeout: 246 seconds]
emeb_mac has joined ##openfpga
jeanthom has joined ##openfpga
futarisIRCcloud has joined ##openfpga
jeanthom has quit [Ping timeout: 260 seconds]
mumptai has quit [Quit: Verlassend]
show1 has quit [Ping timeout: 240 seconds]
m4ssi has quit [Remote host closed the connection]
jeanthom has joined ##openfpga
jeanthom has quit [Ping timeout: 268 seconds]
lexano has quit [Ping timeout: 260 seconds]
lexano has joined ##openfpga
<mithro>
Anyone know what the name for the behaviour were a software vendor requires a separate license + payment for some feature (such as advanced optimization) in the software? I think it's something like "market segmentation" or "feature stratification".....
<etrig>
these are actually a class of software bugs called flexlm that vendors refuse to patch