SNUG:All My X's Come From Texas…Not!!
Matt Weber
Jason Pecor
Silicon Logic Engineering
In a recent ESNUG article ( http://www.deepchip.com/items/0421-01.html), eighteen engineers shared their view of the current usefulness of gate level simulation. Only one of those engineers has completely removed gate level simulation from their design flow. The other engineers listed many reasons for continuing to do some level of gate level simulation.
1. Since scan and other test structures are added during and after synthesis, they are not checked by the rtl simulations and therefore need to be verified by gate level simulation.
2. Static timing analysis tools do not check asynchronous interfaces, so gate level simulation is required to look at the timing of these interfaces.
3. Careless wildcards in the static timing constraints set false path or mutlicycle path constraints where they don't belong.
4. Design changes, typos, or misunderstanding of the design can lead to incorrect false paths or multicycle paths in the static timing constraints.
5. Using create_clock instead of create_generated_clock leads to incorrect static timing between clock domains.
6. Gate level simulation can be used to collect switching factor data for power estimation.
7. X's in RTL simulation can be optimistic or pessimistic. The best way to verify that the design does not have any unintended dependence on initial conditions is to run gate level simulation.
8. It's a nice "warm fuzzy" that the design has been implemented correctly.
Matt Weber
Jason Pecor
Silicon Logic Engineering
In a recent ESNUG article ( http://www.deepchip.com/items/0421-01.html), eighteen engineers shared their view of the current usefulness of gate level simulation. Only one of those engineers has completely removed gate level simulation from their design flow. The other engineers listed many reasons for continuing to do some level of gate level simulation.
1. Since scan and other test structures are added during and after synthesis, they are not checked by the rtl simulations and therefore need to be verified by gate level simulation.
2. Static timing analysis tools do not check asynchronous interfaces, so gate level simulation is required to look at the timing of these interfaces.
3. Careless wildcards in the static timing constraints set false path or mutlicycle path constraints where they don't belong.
4. Design changes, typos, or misunderstanding of the design can lead to incorrect false paths or multicycle paths in the static timing constraints.
5. Using create_clock instead of create_generated_clock leads to incorrect static timing between clock domains.
6. Gate level simulation can be used to collect switching factor data for power estimation.
7. X's in RTL simulation can be optimistic or pessimistic. The best way to verify that the design does not have any unintended dependence on initial conditions is to run gate level simulation.
8. It's a nice "warm fuzzy" that the design has been implemented correctly.
No comments:
Post a Comment