beingbobbyorr
Newbie level 3
At my company, we have some FPGA & ASIC designers that insist on using BATS (back-annotated timing simulations) to prove timing, because they have trouble wrapping their heads around (read: trusting) STA (static timing analysis).
I want to demonstrate to them the lack of path sensitization and propagation ( to primary outputs of the design ) that these back-annotated timing simulations are producing. Would standard code-coverage metrics ( enabled with compiler options in the script of an HDL simulator ) be the way to go? Or are there other tools/methods? I think these designers are fooling themselves that they're getting a high percentage of 'toggle activity' on his internal nets just by observing that they're doing a walking-1's/0's test on some input pins.
Put another way, I'm looking for the back-annotated timing simulation equivalent of the way fault grading works for testability analysis to ferret out controllability/observability issues.
I want to demonstrate to them the lack of path sensitization and propagation ( to primary outputs of the design ) that these back-annotated timing simulations are producing. Would standard code-coverage metrics ( enabled with compiler options in the script of an HDL simulator ) be the way to go? Or are there other tools/methods? I think these designers are fooling themselves that they're getting a high percentage of 'toggle activity' on his internal nets just by observing that they're doing a walking-1's/0's test on some input pins.
Put another way, I'm looking for the back-annotated timing simulation equivalent of the way fault grading works for testability analysis to ferret out controllability/observability issues.