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.

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. 

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.  

I agree when it comes to the summed up violation value. The next figure will be the sum of all slacks in the department and then in whole country. I wonder what it should express.

Recently a XI-REP announced it might give an idea about the likelyhood if a design might fail in reality, but i had to correct him that way that one single signal with a slack of e.g. 0,1ns might cause more likely an error (with extreme temps and voltages and bad chip lots) than a value of 1ns when summed up 10 signals because there are vulnerable and less vulnerable signals and summing them up required weighting.