Forums

FPGA speed and timing closure metrics

Started by kaz 5 months ago2 replieslatest reply 5 months ago43 views

We have plenty data sheets, documents, forum replies and videos on various fpgas and designs. However what is missing in all cases is some idea how fast can one go for a given fpga. I know this varies with design and designer but is there any basic metric for a set reference case.

Moreover if a design fails timing extensively are there any useful metrics for checking "progress" on timing performance as exceptions are added or design changes done. I know we get worst negative slack, total negative slack and number of failing endpoints as ratio to all endpoints. But from my experience these metrics do not do well and are not linear and could be paradoxical. Thus they are practically useless except in simple timing violations.

Any thoughts please.

[ - ]
Reply by PeterJune 2, 2021

G'day Kaz,

"Any thoughts please" ..

If I'm stumped on the closure then I have sometimes resorted to creating a seperate and fictitious clock source, declaring this in the constraints and then disconnecting various 'components' or modules in the design for the path(s) causing the problem(s) and connect these to the fictitious clock domain to see which area is causing the exceptions. 

You cannot do this for all system designs of course as it depends on the interconnection of the modules and will generate new reports in the timing analysis but this crude method can sometimes help clarify where the bottleneck is coming from i.e. it simplifies the path and focuses attention down to the problem area(s). 

Not exactly what you were looking for but hope this helps. 

All the best, Peter. 

[ - ]
Reply by kazJune 2, 2021

Thanks Peter,


That is ok for localising bottlenecks but I am really seeing widespread violations as our clock is 491.52MHz with a ZU29 well packed (vivado). I am not after specific bottlenecks but instead I identify multicycle paths, false paths, do ip reconfigurations...etc and want to check my progress on such valid changes. I see timing exceptions taken in and relevant paths rescued but I am in the dark for all other paths in the project as they behave sometimes as expected or erratically and the negative slack metrics get better or worse across other paths with no clear pattern.