From: Mark Baur <mbaur@brooktree.com>
John, Could I join ESNUG? To prove I need ESNUG, I wrote you a little
rhyme. Think "Green Eggs and Ham". (Corny, but I'm ill, medicated and
trying to work at the same time.)
Could I, Would I design in gates ?
I would not, could not design in gates.
I use Synopsys, which I hate.
I get confused with buffer trees
and fanout logic, my limit's three.
In my mind, full of RTL
of perl scripts and unix shell
I should not, could not think in gates
Unless the tapeout grows too late.
But hidden commands and secret switches,
known by synopsys daemons and synthesis witches,
from ESNUG to this poor designer
will make his chips even finer.
Now, can I _please_ join ESNUG? :)
- Mark Baur
Brooktree
( ESNUG 286 Item 1 ) ---------------------------------------------- [4/98]
From: clayd@systems.com (Clay Degenhardt)
Subject: Verilog vs. VHDL, NT vs. Unix, and Ron Collett's Bad Advice
Hi John-
Thought I'd pass along some thoughts after reading your article "From
Beirut to Bosnia" posted on techweb.cmp.com as I was searching for
references to Collett International (Ron Collett).
Before coming to Systems Science, I worked for Zycad over 6 years. Ron
was contracted and, as a stipulation, would speak to the company about his
vision of the simulation-environment-of-the-future. Ron assuredly promoted
the demise of Verilog in favor of the upcoming contender, VHDL. On that
advice, Zycad's executives based the future of the company on a hardware
engine (ViP) designed to digest raw VHDL in preparation to capture the VHDL
market which was prophecized to take over by 1996. Because of this huge R&D
investment, Zycad was fatally crippled and by the time they backtracked to
update the successful gate-level simulator (Paradigm XP, Lightspeed), they
had already lost momentum and could no longer invest in the resources
necessary to regain lost ground.
After my first experience hearing Ron's presentation, I was always
very skeptical of his market analysis. In 1996, it hit directly in my
realm when he avoided the VHDL-versus-Verilog topic and began to harp on
the demise of the workstation platform in favor of NT. I have always
been in the Systems/Networking support end of the organization working
in the verification market for over 10 years. Understanding the trends
taking place in the EDA environment is essential to successfully
planning and implementing appropriate computer and networking resources.
In a sense, Ron's interpretation was in the right direction, but with an
overaccelerated time frame. At that time, NT v3.5 was starting to make
inroads into the engineering environment based on cost-performance
benefits. NT v4.0 was a better design (less buggy, better multi-
tasking, better interface) and has made a big push into the EDA world.
I believe Sun saw this trend forming several years ago and put a lot of
investment into the transition from SunOS to Solaris in order to support
high-end 64-bit processing. It's my feeling that Sun provided an
inadequate transition path and quite a few customers made the decision
to go NT rather than convert long-standing and stable SunOS machines to
once-buggy Solaris. Giving NT a further push were the constant OS
changes by HP from the Engineer-friendly Apollo Domain OS through
various HP/UX flavors. Also, the IBM RS6000 AIX OS was a good reason in
it's own right to scare users to the more friendly and increasingly more
powerful NT platform.
Ever since the nimble Sun sparc-based machines killed the dinosaur DEC
machines, they have been the preferred choice in the engineering market.
The pipelined RISC processor, clean Unix OS, along with the well-
established X-windows interface is still the preferred environment for
serious Engineering work (believe me, engineers *HATE* PCs crashing in
the middle of long simulations, which is a common occurrence). But
besides the number-crunching layout/simulation aspects of the Engineer's
work, they are being asked to perform project management, documentation
and presentation duties well-suited to the PC; an expensive proposition
for a workstation. As Engineers become more PC-savvy, they realize the
tremendous amount of inexpensive and powerful application software
available on the PC and desire to make use of it in the workplace. The
result is the current situation we're seeing of the hybrid environment:
A workgroup of users working on NT platforms with one or 2 Sun
workstations acting as servers for "serious work". X-server software
runs very well on the PC now so it can successfully function as a window
into the Unix environment while other PC-based applications are active.
I believe Sun is seeing this trend and the Darwin systems (Ultra 5,
Ultra 10) are a competitive step with affordable pricing and excellent
performance. Despite this, I will probably purchase a few with low-end
display systems which will act as compute servers and engineers will
primarily use PCs as their desktop interface. While Zycad lost the battle
by betting on VHDL, hopefully Sun will be able to steer their ship to avoid
the Intel/Microsoft iceberg that will turn them into the next DEC (hmmm,
wouldn't that be funny if Microsoft eventually bought Sun?)
Anyway keep up the great insights!
- Clay Degenhardt
Systems Science
( ESNUG 286 Item 2 ) ---------------------------------------------- [4/98]
Subject: ( ESNUG 285 #1 ) DC 98.02 "write_script" Writes Out Erroneous Code!
> Put simply: If you do a write_script in 98.02, you may get a script which
> contains erroneous code. Reading this code back into dc_shell will then
> cause errors. The worst offender we've seen so far is the following:
>
> set_wire_load "SMALL" -library "udr180T155V45" -mode "enclosed" \
> -selection_group "udr180T155V45" -library "udr180T155V45"
>
> Astute readers will note that it's illegal to specify "-library" more
> than once with a set_wire_load command, even if it's the same library.
> If this is read back in to dc_shell, it correctly reports an Error.
> This only seems to affect multi-pass compiles; it did not show up
> in the first compile pass, but was present in subsequent passes.
>
> We also saw several lines similar to the following:
>
> set_input_delay 0 find(port,"MINS")
>
> When read back in to dc_shell, you are of course warned not to specify
> an input delay without an associated clock. Synopsys has issued a STAR
> on this matter. So far I don't know of a work-around.
>
> - Tom Harrington
> Ford Microelectronics
From: [ Kenny of South Park ]
John,
Pls have me anon.
After getting Tom's message I carefully reviewed the write scripts and the
log files from runs which I recently did with 98.02. When I got 98.02 in,
I ran test cases against the LSI LCBG10P, and the Honeywell HX2000R
libraries using a "Compile - Characterize - Write Script - Recompile"
methodology, and I could find no errors.
All of the 'set_wire_load' command in my write_scripts were normal:
set_operating_conditions "WCCOM" -library "lcbg10piov"
set_wire_load "B14X14" -library "lcbg10pv" -mode "top"
and
set_operating_conditions "WORST_ENV" -library "hx2000r_wc_3.3V"
set_wire_load "hx2160r_wl" -library "hx2000r_wc_3.3V" -mode "top"
I saw nothing like the double "-library" references that Tom saw. This
might have something to do with the specific ASIC library he was using.
I couldn't duplicate his problem.
- [ Kenny of South Park ]
( ESNUG 286 Item 3 ) ---------------------------------------------- [4/98]
From: David C Black <dcblack@qualis.com>
Subject: Newer Verson of Design Compiler LOGSCAN v1.20 Now Available
John,
I've put a new rev of the Design Compiler LOGSCAN utility on my company's
web site at: http://www.qualis.com/library. It is located in the
Technology Resources section as both tar and zip files. Standard MANIFEST,
README, INSTALL and LICENSE are included this time around. Let me know
if you have difficulty accessing or using it.
Also, please report any bugs AFTER rereading the manpage AND verifying
the bug's repeatability. If you do send a bug report, please include
details with an carefully worded explanation.
I will be actively supporting LOGSCAN with regard to any killer bugs IN MY
SPARE TIME. Enhancements will be _quietly_ considered relative to time
available. If you would like to *pay* for enhancements/support, please
contact Michael Horne, mikeh@qualis.com, 888-644-9700.
(You can also expect another minor update to appear at the web page in the
near future to correct an installation issue. For now, just be sure to
(A) rename the executable to 'logscan'; (B) make sure it's
executable/readable; and (C) modify appropriately if your Perl 5 executable
is named anything other than 'logscan'.)
- David C Black
Qualis Design
( ESNUG 286 Item 4 ) ---------------------------------------------- [4/98]
Subject: (ESNUG 283 #1 285 #6 ) Formal Verification, Formality & Chrysalis
> I have used both Chrysalis and Formality to do RTL to gate comparisons
> on a 850k gate chip. Both tools had their successes and their
> failures but I think that Chrysalis has a more mature tool without
> going into technical details about algorithms. The Chrysalis tool
> was available on the market long before Formality and I did pretty
> much all work with Chrysalis.
>
> One of the most critical issue I have with Formality is that it is
> using Synopsys synthesis libraries. If there is a bug in the synthesis
> library the resulting gatelevel netlist will not be functionally
> equivalent to the RTL and you would not be able to find this with
> Formality since your reference was incorrect.
>
> Chrysalis uses the ASIC vendors library which is also the one used
> for ASIC sign-off. If the synthesis library is different from the sign-
> off library this will today only be found with Chrysalis.
>
> I did find a bug in our vendors synthesis library. One type of flip
> flop had an asynchroneous reset but it was modelled as a synchroneous
> reset flip flop in the synthesis library. This bug would have been
> pretty hard to find in the lab.
>
> - Anders Nordstrom
> Nortel Ottawa, Ontario
From: "Frank J. Rich" <fjrmrt@snet.net>
OK, John. What's your take on Formality's current capability? Is it the
usual 'trust us, we'll take care of the problems', or does the approach
Synopsys has taken -- same compiler for DC and Formality, use of .db file
to represent logic elements, switching DC versions to find differences, the
same mapper, parser, synthesizer, etc., etc.
Are the comments above meaning to say: We'll work w/ the tool, hacking away
until it does the job; because of the investment in Syn (dare to interpret
that as a double entendre). If so, we're in the same boat, and should plan
on added time and cost in solving the verifications we do.
Or, should designers looking to Formality to chase arduous regression
simulations at the gate level consider it a reasonable alternative? Is
any user going to understand the risk in using Formality also going to be
working on real silicon? Or the issues he (and Chrysalis) raises significant
enough to bother about? Some clear and conclusive answers would be helpful!
- Frank J. Rich
MRT
---- ---- ---- ---- ---- ---- ----
Hi John,
I am a Formality CAE and would like to respond to Anders' post. Please
don't use my name directly. [ A Synopsys Formality CAE ] would be fine.
Formality provides support for both Synopsys db libraries and verilog
simulation libraries. The support for verilog libraries was added after
our early pre-production releases and is currently available for use if you
have installed any release newer than 1997.10-3. The verilog library
support was used successfully by a number of customers during a beta test
that was recently conducted.
Since Formality can read db libraries and verilog simulation libraries,
it is possible to verify a db library against a verilog simulation library
directly within the tool. If a db library has been verified against a
golden verilog simulation library, it should make no difference to the
user which format of library to use in Formality when verifying a design.
- [ A Synopsys Formality CAE ]
( ESNUG 286 Item 5 ) ---------------------------------------------- [4/98]
Subject: ( ESNUG 282 #8 ) Library Compiler Won't Take Discharge Cells
> I have a problem/challenge - how to "feed" Library Compiler with discharge
> cells? As it was proposed in the course -- the general direction is to
> define it as an ITS module. I've been searching in the openbook
> ("Synopsys On-Line Docs") for an example of discharge cells but I found
> none.
>
> I would appriciate if someone could send me an example of ITS format
> with the required timing arcs (I mean the names/kinds of arcs -- not the
> numbers) for a discharge cell. Here is an example of a typical circuit:
>
> +---o NOUT
> |
> |
> EN---||
> |
> |---------+
> A---|| |
> | B---||
> | |
> | |
> | C---||
> | |
> | |
> \/ \/
>
> Let's say that the EN input is clock or "something & clock"
>
> - Eran Vodevoz
> Analog Devices Herzlia, Israel
From: Eran Vodevoz <eran.vodevoz@analog.com>
John,
I just wanted to follow-up on my problem. Here's an example I got from
Synopsys on how to model a Discharge Cell in Library Compiler:
library(Lib1) {
default_inout_pin_cap : 1.0;
default_inout_pin_fall_res : 0.0;
default_inout_pin_rise_res : 0.0;
default_input_pin_cap : 1.0;
default_intrinsic_fall : 1.0;
default_intrinsic_rise : 1.0;
default_output_pin_cap : 0.0;
default_output_pin_fall_res : 0.0;
default_output_pin_rise_res : 0.0;
default_slope_fall : 0.0;
default_slope_rise : 0.0;
default_fanout_load : 1.0;
k_process_drive_fall : 1.0;
k_process_drive_rise : 1.0;
k_process_intrinsic_fall : 1.0;
k_process_intrinsic_rise : 1.0;
k_process_pin_cap : 0.0;
k_process_slope_fall : 1.0;
k_process_slope_rise : 1.0;
k_process_wire_cap : 0.0;
k_process_wire_res : 1.0;
k_temp_drive_fall : 0.0037;
k_temp_drive_rise : 0.0037;
k_temp_intrinsic_fall : 0.0037;
k_temp_intrinsic_rise : 0.0037;
k_temp_pin_cap : 0.0;
k_temp_slope_fall : 0.0;
k_temp_slope_rise : 0.0;
k_temp_wire_cap : 0.0;
k_temp_wire_res : 0.0;
k_volt_drive_fall : -0.26;
k_volt_drive_rise : -0.26;
k_volt_intrinsic_fall : -0.26;
k_volt_intrinsic_rise : -0.26;
k_volt_pin_cap : 0.0;
k_volt_slope_fall : 0.0;
k_volt_slope_rise : 0.0;
k_volt_wire_cap : 0.0;
k_volt_wire_res : 0.0;
time_unit : "1ns";
voltage_unit : "1V";
current_unit : "1uA";
pulling_resistance_unit : "1kohm";
capacitive_load_unit (0.1,ff);
nom_process : 1.0;
nom_temperature : 25.0;
nom_voltage : 5.0;
cell(discharge) {
area : 1;
interface_timing = TRUE;
pin(A) {
direction : input;
capacitance : 1;
}
pin(B) {
direction : input;
capacitance : 1;
}
pin(C) {
direction : input;
capacitance : 1;
}
pin(EN) {
direction : input;
capacitance : 1;
clock = true;
}
pin(NOUT) {
direction : output;
timing() {
timing_sense : negative_unate;
when : "A&!(B & C)";
sdf_cond : "A==1'b1"
intrinsic_rise : 0.38;
intrinsic_fall : 0.15;
rise_resistance : 0.1443;
fall_resistance : 0.0589;
slope_rise : 0.0;
slope_fall : 0.0;
related_pin : "EN";
}
timing() {
timing_sense : negative_unate;
when : "(B & C) &!A";
sdf_cond : "B==1'b1 & C==1'b1"
intrinsic_rise : 0.38;
intrinsic_fall : 0.15;
rise_resistance : 0.1443;
fall_resistance : 0.0589;
slope_rise : 0.0;
slope_fall : 0.0;
related_pin : "EN";
}
timing() {
timing_sense : negative_unate;
when : "(!B + !C) & !A";
sdf_cond : "(B==1'b0 + C==1'b0) & (A==1'b0)"
intrinsic_rise : 0.38;
intrinsic_fall : 0.15;
rise_resistance : 0.1443;
fall_resistance : 0.0589;
slope_rise : 0.0;
slope_fall : 0.0;
related_pin : "EN";
}
}
}
}
- Eran Vodevoz
Analog Devices Herzlia, Israel
( ESNUG 286 Item 6 ) ---------------------------------------------- [4/98]
From: wsnyder@world.std.com (Wilson Snyder)
Subject: A "Snyder"-fied Version Of McNamara's Verilog-Mode EMACS
Hi, John,
I'd like to announce a new version of Michael McNamara's verilog-mode for
Emacs. I've added some inline preprocessing features that are major time
savers for Verilog coders. This mode will expand a nice compact Verilog
program like:
module example (/*AUTOARG*/);
input i;
output o;
/*AUTOINPUT*/
/*AUTOOUTPUT*/
/*AUTOREG*/
inst inst (/*AUTOINST*/);
always @ (/*AUTOSENSE*/) begin
o = i;
end
endmodule
To what the tools really require:
module example (/*AUTOARG*/
// Outputs
lower_out, o,
// Inputs
lower_in, i
);
input i;
output o;
/*AUTOINPUT*/
input lower_in; // To inst of inst.v
/*AUTOOUTPUT*/
output lower_out; // From inst of inst.v
/*AUTOREG*/
reg o;
inst inst (/*AUTOINST*/
// Outputs
.lower_out (lower_out),
// Inputs
.lower_in (lower_in));
always @ (/*AUTOSENSE*/i) begin
o = i;
end
endmodule
With the end result being that modules that instantiate other modules can
be constructed almost automatically, and be updated when a lower module
needs a new signal with only two keystrokes.
The best thing is that you can toggle between expanded and unexpanded, and
see exactly what is happening right inside Emacs. You don't have to change
any methodologies, since the expanded form is what is saved. And if it
doesn't do what you want, you can edit what it creates and just remove the
magic comments.
I'll take suggestions and make fixes as I can. But of course, you get what
you're not paying for. (I should specifically warn that the parsing is
trivial; it is based on regular expressions so complex constructs probably
won't work. Also AUTOINST works best with the one-module-per-file
methodology.)
For the code, see Mac's http://www.surefirev.com/resources.html
- Wilson Snyder
( ESNUG 286 Item 7 ) ---------------------------------------------- [4/98]
From: tsuhua@tsuhua-ultra.cisco.com (Tsu-Hua Wang)
Subject: Free FSM Analysis Tool "cisco_fsm" For Verilog Based Designers
Greetings,
I would like to announce a FREE finite state machine (cisco_fsm) analysis
tools. In next few days, we will release cisco_fsm on a limited basis
(i.e. you cannot develop Cisco competing products by applying cisco_fsm
tools and only a Solaris version is available.) Please go visit:
http://www.employees.org/~ciscofsm and come to our presentation at IVC'98,
http://www.hdlcon.org.
cisco_fsm features:
- automatically extract fsms from Verilog files
- fsm static verification (reachability tool)
- fsm dynamic verification (coverage tool)
- fsm visual verification (bubble diagram tool)
- Text to graphics
To use this tool you must you have to also download AT&T's "dot" tool at
http://www.research.att.com/tools/graphviz
- Tsu-Hua Wang, Ph.D.
Cisco Systems
( ESNUG 286 Item 8 ) ---------------------------------------------- [4/98]
Subject: Techniques That Allow Using Java As A Verilog PLI ?
> Does anyone know if there exist tools or even it's possible to use Java
> as a Verilog PLI? How about using C++ classes in the code for PLI. I
> need them to model some complex telecomm devices and it's very AWKWARD
> to use C and downright impossible to use vhdl/verilog.
>
> As an observation: EDA languages (vhdl/Verilog) and tools (Modelsim,
> VSS, Cadence's tools) seem way behind the software world. Formal
> analysis tools are useful to verify the gate level against rtl designs.
> But to do system modeling or verify rtl designs, more powerful languages
> such as Java or C++ will be greatly helpful.
>
> - Jian Zhang
> DSC Petaluma, CA
From: Bob Beckwith <beckwith@whinny.tdh.qntm.com>
I don't know of anyone currently using Java (sort of a back burner project
of mine), but people DO use C++ for PLI/FLI code (also for system test
and verification). There was a paper on one method of "hooking up" tests
written in C (or C++) to Verilog at the IVC conference in Santa Clara.
There's also a commercial product available that pretty much does the
same thing (VCPU from SimTech).
Is this what you're talking about?
- Bob Beckwith
Quantum Corp
---- ---- ---- ---- ---- ---- ----
From: Jian_Zhang <jzhang@optilink.dsccc.com>
Thanks for the reply, Bob.
What I'm looking for is to use object oriented portion of C++ (classes,
inheritance, etc.) to build my models using PLI for verilog or FLI for VHDL.
The existing standard PLI only supports procedure oriented C programming
and C++ classes are not allowed.
Furthermore, I am also hopping to be able to present simulation output using
some kind of GUI. I know there are tools like i-Logix' HDL express, etc
doing things like that. But I need to use standard simulators such as
Modelsim, VSS, etc as my primary simulation environment and I need to have
more control to the code and using standard interfaces like PLI/FLI.
Although I am hardware designer, I started using Java as my GP programming
language early last year and have been hooked since.
- Jian Zhang
DSC Petaluma, CA
---- ---- ---- ---- ---- ---- ----
From: Bob Beckwith <beckwith@whinny.tdh.qntm.com>
Jian Zhang wrote:
> What I'm looking for is to use object oriented portion of C++ (classes,
> inheritance, etc.) to build my models using PLI for verilog or FLI for
> VHDL. The existing standard PLI only supports procedure oriented C
> programming and C++ classes are not allowed.
I know of people that have done this with verilog. You may have to resort
to some fairly sophisticated hackery (an oxymoron?) in order to make it
work, but it definitely can be done. This biggest problem is static object
constructors (and there may be some issues if you try to mix C stdio with
C++ streams) but you can certainly write C++ classes to encapulate the
PLI functionality in a straightforward manner. What you can NOT do with
the PLI is modify the netlist topology (you could write even more classes
that allow you do implement "hardware" widgets, but where they connect
in with your HDL code would presumably be "fixed")
> Furthermore, I am also hopping to be able to present simulation output
> using some kind of GUI. I know there are tools like i-Logix' HDL
> express, etc doing things like that. But I need to use standard
> simulators such as Modelsim, VSS, etc as my primary simulation
> environment and I need to have more control to the code and using
> standard interfaces like PLI/FLI.
You should look into the MVC (model/view/controller) methodology that
evolved with Smalltalk. In a nutshell, each entity (i.e. object) has 3 parts
(listed above). The model -- which is the actual object, a view which is
its visual representation and a controller (a way of making the model do
things and also vary model parameters). You could adopt this and implement
in parts. Once you've got all three going, you'll have your GUI.
- Bob Beckwith
Quantum Corp
---- ---- ---- ---- ---- ---- ----
From: Petter Gustad <pegu@computer.org>
Jian_Zhang writes:
> Does anyone know if there exist tools or even it's possible to use Java
> as verilog PLI? How about using C++ classes in the code for PLI. I
> need them to model some complex telecomm devices and it's very AWKWARD
> to use C and downright impossible to use vhdl/verilog.
Basically you can use any language as long as it support C calling
convention. E.g. in C++ you have to declare the PLI interface routines as
extern "C" (I had to make veriuser.h C++ aware), but you can still use
classes etc. in the bulk of your code. This is quite a few years ago (I
used the method described below) and I think I had to play some tricks to
make sure the constructors was called since the main program is not written
in C++.
What we did where I work was to write a small PLI routine with a socket
interface. We have the different pattern generators and verifiers running
as separate UNIX (or they could potentially run on a PC using INET style
sockets) processes and communicating with the Verilog model using sockets.
Another advantage of this is that you don't have to link your Verilog
simulator each time you change your test, you only compile and link the
smaller C++ pattern generators. The disadvantage is that the socket
communication could become an bottleneck, but we have limited data sent over
the socket and I don't think this is a problem. If your company has an
excessive number of simulator licenses and computers you could use this
method to do parallel simulation as well.
- Petter Gustad
( ESNUG 286 Item 9 ) ---------------------------------------------- [4/98]
Subject: A Verilog Reader for Intel HEXfiles
> Does anybody have a verilog reader for Intel hexfiles or do you have
> any idea, where I can find such a reader?
>
> - Reichert Ulrich
> Siemens AG Munich
From: Thomas.Coonan@Sciatl.com (Thomas A. Coonan)
Hi,
I have a Verilog PIC core that needed such a beast. I initially went from
Intel HEX to a particular VHDL look-up-table implementation, and then wrote
another program that went to the simpler ascii hex file for use with
$readmemh. Careful -- I was dealing with a PIC with a 12-bit program code
width word, so, watch any truncation that might be there. Can you poke
around my WWW site first, and see if you find what you need? Look on my
page under Synthetic PIC (check ether VHDL or Verilog version. File should
be something like HEX2ROM.CPP or HEX2VHDL.CPP. It's a fairly generic C
program.)
- Thomas A. Coonan
http://www.mindspring.com/~tcoonan
( ESNUG 286 Item 10 ) --------------------------------------------- [4/98]
From: Salman <salman@vlsi29.gsfc.nasa.gov>
Subject: How Can I Use My Cadence Simwave Tool To View Synopsys VSS?
John,
Does anybody know of a better waveform viewer than the lousy one that comes
with Synopsys VSS, yet is compatible with the Synopsys simulator? I have
the simwave tool from Cadence for our verilog simulations. Is there any way
to use it (compatibility wise) with vhdlsim?
- Salman
NASA Goddard Space Flight Center Greenbelt, Maryland
( ESNUG 286 Item 11 ) --------------------------------------------- [4/98]
From: bellman@azmda.sps.mot.com (Charles Bellman)
Subject: Seeking Accurate, Many Decimal Digits Delays On Inputs
John,
I have a method of verifying libraries in which I create an all-cells
testcase and part of the verification tool writes out an SDF file to compare
timing with other tools. I was wondering if anyone knows an easy way to
automatically set the drive at each pin such that I am assured that there
is, say, 0.5ns at all inputs. The set_drive command will work, but I need
to know the capacitance at each input port in order to set each pin's drive
correctly, e.g. set_drive <0.5ns/capacitance> <input_port>. The problem
is knowing each input's capacitance. I've tried to get the capacitance
attribute by using the 'get_attribute' command, unsuccessfully. I finally
wrote a Perl script to create a set of set_drive commands, based on a
report using the 'report_net' command. The problem with that is, the
resolution is only to 2 decimal places (load field):
Net Fanout Fanin Load Resistance Pins
------------------------------------------------------------
INPUT_1 1 1 0.01 0.00 2
INPUT_2 1 1 0.01 0.00 2
"Load" here may be 0.0149 or 0.0101 -- so you don't generate a very precise
drive value this way. I don't want to change my library input capacitances
from pF to fF right now. That would certainly help in the report. Any
other ideas?
- Chuck Bellman
Motorola NCSG SemiCustom
|
|
