About gatelevel generated from DC

[parag_paul@hotmail.com]

hi All,
WE are having some simulation differences between rtl and gatelevel
when we run a design with gatelevel verilog.

There are some delays in the UDP's generated in the gate level. You
can see the UDP with a delay. I am not giving the whole scenario here
since I am new to DC and may be there are experts who know the reason
behind this delay in the gate level post synthesis. If you are not
able to infer anything from the data below, I will try to reduce as
much as possible and give you the whole design

module FD1(D, CP, Q, QN);
output Q, QN;
input D, CP;
p_dreg #1 (Q,CP,D);
not (QN,Q);
endmodule
`endcelldefine

primitive p_dreg(q,cp,d);
output q;
reg q;
input cp,d;
table
// cp d : present q : next q
r 0 : ? : 0;
r 1 : ? : 1;
f ? : ? : -;
b * : ? : -;
x 0 : 0 : 0;
x 1 : 1 : 1;

 

[Mike Lewis]

<parag_paul@hotmail.com> wrote in message
news:ef05a59c-1b3b-430d-9215-ac5700238189@h11g2000prf.googlegroups.com...

hi All,
WE are having some simulation differences between rtl and gatelevel
when we run a design with gatelevel verilog.

There are some delays in the UDP's generated in the gate level. You
can see the UDP with a delay. I am not giving the whole scenario here
since I am new to DC and may be there are experts who know the reason
behind this delay in the gate level post synthesis. If you are not
able to infer anything from the data below, I will try to reduce as
much as possible and give you the whole design

module FD1(D, CP, Q, QN);
output Q, QN;
input D, CP;
p_dreg #1 (Q,CP,D);
not (QN,Q);
endmodule
`endcelldefine

primitive p_dreg(q,cp,d);
output q;
reg q;
input cp,d;
table
// cp d : present q : next q
r 0 : ? : 0;
r 1 : ? : 1;
f ? : ? : -;
b * : ? : -;
x 0 : 0 : 0;
x 1 : 1 : 1;

