whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
Wanda[cis] has quit [Quit: Bridge terminating on SIGTERM]
Micko[m] has quit [Quit: Bridge terminating on SIGTERM]
galibert[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #prjcombine
_whitelogger has joined #prjcombine
Wanda[cis] has joined #prjcombine
<Wanda[cis]>
so I know I'm not beating the Chiri Kitsu allegiations here, but
<Wanda[cis]>
current status: I have recovered all derating factors for ice40 and modified timing extraction code to compute the base timing backwards from icecube SDF export
<Wanda[cis]>
that is, icecube exports a triple of (base * min_factor : base * typ_factor : base * max_factor); I compute the three factors and compute base from it, then stuff it to the database.
<Wanda[cis]>
however, there is a problem, in that icecube rounds every SDF number to 6 decimal places
<Wanda[cis]>
this cannot stand and I need to fix it.
<Wanda[cis]>
I could just round harder (to 5 decimal places), and it'd mostly fix the problem, except then I'd lose more precision in other timings where the base data apparently has 6 significant figures.
<Wanda[cis]>
so I have come up with a perfect solution.
<Wanda[cis]>
icecube allows you to specify the derating parameters. temperature, voltage range, process corner. it computes the factors from those.
<Wanda[cis]>
turns out if you provide batshit data, the relevant function errors out. and returns -1.0 instead of the factor as a sentinel.
<Wanda[cis]>
which doesn't actually abort processing.
<Wanda[cis]>
and this results in no precision loss, since the raw base value ends up in SDF file (they are never more than 6 significant figures in the source data in the first place).
<Wanda[cis]>
* ends up directly in, * in the SDF file