Strange Netlist Simulation Bug

P

pallav

Guest
I'm observing a strange netlist simulation problem. I can't seem to
locate the source of the problem so I'm looking for some ideas.

The verilog code is posted here: http://www.pastey.net/125273

It is basically the fetch stage which computes the PC address for
fetching instructions. At reset, the PC should be set to BFC00000. The
RTL code simulates fine. I synthesize it using DC Compiler.

I try simulating the netlist with my testbench. Here is the simulation
waveform: http://imagebin.ca/view/zd3qw0th.html

I'm using a synchronous active-high reset for all my blocks. When
reset is high, PC should get set to BFC00000. All of the bits get set
except pcF[2] which stays at X. I don't understand why this is
happening. I've examined the RTL code and it looks OK to me.

Looking at the synthesis report, there are no latches in the design
and pcF is correctly inferred as a flip-flop:
Inferred memory devices in process
in routine fetchU line 650 in file
'/home/pgupta/cad/mips32/src/mips32.v'.
===============================================================================
| Register Name | Type | Width | Bus | MB | AR | AS | SR |
SS | ST |
===============================================================================
| pcF_reg | Flip-flop | 9 | Y | N | N | N | N |
Y | N |
| pcF_reg | Flip-flop | 23 | Y | N | N | N | Y |
N | N |
===============================================================================

I've flattened the entire hierarchy for synthesis but I don't see how
that should affect pcF[2]. Does any body have any ideas what could be
wrong or things I can test out?

Thanks.

Kind regards.
 
pallav wrote, On 09/16/09 11:43:
I'm observing a strange netlist simulation problem. I can't seem to
locate the source of the problem so I'm looking for some ideas.

The verilog code is posted here: http://www.pastey.net/125273

It is basically the fetch stage which computes the PC address for
fetching instructions. At reset, the PC should be set to BFC00000. The
RTL code simulates fine. I synthesize it using DC Compiler.

I try simulating the netlist with my testbench. Here is the simulation
waveform: http://imagebin.ca/view/zd3qw0th.html

I'm using a synchronous active-high reset for all my blocks. When
reset is high, PC should get set to BFC00000. All of the bits get set
except pcF[2] which stays at X. I don't understand why this is
happening. I've examined the RTL code and it looks OK to me.

Looking at the synthesis report, there are no latches in the design
and pcF is correctly inferred as a flip-flop:
Inferred memory devices in process
in routine fetchU line 650 in file
'/home/pgupta/cad/mips32/src/mips32.v'.
===============================================================================
| Register Name | Type | Width | Bus | MB | AR | AS | SR |
SS | ST |
===============================================================================
| pcF_reg | Flip-flop | 9 | Y | N | N | N | N |
Y | N |
| pcF_reg | Flip-flop | 23 | Y | N | N | N | Y |
N | N |
===============================================================================

I've flattened the entire hierarchy for synthesis but I don't see how
that should affect pcF[2]. Does any body have any ideas what could be
wrong or things I can test out?

Thanks.

Kind regards.
Click to expand...
You may want to check out your netlist and trace back the 'd' input of
the flop. What can happen is that you have a convergent path of the true
and complement of a signal which is 'x'. For example 'a & ~a'. In real
H/W 'a' is either 0 or 1, so the output will always be 0; in simulation
the result is 'x'; and it this 'x' that can propagate into the 'd' input
of the flop even when reset is asserted.

Some synthesis tools have directives to make sure that the reset is
close the the 'd' input of the flop and not moved deep into the logic cone.

Regards, Jurgen.
 
On Sep 16, 9:06 pm, Jurgen Schulz <jurgen.sch...@sun.com> wrote:
pallav wrote, On 09/16/09 11:43:



I'm observing a strange netlist simulation problem. I can't seem to
locate the source of the problem so I'm looking for some ideas.

The verilog code is posted here:http://www.pastey.net/125273

It is basically the fetch stage which computes the PC address for
fetching instructions. At reset, the PC should be set to BFC00000. The
RTL code simulates fine. I synthesize it using DC Compiler.

