Yesterday, 1/5th of the world's population, a little over 1 billion people,
celebrated Chinese New Year. This marked the beginning 4693, the Year Of
The Pig in Chinese astrology. It's supposed to be one of happiness & good
fortune in what you're currently working on -- but not good for starting new
endeavors. How do I know this? Well, I *am* a Cooley you know... :^)
- John Cooley
(plus I read the Boston Globe newspaper!) the ESNUG guy
( ESNUG 209 Item 1 ) ---------------------------------------------- [2/1/95]
Subject: (ESNUG 205 #5 206 #2 207 #4 208 #2) Synopsys->Mentor w/ "db2eddm" Sucks
>When we asked both Mentor & Synopsys about going from EDIF to EDDM, the
>answer was a definite "NO". We have encountered some problems with the
>db2eddm path (nets crossing bus rippers that were shorted in Mentor and not
>in Synopsys, etc.) Do you have any suggestions from any of your readers?
From: jco@egnetz.uebemc.siemens.de (Jon Connell)
John,
This used to be a major problem for us and meant that we had to upgrade to
the newest Design Compiler release as it became available. Since we started
using v3.2a to create our schematics, we've had no problems whatsoever! You
have to be careful if you're using an earlier Design Compiler release not to
create schematics since the earlier releases can break your sheets. Here's
the script I use to create my schematics:
echo_include_commands = "false"
single_group_per_sheet = "true"
bus_naming_style = "%s(%d)"
bus_range_separator_style = ":"
gen_cell_pin_name_separator = "_"
gen_match_ripper_wire_widths = "true"
suppress_errors = suppress_errors + { "NMA-16", "NMA-14" }
change_names -rules siff -hierarchy
create_schematic -hierarchy -rip_same_width -no_type_mappers -size infinite
The name rule "siff" is defined in $SYNOPSYS/admin/setup/.dc_name_rules as:
define_name_rules siff -special siff -collapse_name_space \
-replacement_char "_" \
-case_insensitive -max_length 29 \
-allowed "A-Z a-z _ 0-9 ()" \
-first_restricted "_ 0-9" -last_restricted "_"
Most of the problems in the earlier releases were Design Compiler defects and
they seem to be fixed now. Schematics are insanely complicated beasts so
there's still a chance that a design will break the schematic generator. If
it does, choosing a different sheet size or sorting the outputs will usually
fix the problem as this forces the generator to create the schematic
differently.
- Jon Connell
Siemens IC Design Center, Munich, Switzerland
( ESNUG 209 Item 2 ) ---------------------------------------------- [2/1/95]
From: [ Anon. ]
Subject: Synopsys/Mentor Interaction Causing Shorts On The *SAME* Bus
Hi John!
We've never met but I feel I know ya after cruising through the ESNUG
postings. Just for grins (or at least until I clear it with my boss)
ya better keep me anonymous also.
From what I understand concerning the Mentor/Synopsys interface people are
talking about a "physical" short that occurs because Mentor and Synopsys
handle bus rippers differently. When the schematic is transferred across, it
is not in a "netlist" format but in a graphical format (i.e. Draw line from
point A to point B. Place ripper at location x,y. Draw line from C to D).
If line CD happens to intersect the end of the ripper (which are sometimes
different sizes in the two libraries) Mentor treats it as a short.
The problem that I am having is not as subtle. When I run change_names with
the rules that are spelled out in the answer that I got back from SolvIt,
change_names actually "Warns" me that it is changing bus members. It seems
that if there are any unused bits in the bus it shuffles the other bits "up"
to fill in the gaps. Thus, if you have a bus A(1:0) and within the block
only use A(0) it "changes" the net name of the net after the ripper to A(1).
Then it realizes that A(1) already exists and so it, using its naming
convention, appends a 1 on the end of the name so as to make it unique, thus
you have A(1)1. So on one side of the ripper you have A(1:0) and on the
other A(1)1. Of course, Mentor looks at the name, sees the closed parenthesis
and says "Ah ha!, I have a schematic that has on one side of a ripper A(1:0)
and on the other A(1) but the "rule" property on the ripper is specifying
that this is bit 0. Therefore, there is a short between A(1) and A(0)!
BTW, I am using 3.1b (historic reasons; not due to any loyalty) and sent a
test case that displays this action to the Synopsys support center. Also my
"local" AE came up with a workaround which is to define a second set of name
rules that contains only the rule equal_port_nets (which is in the original
rule set). Running change_name a second time using this second rule set
magically "straightens" things out but I am not impressed. I want to know
what it is doing.
- [ Anon. ]
( ESNUG 209 Item 3 ) ---------------------------------------------- [2/1/95]
Subject: (ESNUG 208 #0) Synopsys's Upcoming Fancy New Product Announcement
sogle@cti-main.mhs.compuserve.com (Sean Ogle) writes:
>
> John, could you send out the where/when details of Synopsys's fancy new
> product announcement this upcoming Tuesday, Feb. 7th.
>
> - Sean Ogle
From: ljen@Synopsys.COM (Jennifer Law)
John, the new product briefing is happening at Techmart in Santa Clara from
3 to 6 PM. The breakout is as follows: 30 minutes intro & refreshments, 40
minutes overview, two 15 minute live demos, followed by letting people mix
between hands-on using the new tools and/or attending the cocktail party.
For anyone wishing to attend can either e-mail me at "ljen@synopsys.com" or
phone at (415) 694-1953 and I'll sign them up.
- Jennifer Law
Synopsys Marketing Communications
( ESNUG 209 Item 4 ) ---------------------------------------------- [2/1/95]
Subject: (ESNUG 206 #4 208 #3) Set_Driving_Cell IS A Useless Command
> What you would expect is set_driving_cell compile the block assuming that
> the input port is being driven by the specified cell and that ALL of the
> rules pertaining to that cell would be considered during optimization. (It
> turns out that this is not at all the case.) The only thing that the cell
> is used for is to check timing. What this means is that the max_fanout and
> max_capacitance attributes on the specified cell are ignored during
> optimization!
From: [ Synopsys R&D and Synopsys Technical Support ]
John, currently, set_driving_cell is just a more accurate version of
set_drive; it allows the port to model the transition or load-dependent delay
of the external driving cell. Neither set_drive nor set_driving_cell have
any interaction with design rule attributes.
ESNUG 206 Item 4 (quoted above) requests that set_driving_cell also be used
to determine design rules such as max_capacitance, max_transition, and
max_fanout. This request will be considered during planning for future
versions of the tool. Star-23506 has been filed for this.
> If you're using the table lookup timing model with input transition & load
> capacitance as parameters, you really need the transition attribute because
> of the default transition if there's no attribute is 0 delay, perfect edge,
> which in our case results in 0 gate delay. We also found this
> counterintuitive and expected set_driving_cell to operate as the user
> describes, i.e. set_driving_cell replaces and supercedes set_drive.
ESNUG 208 Item 3 (quoted above) brings up a different issue. The nonlinear
delay model allows a cell's output pin transition to depend on the transition
on the input. This effect is usually small, but is important for smaller
geometries. set_driving_cell captures most of the information about such
cells, but does not specify what input transition to use when calculating the
port delay. A zero transition is assumed. This means that the delay of the
port will be slightly optimistic for driving cells where output transition
depends on input transition. This should not cause an output transition of
zero, however. Even with a perfect waveform at the input, if the output of
a gate is loaded, there will be nonzero transition time at the output. The
library should be characterized at zero input transition and nonzero load,
in addition to other data points.
set_driving_cell deletes information of set_drive (and vice versa). This
does not cause the above problem, however. What is needed is additional
information about the transition time on the input of the driving cell.
Enhancement Star-24306 has been filed for this request.
- [ Synopsys R&D and Synopsys Technical Support ]
( ESNUG 209 Item 5 ) ---------------------------------------------- [2/1/95]
From: gel101@gel.ulaval.ca (Vincent Rowley)
Subject: VHDL Errors Using "liban" rev. 5.1d On My FPGA
Hello, John,
Using the Synopsys liban program to extract the xprim_4000_5_components.vhd
and xprim_4000_5_FTGS.vhd.E files from xprim_4000-5.db library, I got errors
involving:
REAL port name: A<0> VHDL port name: Ax0x
I used the following command:
liban -arch FTGS syn/xprim_4000-5.db -output src/xprim_4000_5 -xgen
My question is: How can I tell to liban to use "(" and ")" instead of x
in the VHDL port name? (I want A(0) instead of Ax0x.)
- Vincent Rowley
Cite Universitaire, Quebec, Canada
( ESNUG 209 Item 6 ) ---------------------------------------------- [2/1/95]
Subject: (ESNUG 208 #5) Seeking Confessions From The Speed Freaks
> I'd like to see on ESNUG the techniques people use to get high speed designs
> from synthesis. Assume you are starting out with good coding style, good
> partitioning for synthesis, & a good synthesis library. Assume the default
> compile ("compile") doesn't meet your timing goals. What do you do next?
> Map effort high? How do you overcome local minimums? What if that doesn't
> work? What do you try next? I would like to see ESNUG answers posted as:
>
> First, I try this ....
> Second, If that doesn't work I try ...
> Third, If that doesn't work I try ...
From: jadams@fore.com (Jay Adams)
First, I encounter a standard compile producing erroneous results.
Second, I call the synopsys hotline and leave a message.
Third, I send the support center e-mail.
Fourth, I wait.
Fifth, I wait.
Sixth, I wait.
Seventh, I wait.
Eighth, I wait.
Ninth, I get a call tracking number from the auto-attendant.
Tenth, I wait...
976th, I wait...
2385th, I get e-mail telling me to supply more information.
2386th, I go back to step 3.
- Jay Adams
FORE Systems
( ESNUG 209 Item 7 ) ---------------------------------------------- [2/1/95]
From: jc@lsil.com (Joseph Cesana)
Subject: How To Retain A Verilog Function's Hierarchy After Synthesis?
Hi John, I'd like to know if Synopsys can synthesize a Verilog Function and
keep it as a submodule. (I know it can synthesize it but the Function is
flattened at the top level.) Is there any command that would keep the
Function as a hierarchical entity?
- Joseph Cesana
LSI Logic
( ESNUG 209 Networking Section ) ---------------------------------- [2/1/95]
Lisle, IL - Tellabs, Inc. seeking a perm. ASIC designer with 4-7 years exp.
High-speed design, telecom, DSP & VHDL. No Headhunters! "dan@tellabs.com"
Austin, TX: AMD K5 project seeking IC designers w/exp. in Verilog, Synopsys,
F/P, APR or custom. Principals ONLY. Email: Robert.Jones@amd.com
|
|
