<Wanda[cis]>
does this sound like a reasonable timing model?
<Wanda[cis]>
with something simple like siliconblue, I'd just grab the above straight from prjcombine timing database; for more complex timing models like xilinx, the target code would be expected to compute them in whatever way
gatecat[m] has joined #prjunnamed
<gatecat[m]>
there is the kind of 4-corner thing Xilinx does to account for OCV
<Wanda[cis]>
yeah I've seen the 4-corner thing and I don't really understand it
<Wanda[cis]>
do you have literature?
<gatecat[m]>
like the idea is you run setup within the range of a slow process and hold within the range of a fast process
<Wanda[cis]>
how is that different from just using max delay for setup and min delay for hold?
galibert[m] has joined #prjunnamed
<galibert[m]>
Isn’t floating point easily annoying compared to say picoseconds as u64?
<galibert[m]>
Just for the non commutativity issues ?
<gatecat[m]>
Wanda[cis]: because you'll never have worst-case max and best-case min on the same chip at the same time
<Wanda[cis]>
galibert[m]: yeah that was my thinking when I did the CPLD stuff.
<gatecat[m]>
these things are kind of correlated
<Wanda[cis]>
except turns out this doesn't help anything
<gatecat[m]>
the idea is you run setup with the possible local variations on a slow-case chip and hold with the possible local variations on a fast-case chip
<Wanda[cis]>
because for more complex models you need to compute timings from RC data anyway
<gatecat[m]>
you can also just implement this by supporting different corners for setup and hold aiui
<galibert[m]>
Pathfinder doesn’t get annoying when you don’t have commutativity on add?
<galibert[m]>
Or whatever routing algorithm
<Wanda[cis]>
and even for stuff like siliconblue the data you get from SDF has like 6 digits and is in hundreds of picoseconds, so you'd need integer fs to not lose precision, and at this point why not just use the fucking floats
<gatecat[m]>
galibert[m]: nothing stops the router using integers, it's probably going to use a fast simplified delay model anyway...
<Wanda[cis]>
yeah we may want to cast the components into high-precision ints anyway once the RC computations are done
<Wanda[cis]>
but I do believe the database should be in floats
<gatecat[m]>
yeah, agreed
<Wanda[cis]>
oh, there's also stuff like derating which you also want to do on floats
<Wanda[cis]>
gatecat[m]: okay, yeah, but
<Wanda[cis]>
that'd mean you want SLOW_MAX for setup, and FAST_MIN for hold, right?
<Wanda[cis]>
what would SLOW_MIN and FAST_MAX be for, then?
<gatecat[m]>
you'd use one for clock delays and one for data delays, iirc
<Wanda[cis]>
oh
<Wanda[cis]>
ohhh.
<gatecat[m]>
or well, launch clock vs capture clock
<Wanda[cis]>
yeah okay I see
<Wanda[cis]>
so for setup I'd do SLOW_MAX for the data, SLOW_MIN for capture clock?
<Wanda[cis]>
and for hold, FAST_MIN and FAST_MAX respectively?
<gatecat[m]>
yeah, I think so
<gatecat[m]>
although I think this doesn't affect the data model, so long as you support different corners for the data anyway
<Wanda[cis]>
hm.
<gatecat[m]>
you'd just run setup with the SLOW data and hold with the FAST data
<gatecat[m]>
not sure if there are any more complex cases where this breaks
<Wanda[cis]>
I mean, it may affect the database format
<gatecat[m]>
yeah
<Wanda[cis]>
or I'd just have a completely separate instance of timing data for FAST vs SLOW? hrm.
<gatecat[m]>
I think that might be how I'd implement it
<Wanda[cis]>
I don't really understand how ISE does it still
<Wanda[cis]>
so the speed files store every delay datum as a (fast_min, fast_max, slow_min, slow_max) tuple
<Wanda[cis]>
but then you also have speed grades
<Wanda[cis]>
and you have a special "minimum delay" speed grade which it claims is for hold analysis
<gatecat[m]>
oh yeah, thinking about I've seen that in Diamond too, so I guess it's a neocad thing
<Wanda[cis]>
so you'd have like 4 speed grades for example: -1, -2, -3, min-delay
<gatecat[m]>
yeah I honestly don't know why you need min-delay and the fast_ timings
<Wanda[cis]>
... yeah
<Wanda[cis]>
okay
<Wanda[cis]>
so for delays, I want (fast + slow) × (min, max), okay
<Wanda[cis]>
with × unateness as appropriate
<galibert[m]>
fwiw, Im not 100% certain but quartus on the cyclone v seems to only use speed grade on routing connections and not within tiles
<Wanda[cis]>
for setup... I only care about SLOW_MAX? and FAST_MIN for hold?
<Wanda[cis]>
er
<Wanda[cis]>
FAST_MAX for hold?
<gatecat[m]>
for the setup constraint itself? yeah I think so
<Wanda[cis]>
as in, the actual FF setup constraint
<Wanda[cis]>
yeah
<Wanda[cis]>
and for pulsewidth / period, I only care about SLOW_MAX, okay
<gatecat[m]>
yeah
<Wanda[cis]>
and I suppose I should still make sense of the funny min delay grade at some point
<Wanda[cis]>
the toolchains also give me "typical" delay values, I assume they are basically perfectly useless?
<gatecat[m]>
yeah I have no idea what you would do with those
<Wanda[cis]>
xilinx used to include them in speed files in spartan3 era (they had min/typ/max triples for everything), they're gone on spartan6 (which has fast_min/fast_max/slow_min/slow_max quads instead)
<Wanda[cis]>
oh hm.
<Wanda[cis]>
unateness works funny when tristate buffers are involved
<gatecat[m]>
oh ugh
<Wanda[cis]>
so SB_IO has effectively clock-to-out tuple of (0-to-1, 1-to-0, z-to-0, z-to-1, 1-to-z, 0-to-z), I guess?
<Wanda[cis]>
at least that crap doesn't propagate through the device
<Wanda[cis]>
... and with combinational circuits you can easily construct something that results in a 12-tuple of min-max pairs, by multiplying the above with input rise vs fall edge
cr1901 has quit [Read error: Connection reset by peer]