Editor's Note: A few years ago, I had a girlfriend who didn't own a car.
The way she got around was either by the commuter train (to get into
Boston), by taxi (if she needed to go somewhere local) or, most often, by
"John's Taxi Service." (i.e. me) (I didn't mind because we enjoyed each
other's company most of the time.) Whenever I'd go on a business trip,
I'd lend her my car for the time while I was gone. And when I'd get back
after, say, a week, I'd sometimes find she had put over 100 miles a day on
that car! When I'd ask her about all this driving, she'd tell me: "John,
you don't know what it's like to be without a car. It sucks! You have
to beg friends for rides or pay exhorbitant taxi fares. You can't just
go somewhere for fun like that -- it's "let's go to the XYZ" and hope
they want to go, too. You just don't understand."
Last week, on a consulting job, I flew into a distant airport and went to
to rent a car. As it turns out, my driver's licence *expired* on my
birthday last month (remember? National Depression Screening Day?) -- and
they all refused to rent me a car! Now every morning on this consulting
job I have to pay a taxi $15.00 to get me to the job site. Every night,
I have to beg one of my fellow consultants to drive me home! Aaargh!
When I eventually make it back to Massachusetts, I'm gonna drive me 100
miles in no particular direction and enjoy every minute of it! :^)
- John Cooley
the ESNUG guy
( ESNUG 255 Item 1 ) -------------------------------------------- [11/96]
From: bodack@sican.de (Ruediger Bodack DDF)
Subject: Is DesignSource *Already* A "Dead" Product?
John,
I just got a mail (real paper) from the Synopsys Marketing. They told
me that DesignSource will not be supported after 3.5.
This is strange. A year ago they wanted all the users to switch from
SGE to that new tool, and now we have to go back. Some people probably
considerable spent time (and money) on that tool. Fortunately in my
company not many designers started to use Design-Source because of its
PC-like user interface.
I have no doubts that the world needs something like Designsource or
SGE. It makes sense to draw module hierarchies instead of typing
architectures, entities and testbenches, especially for a slow typing
guy like me. DS was a good start, but had some limitations against
SGE. At the moment I am using Cadence framework with success to do the
same work for Verilog. I would like to do the same in VHDL with
Synopsys. Have you (or anybody else) heard anything about the reasons for
Synopsys to play around with us?
- Ruediger Bodack
SICAN GmbH, Hannover, Germany
( ESNUG 255 Item 2 ) -------------------------------------------- [11/96]
From: byron.reams@ColumbiaSC.NCR.COM (Byron Reams)
Subject: One User's Trip Report On The Synopsys Verification Seminar
Hi, John,
Here are my observations from recently attending the Synopsys sponsored
seminar on Cycle Based Simulation (CBS) in Orlando, FL, last Thursday.
The seminar was divided into three parts. Part one presented Synopsys'
vision for design flow in the near future. Part two concentrated on the
cycle-based approach to simulation in general and the Synopsys simulator,
Cyclone, specifically. Part three focused on emulation and Arkos, Synopsys'
emulation solution.
Synopsys' Vision
----------------
Essentially, this boils down to Synopsys wanting to be a one-stop shop
for all your ASIC development needs. Their design verification vision
combines the following elements:
o Common language front-end (Verilog and VHDL).
o Common user interface and debugging tools.
o Event simulator (VSS)
o Cycle-Based simulator (Cyclone)
o Co-simulation (allowing Verilog and VHDL to play together).
o Acceleration and emulation (ARKOS).
Synopsys views design verification in terms of three independent goals:
1) Speed
2) Flexibility & Interactivity
3) Detail
Of course no single verification tool can effectively meet all three
goals. Synopsys wants to provide a suite of tools that all use a common
user interface to meet these specific goals.
Optimizing Design for Synthesis
-------------------------------
Synopsys views this as the overriding design requirement, that the design
should be optimized for synthesis (of course synthesis goals can vary:
speed, area, power, etc.) Once this is accomplished, all the other
Synopsys tools should play well with this design. As an example, if you
write code that is synthesizeable, then Cyclone can take full advantage
of that fact in providing significant performance improvements over Event-
Based simulators. As soon as you start writing non-synthesizeable code
(ie. in your testbench) Cyclone can no longer be used to give that per-
formance boost. However, and this is significant, that doesn't mean you
can't use Cyclone. In fact, with their tool suite, if your design/test-
bench is a mix of synthesizeable and non-synthesizeable code, some parts
will run on the Cycle-Engine, and the rest will run on the Event-Engine.
Addressing the Verification Gap between Simulation and Emulation
----------------------------------------------------------------
Synopsys claims there's a gap in today's approaches to verification.
Graphically, they expressed with:
^
10Mhz | o Real HW
S |
P 1Mhz | o Prototype
E |
E 100Khz | o HW Emulation
D |-------------------------------------------------------
10Khz |XXXXXXXXXXXXXXXXXXXXXXX GAP XXXXXXXXXXXXXXXXXXXXXXXXXXX
|-------------------------------------------------------
1Khz | o Cycle-Based
|
100Hz | o Gate accelerators
|
10Hz | o Compiled/Native
|
1Hz |
|
--------------------------------------------------------->
1min 1hr 1day 1week
Turnaround Time
Effectively, what Synopsys is talking about here is using CBS to close
the gap from the bottom, and ARKOS as a simulation accelerator and
hardware emulator to close the gap from above. By using a common
user interface and common debugging tools for both, it addresses the
Turnaround Time issue which is a problem for current CBS tools and also
current emulation tools.
How Would CBS Play in a System Sim Environment
----------------------------------------------
Our system simulation environment consists of multiple instantiations
of a bus functional model for a large microprocessor coupled to
multiple instantiations of our targeted ASIC chipset design. The good
news is our targeted ASIC chipset should reap the full benefit of CBS
performance (being a totally synchronous design). The bad news is we
don't have source for the bus functional microprocessor model. Our gut
feeling is that much more than half of the simulator's time is spent in
the model code (as opposed to the target design code). This is based
on observation of simulation performance as the design has grown.
Essentially, our simulation throughput hasn't decreased appreciably as
the target ASIC has grown.
I asked several different folks about this and unanimously received the
response that this will be addressed in the future as CBS catches on.
Customers will push the model providers to provide RTL functional models
that are amenable to acceleration with CBS. This is even more likely
for models like a P6 BFM since Synopsys is now the model provider, not
Intel. Synopsys admitted that they don't have the resources now to do
this and it is unlikely to change in the near future, especially since
Intel doesn't provide them with any test suites to use for verification
after changing the model.
I also asked them if there were any customers that haven't realized
significant performance gains with Cyclone and why. In every case
it came down to one of two reasons:
1) The simulation environment was "event-lean", meaning there were
few events between clocks so Cyclone became essentially an event
simulator.
2) The simulation environment was heavily weighted in code that couldn't
be optimized for CBS. Unfortunately this sounds alot like our
system sim environment.
Synopsys suggested that we could do two things. First, we could create
our own RTL bus functional model. Second, we could rely more on block
simulation environments in which the testbenches were coded to take
advantage of CBS.
Cost of CBS
-----------
At $60,000 per license, CBS is a _COSTLY_ simulator. At that price you
have to be very sure that you are going to realize the maximum potential
of CBS to increase simulation throughput. To put that in perspective, a
license for VSystem from MTI (Model Technology) is about $10K. If I buy
6 of those licenses I can quickly and easily increase my simulation
throughput 6X (assuming I have available workstations). Just a thought.
Also, when I asked, Synopsys was very tight-lipped about any Formal
Verification products they "might" be working on.
ARKOS Emulation Solution
------------------------
I was pretty impressed with ARKOS. Unlike Quickturn, it does not fit
the target design into FPGAs. Rather it uses a bank of specialized
processors that are optimized to handle boolean evaluations very
quickly. One of the great weaknesses of the FPGA approach is the
enormous SW complexity associated with partitioning and mapping the
design to the FPGAs. As a result, compiles are very compute intensive
requiring multiple (10-100) workstations for overnight jobs. Another
problem is the probing of internal nodes.
The key features of processor-based emulation are the quick time for
the initial compile. Synopsys stated that it was reasonable to expect
compile performance on the order of 250,000 gates/hr using a single
workstation! They have frequently observed much better performance on
high gate-count ( > 1 million gates) designs. Incremental compiles for
increasing visibility is measured in minutes (not hours). It has high
visibility of internal nodes. All of this combines to make ARKOS useable
as more than just an in-circuit emulator.
Positioning of ARKOS
--------------------
As I mentioned before, Synopsys is positioning ARKOS in such a way to
help fill in the design verification gap between traditional simulation
and emulation. Emulation equipment is EXPENSIVE!! Then consider that
it is only used toward the end of the design cycle. What if you could
find a way to effectively use that equipment earlier in the design cycle?
Synopsys is pushing ARKOS to do just that.
Early in the design phase ARKOS can be used in a software co-simulation
mode in which the design is downloaded to ARKOS, and the testbench is
simulated on the workstation. In such a mode, the operation of ARKOS
would be transparent to the user in the simulator environment. This
would provide the benefit of hardware acceleration of the target design.
Another mode of operation would be a C-Testbench mode. Here the testbench
would be a software model written in C (ie. C-Pentium Pro model, C-PCI
model etc.). The workstation would drive the hardware accelerated design
in ARKOS.
A third mode of operation would be a standalone mode. Both the testbench
and the target design are downloaded to ARKOS providing a complete
hardware acceleration of the simulation. When using this mode, it is
still possible to use software models for things like memory, bus (PCI),
cache memory, etc. Overall speed would be throttled by the software
models.
The last mode of operation is In-Circuit mode. I've already outlined
its benefits over Quickturn. (See ARKOS Emulation Solution above.)
In short, Synopsys wants to be a complete solution for ASIC development.
Their vision makes alot of sense. If they can pull it off, watch out.
They could end up ruling the EDA market. I believe that we will
pursue Cyclone as an incremental improvement (albeit an expensive one) in
our simulation capability. Couple that with some hot new HP or Sun
workstations and we should see very respectable increases in our
simulation throughput. If I can get qualified for an evaluation copy
of Cyclone, I will be evaluating it against my testbench environment on
my current design. I'll let you know how it goes.
- Byron Reams
NCR, Columbia, SC
( ESNUG 255 Item 3 ) -------------------------------------------- [11/96]
Subject: (ESNUG 253 #11 254 #4) Can't Reset "max_capacitance" Post-layout!
>> While receiving a post-layout netlist we usually get some/many design rule
>> violations depending on the design and the quality of the libraries.
>> Usually max_capacitance violations can be ignored if they're less than
>> 150% and you do not want to change the netlist more than necessary. It
>> seems Design Compiler is not capable of handling this problem since it
>> will try to remove *all* violations. It is not possible to increase the
>> max_capacitance value?!! (Does anyone not want this? Why?) ... We
>> managed by manipulating (subtracting) capacitance from the data in the
>> annotation-file. However, this is not our preferred design methodology!
>I've recently been through this and I succesfully used the following
>command to change the max capacitance constraint on library cells:
>
> set_attribute LIBRARY_NAME/CELL_NAME/OUTPUT_PIN_NAME max_capacitance X
>
>If you got fancy and used this in a script with the get_attribute command,
>you could automate changing all library cells. Also, you could ask your
>ASIC vendor to provide a library with all the max capacitance attributes
>at 150%, or modify it yourself if you have the source code.
From: "jeffery scott" <jeffs@nortel.ca>
John,
Our vendor likes to use max cap values which are 80% of the value used
in their DRC tools. This isn't too bad for 1st/2nd pass synthesis, but
it is a nightmare during postlayout IPO (Synopsys is out fixing
"nonproblems" during IPO ). My fix was to use the above methodology
to effectively multiply the current max_capacitance value by 1.25. I
wrote a script which goes to every pin in every cell in your library
and prints out the hierarchical pin name and the current capacitance
value to a file. (DC_SHELL couldn't multiply the value itself because
the value was a string not a floating point). I then used perl
to multiply the numbers and add the other syntax of the command.
Here is the dc_shell script (just fill in YOUR_LIB_NAME):
library = YOUR_LIB_NAME
cells_in_lib = library + "/" + "*"
cells = find( cell, cells_in_lib)
foreach ( cellname, cells ) {
pins_in_cell = cellname + "/" + "*"
pins = find( pin, pins_in_cell)
list pins
foreach ( pinname, pins ) {
fullname = cellname + "/" + pinname
list fullname
get_attribute fullname max_capacitance
if(dc_shell_status) {
max_cap = get_attribute(fullname,max_capacitance)
echo fullname >> cap.list
echo max_cap >> cap.list
}
}
}
This creates a file called cap.list
You can use perl to multiply the number and format the file into a
dc_shell script to be read back into synopsys. Run this command
if you have perl on your system (you can change the 1.25 multipy
to any floating point multiply.)
cat cap.list | perl -ne 'chop;$foo = $_;$_=<>; \
s/;s/;chop;$foo2 = 1.25*$_; \
print "set_attribute $foo max_capacitance $foo2\n";' \
> new_max_cap.dc
This new file "new_max_cap.dc" has the updated max_capacitance values
for all outputs in a library and can be read into synopsys before IPO
to update the values in the current db.
I know that this is a kluge but it worked for me in about 2 minutes.
Note: These settings are not saved to the library only in the db
file that you are working on!!! Don't get tricked!!
- Jeffery B. Scott
Nortel, Morrisville, NC
( ESNUG 255 Item 4 ) -------------------------------------------- [11/96]
From: dchapman@goldmountain.com (Dave Chapman)
Subject: My Internal Tri-State Vs. MUXes Buddhist Rules Of Thumb
Yo, John,
I liked your column in this week's EE Times about the endless discussions
over internal tri-state busses and muxing. The rule of thumb I use is:
- Less than/equal to 4 devices on a bus, multiplex.
- Less than/equal to 8 devices, probably mux, maybe tri-state.
- Less than/equal to 12 devices, probably tri-state.
- More than 12 devices, tri-state.
This is based of the trade-offs in synthesis of keeping track of tri-state
bus enables versus keeping track of the additional logic for the mux. It
is also based on the observation that the fan-in delays for muxes scale,
while the high-current driver delays are constant. (In other words, in
small cases the mux will be faster, while in large cases, tri-state will be
faster.) Also, for designs where there is a common enable for, say, 32
data lines, the control logic for tri-state will requires fewer gates than
the logic to support 32 instances of a 10-1 mux.
Note that future changes in logic technology will cause the trade-offs to
change (like you mentioned) but probably not by much.
- Dave Chapman
Goldmountain
( ESNUG 255 Item 5 ) -------------------------------------------- [11/96]
Subject: ( ESNUG 253 #3) Forced JTAG Insertion Especially When I Don't Want It
> I am using Synopsys 34b. Irrespective of whether the set_port_is_pad
> attribute is set or not, insert_jtag always adds JTAG_BSR for all ports
> of my core block! ( And I do not want to make all my design ports to be
> JTAGed!! Due to performance reasons, I want only a few of them to have
> boundary scan cells and avoid it for the rest!)
>
> I tried all options, nothing seems to work to stop this forced JTAGing.
> Is it a bug with Synopsys 34b Test Compiler or what ?
From: [ A Helpful Synopsys TC CAE ]
John,
The set_port_is_pad command applies to pad synthesis, not to boundary
scan register definition.
Test Compiler has the ability to generate a boundary scan register
which contains only a subset of the ports in a design. The only
command which explicitly excludes design ports from the boundary scan
register is "set_jtag_port false {port_list}".
Unless insert_jtag is invoked with -no_pads option, Test Compiler
performs pad synthesis along with JTAG synthesis on all ports which
contain the port_is_pad attribute. The only exception is those ports
which are listed in the port_list of the set_jtag_port false command.
The design ports given the port_list of this command are excluded from
pad synthesis.
Therefore, if a customer wants to exclude ports from the boundary scan
register but yet perform pad synthesis on all I/O in the design, the
following sequence of commands will accomplish this:
set_jtag_port false {port_list}
insert_jtag
set_port_is_pad {find (port, "*")}
insert_pads
> Also, I would like to use my own JTAG_BSRIN instead of Synopsys JTAG.db
> modules. How can I tell the Test Compiler to use it?
The methodology associated with developing and using boundary scan
components other than the ones defined in the Synopsys jtag.db is
documented in the "Using Custom Boundary Scan Cells" (version 3.4b) and
the "Test Compiler User Guide" (version 3.5a). These documents are
available in the Synopsys On-Line Documentation.
- [ A Helpful Synopsys TC CAE ]
( ESNUG 255 Item 6 ) -------------------------------------------- [11/96]
From: Paul Laberge <plaberge@micron.com>
Subject: I Can't Constrain My "Ideal" PLL Generated Clocks
Hi John,
I'm trying to create a clock that comes from an internal clock driver. I've
got no clock tree, just a global clock net, so Synopsys sees 10,000 loads on
the clock driver. This is a pre-layout netlist, so I just want to see an
ideal clock. I've tried "set_load 0 CLKNET" but this only gets rid of the
wire capacitance, there's still 130pf of capacitance from clock input pins
of all the flops. I've tried setting the variable:
create_clock_no_input_delay = true
but this doesn't seem to do anything. I've also looked at the attribute
"propagated_clock", but it's not set. (Isn't this a common problem with
prelayout netlists that contain PLL's?)
The only thing I've gotten to work is temporarily disconnecting the clock
net from it's driver, creating a port, making the clock net to new port
connection, and then doing a "set_drive 0 new_port". Obviously this method
is not preferred. Any better ideas?
- Paul A. LaBerge
Micron Electronics
( ESNUG 255 Networking Section ) -------------------------------- [11/96]
Fremont, CA -- Cirrus seeks exp. Verilog/VHDL/Synopsys based ASIC designers
to do some fresh design work. Death to headhunters! "bezzant@cirrus.com"
|
|
