timing verification

[rickman]

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

Hi Rickman,

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

I do functional verification through TLM in VHDL and I'm about to dig in
the usage of OSVVM for constrained coverage. Unfortunately this approach
does not give me the level of observability I needed, especially on
internal bus protocols, that's why I wanted to explore other means.

Sounds like I am a bit behind in this. I have always verified timing by
setting timing constrains for the P&R tool which verifies the design
meets the timing constraints. Is there some other aspect of timing that
constraints don't work for?

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.

PSL, OVL, SVA, OSVVM, TLM...??? I need to check this out I expect.

For timing at higher levels, like "does this happen three clock cycles
after that happens", I have always just verified that by inspection or
functional simulation. Are these tools ways of adding formal
verification of this sort of timing?

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?

--

Rick

 

[HT-Lab]

Hi Rickman,
On 28/10/2013 23:16, rickman wrote:

On 10/16/2013 4:32 AM, HT-Lab 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 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.

...

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?

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
Fmax static timing, can be covered by a synchronous testbench that
meets the setup and hold pin requirements of the programmable device
design.

On Monday, October 28, 2013 1:25:30 PM UTC-7, alb wrote:

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