<pepijndevos>
What info is needed to add timing-aware ABC9 support to an arch?
emeb has joined #yosys
<ZirconiumX>
pepijndevos: A good start is LUT input to output delays
<ZirconiumX>
That lets ABC9 do a lot of its magic
s_frit_ has quit [Remote host closed the connection]
<pepijndevos>
How is that specified? Looking at ECP5, but it's a bit mysterious
<ZirconiumX>
As of latest Yosys, you use Verilog specify blocks
s_frit has joined #yosys
<ZirconiumX>
An incredibly brief tour of the syntax is that a specify block is within `specify`/`endspecify` and contains entries that look like `(input => output) = delay;` for combinational delay
<ZirconiumX>
Essentially, `(I0 => O) = (449, 386)` means it takes 449ps for a 0->1 transition on I0 to propagate to a 0->1 transition on O, and 386ps for a 1->0 transition
<whitequark>
huh I didn't realize those will be different
<ZirconiumX>
[not an expert disclaimer] I think it's to do with base saturation
<pepijndevos>
Probably mismatch between PMOS and NMOS?
<whitequark>
I thought they make PMOS transistors larger to avoid that
<ZirconiumX>
Either way, while I don't know why/how, I'm reasonably confident on the what: it's unateness timings
<pepijndevos>
I guess there is a trade-off between making your switches 4 times bigger or dealing with a bit of assymetry.
<pepijndevos>
But not 100% sure either... can't peek in the FGPA designer's mind
<whitequark>
4 times?
<whitequark>
why 4?
<ZirconiumX>
Yeah, trying to even out the 0->1/1->0 transitions in silicon harms 0->1 time for 1->0 time
<ZirconiumX>
So it's potentially slower switching overall
<pepijndevos>
I pulled that number out of my magic hat, but IIRC that's about how much worse PMOS is. Might be completely wrong on that.
<pepijndevos>
Also worth considering is that making the switch bigger gets more parasitic capacitance, making it slower again.
<pepijndevos>
So maybe they are actually matched in terms of gm, but due to their size are a bit slower. Dunno...
<ZirconiumX>
Anyway, pepijndevos, that'll give you a start. You don't have to care about unateness because I'm *fairly sure* ABC9 doesn't perform unateness analysis
<ZirconiumX>
But you can add it if you have it, and maybe it makes useful documentation
<pepijndevos>
Right. I'll just plug in whatever numbers I like.
<pepijndevos>
Like... I have several different speed grades which each have 4 numbers that I believe to be some variations of fast/slow/hot/cold
<ZirconiumX>
Pick the worst-case delays
<ZirconiumX>
You have a small amount of area to fudge it ~~like I do~~ but the numbers have to make *some* level of sense
<ZirconiumX>
e.g. if you have a LUT6 made of LUT4s at the same delay as pure LUT4s, ABC9 will heavily favour the LUT6s, destroying your area
<pepijndevos>
will try, thanks.
<pepijndevos>
I'd think as long as I pick numbers from the same class for everything it should work out.
<ZirconiumX>
Well, not quite
<ZirconiumX>
ABC9 has a requirement of nondecreasing input delays
<ZirconiumX>
i.e. for a LUT4, A <= B <= C <= D
<ZirconiumX>
This does not hold for the Cyclone 10GX, which is a bit painful
<daveshah>
I feel like Yosys might fix this up now