I agree with Jim. The only part of this rule that I accept as valid,
is that STA alone is no replace for netlist simulation, but not for
timing reason but for proof of functionality after synthesis.
In fact there are things like some asynchron inputs that tend to be
"easy" covered by STA, but are impossible to simulate, as a simulation
tends to be overpessimistic in case of recovery from 'X'.
I also disagree with rule #5. Even for FPGAs are asynch resets
necessary for some classes of designs (typically for flash or fuse
base Fpgas that are active with power-up) which require asynch reset.
There are several technics available to prevent any problems due to
the asynch reset.
Tip #4 seems to me to be marketing from Xilinx as other cores are
available and have their market.
And last: Tip #7 is lacking it should read "every rule may be violated
if you know why you violate the rule and what happens if you violate
the rule"
bye Thomas
I agree with Jim about STA vs Timing Simulation for verifying timing.
For verifying false/multi-cycle paths, I sometimes add assertions in
the RTL to ensure that those assumptions are correct. That lets me
verify those constraints at much faster RTL simulation speeds, where
more corner cases can be run per unit time (= $).
I think the amount of effort/time spent in full timing simulation has
to be balanced against the "risk (= cost * propability) of failure".
If you have early access to the rest of the hardware with which to
integrate your design in the lab, debugging there (especially with
tools like chipscope) can be more productive than running exhaustive
test cases through slow, full timing simulations. On the other hand,
if you are a consultant, and your customer expects your design to work
the first time it touches hardware, then the "cost of failure" can be
pretty high, and warrants much more effort in full timing simulation.
I also would take into account what type of design it is, and whether
or not the tool flow for that design has been proven in the past, to
get an idea of the likelihood of tool-induced errors. Other than false/
multi-cycle path constraint errors, tool-induced errors are the only
type of error a full timing simulation will catch that an RTL
simulation will miss. If you are using a proven toolset and not
plowing new ground with it, and your functional (rtl) simulations have
assertions to catch problems with false/multicycle path constraints
(or you use other means to verify them), and your STA results are
good, there is much less (perhaps even no) need for running full
timing simulations, and you're better off running more test cases
through your RTL simulations.
Finally, I would ammend #5 to allow asynchronous reset and clear only
for initialization (i.e. startup), not for functional operation. And
such asynchronous control signals must be designed to deassert
synchronously to each clock domain they affect. Applying asynchronous
reset is a truly asynchronous function; taking it away is a
synchronous function, and must be handled with proper synchronization
techniques.
Andy
