<tnt>
because you're not looking at the same path at all ?
<tnt>
First one looks like a purely comb path across the design, the second looks like an internal FF -> FF path.
<jonpry>
It is a critical path report from each tool
<jonpry>
As I understand it, ABC stime removes the FF from the ends of path
<tnt>
Are you sure you even loaded the same process corners libraries ?
<jonpry>
Yes
<tnt>
And where is that OpenSTA from ? Is it post-synth ? Or post-pnr ? And setup with the same load and drive caracteristics ?
<jonpry>
It's post-synth. Right after yosys does the stime, i write out and run it through opensta
<jonpry>
I have not setup any wire load in OpenSTA. Maybe it has some default?
<killjoy>
ABC does not look like a timing analysis tool, so I would tend to believe opensta, who's output looks more like a timing analysis tool should.
<killjoy>
And if wireload is zero it is probably zero, but read the manual.
<jonpry>
I cannot make sense of the OpenSTA output. 0.00 0.00 ^ _108437_/CLK (sky130_fd_sc_hd__dfrtp_1)
<jonpry>
Says Clk->Q on the DFF is 5.82ns. How can that be?
Guest78 has joined #yosys
<killjoy>
Ok, so you need to read that report and understand it, from top to bottom.
Guest78 has quit [Client Quit]
<killjoy>
Your start is the rising edge of the clk, clock network delay is ideal so you have no load, and the times are probably in picoseconds through the path.
<tnt>
Not really sure what ^ and v mean but the rest is pretty clear.
<tnt>
PRetty sure the times are in ns.
<killjoy>
I also see no interconnect delays, just gate delays, so again, wireload is zero. AKA: you are not running an annotated timing sim.
<jonpry>
The liberty file says time units are ns. And I know from experience that the approximate speed of sky130 logic is in the 100ps range
<killjoy>
ns is a long time though.
<tnt>
heh, this is not a state-of-the art process ...
<killjoy>
tnt: If it takes 5ns to charge a pin on a gate, that's forever.
<tnt>
yeah
<killjoy>
Ok then. Last time I did STA signoff I was working at 28nm process node, so could be.
<tnt>
ps is just not believable.
<killjoy>
Ok if you say so. It's been a while since I did STA signoff so maybe I'm just rusty.
<killjoy>
tnt: The ^ and v are likely rising and falling edge indicators.
<killjoy>
So clk rises, Q rises, X rises, Y falls, etc.
<tnt>
Oh right yeah, asymettric delays, good call.
<killjoy>
Cell libraries have different characteristics for rise times and fall times.
<killjoy>
Gates are not perfectly symmetric.
<killjoy>
Well, IME anyway.
<killjoy>
This path is basically saying "it's way long dude, put in some pipeline stages or make it shorter."
<tnt>
Some things are a bit surprising to me in that report : (1) you have clkbuf and clkxxx cells in the path ... those are usually special for the clock tree and not meant for general purpose logic and shouldn't be inferred. (2) some cells seem to take a _very_ long time. (3) they are all the _1 variant like is the upsizing process didn't occur to compensate the gate size with the net fanout.
<killjoy>
I'm used to looking at primetime reports. There should be a number in this report that indicates the fanout on a pin.
<killjoy>
But I don't see it.
<killjoy>
Oh god, googling this stuff brings back so many memories...
<jonpry>
I agree with those observations. The yosys synthesis script can probably me modified to prevent it from using clock buffers. But it's still not clear to me why the Clk->Q thing happens. Even if I run the OpenSTA included examples. They are all like 2-3 gate circuits and for some examples it shows this huge CLK->Q and for other examples it shows as .2ns
<killjoy>
You don't worry about that clk->Q.
<killjoy>
You have to clock your flop for it to work, man.
<killjoy>
Else, nothing happens.
<killjoy>
This is from Parallax?
<jonpry>
The flop has maximum operating speed > 200mhz, in fact it can go ghz
<killjoy>
Good for you?
<killjoy>
It still has a propagation delay of 5.82ns apparently.
<jonpry>
But it doesn't
<killjoy>
Well then your configuration is wrong for your synthesis.
<killjoy>
AKA: you used the wrong flop.
<killjoy>
Because _THAT_ flop has a 5.82ns propagation delay from clk->Q.
<tnt>
jonpry: what process corner did you use ?
<killjoy>
And that's a good question.
<jonpry>
sky130 typical
<killjoy>
It's also the smallest drive flop (probably) in the library.
<tnt>
tt_025C_1v80 ?
<killjoy>
If I'm interpreting the nomenclature correctly.
<tnt>
yes, _1 is the weakest output drive.
<killjoy>
Holy crap this is a big node.
<tnt>
yeah, it's mixed 130/180 nm.
<jonpry>
sky130_fd_sc_hd__ff_n40C_1v76
<killjoy>
1v8 is huge to me.
<tnt>
I ask you what process corner you tell me "typical", then you pull out a "fast/fast" one ...
<jonpry>
Well, I got it wrong. the fast/fast is what the pastebin was generated on
<killjoy>
tnt: Is this a free library or something?
<killjoy>
nvm found it.
<tnt>
yeah, it's the skywater 130nm process that's freely available PDK
<tnt>
(hence why it's "old")
<killjoy>
I need to change my thinking, don't mind me.
<killjoy>
There's lots of old processes that get wide use, I'm just not used to them.
<killjoy>
When I was in this sphere, we were chasing the bleeding edge of what TSMC had to offer because I worked for PMC-Sierra back when it existed.
<killjoy>
It's been a while though so I should just be more accepting of the things I don't know.
<tnt>
But still, in that liberty file I don't see anything close to 5 ns clk->q.
<jonpry>
Maybe it is huge fanout. Does yosys know how to make tree's of buffers to drive large loads?
<jonpry>
Funny thing is that this design runs 100mhz in fpga
<tnt>
as I said, I'm already surprised all your gates are _1
<tnt>
buffer / upsizing / ... are additional steps.
<tnt>
AFAIR the openlane custom ABC script does them.
<killjoy>
Yeah, we're pretty sure your synthesis script is screwy.
<killjoy>
It looks like it did a simple first-pass synthesis and nothing else frankly.
<killjoy>
As far as the ABC output, I wouldn't even look at that really.