Is openlane timing constraint driven? Or is CLOCK_PERIOD just a check at the end?
The reason I ask is I want to know if I need to successively decrease CLOCK_PERIOD until the tool can't close timing or I should just run it once and I know from my timing slack how fast I can run my design
05/10/2021, 6:38 PM
The timing report at the end is most accurate and gives you the slack for setup and hold. So then you can work out what the max clock would be.
Thanks. So the tool just runs and lets you know what it achieves.
In the Cadence tools you tell it the clock period you want and it will work at rearranging things until it can reach the constraint (or give up).
I didn't think that's how openlane worked, but I wanted to check I wasn't leaving some MHz on the table by not asking it to work hard enough
05/10/2021, 6:43 PM
Yeah Im pretty sure that's not possible. For a start yosys can't do timing driven synthesis yet
05/10/2021, 6:44 PM
Cool cool, good to know the approach to take
I've also just started using your summary tool, very nice.
Definitely makes things a lot clearer
05/10/2021, 6:47 PM
So I would look at improving the critical path in your RTL and look at the high speed standard cells (I have no idea about anything other than the hd library)
05/10/2021, 6:50 PM
I'm about to give the hs cells a go. I had some trouble with them when openlane first came out but that was a loong time ago in terms of the development arc of openlane so hopefully they don't give me any hassle
Using the hs cells shows about a 50% increase in speed which would be welcomed but it fails at fastroute. Searching through slack other people have seen the same issue.
Guess I'll just stick with the hd cells for now