I try simulating the netlist with my testbench. Here is the simulation
waveform:http://imagebin.ca/view/zd3qw0th.html

I'm using a synchronous active-high reset for all my blocks. When
reset is high, PC should get set to BFC00000. All of the bits get set
except pcF[2] which stays at X. I don't understand why this is
happening. I've examined the RTL code and it looks OK to me.

Looking at the synthesis report, there are no latches in the design
and pcF is correctly inferred as a flip-flop:
Inferred memory devices in process
        in routine fetchU line 650 in file
                '/home/pgupta/cad/mips32/src/mips32.v'.
==============================================================================> > |    Register Name    |   Type    | Width | Bus | MB | AR | AS | SR |
SS | ST |
==============================================================================> > |       pcF_reg       | Flip-flop |   9   |  Y  | N  | N  | N  | N  |
Y  | N  |
|       pcF_reg       | Flip-flop |  23   |  Y  | N  | N  | N  | Y  |
N  | N  |
==============================================================================
I've flattened the entire hierarchy for synthesis but I don't see how
that should affect pcF[2]. Does  any body have any ideas what could be
wrong or things I can test out?

Thanks.

Kind regards.

You may want to check out your netlist and trace back the 'd' input of
the flop. What can happen is that you have a convergent path of the true
and complement of a signal which is 'x'. For example 'a & ~a'. In real
H/W 'a' is either 0 or 1, so the output will always be 0; in simulation
the result is 'x'; and it this 'x' that can propagate into the 'd' input
of the flop even when reset is asserted.

Some synthesis tools have directives to make sure that the reset is
close the the 'd' input of the flop and not moved deep into the logic cone.

Regards, Jurgen.
Click to expand...
Hi Jurgen,

Thanks for this insight. I looked at the netlist in detail and was
able to track down the problem to these three gates:

MUX21X2 U12831 ( .IN1(n11344), .IN2(n7489), .S(n6936), .Q(n11309) );

NAND4X0 U12833 ( .IN1(n11309), .IN2(n11308), .IN3(n11307), .IN4
(n11306),
.QN(n72) );

DFFX2 datapath_fu_pcF_reg_2_ ( .D(n72), .CLK(clk), .Q(pcF[2]), .QN
(n6936) );

The Qbar of the pcF[2] flop is being used a select signal to the MUX.
So at start time, pcF[2] is X, hence Qbar is X, which makes the output
of the MUX/NAND be X and thus, the input to the flop is always X even
if reset is asserted.

I'm using synchronous resets. I had added the "// synopsys
sync_set_reset "reset" directive but that doesn't seem to help. From
the netlist, it seems like the synchronous reset has moved very far
out of the logic cone. I will have to look at the documentation for
ways to fix/resolve this.

Not sure why DC Compiler is generating this type of a feedback only
for pcF[2] and not for the other bits in the pcF flop.

Thanks for your help.

Kind regards.
 
pallav wrote, On 09/16/09 21:06:
On Sep 16, 9:06 pm, Jurgen Schulz <jurgen.sch...@sun.com> wrote:
pallav wrote, On 09/16/09 11:43:



I'm observing a strange netlist simulation problem. I can't seem to
locate the source of the problem so I'm looking for some ideas.
The verilog code is posted here:http://www.pastey.net/125273
It is basically the fetch stage which computes the PC address for
fetching instructions. At reset, the PC should be set to BFC00000. The
RTL code simulates fine. I synthesize it using DC Compiler.
I try simulating the netlist with my testbench. Here is the simulation
waveform:http://imagebin.ca/view/zd3qw0th.html
I'm using a synchronous active-high reset for all my blocks. When
reset is high, PC should get set to BFC00000. All of the bits get set
except pcF[2] which stays at X. I don't understand why this is
happening. I've examined the RTL code and it looks OK to me.
Looking at the synthesis report, there are no latches in the design
and pcF is correctly inferred as a flip-flop:
Inferred memory devices in process
in routine fetchU line 650 in file
'/home/pgupta/cad/mips32/src/mips32.v'.
===============================================================================
| Register Name | Type | Width | Bus | MB | AR | AS | SR |
SS | ST |
===============================================================================
| pcF_reg | Flip-flop | 9 | Y | N | N | N | N |
Y | N |
| pcF_reg | Flip-flop | 23 | Y | N | N | N | Y |
N | N |
===============================================================================
I've flattened the entire hierarchy for synthesis but I don't see how
that should affect pcF[2]. Does any body have any ideas what could be
wrong or things I can test out?
Thanks.
Kind regards.
You may want to check out your netlist and trace back the 'd' input of
the flop. What can happen is that you have a convergent path of the true
and complement of a signal which is 'x'. For example 'a & ~a'. In real
H/W 'a' is either 0 or 1, so the output will always be 0; in simulation
the result is 'x'; and it this 'x' that can propagate into the 'd' input
of the flop even when reset is asserted.

