( ESNUG 144 Item 1 ) ---------------------------------------------- [8/93]
From: [ Anonymous ]
Subject: Bug in Inferring Latches with Asynchronous Clear and/or Preset
John,
Please keep me anonymous on my email. By the way, thanks for the
excellent job you are doing with ESNUG. I have picked up several pointers
from your EMAILs and hopefully, the interaction will help "light a fire"
under Synopsys to improve the quality of their code. We seem to get bitten
by what would appear to be simple problems to address with the proper focus.
Synopsys seems to be focusing on future releases and not on supporting or
improving problems that have been around. It also appears that their code
is possibly somewhat "spaghetti" when I hear of the many weird problems
reported.
Anyway, here's the bug I'm seeing with v3.0a-10063...
I have reported problems in the past relating to inferring D latches
with asynchronous clear and/or reset from verilog HDL to Synopsys and it
appears they have made some changes to the algorithm but have failed to fix
the problem correctly. With the 2.2b release, the following verilog HDL:
always @(DA or RESETZ or LATZA)
begin
if (!RESETZ) QA <= #1 1'b0;
else if (LATZA) QA <= #1 DA;
end
would result in a simple D latch with the asynchronous clear operation
performed by gating the D input low and forcing the latch into a transparent
state. This is "bad" logic since there is an inherent race condition created
when the reset input is deasserted.
The user was forced to hard instantiate an D latch with an asynchronous
clear:
LATC ILST1 (.Q(QA), .D(DA), .LATZ(LATZA), .CLRZ(RESETZ) );
With release 3.0a-10063, this behavior has been changed and a LATC is
inferred correctly in some cases. However, depending on how the HDL is
written, the tool will revert to its old bad habits of inferring a simple
D latch and steering D and the latch enable appropriately. For example;
the following code fragment will result in LATC elements:
always @ (wr or data_bus or reset_z)
begin
if (!reset_z)
begin
lat[5:0] = 6'h00;
end
else if (wr)
begin
lat[5:0] = data_bus[5:0];
end
end
This results in 6 LATC cells which is the desired result. Now, if the code
is changed slightly to:
always @ (wr or data_bus or reset_z)
begin
if (!reset_z)
begin
lat[7] = 1'b0; /* Added lat[7] here! */
lat[5:0] = 6'h00;
end
else if (wr)
begin
lat[7] = data_bus[7]; /* Added lat[7] here! */
lat[5:0] = data_bus[5:0];
end
end
Synopsys resorts to its old bad logic and creates 7 D latches without
asynchronous clear and steers the logic on the D and latch enble inputs.
Is there a workaround other than: ?
1) instantiate gate level cells (LATC in this case). Drawback is
lack of technology independence. Can/will Synopsys choose a
higher drive cell LATC (ie. a LATCX2) to meet timing constraints
if needed?
2) I can use a flip-flop with asynchronous reset but of course
the size is larger than a D latch with asynchronous clear and
the behavior difference is not always acceptable.
On a similar note, inferring a D latch with both asynchronous clear and
preset seems to always result in a D latch with the clear and preset logic
steering the D and latch enable inputs. This is a bug as well.
- [ An Anonymous User ]
( ESNUG 144 Item 2 ) ---------------------------------------------- [8/93]
From: mike@wv.MENTORG.COM (Mike Walsh)
To: hotline@synopsys.com, jcooley@world.std.com
Subject: Synopsys/Mentor Falcon Framework Integrator
I just returned from one of my customers who just installed Synopsys v3.0b
with the Falcon Framework integraror. Everything seems to be okay with
exception of actually invoking the Synopsys application from the Mentor
Design Manager application.
Has anyone experienced this problem? When I try to bring up dc_shell it
tries to execute a shell script that does not exist. This is true for three
applications that I tried. I was not involved when the previous version
(v3.0a) was installed so I don't know much about the past history.
- Michael P. Walsh
Application Engineer
Mentor Graphics Corporation
( ESNUG 144 Item 3 ) ---------------------------------------------- [8/93]
Subject: ( ESNUG 141 #1 ) "Inconsistant References Problem During Synthesis"
>> I am having a lot of problems synthesizing a particular design. I get the
>> following message:
>>
>> Error: Inconsistent references found for cell '*SELECT_OP_1_1_1'. (OPT-205)
>
>You probably have a dont_touch_network on your async reset pin... The
>dont_touch_network causes synopsys to have problems in the mapping phase,
>but will eventually map to the desired flip flops... If you remove the
>dont_touch_network, you probably won't get the error.
From: bobv@hwcae.az.honeywell.com (Bob Valicenti)
Dear John,
I was mistaken!! I confused the error this person got with another one that
Synopsys often gives which would have been :
Error: dont_touch found for cell '*SELECT_OP_1_1_1'. (OPT-205)
Sorry about the messup!!!
- Bob Valicenti
Honeywell Commercial Flight
[ Editor's Note: Not too long ago I posted a little problem I had with "rm"
and "*" that made life a little interesting. Mistakes happen. ESNUG is
an electronic magazine where Synopsys users and the Synopsys technical
staff can meet to discuss issues -- not every word uttered here is going
to be "correct" -- we're shooting at a continually moving target. Thanks,
though, Bob, for following up on this. - John Cooley, the ESNUG guy ]
( ESNUG 144 Item 4 ) ---------------------------------------------- [8/93]
Subject: ( ESNUG 143 #3 ) "Characterized Submodules Inherit Big Wire Models"
> Do you know why the characterize function places the top module's wire
> load module on the cell you're characterizing?? This seems wrong to me.
> It means that if I have a 40K gate die size on the top level, and I
> characterize a 100 gate sub-module, that sub-module ends up with delays
> for the 40K gate die! I have been undoing this "feature" after every
> characterize (big pain in the butt). Any suggestions?
--- --- ---
From: jefff@mars.sps.mot.com (Jeff Freeman)
To paraphrase the man page:
When no wire_load_model_mode is specified, a default wire_load_model_mode
is sought in the first library in the link path during compile. If the
library does not have a default, the top-level wire load model is used to
compute wire capacitance for all hierarchical or top-level nets is used.
I believe eventually you don't want to continue using this default
wire load mode. It is just for initial synthesis estimates until
the user takes the time to create more than one wire load model in which
the segmented or enclosed mode of wire load mode may be used.
When characterize is run, the subdesign will get the parent's wire
load if the wire load mode is "top".
- Jeff Freeman
Motorola
--- --- ---
From: [ Anonymous ]
John, please eliminate my name and company from this post. Thanx.
Synopsys has 3 modes for wire loads: top, enclosed, and segmented.
top: Wire load of the top-level is used for all levels.
This is the default unless the library specifies otherwise.
enclosed: The wire load model of the smallest design that
encloses a net completely is used for that net.
segmented: The net is broken into segments, one segment within
each hierarchical design.
Use the command "set_wire_load -mode enclosed" or "set_wire_load -mode
segmented" to cause characterize to assign the proper wire_load to sub
modules.
- Anonymous
|
|
