Editor's Note: Every now and then I get asked the question: "Since
you're an engineer, John, why don't you live in California?" Well,
my answer to that could be best summerized in sharing with you the
random conversations I've overheard at parties in San Jose and in
Boston. At the San Jose party I got to hear in great lengths a very
detailed comparison of workstations versus high performance PCs.
<yawn!> At the Boston party, I overheard someone ask another: "What
if there were no hypothetical questions?" (Which made me laugh!)
- John Cooley
the ESNUG guy
( ESNUG 261 Item 1 ) -------------------------------------------- [5/97]
From: rajen@jaxom.eng.pko.dec.com ( Rajen Ramchandani )
Subject: WARNING: Synopsys "bk" DesignWare Adders Are BROKEN!!!!
Hi John,
In the new release of Synopsys 1997.01, the designware foundation library has
new architectures for adders called "bk". I guess the synonym means Broken.
From an Implementation Report of the design:
===========================================================================
| | | Current | Set |
| Cell | Module | Implementation | Implementation |
===========================================================================
| FsDerivativeChannel_return/add_172 | DW01_add | bk | |
| FsDerivativeChannel_return/add_173 | DW01_add | bk | |
| U1494 | DW01_add | clf | |
===========================================================================
We found that these adders were not functioning as advertised and 4 MSB bits
of the 52 bit adder were producing incorrect output results. Actually
Chryalis symbolic verifier found this out for us. <*COMMERCIAL PLUG*>
Simulation also showed the BUG. Synopsys is aware of the problem and is
working on fixing it. In the meantime the workaround suggested by Synopsys
is not to use the parts.
So if you want to save your sanity include the following to your script
set_dont_use {dw01.sldb/DW01_*/bk}
Also if your design contains any of these bk adders then make sure you
verify the gate_level netlist thoroughly or formally verify the design.
To check if your design contains any of these parts do a
read -f db YOUR_DESIGN.db
report_resources
and check the implementations.
- Rajen Ramchandani
Digital Equipment Corporation
( ESNUG 261 Item 2 ) -------------------------------------------- [5/97]
From: Larry Fiedler <fiedler@NVidia.COM>
Subject: One User's Initial Impressions On PrimeTime
Dear John,
I know that Synopsys is announcing PrimeTime soon. I was fortunate to be a
beta site for the tool. Here is a letter in case anyone is asking "what is
this thing"?
PrimeTime is a static timing analyzer from Synopsys. It can read the
Synopsys database as is and it is faster and smaller. Instead of dc_shell,
Primetime uses pt_shell. On our design, dc_shell takes 640MB and 2850
seconds whereas pt_shell takes 325MB and 1123 seconds for the same task.
It also has some better MCP controls. (We use Synopsys for timing
verification.) PrimeTime is a very good fit for us as it can use the
Synopsys database as is.
The design is the RIVA128, a 3D multimedia accelerator for AGP and PCI
based computers. It is in a 0.35um process and has 3.5M transistors
or 216k instances. As could be expected with a design this large,
there are several timing issues. There are 3 major and 1 minor clock
domains, The major clock domains, such as pci_clk, and pixel_clock each
have versions of themselves that are skewed and maybe half frequency.
In addition there is clock gating, asynchronous and synchronous internal
rams and a CAM with half clock timing.
Our design methodology is that designers supply a netlist and a false
path file. The false path files use variables like "context_cell",
"context" and rely on "current_instance"; they look something like:
set_false_path -from Fanout_fbi_g_busy -to context + "dp/lvl0/ctag/*"
set_false_path -from Fanout_fbi_g_busy -to context + "dp/lvl0/aintp/*"
An explanation of all this is perhaps worthy of another letter. (The idea
is to capture the false path information once.)
In addition to being faster and smaller, pt_shell caught a few half cycle
paths better than dc_shell. It also has a better clock gating detect and
reporting mechanism. The tool itself can handle better MCP's like "-through"
although we did not use this. It also has a faster characterize capability.
pt_shell is different than dc_shell in that it uses TCL, a better
language to be sure, but nonetheless different. There is a translator
that works well. But in the end, I took the route of building a
database with the false paths and timing constraints from dc_shell and
merely reading in the database with pt_shell. The db had to be created
for flattening and SDF purposes and this kept the same-but-different
files from proliferating.
- Larry Fiedler
NVidia
( ESNUG 261 Item 3 ) -------------------------------------------- [5/97]
From: "David C. Black" <dblack@ink.apple.com>
Subject: A Non-JTAG 1149.1 Test Compiler Technique For DC Parametrics
John,
I would like to share a Test Compiler technique I have used recently to
simplify creation of the "DC parametrics output test". For those unfamiliar
with the test, it is simply a test that places the outputs of your design
into both high and low states in as few vectors as possible. During
fabrication, this test is used to verify output drivers and bonds.
Typically, this test is hand crafted. If your design utilizes JTAG 1149.1,
the following may be uninteresting, since it is quite easy to scan values
into the output pads on a JTAG device. The following technique assumes that
you are using some form of scan, preferably full-scan, and of course the
Synopsys Test Compiler; although, some other scan tools may be able to
provide a similar feature to use this technique.
Simply, I use the Synopsys command "set_test_require" to establish that the
enables on all output drivers are active, and establish a value for the
output ports' values as well. I then initiate ATPG for the device, but only
write out a single scan vector. The "set_test_require" command directs the
Test Compiler to create a test vector pattern that establishes the
required value on the specified node. There are a few minor catches to
this approach.
First, there is a bug in TC v3.5a that must be worked around. Namely, you
cannot set_test_require the output port of a tri-state device. The simple
work-around is to set_test_require the input port. For example, if your
output pad is instantiated thusly (Verilog):
OPO53 PIN_112o ( .A(ready_out), .ENZ(ready_enable_), .Y(ready_pad) );
// INPUT ENABLE 3ST-PAD
where Y is to the tri-state output pad, use:
set_test_require "zero" find("pin","*/PIN_*o/ENZ")
set_test_require "one" find("pin","*/PIN_*o/A")
Notice that I use a consistent naming notation for the instances of my I/O
pads to simplify finding them. You could also probably use some form of
filter() to find cells that are I/O pads.
Second, you may find that Test Compiler is unable to establish the
requested set_test_require'ments because there is a logical contradiction
in your logic. For example, if one output is the complement of another,
then you will need to special case those output ports. Also, open-drain
outputs may be impossible to set high (as opposed to tri-state). When TC
finds a contradiction during create_test_patterns, you will receive a
message such as:
dc_shell> create_test_patterns -output "outhi" -backtrack_effort "high"
...SOME OUTPUT DELETED...
Loading design 'F642397'
Checking test design rules
...
Fault coverage 0.00 0.00
No. of test patterns 0
Test Generation Time (CPU) 7.00 sec
Information: No tests generated - conflicting signal
requirements in design.
Use the 'report_test -atpg_conflicts' command for more
information. (TEST-208)
Simply, follow the directions:
dc_shell> report_test -atpg_conflicts
****************************************
Report : test
-atpg_conflicts
Design : F642397
Version: v3.5a
Date : Tue Mar 11 17:22:47 1997
****************************************
Design Object Conflict Reason
------------- ---------------
uDie/uIo/S_53/Y (Pin) set_test_require "1"
1
dc_shell>
It is too bad that you only get these error messages one at a time;
however, it doesn't take much time to isolate these cases.
Eventually, I settled on a script with roughly the following:
read final.db
$OPEN_DRAIN = find("pin",{ "uDie/uIo/PIN_021o/A", \
"uDie/uIo/PIN_033o/A" });
$OPPOSING = find("pin",{ "uDie/uIo/PIN_210o/A" });
$NEVER = find("pin",{ "uDie/uIo/PIN_056o/A" });
$OUTPUTS = find("pin","uDie/uIo/PIN_*o/A") - $TDO - $OPEN_DRAIN \
- $OPPOSING - $NEVER;
$ENABLES = find("pin","uDie/uIo/PIN_*o/GZ") - $TDO_EN;
set_test_require zero $ENABLES >/dev/null;
set_test_require one $OUTPUTS >/dev/null;
set_test_require zero $OPPOSING >/dev/null;
set_test_require zero $OPEN_DRAIN >/dev/null;
remove_attribute $NEVER, "test_require"
create_test_patterns -output "outhi" -backtrack_effort "high"
write_test -input "outhi" -output "outhi" -format "verilog" -first 1
/* repeat for output's low */
Of course, your lists and the output format will differ.
Please use this information to get your designs through test faster, and
consider sending in your own tips to ESNUG. The more everyone shares, the
more the entire design community moves forward. Also, we all spend less
time doing reinventing the same wheels.
- David C Black
Apple Computer, Austin, TX
( ESNUG 261 Item 4 ) -------------------------------------------- [5/97]
Subject: (ESNUG 259 #1) dc_perl: Enhancing dc_shell Using a Perl Wrapper
> John, as you requested, here's a copy of my dc_perl paper and the actual
> script itself for publication on ESNUG. As I said at SNUG'97, I'd like
> to see what users can do with this; break it!, change it!, make it better
> and share how you improve it with the rest of us!
From: Mark Super <msuper@cisco.com>
John:
The dc_perl script is a very interesting piece of work which will add
to the capability of dc_shell.
However I want to pass along a problem that was found. The dc_perl
script ran well under SunOS but the first attempt to run the script
under Solaris did not. Also I believe I was able to determine the
cause of the problem and a workaround.
The dc_perl script will need to use a SunOS version of Perl and not a
Solaris version. The script requires a SunOS version because of a bug
in the chat2.pl program. The chat2.pl program was implemented with the
Perl select function which is based on a select(2) system call.
However the select(2) system call apparently exists in SunOS and not in
Solaris. Without the select(2) system call the dc_perl script will not
block or wait for the array of handles that are ready for I/O. But if
the dc_perl script is run with a SunOS version of Perl then it will
work under both SunOS and Solaris.
Also there is a type error in the sub _get_line.
Old: Outbuffer = $2
New: $OutBuffer = $2
- Mark Super
Cisco Systems
---- ---- ---- ---- ---- ---- ----
From: hofflee@hsd.utc.com ( Leland Hoff )
John -
I read ESNUG 259 #1 and decided that this perl wrapper was something
that I wanted to use here. So I dutifully grabbed the latest perl 5.003
from the 'net and compiled it on my machine.
After all this I stripped the ESNUG filler down to just the dc_perl
script and ran it. It gagged with a "Can't modify constant item... " error
after some digging I found a typo in the dc_perl script. It was at line 399
in my stripped file. In the subroutine _get_line + 13 lines
line 13 looks like this: OutBuffer = $2 ; rest to OutBuffer
but it should be: $OutBuffer = $2 ; rest to OutBuffer
This got rid of the error. I hope this keeps anyone else from having
this problem.
- Leland Hoff
Hamilton Standard Division of United Technologies
( ESNUG 261 Item 5 ) -------------------------------------------- [5/97]
Subject: (ESNUG 260 #1) Protocol Compiler (Dali), BC & ATM Interface Design
> Dali is an environment for ASIC designers to create designs with complex
> interfaces and structured data streams. The increasing complexity of
> protocols have made existing design methodologies difficult and cumbersome.
> Debugging an initial design to meet performance requirements, and later
> re-engineering the design to accommodate modifications in protocol
> specifications or other changes, is time-consuming if not difficult. Dali
> was developed in response to these and other challenges.
From: dchapman@goldmountain.com (Dave Chapman)
Dear John,
I don't know quite what to say about this one. On the one hand, it is
clearly useful to SOMEONE to have done this work, and the tool seems to be
very powerful, but. . .
There seems to be an attitude of "isn't this cool", which does not pay
enough attention to the hardware/software tradeoff implied by putting so
much functionality into silicon. I figure that this is particular part is
going to wind up looking like Yamaha's ISDN chip which has Layer 2 (LAPD)
built in. On the one hand, it is an astonishing achievment, but on the
other hand, everybody turns off the Layer 2 features. Why? Because it
doesn't quite do what we want it to do and there is no way to fix, change,
or add to it.
This ATM this looks like the first in a long series of highly
sophisticated, unflexible, hard-to-use, and generally crappy "systems on
silicon". A tool which encourages people to built such things is NOT a
technology advance.
The single most important decision in modern system design is which
functions to put in software versus silicon. Because this tool biases that
decision towards silicon, I predict that there will be a few crash-and-burn
scenarios in the near future.
I'm not pessimistic, just experienced.
- Dave Chapman
Goldmoutain
---- ---- ---- ---- ---- ---- ----
From: rramsay1@ford.com (Rodney Ramsay)
John,
In case you didn't already notice, ProtocolCompiler documentation is
also included in the 1997.01 CD for Synopsys Online Documentation. :-o
- Rod Ramsay
Ford Microelectronics Inc.
---- ---- ---- ---- ---- ---- ----
From: Randy Bolling <randy@vela.com>
John,
I can't help but reduce the problem of a "protocol" compiler to a BNF
description of the stream you wish to parse and applications / ramifications
upon parsing that stream. Ever written a tool or two using lex and yacc?
I know this application varies greatly, but the complexity of the parsing
does not. What at first appears to be ground-breaking is really the next
logical step. Not that I am taking away from this step. It is a
SIGNIFIGANTLY important step in the advancement of an often lacking field
of EDA tools. This is one step towards realizing small-team million gate
designs. It's also a transformation of an existing set of problems already
solved in the world; just not applied to EDA tools until recently.
I wonder if it has rules preventing it from suffering from the left vs.
right recursion problem. Need to look closer...
Language =
{ Terminals (terminal),
Non-Terminals (reference & sequential & alternative frames),
StartSymbol (pinout),
Productions (optional & repeat frames, qualifiers and if's) }
I can immagine Salvador would have named the tool "De Geus" or maybe just
"Domenech".
- Randy Bolling
Vela Research
( ESNUG 261 Item 6 ) -------------------------------------------- [5/97]
From: Yonghee Im <yonghee@phoenix.dwe.co.kr>
Subject: How Does One Kill Zombie Synopsys Licence Daemon Processes Neatly?
Hi, everyone;
I got a problem when using 'design compiler' of Synopsys. The system broke
down from 'disk full' while synthesizing a design on 'design compiler'.
After rebooting system, I found the process alive on license server, even
though the process doesn't exist any longer on my system. As you know, we
can look at active users using Synopsys tools with 'synopsys_users' command.
I can't restart license daemon because other workers are running tools.
What can I do so as to remove only the Zombie process?
- Yonghee IM
Daewoo Electronics Co.
( ESNUG 261 Item 7 ) -------------------------------------------- [5/97]
From: "N.Chandrapati" <chandra@synopsys.com>
Subject: HW Design: Creating A Single Cycle Write With Asynchronous Memory
Hi!
We see a problem with doing Asynchronous memory accesses in single-clock
cycle. The question is : Is it safe to use both clock edges to generate
write enable (gate it with the clock) to the memory.
0 1 2 3
-- --------- ----------
\_____/ \________/ \_______ Clock
------------------ ----------
\_________/ Wr_Enbl
------- --------------------- ----------
_______X _____VALID___________X __________ ADDR/Data
The problem is at edge 3 where hold time on addr/data will be entirely
dependent on buffers/routing delays. Another problem is that when we use
both clock-edges, there's a restriction on the duty cycle of the clock.
These problems could be dealt with by trying to meet these by adding delay
lines/buffers - but this is not a reliable solution.
One solution we can think of is to double the memory width so that data from
2 clocks can be written at a time, allowing synchronous write enable.
Any ideas, (other than increasing the memory width), are greatly
appreciated.
- N. Chandra
Synopsys
( ESNUG 261 Networking Section ) -------------------------------- [5/97]
Milpitas, CA - Toshiba seeks engineer to synthesize uP. Verif., Synopsys,
Perl, C, Tcl, phys. design, Japanese speaker a plus. "LandmH@taec.com"
|
|