Some synthesis tools have directives to make sure that the reset is
close the the 'd' input of the flop and not moved deep into the logic cone.

Regards, Jurgen.

Hi Jurgen,

Thanks for this insight. I looked at the netlist in detail and was
able to track down the problem to these three gates:

MUX21X2 U12831 ( .IN1(n11344), .IN2(n7489), .S(n6936), .Q(n11309) );

NAND4X0 U12833 ( .IN1(n11309), .IN2(n11308), .IN3(n11307), .IN4
(n11306),
.QN(n72) );

DFFX2 datapath_fu_pcF_reg_2_ ( .D(n72), .CLK(clk), .Q(pcF[2]), .QN
(n6936) );

The Qbar of the pcF[2] flop is being used a select signal to the MUX.
So at start time, pcF[2] is X, hence Qbar is X, which makes the output
of the MUX/NAND be X and thus, the input to the flop is always X even
if reset is asserted.

I'm using synchronous resets. I had added the "// synopsys
sync_set_reset "reset" directive but that doesn't seem to help. From
the netlist, it seems like the synchronous reset has moved very far
out of the logic cone. I will have to look at the documentation for
ways to fix/resolve this.

Not sure why DC Compiler is generating this type of a feedback only
for pcF[2] and not for the other bits in the pcF flop.

Thanks for your help.

Kind regards.
Click to expand...
Looks like you are already using the correct directive. You might also
try setting 'hdlin_ff_always_sync_set_reset' to true before you read in
your RTL. If this does not help, then simply force the problem net to a
random 0 or 1 for a few cycles when reset is asserted; this will allow
you to simulate. You can then use an equivalence checking tool to prove
that gates==RTL.

Regards, Jurgen.
 
DFFX2 datapath_fu_pcF_reg_2_ ( .D(n72), .CLK(clk), .Q(pcF[2]), .QN
(n6936) );

Shouldn't it pick up a flop with reset ? Something like -

DFFX2 datapath_fu_pcF_reg_2_ ( .D(n72), .CLK(clk), .R(reset), .Q(pcF
[2]), .QN(n6936) );

Plus there should have been an enable signal which is missing.

Kauser.
 
On Sep 18, 8:31 am, Kauser <kauser.jo...@gmail.com> wrote:
), .QN
(n6936) );

Shouldn't it pick up a flop with reset ? Something like -

DFFX2 datapath_fu_pcF_reg_2_ ( .D(n72), .CLK(clk), .R(reset), .Q(pcF
[2]), .QN(n6936) );

Plus there should have been an enable signal which is missing.

Kauser.
Click to expand...
All (except one) the DFFs in my cell library are asynchronous set/
reset. The one DFF that has a sychronous set/reset is active-low. I'm
going to try to change the code around to see if DC compiler can pick
up on active-low reset. With active-high synchronous reset, its seems
to just treating that as a ordinary input rather than inverting it and
feeding it to the synch reset DFF.

I can report however that I was able to get my netlist to simulate
properly after using force/release on two nets. The second problematic
net was on a 6 bit flop. 5 bits were being set to 0, while one was
showing up as X. I again had the feedback problem on this net.

Also there is no enable signal on the flop in the cells. So a mux
would be necessary for the D input.

I guess for my next design example, I'll just use asynchronous resets
with synchronous deassertion. Thanks for the help.

Kind regards.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top