Editor's Note: I'm suffering from horrible family guilt. I grew up in
Vermont and my parents still live there. Ever since one of my brothers
moved to Florida and my other brother moved to Texas, our parents have
made it their secret mission to send Vermont propaganda to them on every
gift-giving holiday. Vermont maple syrup, Vermont calendars, books on
New England, etc. And, of course, there's ALWAYS an open invitation to
return to Vermont for a ski or leaf-peeping vacation. I'm seen as the
one loyal son because I live near Boston -- and that's where the guilt
is... Tomorrow my girlfriend and I are flying to nice warm 80 degree
Costa Rica. A week long vacation of scuba diving and soaking in mineral
spas next to live volcanos. No phones, no computers. Did I forget to
say that this year's winter in Boston has closely matched a typical
winter in Moscow??? You know -- the type of winter that causes foreign
invaders to turn around and go back home? -- I just can't go Vermont
tundra skiing again this year! Oh, the guilt... the horrible guilt...
- John Cooley
the ESNUG guy
( ESNUG 342 Subjects ) ------------------------------------------- [2/00]
Item 1: ( ESNUG 340 #1 ) We Found PKS Timing Correlates Within 3 Percent
Item 2: Do NOT Use "set_dont_touch_network" On Clocks With DC 99.10 !!
Item 3: Revision Control Software - Clearcase, RCS, SCCS, Cliosoft, & CVS
Item 4: Hey! Chronology's QuickBench Is A Player In This Market, Too!
Item 5: Help! Synopsys Is Killing Our Vera Ethernet Transactor Library!
Item 6: ( ESNUG 341 #7 ) Users Critique Altera Quartus & FPGA Compiler II
Item 7: ( ESNUG 341 #6 ) Users On ModelSim's Verilog/VHDL Co-Simulation
Item 8: ( ESNUG 340 #5 341 #13 ) Sample PLI To Force FF's To 1's Or 0's
Item 9: Quick, Initial Customer Impressions Of The New TetraMAX ATPG Tool
Item 10: ( ESNUG 341 #5 ) "Model" Command & Fake DC Library Elements
Item 11: ( ESNUG 341 #3 ) For Single Paths, Feed DC IPO PrimeTime Verilog
Item 12: Do You Think Synopsys Should Provide STAMP/BLAST Models For ICs?
Item 13: How Should A Foundry Craft A .lib That's Optimal For Synthesis?
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 342 Item 1 ) --------------------------------------------- [2/00]
Subject: ( ESNUG 340 #1 ) We Found PKS Timing Correlates Within 3 Percent
> A final note: in it's current state PKS uses Ambit at the front end with
> the Ambit Static Timing Analyzer, and Qplace at the back end with Pearl
> as the Static Timing Analyzer, something we thought was a mishmash and
> certain to cause timing correlation problems.
>
> - Jon Stahl, Principal Engineer
> Avici Systems N. Billerica, MA
From: Jay McDougal <jaym@hpcvcdt.cv.hp.com>
Hi John,
I have to disagree. We use both Ambit and Silicon Ensemble (Qplace). I
have also been using PKS for about 4 months and have found that the timing
correlation between Ambit, PKS, Pearl, and even PrimeTime is very good.
Sure there will be some 1-2% differences but I consider that noise. I am
getting great timing closure within 0-3% of PKS predicted timing after
full routing and parasitic extraction. I call that great! Now, if I could
just get better correlation between the PKS "router" and the final Wroute
to agree on congestion and routability I would really be happy. I have to
agree that a single timing engine is preferable, but I find actual use of
the current solution very workable and better than Jon Stahl's "mishmash"
characterization that was given here.
- Jay McDougal
Agilent Technologies (formerly Hewlett-Packard)
( ESNUG 342 Item 2 ) --------------------------------------------- [2/00]
From: Kayla R Klingman <kayla.r.klingman@tek.com>
Subject: Do NOT Use "set_dont_touch_network" On Clocks With DC 99.10 !!
Hi, John,
We found a bug in DC 99.10 where:
1) You clock on the negedge of the clock
2) You have a constant as the data in to a flop
3) And your clock has set_dont_touch_network on it
It would add buffers to the clock, even though you told DC to leave it
alone. The answer that came back from R&D at Synopsys was:
Get rid of the set_dont_touch_network on your clock.
In DC 99.10 they started assuming an ideal clock, so set_dont_touch_network
was redundant. They got rid of the set_dont_touch_network and the extra
clock buffering went away. We're still waiting to hear why we have
dangling gates, but simplify_constants -boundary_optimization gets rid of
them.
- Kayla Klingman
Tektronix, Inc. Oregon
( ESNUG 342 Item 3 ) --------------------------------------------- [2/00]
Subject: Revision Control Software - Clearcase, RCS, SCCS, Cliosoft, & CVS
> This is a survey and question about RCS. I would like to know in the
> Verilog world who's using RCS revision control software. I have used it
> and found it quite useful to manage projects particularly when it was
> being used with a GUI (i.e. Renoir, CS-RCS etc). I was wondering if
> others have had the same experience and what company you're with (i.e.
> no vendors saying how much we need it). Thank you for your help.
>
> - Joshua Schwartz
> Redux Communications Israel
From: Edward Arthur <eda@ultranet.com>
We use RCS/make/scripts to manage all of our ASIC/verification activities.
About half the engineers use the command line interface and the other half
use Emacs to check-in/check-out files.
- Edward Arthur
Lucent Technologies
---- ---- ---- ---- ---- ---- ----
From: "Richard Nuth" <nuth@col.hp.com>
We use it for our Verilog projects here. Our alternative is Clearcase,
which is used by our software development teams. This seems to be overkill,
so we adopted RCS instead. We all use the command line interface and
scripts to manage the projects on both unix and Windows platforms.
- Richard Nuth
Agilent Technologies Colorado Springs, CO
---- ---- ---- ---- ---- ---- ----
From: Rick Filipkiewicz <rick@algor.co.uk>
In common with the s/w engineers, I use CVS to manage an FPGA/ASIC project
written in Verilog. CVS uses RCS at the bottom end but also allows
management of whole groups of files and you can do branching/merging of
different development streams. There's also an Emacs CVS-mode.
- Rick Filipkiewicz
Algorithmics Ltd. UK
---- ---- ---- ---- ---- ---- ----
From: Sanjay Spatel <sanjay@cliosoft.com>
Take a look at SOS from cliosoft. http://www.cliosoft.com It does what
RCS does and more, including support for remote site and version control
support for directories which is critical for configuration management.
- Sanjay Spatel
Cliosoft
---- ---- ---- ---- ---- ---- ----
From: Petter Gustad <pegu@dolphinICS.no>
We've been using SCCS for quite some time and later CVS for source control
of ASIC design files, test benches and supporting tools. Most people use
the command line interface but some (including myself) use emacs vc.
One of my favorite RCS/CVS tricks is to put the file version number in a
simulation dump file (signalscan trn file in my case):
// synopsys translate_off
reg [639:0]RCS_ID;
initial
begin
RCS_ID = "$Id: papu.v,v 2.13 1999/02 15:30:51 pegu Exp $";
end
// synopsys translate_on
You can then find RCS_ID in the respective module in your waveform viewer
to observe the file version number.
- Petter Gustad
Dolphin Norway
( ESNUG 342 Item 4 ) --------------------------------------------- [2/00]
Subject: Hey! Chronology's QuickBench Is A Player In This Market, Too!
> Anyway, I'd like to move beyond this issue and encourage more detailed
> *technical* user letters about Vera and/or Specman -- you know, bugs,
> tips, gotchas, workarounds, scripts, etc...
>
> - John Cooley
> the ESNUG guy
From: Wade Hostler <whostler@chronology.com>
Hi John,
You've invited contributions on VERA and Specman, and I'd like to see our
product added in there, too. Chronology QuickBench has a hardware
verification language called RAVE which stacks up very well against VERA or
Verisity's e language, along with a powerful tool for creating bus
functional models. I'll limit my plugging here, but I would suggest that
anyone who is looking into VERA or Verisity should also check us out at
http://www.chronology.com too.
- Wade Hostler,
Sr. Apps Engineer
Chronology Corporation Oceanside, CA
( ESNUG 342 Item 5 ) --------------------------------------------- [2/00]
From: Vallath Nandakumar <vallath.nandakumar@amd.com>
Subject: Help! Synopsys Is Killing Our Vera Ethernet Transactor Library!
John,
At AMD, we designed the SwitchIT family of ethernet switch chips. Most of
our verification (simulation) we did using Vera. An important part of it
was the Vera Ethernet Transactor Library, or ETL. Even though it was the
first time we used Vera, it was a BIG time-saver for our project, compared
to our prior experience with Verilog testbenches.
When we first looked at Vera ETL, it had no RMII (Reduced Media Independent
Interface) support, and no half-duplex support. Systems Science added these
features for our support. We added to Vera ETL lots of code to support our
proprietary interfaces, with help from Systems Science and Synopsys.
We did waste some time in debugging ETL, particularly the half-duplex code.
Certain other parts of the code, like the tricky Gigabit 10-bit interface,
was completely bug-free. Having the source code helped us a great deal,
since we could fix minor (and major) bugs ourselves. Synopsys usually
wanted test cases, and their response time wasn't always fast enough for
us, so it was useful for us to have the code handy.
Large parts of the testbench remained unchanged for block level and chip
level verification, for RTL and gate, and for simulation with and without
backannotated timing. Having the exact same testbench for all these saved
us a bundle of time, too. Vera 3.13 is not perfect for timing simulation,
since asynchronous drives etc. are a little tricky, but we did bypass
the hurdles. Partly by having Verilog wrappers to do some of the timing
functions.
Synopsys unfortunately no longer supports Vera ETL; instead they are
diverting everyone to SmartModels and other models from their LMC group.
Vera ETL has powerful features for packet checking at output ports, but
the new simulation models don't have these features. They are not offering
source code for the new models. These negatives are not good news for us
right now, having invested quite a bit of time in learning, debugging,
and maintaining Vera ETL.
We plan to continue using Vera, since it is well-suited to our networking
needs. Vera has improved tremendously between 3.13 and 4.x in features.
I would be interested in hearing from other users here on ESNUG who use
Vera in networking applications.
- Vallath Nandakumar
AMD Network Products Division
( ESNUG 342 Item 6 ) --------------------------------------------- [2/00]
Subject: ( ESNUG 341 #7 ) Users Critique Altera Quartus & FPGA Compiler II
> As part of the verification of our ASIC design, we plan to build an FPGA
> based prototype using Altera 20K Apex devices. Unfortunately we're having
> problems compiling our VHDL directly w/ Quartus (Altera's Apex software).
> We get lots of 'internal' errors, plus it appears that Quartus is quite
> restricted in its VHDL support. Another option would be to use Synopsys
> FPGA Compiler II. I was wondering if anyone has had any stories about
> using FPGA Compiler II in conjunction with Altera Quartus ?
>
> - Justin Smith
> Atmosphere Networks Osborne Park, Western Australia
From: [ The Cat In The Hat ]
John, keep me anon.
My company works in VHDL targeted to both ASICs and FPGAs. Our experience
is that if you want good quality results and few language hassles, you have
to use either Exemplar or Synplicity.
- [ The Cat In The Hat ]
---- ---- ---- ---- ---- ---- ----
From: Jay Dowling <jay@acut.com>
If you want the smallest, fastest results and want to get them in the least
amount of time when synthesizing Verilog, VHDL, or a combination of both to
any FPGA architecture, then you should be using Synplify. They support
both languages better than anybody else.
- Jay Dowling
Acut
---- ---- ---- ---- ---- ---- ----
From: Brian Carlton <carltb@ntd.comsat.com>
John,
I think the problem is in the Altera place and route part. I am using
Synplicity for synthesis, and I still have plenty of the sorts of problems
Justin describes.
- Brian Carlton
Comsat
---- ---- ---- ---- ---- ---- ----
From: Gaedke Klaus <GaedkeK@thmulti.com>
Hello, John,
We have just finished a 30k design using FPGA Compiler II (Altera Edition).
We were able to set up a stable design flow within a few days. FPGA
Compiler II accepts VHDL RTL-code exactly like Design Compiler, therefore
we did not get any error messages for a design previously synthesized by
Design Compiler. The tool is stable and has a stable link to Quartus
(either flat or hierarchical EDIF). The run time is OK (about 1 hour for
30k gates on an Ultra Sparc 60). LPMs are supported. Post-synthesis
verification of the netlist did not show errors. One thing you can't trust
are the timing estimations, we found a difference of factor 6 (!) between
FPGA compiler II prediction and Quartus timing report. Besides that: it's
good stuff!
- Gaedke Klaus
Thmulti
---- ---- ---- ---- ---- ---- ----
From: Kathy Brown <kbrown@ti.com>
Hi, John,
I'm happy to have something to contribute to the discussion, as I have often
profited from ESNUG myself.
We've been using FPGA Compiler II on our project for about 2 months. (Ver
3.3.0.4517, we stopped using version 3.3.1.4719 when Quartus could not read
the EDIF files it created). We were urged to use FC2 for synthesis, rather
than synthesizing with Altera Quartus, tool by Altera themselves. The
reason was that they felt we would get better timing closure as the tool
comes from a place where synthesis is their bread and butter.
Initially we found that we got smaller area results from FC2, and good
timing. We have not gone back to make any more comparisons.
DC-shell users will find the GUI somewhat painful, with very few options.
I tried to figure out fc2_shell, the equivalent command line version of the
GUI but could not get adequate documentation. Synopsys support said there
was no reference guide for fc2_shell but they had some informal notes which
they sent. The commands were very basic -- not what I was looking for
(set_dont_touch). Due to time pressures, I continued to use the GUI
instead. If your design is less than 70% full and doesn't push timing too
much, then this is a decent option.
However, if you are trying to squeeze your design in (93% of capacity) and
still meet timing, good luck. Our solution was to reduce the logic to less
than 70% of capacity and wait for the larger parts (600E in March '00).
The tool gives two basic options: optimize for area or speed, and each with
a level of effort (low, high). My experience with optimizing for speed was
that it tended to eat up the whole device, even with a design which was 65%
full if optimized for area. Not too spiffy for practical reasons. My
experience with optimizing for area did not show any such problems, and the
speed was very similar to the one which was optimized for speed (the speed
comparison was done after place and route with Quartus, see below).
About the speed numbers from FC2 -- totally unrealistic. Whatever they are
using for the equivalent of a wire load model is woefully inadequate.
Numbers like 100 MHz before P&R become 14 MHz after P&R! (I did not get as
good timing numbers from a Quartus compile followed by a Quartus P&R, to be
honest though.)
Another issue I came up against is that FC2, at this time 99.10 version,
does not support the use of the memory blocks as logic blocks. For a
design which is pretty full to capacity and not using much memory, this is
a great option. Synplicity is able to do this, and possibly other tools,
I'm told. I also heard that this capability may be in the next version of
FC2. The local support is looking into a work-around within FC2, but I
haven't heard back from them in a week.
All in all, I would recommend FC2.
- Kathy Brown
Texas Instruments Dallas, Texas
( ESNUG 342 Item 7 ) --------------------------------------------- [2/00]
Subject: ( ESNUG 341 #6 ) Users On ModelSim's Verilog/VHDL Co-Simulation
> We're thinking about using Modeltech's ModelSim to simulate a Verilog
> gate level design in a VHDL-Testbench. (We want to reuse the VHDL
> testbench we designed together with the Verilog RTL code of the design.)
> I'm interested in any user experiences with ModelSim's Verilog engine &
> their VHDL/Verilog co-simulation. How about their:
>
> - Simulation time ( especially for designs about 100k gates)?
> - Compile time ( especially for designs about 100k gates)?
> - Backannotation (again, for 100k gates)?
>
> If someone has experiences compared to Verilog-XL or Synopsys's VCS or
> Viewlogic's Fusion, it would be great. Many thanks for moderating the
> ESNUG, John.
>
> - Georg Zehentner
> HEIDENHAIN GmbH
From: Svein Haustveit <svh@networks.nera.no>
Hi, John,
I have a response to ESNUG 341 #6 -- "What's The Customer Dirt On ModelSim's
Verilog/VHDL Co-Simulation?" We found no serious dirt on our limited
ModelSim Verilog/VHDL co-simulation trial.
I have tried out ModelSim VHDL/Verilog cosimulation on a 300K design with
the same mix as Georg intend to use. (VHDL testbench and Verilog design).
I normally do all-VHDL simulations and the cosimulation worked out OK.
There is a single user interface and user operation is identical to single
language operation. As I understand it, there is no separate Verilog
simulation engine communicating with the VHDL simulator, but a single
simulator kernel handeling both languages.
I have no benchmark with other simulators, but ModelSim Verilog gatelevel
was 2X faster than ModelSim VITAL/VHDL gatelevel simulation (both with
testbench in VHDL). Compile time and SDF annotation is done in few minutes
and is not an issue for a 100K design.
There is one issue with SDF annotation. If you change your testbench and
restart your simulation, with the restart command the SDF annotation is
repeated even if the design is unchanged.
This is the same as for a VHDL-only simulation.
- Svein Haustveit
Nera Networks Bergen, Norway
---- ---- ---- ---- ---- ---- ----
From: Gregg Lahti <gregg.d.lahti@intel.com>
John -
MTI makes a darn good simulator for cosim. It's the only single-kernel
simulator on the market. Having both languages running and debuggable
in the same simulator is the only way to go. I've use it here at Intel
in these dual-language configs with very good success:
- nothing but VHDL
- VHDL and Verilog RTL, VHDL test bench
- Verilog gate-level netlist, VHDL test bench
- nothing but Verilog
The latest relese 5.3c has some serious significant speed improvements
to Verilog. You'll note that Verilog has at least a 2-10X sim speed
improvement over VHDL simulation speed using modelsim for both languages,
depending upon how the VHDL & Verilog is written.
As far as caveats go, I can think of one where std_ulogic doesn't connect
up well with Verilog in co-sim; you need std_logic instead. ('Course, I
can think of a lot of reasons why one should use std_logic over
std_ulogic). It would be nice if modelsim could use the modelsim.ini file
to point to a Verilog library (not a sub-unit) instead of using the -L
[libname] from the command line. Haven't tried this method in the latest
5.3x variation, or it may be that modelsim just won't support it.
One of the nicest features of modelsim (Verilog or VHDL) is the TCL
interface. As an example, we were designing a custom micro-controller in
the middle of our ASIC and one of the engineers coded up a debugger window
in TCL/TK that connected into the uC during simulation. The debugger
showed all of the uC registers, program counter, and had the ability to
breakpoint the simulator on specific values in any register. Development
was a few days and about a few hundred lines of TCL/TK code. Very sweet,
saved man-weeks of effort debugging compiled assembly code from our SW team
on the RTL simulation. To do it in C/PLI/FLI would have been a serious
effort (especially the X windowing gunk), but the TCL/TK method in modelsim
was a slam-dunk.
- Gregg Lahti
Intel Corp Chandler, AZ
---- ---- ---- ---- ---- ---- ----
From: [ I Wear My Sunglasses At Night ]
John, please keep me anon.
Couldn't wait to tell you how happy I'm with ModelSim. Of course, I've been
using it for years. However, I have also use VCS for years, happy with it
too.
However, we have most if not all of our models in VHDL and ALL of our test
benches in VHDL. I have been pushing Verilog since I've been here, and it
is starting to catch on. My last two project have run all the RTL sims in
VHDL and the gate sims in VHDL TB with Verilog gates. This runs seamlessly.
It speeds up the sim 10X faster than Vital.
Our current project we decided to go Verilog RTL and VHDL test bench and
models. Once again for legacy reasons. We made this decision after running
some tests. We converted a large block (about 30K gates) from VHDL to
Verilog RTL. About 3000 lines of code. The VHDL runs at about 4000 cyc/sec
the Verilog with the VHDL TB runs at 16K cyc/sec.
The other reason to use ModelSim is you don't have to recompile, or have
multiple binaries for each type of workstation. We currently have access
to HP's, Sun's, IBM's, and Linux. We can run sim's on which ever is
available or the fastest hardware at the time. BTW, Linux is at least
clock for clock as fast as HP and Sun (forget IBM) on X86. That means that
an 800MHz PIII is about 2x faster than a SUN Ultra 80 450MHz.
Now for the negative. ModelSim does not appear to be optimized for PLI's.
I have a design that is all Verilog, including the testbench, which has
several PLI's. Here VCS is much faster than ModelSim by 4x to 10x.
BTW, all my numbers are for ModeSim 5.3c and VCS 5.1.
- [ I Wear My Sunglasses At Night ]
---- ---- ---- ---- ---- ---- ----
From: Rick Munden <munden@acuson.com>
Hi, John,
I have been using ModelTech's VHDL/Verilog cosimulation capability for
about 2 years. I am not using in quite the way Georg Zehentner is
asking about. In my environment ASICs and FPGAs are designed in Verilog
but off-the-shelf components are modeled in VHDL (see the Free Model
Foundry at http://vhdl.org/fmf). The board level design is netlisted in
VHDL. The testbench may be in either language but is most often in
Verilog. So far, ModelSim has done great. The only problem I am aware
of is an inability to have a Verilog tran primitive in a mixed language
simulation. Since these do not appear in RTL code it has not been an
issue. MTI performance is much better than our previous Verilog simulator.
- Rick Munden
Acuson
---- ---- ---- ---- ---- ---- ----
From: "William E Lenihan III" <wlenihan@notes.west.raytheon.com>
Hi, John,
My case isn't exactly what Georg is looking for, but for what it's worth:
I've used ModelSim PE Plus 5.3a on a ~25k gate design that was 90% Verilog
and 10% VHDL for the UUT, with all Verilog for the testbench. I was very
impressed at how seamless the mix of the two languages went. I have no
quantitative info to support this, but compile times & simulation times
didn't seem to be any different from other, similarly-sized, single-language
designs/blocks I've worked on (but remember, it was a small design and only
a small fraction VHDL). Although written in synthesizable-RTL style code,
this model was never synthesized, so I can't comment on back-annotated sims.
In the writing of the code, there seemed to be only 2 caveats that had to be
followed:
1) When passing parameters in the parent Verilog module down to generics
in the child VHDL module, you could not use the 'defparam' construct,
but had to use the module instance parameter value list, ordered the
same way as the generics appear in the entity:
// vhdl component instantiated within Verilog ... ok for ModelSim:
cdecode #(2,4) U1 (.EN(1'b1), .AD(addr[1:0]), .DCODE(wordce[3:0]));
// vhdl component instantiated within Verilog ... NOT ok for ModelSim:
cdecode U1 (.EN(1'b1), .AD(addr[1:0]), .DCODE(wordce[3:0]));
defparam U1.s_addr = 2;
defparam U1.s_decode = 4;
2) There's another rule involving case sensitivity, but I lucked out in
that my default coding style never led to any problems.
It's all well documented in the ModelSim manuals. I couldn't be happier
with this simulator (well, actually, I could... if Model Tech would be
upfront about what parts of the LRM they don't support!)
- Bill Lenihan
Raytheon Systems Co. (formerly Hughes Aircraft Co.)
( ESNUG 342 Item 8 ) --------------------------------------------- [2/00]
Subject: ( ESNUG 340 #5 341 #13 ) Sample PLI To Force FF's To 1's Or 0's
> So, do what the real hardware does, power up everything 1 or 0.
>
> How do you get rid of them? Write a simple PLI ACC program that loops
> through every reg in the design, fetches the value, and if X sets it to
> 0. You call this routine during reset, and all X's are gone. You then
> run an entire regression.
>
> - Wilson Snyder
> Maker Communications Framingham, MA
From: Thorsten Lutscher <thorsten.lutscher@force.de>
To: Wilson Snyder <wsnyder@maker.com>
Hi Wilson,
Such a PLI function to pre-set the default values of FFs at simulation
start time would be very helpful for us to fix the usual reset problems.
Unfortunately I have never written a PLI function and I would like to
ask you to provide it for other ESNUG readers as well.
- Thorsten Lutscher
FORCE Computers GmbH
---- ---- ---- ---- ---- ---- ----
From: Wilson Snyder <wsnyder@maker.com>
To: Thorsten Lutscher <thorsten.lutscher@force.de>
Hi, Thorsten,
I thought of submitting the code, but it's part of our whole enviornment
and thus doesn't use the "normal" PLI routines. Here is what I have.
#ident "$Id: gate.c,v 1.12 2000/31 14:43:21 wsnyder Exp $"
/
* This module contains free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as published
* by the Free Software Foundation; either version 2, or (at your option)
* any later version.
*
**********************************************************************
* gate.c - Gate level randomization
**********************************************************************
*/
#include <stdio.h>
#include <stdarg.h>
#include <unistd.h>
#include <strings.h>
#include <fcntl.h>
#include <ctype.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/un.h>
#include <sys/uio.h>
#include <sys/time.h>
#include "pli.h"
#include <ehi.h>
/* Local Module defines */
/* Globals */
/* Prototypes */
/**** Internal code begin */
static int gate_sets;
void gate_randomize_net (
handle net_handle,
int value)
{
static s_setval_delay accdelay = {{accRealTime},accNoDelay};
static s_setval_value accvalue = {accBinStrVal};
char *val = acc_fetch_value (net_handle, "%b");
char *bit;
/* Look bit by bit, set any x to 0/1.... if chg... */
for (bit=val; *bit; bit++) {
if (*bit=='x') break;
}
//UTIL_PRINTF ("\tnet %s = %s\n", acc_fetch_fullname (net_handle), val);
if (*bit) {
if (!strcmp (acc_fetch_name(net_handle), "notifier")) {
/* Skip notifier nets */
return;
}
/* Have a x */
for (bit=val; *bit; bit++) {
if (*bit=='x') {
if (value==2) *bit='0';
else if (value==1) *bit='1';
else if (value==3) {
*bit = (lrand48() & 1)?'1':'0';
}
}
}
UTIL_PRINTF ("\tnet %s <= %s\n", acc_fetch_fullname (net_handle), val);
accvalue.value.str = val;
acc_error_flag = 0;
acc_set_value (net_handle, &accvalue, &accdelay);
gate_sets++;
if (acc_error_flag) {
UTIL_WARN ("Problem setting net %s = %s\n", acc_fetch_fullname (net_handle), val);
}
}
}
void gate_randomize_recurse (
handle mod_handle,
int value)
{
handle net_handle;
static regs[3] = {accRegister, accIntegerVar, 0};
static mods[3] = {accModuleInstance, accCellInstance, 0};
if (ehi_debug_level) UTIL_PRINTF ("Module %s %s\n", acc_fetch_fullname (mod_handle), acc_fetch_defname (mod_handle));
for (net_handle=NULL;
(net_handle = acc_next (regs, mod_handle, net_handle));) {
gate_randomize_net (net_handle, value);
}
for (net_handle=NULL;
(net_handle = acc_next (mods, mod_handle, net_handle));) {
gate_randomize_recurse (net_handle, value);
}
/*Can't look inside primitives */
/*
for (net_handle=NULL;
(net_handle = acc_next_primitive (mod_handle, net_handle));) {
UTIL_PRINTF (" subpr %s %s\n", acc_fetch_fullname (net_handle), acc_fetch_defname (net_handle));
}
*/
}
/* $gate_randomize ("bench.board.c0.mxt4400_shell.mxt4400", 1/2/3, #set);
* First parameter is top level module name to be initialized
* Second parameter 0, don't initialize.
* Second parameter 1, X's -> 1's
* Second parameter 2, X's -> 0's
* Second parameter 3, X's -> random 1 or 0
* Third parameter is output net set when something was changed.
* This is generally used to call gate_randomize every cycle till nothing
* is left in a X.
* Note that memories are NOT reset (as Verilog doesn't provide access to them),
* you need to do that in Verilog code. */
void gate_randomize_pli (void)
{
handle mod_handle;
char * hier = pli_getsp(1);
int value = pli_getp(2); /* 0=0, 1=all 1s, else randomize */
pli_info (0, "Starting gate randomization... (%s)\n",
((value==2)?"zeros"
:((value==1)?"ones"
:((value==3)?"random":"no change"))));
acc_initialize ();
/*acc_configure (accDisplayWarnings, "true");*/
mod_handle = acc_handle_object (hier);
if (acc_error_flag) {
UTIL_FATAL ("Can't find %s\n", hier);
}
gate_sets = 0;
gate_randomize_recurse (mod_handle, value);
acc_close ();
pli_info (0, "Completed gate randomization, %d X's.\n", gate_sets);
pli_putp (3, gate_sets);
}
You need to change the pli_ calls to the tf_getp and tf_putp parameters,
then have a pli.tab that maps $gate_randomize to the gate_randomize_pli
function. John, maybe you could talk one of your readers into tweaking
this PLI code sample into something more modular and useable for the general
ESNUG community? I don't have time to do this myself, but I'm glad to
volunteer this PLI code to get it started.
- Wilson Snyder
Maker Communications Framingham, MA
( ESNUG 342 Item 9 ) --------------------------------------------- [2/00]
Subject: Quick, Initial Customer Impressions Of The New TetraMAX ATPG Tool
> "Synopsys Test roadmap featured TetraMax for ATPG. They claim 5X
> speed improvement over Test Compiler, 10X capacity improvement and
> 2X vector compaction. We'll see."
>
> - an anon engineer
From: Roberto Mattiuzzo <Roberto.Mattiuzzo@st.com>
Hi, John,
I came across this quote in your DAC'99 Trip Report on your web site talking
about Synopsys TetraMax ATPG.
We've recently run TetraMax on a complex 3 million gate design that is
already in production. The original set of vectors (30 million) had been
generated using Synopsys TestGenXP (formerly Sunrise). We used to run
TestGenXP ATPG distributed over a dozen hosts, resulting in about 3 days CPU
time (more than one month on single CPU!!!). We did the same with TetraMax
and the results have been quite astonishing: 4 days on a single CPU only,
producing *half* the vectors w/ a negligible coverage reduction (about 1%).
We're now working on correlating the vectors on ATE versus the original set,
but certainly this preliminary result is very satisfactory.
- Roberto Mattiuzzo
STMicroelectronics Agrate, Italy
( ESNUG 342 Item 10 ) -------------------------------------------- [2/00]
Subject: ( ESNUG 341 #5 ) "Model" Command & Fake DC Library Elements
> Design Compiler has a command called "model", which does everything you
> need, including updating the library. After Tom models his design, he
> should use remove_design to get rid of the original.
>
> - Oren Rubinstein
> GigaPixel Corp. Santa Clara, CA
From: [ Where's The Beef? ]
John, anonymous, please.
I did a 'man model' in DC 98.02, and found a help page for the 'model'
command, but don't find one in DC 99.10. It sounds like a useful feature,
but where did it go? Maybe Synopsys removed a feature, or maybe they just
didn't bother to include it with the documentation (our install of 99.10
was missing about a bunch of the man pages, because they just didn't fit
on the disk we got from Synopsys).
- [ Where's The Beef? ]
( ESNUG 342 Item 11 ) -------------------------------------------- [2/00]
Subject: ( ESNUG 341 #3 ) For Single Paths, Feed DC IPO PrimeTime Verilog
> One of the biggest roadblocks was that we were unable to run DC IPO to
> our satisfaction. It took many days to run (on 360MHz UltraSparcs),
> was repeatably crash-prone, and didn't produce good results. (We tried
> both 98.08-1 "normal" IPO, and 99.05-2 Floorplan Manager IPO). ...
> I wrote a program that reads the Primetime output and upsizes gates
> whose individual delays exceed user-specified limits. That is, it
> looks for and speeds up all the slow gates in the failing paths. ...
>
> - Jeff Winston
> Maker Communications Framingham, MA
From: Denis Bzowy <bzowy@Lucent.COM>
John,
Another way of doing fast DC IPO on a single path is to turn the PrimeTime
timing report into Verilog, e.g.
SBNX3 U94 ( .A( \bff/q[31] ), .Z( n457 )); // .85 pF
MUX21 /maci/U356 ( .SD( n457 ), .Z( /maci/net34253 )); // .41 pF
...
and run this little Verilog with set_load / set_res through Synopsys IPO.
Since IPO considers gate interactions, it gives better results than
gate-at-a-time tools. (Be sure to report_timing before optimizing, too.
For example, you might have A->Z in the path, but a slow transition time
from B->Z .) In theory you could add PDEF for just those gates and run
LBO, but I have not tried this.
For full-chip IPO, we at Lucent Europe have an in-house tool, ZIPO. It's
fast, because it treats gates independently; does no uniquify; uses
Synopsys delay tables; can be told to make modules smaller, or faster,
or fix max_transition; and can add buffers.
- Denis Bzowy
Lucent Microelectronics Munich, Germany
( ESNUG 342 Item 12 ) -------------------------------------------- [2/00]
From: Jonathan Hampton <jhamp@lucent.com>
Subject: Do You Think Synopsys Should Provide STAMP/BLAST Models For ICs?
John,
I'm wondering how many others out there would find it valuable for Synopsys
to provide static timing models in addition to LMC models for IC devices?
Since Synopsys works closely with IC vendors to certify their LMC models,
any static timing models provided could also carry that same certification.
They could provide STAMP models, since STAMP is a Synopsys standard modeling
language, or they could provide BLAST models.
Anyone else think that this would be valuable?
- Jonathan Hampton
Lucent Technologies
( ESNUG 342 Item 13 ) -------------------------------------------- [2/00]
From: [ One Of The 47 Ronin ]
Subject: How Should A Foundry Craft A .lib That's Optimal For Synthesis?
Hi John,
I always enjoy ESNUG POST, and I often find good information in there. This
is the first time I send E-mail to you. Please keep me ANONYMOUS.
We acknowledge if we change Synopsys .lib slightly on its cell repertoire or
cell timing value, the sythesis result is affected much. When we added some
new cells, the synthesis result became worse in some cases. We changed the
cell timing a little bit faster, the result was much improved.
We know that constraints, WLM, cell area and many other factors are related
to determine the synthesis result. But we would like to know if someone has
a guide line of developing the library: how we should develop library
optimal for Design Compiler. We tried to find out any application note
and/or documents on Synopsys SolvNET Web and contacted our Synopsys AE, but
we can not get useful information so far.
If someone give us such information on ESNUG, it's very appreciated.
- [ One Of The 47 Ronin ]
|
|