Most gate level primitives will default to a unit time delay (assuming you
haven't back annotated the SDF timing). When I'm doing gate level simulation
w/o timing I will typically add the following switches so that there is zero
delay. A unit delay per gate is likely not going to work.

+nospecify
+notimingcheck


these are for VCS

Mike

 

[parag_paul@hotmail.com]

On Mar 18, 11:11 pm, "Mike Lewis" <some...@micrsoft.com> wrote:

parag_p...@hotmail.com> wrote in message

news:ef05a59c-1b3b-430d-9215-ac5700238189@h11g2000prf.googlegroups.com...



hi All,
WE are having some simulation differences between rtl and gatelevel
when we run a design with gatelevel verilog.

There are some delays in the UDP's generated in the gate level. You
can see the UDP with a delay. I am not giving the whole scenario here
since I am new to DC and may be there are experts who know the reason
behind this delay in the gate level post synthesis.  If you are not
able to infer anything from the data below, I will try to reduce as
much as possible and give you the whole design

module FD1(D, CP, Q, QN);
 output Q, QN;
 input D, CP;
 p_dreg #1 (Q,CP,D);
 not (QN,Q);
endmodule
`endcelldefine

primitive p_dreg(q,cp,d);
 output q;
 reg q;
 input cp,d;
 table
// cp d : present q : next q
   r 0 : ? : 0;
   r 1 : ? : 1;
   f ? : ? : -;
   b * : ? : -;
   x 0 : 0 : 0;
   x 1 : 1 : 1;

Most gate level primitives will default to a unit time delay (assuming you
haven't back annotated the SDF timing). When I'm doing gate level simulation
w/o timing I will typically add the following switches so that there is zero
delay. A unit delay per gate is likely not going to work.

+nospecify
+notimingcheck

these are for VCS

Mike

hi Mike,
I am a software engineer so green behind the ears if I am to be
proper.
Actually it is something like this
I have a evcd file ( VCS ) which has all the value changes that
happened with the RTL simulation on the DUT ports. Now I want to send
stimulus to the DUT ports depending on the value changes on the
gatelevel design ., Due to the one time delay all the values are
coming after one time delay, This causes mismatch between the first
and the second run.

How dies SDF annotation work, does it remove the timing delays on the
UDP's as I want
Is it a standard. If that is so , what was the reason for DC to add
the delay on the gate

-Parag

 

On Mar 18, 7:52 am, "parag_p...@hotmail.com" <parag_p...@hotmail.com>
wrote:

WE are having some simulation differences between rtl and gatelevel
when we run a design with gatelevel verilog.

There are some delays in the UDP's generated in the gate level. You
can see the UDP with a delay.

I would guess that the delay was added to avoid problems due to zero-
delay race conditions.

In RTL code, flip-flops are commonly written using nonblocking
assignments, which gives the output a delay greater than any clock
skew due to ordinary zero-delay logic. If your gate-level design uses
zero-delay UDPs for the flip-flops, that delay is the same as any
other kind of zero-delay logic. That means you can have race
conditions appear in the gate-level simulation that were not in the
RTL simulation. For example, a value might get through two levels of
pipeline registers in a single clock, because the output of the first
changes before the second one evaluates.

There is no equivalent in a UDP to the special delay that nonblocking
assignments use, that is zero but greater than any normal zero delay.
The only way to give it a delay greater than any normal zero delay is
to use a non-zero delay. So there is no way to make your UDP match
the zero delay of the RTL simulation without potential problems due to
race conditions.

You could go the other direction and make your RTL simulation match
the unit delay of the gate-level simulation. Just add a #1 delay to
the RHS of all your nonblocking assignments. That could be a pretty
major change, but you might be able to do it with a simple global
replacement using an editor or script.

Alternately, you could replace the UDP with a behavioral version that
has the same basic behavior, but uses a nonblocking assignment.

 

[parag_paul@hotmail.com]

On Mar 20, 7:19 am, sh...@cadence.com wrote:

On Mar 18, 7:52 am, "parag_p...@hotmail.com" <parag_p...@hotmail.com
wrote:



WE are having some simulation differences between rtl and gatelevel
when we run a design with gatelevel verilog.

There are some delays in the UDP's generated in the gate level. You
can see the UDP with a delay.

I would guess that the delay was added to avoid problems due to zero-
delay race conditions.

In RTL code, flip-flops are commonly written using nonblocking
assignments, which gives the output a delay greater than any clock
skew due to ordinary zero-delay logic.  If your gate-level design uses
zero-delay UDPs for the flip-flops, that delay is the same as any
other kind of zero-delay logic.  That means you can have race
conditions appear in the gate-level simulation that were not in the
RTL simulation.  For example, a value might get through two levels of
pipeline registers in a single clock, because the output of the first
changes before the second one evaluates.

There is no equivalent in a UDP to the special delay that nonblocking
assignments use, that is zero but greater than any normal zero delay.
The only way to give it a delay greater than any normal zero delay is
to use a non-zero delay.  So there is no way to make your UDP match
the zero delay of the RTL simulation without potential problems due to
race conditions.

You could go the other direction and make your RTL simulation match
the unit delay of the gate-level simulation.  Just add a #1 delay to
the RHS of all your nonblocking assignments.  That could be a pretty
major change, but you might be able to do it with a simple global
replacement using an editor or script.

Alternately, you could replace the UDP with a behavioral version that
has the same basic behavior, but uses a nonblocking assignment.

In line with all the above discussion
I am yet to understand the need to back annotation of delays ?
Is it to make the gatelevel behave similar to the RTL
because delays are introduced and everything starts behaving different
-Parag

 

[Mike Treseler]

parag_paul@hotmail.com wrote:

In line with all the above discussion
I am yet to understand the need to back annotation of delays ?
Is it to make the gatelevel behave similar to the RTL
because delays are introduced and everything starts behaving different

For a synchronous design using well tested design rules,
a gate level simulation is more of a process check
than a design verification.

Running an rtl simulation and static timing
tests the design throughly and relatively quickly.
A gate simulation covers the more unlikely errors
contributed by synthesis or my design rules.
A gate sim with delay annotation might find
an error in timing constraints or in my testbench.

-- Mike Treseler