( ESNUG 140 Item 1 ) ---------------------------------------------- [8/93]
From: Synopsys Quality Engineering Group
Subject: Corrupt Synopsys Interface to Falcon Framework (SIFF) Executables
The release version of the v3.0b CD ROM contains corrupt versions of several
SIFF executables for the HP700 platform. The result is that HP700 SIFF
customers will receive a v3.0b CD ROM along with a DAT tape.
The release notes will instruct them to load the release CD ROM, then
overlay (load) the contents of the DAT tape.
Once again, this only affects customers using SIFF with Mentor 8.2 on the
HP700 platform. The Sparc and Apollo versions are unaffected.
( ESNUG 140 Item 2 ) ---------------------------------------------- [8/93]
From: Pradeep Chilka <deep@ole.cdac.com>
Subject: Oops & Datapath Synthesis using DesignWare
> Aaaaaargh! I just managed to save all my incoming ESNUG mail
> to one file and then, in a moment of extreme stupidity, accidently
> removed that file using wildcard operators and "rm" !!! Aaaaargh!
Timely reconfirmation for someone who was considering writing a "rm" script
that would stash a file into a garbage directory instead of removing
it. Thanks. :-)
On a more serious note, is anyone out there using the Synopsys DesignWare
for datapath synthesis where the datapath is netlisted by an external
module compiler? I would be interested in hearing their experiences.
- Pradeep Chilka
Cascade Design Automation Corp.
( ESNUG 140 Item 3 ) ---------------------------------------------- [8/93]
Subject: (ESNUG 134 # 5 & ESNUG 136 #3 ) "Modelling Muxes"
>>I'm having trouble trying to specify the function for a decode-mux cell.
>>The function is:
>>
>> a & ( sa & !sb & !sc & !sd) | b & (!sa & sa & !sc & !sd) |
>> c & (!sa & !sa & sc & !sd) | d & (!sa & !sa & !sc & sd)
>>
>>I need to convey the illegal states of 0 selects high and more than 1
>>select high.
>As a matter of fact, I have never seen Synopsys actually use a mux with
>individual selects, it usually selects AOI's instead (which is really the
>same thing anyway). My assumption is that the functional descriptions for
>these cells is so complicated that it is hard for Synopsys to map to them.
>I believe that the minimum coverage algorithms that are used by Design
>Compiler are better suited to simpler logic functions.
From: brad@hdls.COM (Brad Eltman)
We were once synthesizing a R3000A processor with a library that had a
2 to 1 mux with an unbuffered select line (that is, a select and select
bar.) Synopsys 2.2a (at that time) was clever enough to use this mux
as a logic gate for some kind of complex function (which we never
bothered to figure out) which of course caused the gate level simulations
to go unknown. That was because the gate level model was done correctly
such that when select and select bar were the same logic value the
output would go X. If the simulaton model was not done correctly this
part could have gone to fab!
There is an inherent danger with Synopsys and Espresso to take advantage
of any complex logic gate including tristate muxes, especially since the
gate count for this logic function will be very low and the Synopsys cost
function will see this as very good.
- Brad Eltman
HDL Systems Corp.
( ESNUG 140 Item 4 ) ---------------------------------------------- [8/93]
From kchung@synopsys.com (Kevin Chung)
Subject: ( ESNUG 138 Item 2) "CMOS modelling & characterize"
>When I try to generate a loading constraint file using the "characterize"
>followed by "write_script" commands, the file generated contains statements
>of the form:
>
> "set_load -pin....." and
> "set_load -wire...."
>
>But this is not correct since I am using a CMOS technology; and for CMOS
>it is not supposed to split it into pin & wire loads. (Incidentally, the
>same script generated the correct statements in Synopsys 2.2b!)
As mentioned, there is a problem with command line accessible man (help)
pages and the printed documentation. This information was forwarded to me
from a Synopsys R&D person supporting Design Compiler.
"In the ESNUG posting 138 Item 2, the user seems to have run into a known
documentation mistake in v3.0a. The mistake is in the man-page for
set_load. That man-page incorrectly states that the -wire option of
set_load is reserved for ECL technologies. That is in not true, and
it has been corrected in the latest man-page revision. CMOS designers
can use both the -pin and -wire options of the set_load command. The
two options allow designers to be more specific about how the load on
the output port is distributed between pin-load and wire-load. For CMOS
technologies, it doesn't matter if the designer splits up the load or just
lumps it all into pin-load. In either case, the characterize command is
behaving correctly."
In v2.2, there was no -wire option. That's why the user saw a difference
from v2.2 to v3.0.
I have verified that the v3.0b release man-page has been corrected.
While on the subject, did you know that the Design Compiler Command Reference
Manual "man-pages" are directly accessible from the dc_shell command line and
Design Analyzer command window? Just type "help command_name" where
command_name is the Design Compiler command you want the manpage for and
it will appear.
-Kevin Chung
Synopsys, Inc.
( ESNUG 140 Item 5 ) ---------------------------------------------- [8/93]
From: John Vogel <RYGK80@WACCVM.corp.mot.com>
Subject: TestCompiler STAR 13632, Floating Tie Macros
John, Standard Cell designs typically have macros for internal tie offs;
logic 0 or 1. We use a special variable to ensure that the synthesized
design's Verilog netlist does not contain continuous assignments for
these internal ties:
"compile_fix_multiple_port_nets=true"
We have had problems where sometimes a tie macro output is left floating and
it's destination pin tied to 1'b0 or 1'b1; a big problem for the physical
design process.
I have just been informed that this problem is now a bug, STAR 13632. The
problem occurs when insert_test is performed in a design prior to ATPG. The
Synopsys hotline, has come up with a tempory fix. Prior to running
insert_test, place dont_touchs on the tie macros and their output nets.
Here is the hot line script: (cudos to Michael Albrecht, Synopsys AE)
filter find(cell,"*") "@ref_name == VDDTIE"
vdd_list = dc_shell_status
foreach(member,vdd_list) {
list member
temp = member + "/*"
all_connected temp
net_list = dc_shell_status
dont_touch find(cell,member)
dont_touch find(net,net_list)
}
I have not tested this script, but it makes sense. Also, I would place the
script within another loop that works on all designs automatically.
- John Vogel
Motorola ASIC
( ESNUG 140 Networking Section ) ---------------------------------- [8/93]
Orange County, CA, ASIC Designer experienced with Synopsys, VHDL & processor
design. Exprncd project manager. jima@leo.irv.icl.com (714)458-7282 x4285
|
|
