Looks like the Synopsys Licencing Wars hit the EE Times. (Check out pg.19
of the Jan. 3, 1994 issue) It also appears that the reporter interviewed
many of the non-anonymous people who posted on ESNUG on this topic. I
even got a call from him. (Look, Ma! I'm in the papers!) I'm a little
bummed that he never asked for pictures of my sheep, though... :^(
- John Cooley
the ESNUG guy
( ESNUG 170 Item 1 ) ---------------------------------------------- [1/6/93]
From: [ Anonymous ]
Subject: Sequence Of Clock Definitions Makes A Difference ?!?
John, PLEASE post anonymously.
We are seeing the following behavior with v3.0b and having no luck with
the Synopsys hotline in trying to get a successful solution. We have two
clock nets in our design. The first clk1 is used to latch data at the
I/O pads, the second clk2 drives the rest of the chip. The circuit and one
of the subdesigns look like:
/--->> clk1 (to I/O latches)
|
|
external INV1 | INV2
clock >>----- DRVT8 ----+------ IDRV16 ------->> clk2 (to core of chip)
|
|
clock port
of a subdesign
The clocks, for dc_shell, are defined as follows:
create_clock find(pin, I1/Z) -name clk1 -period 30 -waveform {1.0 20.0}
dont_touch_network {I1/Z}
set_clock_skew clk1 -ideal -plus_uncertainty 0.5 -minus_uncertainty 0.0 \
-rise_delay 0.0 -fall_delay 0.0
create_clock find(pin, I2/Z) -name clk2 -period 30 -waveform {6.0 25.0}
dont_touch_network {I2/Z}
set_clock_skew clk2 -ideal -plus_uncertainty 0.4 -minus_uncertainty 0.00 \
-rise_delay 0.0 -fall_delay 0.0
The sequence
1. create clock clk1
2. create clock clk2
3. characterize the subdesign
Creates a write_script with clk1 attached to the clock port of the subdesign.
the sequence
1. create clock clk2
2. create clock clk1
3. characterize
Creates a write_script with clk2 attached to the clock port of the subdesign.
The *only* differance between the two runs is the sequence of definitions for
the two clocks! Has anyone seen similar problems with characterize or write
script? Has the problem been fixed in 3.0c?
- [ Anonymous ]
( ESNUG 170 Item 2 ) ---------------------------------------------- [1/6/93]
From: daves@cirrus.com (David Sherman)
Subject: Bad Gate Level Code Generated By Synopsys On Asynch Set/Resets
Hi, John!
Design_Compiler produces erroneous gate level logic for this code:
module cnt8Ald(d,ld,incrin,clk,q,incrout);
input [7:0] d;
input ld;
input incrin;
input clk;
output [7:0] q;
output incrout;
wire [7:0] d;
wire ld;
wire incrin;
wire clk;
reg [7:0] q;
wire incrout = (&q) & incrin;
always @ ( posedge clk or posedge ld)
begin
if (ld) q <= d;
else q <= incrin ? (q + 1) : q ;
end
endmodule
Instead of qualifying the load to the set and reset pins of the DFF with data
and !data, it sends the load directly to the set, and only qualifies the reset
with data. For data = 0 in any given bit, set and reset will both be active.
The work around is to tediously specify the behavior for each bit explicitly,
but Synopsys manuals claim the code above will synthesize correctly, so it
seems this is a real bug.
Same behavior has been verified for VHDL.
- Dave Sherman
Cirrus Logic
( ESNUG 170 Item 3 ) ---------------------------------------------- [1/6/93]
From: [ Synopsys Corporate Applications Engineering ]
Subject: (ESNUG 168 #4 169 #2) "Design vs Reference ?"
> "what is the difference between a design and a reference?"
First let's cover some definitions:
Design: A design object that contains ports, nets, and cells. The cells
are instances of library parts or other designs.
Instance: A design object that is an instantiation of a library part or a
design. A cell is a synonym for an instance.
Reference: A design object that represents a group of like instances within
a design. The link command in Design Compiler uses the references
in a design to link all the design instances. In most gate level
designs, there are multiple instances of library parts in the
design. Instead of linking every instance, the link command links
each reference.
Attributes can be attached to each of these design objects. Attributes must
always be removed from the object to which they were originally attached.
Second, let's cover how you set and remove the dont_touch attribute on
design objects:
The dont_touch attribute is a special attribute that affects optimization
no matter where it is attached.
If a dont_touch attribute is attached to a cell, only that cell is not
touched during optimization. Other cells of the same type can be touched.
For example:
current_design TOP
dont_touch find(cell,"U84")
compile
If U84 is one of many instances of a DFF cell in TOP, only cell U84 will
not be touched during optimization.
If a dont_touch attribute is attached to a reference, all cells of that type
(in the design) are not touched during optimization. Cells of this type in
other designs can be touched. For example:
current_design TOP
dont_touch find(reference,"DFF")
compile
All instances of the cell DFF in design TOP will not be touched during
optimization. Instances of cell DFF in other designs may be touched.
If a dont_touch attribute is attached to a design, all cells of that type
(in all designs) are not touched during optimization. For example:
current_design TOP
dont_touch find(design,"ADD")
compile
All instances of design ADD will not be touched during optimization. This
affects TOP and any other design instantiating design ADD.
- Synopsys Corporate Applications Engineering
( ESNUG 170 Item 4 ) ---------------------------------------------- [1/6/93]
From: paul@atri.curtin.edu.au (Paul Nolan)
Subject: Slow VHDL Simulator When Using TEXT IO
John, the VSS simulator slows down a lot when writing output file using the
standard VHDL TEXT-IO package. The files get to about 1 Mega-byte and then
the CPU usage drops off very rapidly. The simulation time is about
400,000,000 ps with a timebase of ps. When the simulator is run without the
TEXT-IO functions, by using a trace to write to files, the simulator doesn't
run into this problem.
We are using: Synopsys V3.0a-10063, SUN OS 4.1.3C, SPARC LX w/ 32 M of memory.
Has anyone else run into this problem?
- Paul Nolan
Australian Telecommunications Research Institute (ATRI)
( ESNUG 170 Item 5 ) ---------------------------------------------- [1/6/93]
From: frazer@idtinc.COM (Andrew Frazer)
Subject: DC Uses NORs When It Is Better To Use NANDs
We have a problem that the Design Compiler loves to use NOR gates. In fact,
it likes using NOR gates so much that it often uses them along with inverters
where it could have just as easily used NAND gates. The problem, is that a
series of NOR/NOT's is larger and slower than simple NAND gates.
Does anyone know how to "encourage" DC to use NAND gates, other than just
eliminating NOR's from the library?
- Andrew Frazer
IDT Inc.
|
|
