( ESNUG 145 Item 1 ) ---------------------------------------------- [8/93]
Subject: (ESNUG 144 #2) "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.
--- --- ---
From: mike@wv.MENTORG.COM (Mike Walsh)
Following up on this issue the problem was that "install_dc" was never
run! We (myself and the customer) were under the impression that when
the Synopsys applications were installed off the CD the installation was
complete. Not so ... RTFM ;-)
- Michael P. Walsh
Mentor Graphics Corporation
--- --- ---
From: [ Anonymous ]
John.
Please keep this anonymous.
It sounds as if this is the same problem that we had on our systems. To
fix it we had to update the Mentor location map files to point to the new
version of the Synopsys tools. We saw this when trying to run db2eddm
(one of the framework integrator tools). You will be able to tell if you
get the proper map to the new tools, because the popup window that appears
is very different in v3.0b than it was in v3.0a.
The Hotline guy who handles Synopsys hotline framework integrator questions
could not give us an exact answer when we reported this problem, but he did
give us enough clues to help us get it figured out. We reported back
to him how we resolved the problem, so if it is the same problem the
hotline should have the answer.
- Anonymous
--- --- ---
From: [ Let Someone Else Find The Bugs! ]
I would like this to be from "Let Someone Else Find The Bugs"!
We've had big headaches trying to use 3.0a and 3.0b VHDL libraries with
Mentor and the Synopsys Falcon Framework Integrator. This has been very
frustrating because Synopsys's special Frameworks install was _supposed_
to make using Mentor _easier_ to use instead of presenting yet _another_ set
of software challenges to overcome. (There have been problems from both the
Synopsys and Mentor sides of this install.) After a _lot_ of spinning our
wheels, we are now using Synopsys as a point tool to minimize interaction
issues with Falcon. My gripe is why couldn't have these bugs been worked
out cooperatively between Synopsys and Mentor instead of having the customers
left on their own to deal with these integration headaches?
- Let Someone Else Find The Bugs!
( ESNUG 145 Item 2 ) ---------------------------------------------- [8/93]
Subject: (ESNUG 144 #1) "Bug Inferring Latches w/ Asynch Clear and/or Preset"
> 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.
--- --- ---
From: vlsiphx!karoshi!fitzs_m@enuucp.eas.asu.edu (Mike Fitzsimmons)
i will add:
3) Do not use bit vector slices in your inference and everything
will be o.k. - i.e. if you need to put a [x:y] or a [x downto y] (VHDL)
in your process - DON'T! -- make signals and reassign accordingly.
- Mike Fitzsimmons
VLSI Technology
--- --- ---
From: kavi@cirrus.com (H. Nimishakavi)
I experienced exactly the same behavior in the inferring of D Latches. Once
I realized that the inferring of the latches (with asynchronous clear) was
dependent on the way code was written, I tried different ways of coding and
found the following way that worked for me without instantiation or use
of ff with async reset. Here is my example.
reg [7:0] lat; // lat is 8 bit wide
reg [7:0] data_out;
wire [7:0] data_bus = data_out;
always @ (wr or data_bus or reset_z)
begin
if (!reset_z)
lat[7:0] <= #1 8'h00; // All 8 bits are initialised
else if (wr)
begin
lat[7] <= #1 data_bus[7]; // Bit 6 is not used
lat[5:0] = #1 data_bus[5:0];
end
end
always @ (rd or data_bus )
if (rd)
data_out = {lat[7],1'b0, lat[5:0]};
else data_out = 8'hz;
Synopsys optimization removes the unused latch at bit 6. The resulting 7
latches have asynchronous reset.
- Kavi H. Nimishakavi
Cirrus Logic, Inc.
--- --- ---
From: dan@emulex.com (Dan Pinvidic)
Why not create two separate "always" blocks for bit 7 and bit[5:0] ?
I have heard that the compiler looks for certain "patterns" in the HDL code
and creates structures accordingly.
Another trick I have used in the past has been to define the RESET term as
opposite (set_opposite cmd) to the DATA if these are ports into the module.
- Dan Pinvidic
Qlogic Corp.
P.S. John, ESNUG is EXTREMELY helpful for "up to date" info. Thanks!
( ESNUG 145 Item 3 ) ---------------------------------------------- [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?
> 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".
From: greg@cqt.com (Greg Bell)
I am using the enclosed mode. Unfortunately, with my libraries I cannot
set the wire load model to none (it picks a default wire load model
with no wire delay and never replaces it). Therefore I am forced to
set the wire delay on each level by hand. Not a problem except when
Synopsys overwrites it when I characterize.
I guess I didn't make it clear that I was NOT using the default wire
load model. That is, I'm saying that Synopsys during "characterize" is
overwriting the wire load model I had originally selected for the sub-design!
Bad!
- Greg Bell
CommQuest Technologies, Inc.
( ESNUG 145 Item 4 ) ---------------------------------------------- [8/93]
From: schooler@boilerbob.corp.mot.com (Tony Schooler)
Subject: I Always Get Latches With Sync RESET Instead of Async RESET in 3.0b
I was wondering if anybody else out there is having problems with v3.0b
generating latches with async. resets. I have the following test case:
module rst (d,rst,clk,q);
input d; // data input to latch
input rst; // async reset to latch
input clk; // clock for lath
output q; // output of latch
reg q;
always @(d or rst or clk)
begin
if (rst) q = 1'b0;
else if (clk) q = d;
end
endmodule
I set the following variable: hdlin_latch_sync_set_reset="FALSE" I always
seem to get a latch with an sync reset. Is there any way with v3.0b to
force an async reset?
- Tony Schooler
Motorola AIEG
( ESNUG 145 Item 5 ) ---------------------------------------------- [8/93]
From: jcooley@world.std.com (John Cooley)
Subject: Cadence Verilog-XL 1.6c.5 "-y" Option Doesn't Seem To Work
I was at a client site trying to do a chip release and I had to verify the gate
level functionality of my Synopsys output by simulating with Cadence Verilog-XL
1.6c.5 on a sparc10.
I got lots o' "can't resolve reference NOR2, NAND3,..." errors when I used
the Verilog invocation:
>verilog design.v test_fixture.v -y /usr/asic/lib
where in the directory "/usr/asic/lib" contained all the individual Verilog
ASIC libraries and each library element fits the naming convention
"NOR2.v", "NAND3.v", etc. One uses the "-y" option in Verilog to point to
your library directory and Cadence Verilog is *supposed* to be able to resolve
references to each of these separate library models in the directory because
they follow the expected file naming convention of "MODEL.v"
After some thrashing around, I found that the workaround for this problem
is during invocation to use the +libext+ option as follows:
>verilog design.v test_fixture.v -y /usr/asic/lib +libext+.v+
Mind you that this is no earth shattering bug, just an annoyance and
its workaround.
- John Cooley
EDA & ASIC Design Consultant
(and ESNUG Moderator, too!)
|
|
