timing verification

[rickman]

Hi Rickman,

On 15/10/2013 23:42, rickman wrote:
...

You use assertions to make sure that your timing constraints itself are
correct. For example, there are occasions where it is not easy to
determine if you always have a multi-cycle path (e.g. a designs with
multiple clock domains). In this case an assertion can help (or prove
exhaustively if you use a formal tool). For false path an assertion even
becomes a must have as checking them manually (i.e. looking at a gate
level schematic!) is an error prone and a very time consuming activity.

Can you explain? I'm not following how an assertion will help.

You can quite easily add an embedded assertion (supplied with the design
itself) that always checks that A happens 3 clock cycles after B. The
problem with Verilog/VHDL is that they are very verbose and hence more
susceptible to bugs, languages like PSL/SVA are designed for this task
and hence are very concise, easy to use for sequences and un-ambiguous.
You can write a page of VHDL/Verilog or 1 line of PSL/SVA.

Counting clock cycles is not the same as timing analysis. That would be
design verification. I can't think of an example of needing to verify
something like this. I guess my designs aren't so complex... or maybe
not so simple?

 

[HT-Lab]

Hi Rickman,

On 10/16/2013 4:32 AM, HT-Lab wrote: ...

Can you explain? I'm not following how an assertion will help.

You put an assertion on the control signals of the path so that the
assertion will fire/fail when the false path is selected (i.e. data
flows through the path). Tools like Fishtail generates the false path
assertions automatically for you.

...

Counting clock cycles is not the same as timing analysis. That would be
design verification. I can't think of an example of needing to verify
something like this. I guess my designs aren't so complex... or maybe
not so simple?

true, using assertions for false and multi-cycle path is merging
functional and timing verification. However, your static timing tool is
not going to tell you if you path is false or not, it just give you the
propagation delay.

Regards,
Hans.
www.ht-lab.com

 

[Mike Treseler]

'n clocks' type verifications for a synchronous design that meets

This is what I typically do myself as well, but that wouldn't be
possible if instead of 'pin requirements' we were talking about
'interface requirements' of an internal interface of your design.

I just use a fast enough clock so that these are all synchronous and
covered by the testbench.

I deal often with asynchronous interfaces therefore I typically
synchronize them before use and do not constraint them at all.

Even in this case, the clock constraint must match the hardware.
Duty cycle etc.

Actually
is there any good guide on how to constraint I/O?.

No. It's a mess. Trial and error.
Synopsis/Quartus sdc works the best.
https://www.google.com/search?q=sdc+file+example

Good luck
-- Mike Treseler