Editor's Note: I don't know. Maybe it's just me. For years, I've had
this secret pride in seeing Dilbert in the funny pages of my local
newspapers. His world is our world. Dilbert exquisitely satarizes all
the idiotic office politics and the mass stupidity one sees as an
engineering citizen the cubicals -- and he's dishing it out from an
engineer's perspective! You go, Dilbert!
Then the horror (at least in my eyes) happened. Someone, somewhere
(probably the same Hollywood execs who thought the movie "Ishtar" was
funny) thought it would be a "great idea" to put Dilbert on TV. <UGH!>
Yesterday, I watched the TV version of Dilbert. I tried. Honest. I
really did want it to be funny & witty & make me laugh out loud. Hey,
Dilbert's one of our own -- we gotta support him! Honest. I tried...
... but it just didn't work. Instead, it just came off as artificially
contrived and, sometimes, outright stupid. Scott Adams has had his
Waterloo and soon our favorite cartoon son will be moving on to
"Garfield" status in the near future. A sad day for engineers... :^(
- John Cooley
the ESNUG guy
( ESNUG 309 Item 1 ) ---------------------------------------------- [1/99]
Subject: ( ESNUG 308 #10 ) More Recent User Benchmarks Of Ambit vs. Synopsys
> I have used both. I am not an expert by any means. I used DC 3.1?
> and found it to be slow. I now use Ambit's BuildGates, it is fast in
> reading the design and in synthesis. May I suggest you call both of them
> and get an evaluation copy for your own consideration. IMHO, feature for
> feature, dollar for dollar Ambit comes out ahead over Synopsys.
>
> Well, they did before Cadence bought them. It remains to be seen if the
> value stays for Ambit, but that's a whole new thread.
>
> - Jerry English
> Planet C
>
> [ Editor's Note: This is *really* lame because he's comparing a current
> version of Ambit versus a 4.5 year old version of Synopsys. Lame!
> Does anyone have any current rev to current rev comparisons? - John ]
From: "Paul.Zimmer" <paul.zimmer@cerent.com>
John,
I read a sort-of Ambit "testimonial" a while back, and was disturbed by
two things:
1) The touted benefits were all PRE-ROUTE. Now, I have seen several
examples over the years of circuits that look larger/slower based
on wire-load pre-route estimates, were actually smaller/faster
when routed. I'm concerned that benchmarks based on pre-route
results will drive the vendors to produce netlist optimized for
the benchmarks, not real-life.
2) Even the pre-route data was dicey, because they didn't really prove
that the difference wasn't in the libraries and/or wire load tables.
The simple solution is to write out a netlist from each, then read
them both into a single tool (or try both tools) for timing
analysis.
This is still imperfect, because the wire-load tables can drive the
tools to different solutions, but at least it is more realistic than
just reciting the estimated cycle time from the tool itself.
I'd love to see comparisons of several decent-sized blocks synthesized
with both tools, then routed.
- Paul Zimmer
Cerent Corp.
---- ---- ---- ---- ---- ---- ----
From: Mike Dini <mdini@dinigroup.com>
John,
We are having trouble getting the attention of our local Cadence sales folk
to get a price and demo of Ambit. If you know, could you forward me the
email address of the VP of sales for Cadence so I may properly complain?
- Mike Dini
The Dini Group
---- ---- ---- ---- ---- ---- ----
From: Jay McDougal <jaym@hpcvcdt.cv.hp.com>
Hi John,
Concerning that 4.5 year old benchmark, I can do a little better, but not
the latest releases. Here are my notes from an Ambit vs. Design Compiler
evaluation I did almost a year ago:
Comparison of BuildGates(v2.0.4) and DesignCompiler(v1998.02):
This comparison includes some general comments, and specific result
comparisons for three different designs in terms of area, circuit
performance, and compile time. All compiles were performed on 100Mhz
HP C180 machines.
General:
BuildGates was fairly easy to use given experience with Design Compiler.
The methods of setting constraints, setting up libraries, and compiling
circuits are very similar. Also, the AMBIT documentation is written
to make the transition from Design Compiler easy. There were a few
things that were different enough to cause some difficulty such as
latch timing and target library specification.
Here is a short laundry list of items I noticed in my short time using
BuildGates.
- Report_timing is nearly interactive (a few seconds) even with 100K gates
- Capability to interrupt and re-enter compile process is great for
debugging timing constraints without waiting for long compiles to finish.
- Re-entrant compiles and control to run individual optimizations seems
like a great feature but I did not use it in my evaluation.
- All read, and write commands run much faster
- Applying constraints and library attributes is also much faster
- Ability to set timing constraints and get reports to hierarchical
boundaries instead of just pins/endpoints is very useful.
Comparisons
Circuit1:
Testcase with small portion of logic from address data path of a CPU,
about 5K gates.
BuildGates 2.0.4 DC 98.02
total compile time 40min 33min
area slack area slack
stats at finish of compile 265 0 292 0
Circuit2:
CPU core (50 to 60K gates) timing critical asking for 110Mhz with 78th
percentile wire load models. There are no path exceptions (false or
multicycle) and no latches.
BuildGates 2.0.4 DC 98.02
total compile time 13.3hrs 8.6hrs
area slack area slack
stats at finish of compile 3052 -0.32 3338 -0.37
In both cases the clk->clk paths all met the constraint but some
clk->out paths had small negative slacks.
Circuit3:
Complete CPU, about 100K gates. Asking for 110Mhz with 78th percentile
wire loads. Multiple path exceptions (both false and disabled paths)
as well as several hundred latches used to guarantee hold times to an
external RAM interface.
BuildGates 2.0.4 DC 98.02
total compile time 37hrs 29hrs
area slack area slack
stats at finish of compile 4900 -0.2 5395 -0.2
Both results are from top down compiles from the behavioral code.
Both circuits meet the clk->clk paths at 110Mhz (9.09ns period). With
the -0.2 slack in CLK->Q paths that end at heavily loaded outputs.
Summary
The results are very similar. BuildGates does show a consistent area
advantage of about 10% and a slightly longer compile time. It also
looks like the capacity of BuildGates may be more limited than that
of DC 98.02 as the compile time difference increased as the circuit gate
count went up.
I did not try any area sensitive designs where the timing was easily
achieved.
- Jay McDougal
Hewlett-Packard
( ESNUG 309 Item 2 ) ---------------------------------------------- [1/99]
From: erikt@bnr.ca (Erik Trounce)
Subject: Any Way To Speed Up This DC Script To Find Clock Domain Crossings ?
I've got an existing design and I need to find all of the clock domain
crossings in order to insert lockup latches for DFT. I could probably read
through the code and find most of them, but I was hoping to automate it
and catch all of them. I've written a dc_shell script that will do this,
however the run time for this script is several days, even on an Ultra-10.
Here is the script I am currently running (for the past 14 hours):
ckList = all_clocks()
foreach (ck, ckList) {
echo "Investigating" ck "registers..." >> clock_xdomain_list
Dplst = {""}
foreach (tock, ckList - ck) {
Dplst = Dplst + all_registers (-clock tock -data_pins -edge_triggered)
}
foreach (Qpin, all_registers (-clock ck -output_pins -edge_triggered)) {
foreach (fanout, all_fanout (-from Qpin -flat -endpoints_only)) {
foreach (Dpin, Dplst) {
if (fanout == Dpin) {
echo "Path:" Qpin "to" Dpin "exists" >> clock_xdomain_list
}
}
}
}
}
Anybody have a faster script that can do the same thing? It can be a
dc_shell script, perl or dc_perl or csh or whatever would be great. It
just needs to be complete and fast(er).
- Erik Trounce
Nortel (Northern Telecom) Ottawa, Ontario, Canada
( ESNUG 309 Item 3 ) ---------------------------------------------- [1/99]
Subject: Looking For Tools That Generate Memory BIST for DRAM's
> I am looking for a tool which can generate Memory BIST for DRAM's,
> something like the Mentor Graphics Memory BIST for SRAM's. Does anyone
> know of any such tool available in the market?
>
> - Manish Shrivastava
> Siemens Microelectronics (Asia Pacific) Ltd
From: sengupta@cisco.com ( Maitreya Sengupta )
LogicVision might have the sort of tool you are looking for. Look at
the following URL: http://www.lvision.com/prelease/pr112596.htm
- Maitreya Sengupta
Cisco
---- ---- ---- ---- ---- ---- ----
From: "Denis P. Reilly" <reilly@kodak.com>
Is anybody familiar with the LogicVision RAM BIST tools? I'd be interested
in knowing what people think of them, as well as other RAM BIST tools...
I'm familiar with Mentor's MBISTA tool, but I'm looking for others, also.
- Denis P. Reilly
Eastman Kodak Company Rochester, NY
( ESNUG 309 Item 4 ) ---------------------------------------------- [1/99]
Subject: DRAM Memory Testing Algorithms, Walking 1's, Address Testing, Etc.
> Would anybody help me in finding out the algorithms for DRAM Address line
> test, Data line test, Walking 1's test, and Walking 0's test?
>
> - Mohit
> Riverrun
From: "Paul Taylor" <p.taylor@ukonline.co.uk>
Try http://www.ednmag.com
The Feb1 '96 magazine has a very good article "Testing RAMs and ROMs"
on page 153.
- Paul Taylor
---- ---- ---- ---- ---- ---- ----
From: pkasieck@cognex.com (Philip T. Kasiecki)
I can give you two of them. These are both done assuming you test 8 bits
at a time, and moving along in the memory is not included. That should be
done just outside the for loops here.
/* Walking 1s -- 00000001, 00000010, 00000100, 00001000, etc. */
data = 0x01;
for(data = 1; data <= 128; data <<= 1) {
Write the data
Read the data
if(data_in != data_out) test fails
}
/* Walking 0s -- 11111110, 11111101, 11111011, 11110111, etc. */
data = 0xFE;
for(data = 254; data >= 127; data = ((data << 1) +1)) {
Write the data
Read the data
if(data_in != data_out) test fails
}
The walking 0s has a little more to it, as you have to account for a zero
coming in at the end when you shift. It's not as simple as the walking 1s.
- Philip T. Kasiecki
Cognex Corporation Natick, MA
---- ---- ---- ---- ---- ---- ----
From: Gary Wong <gary@cs.arizona.edu>
Actually, if you're doing a destructive test (i.e. you don't care about
clobbering what's stored in the memory you're testing), it's better to
step the address _inside_ the loop (ie. write _all_ the data, then go
back to the start and test it all starting from the beginning).
In some circumstances, writing the data and immediately testing it may
appear to pass the memory test even if the RAM isn't there at all (if
the test write values float on the data bus).
No test can detect _all_ failures in finite time, but some get closer
than others. Whatever you implement, give it a quick "sanity check"
and see what kinds of failures will go undetected -- typically the
most common failure modes are that the memory is not there at all, or
data and/or address lines are open, shorted, or crossed. Think about
which of these (and other) cases your implementation will detect.
Don't stop until you're satisfied that the failures that it can't
detect are acceptable. For instance, if you modified the "walking 1s"
test given above to test successive bytes on each iteration, it would
cycle through a pattern every 8 memory locations. It won't detect an
error if address lines A4 and A5 are shorted together, for instance.
This may or may not be acceptable, depending on your requirements.
- Gary Wong
University of Arizona Tucson, AZ
---- ---- ---- ---- ---- ---- ----
From: pkasieck@cognex.com (Philip T. Kasiecki)
> In some circumstances, writing the data and immediately testing it may
> appear to pass the memory test even if the RAM isn't there at all (if
> the test write values float on the data bus).
I guess a short delay (using sleep() or the equivalent in the particular
language being used) would help- or would it?
Another test that can be useful is alternating 1s and 0s, and then
switching them (i.e., first writing 0x55, then 0xAA, for 8 bits).
- Philip T. Kasiecki
Cognex Corporation Natick, MA
---- ---- ---- ---- ---- ---- ----
From: z80@digiserve.com (Peter)
No, the bus cap can hold data up for ages.
You need to write the test value to the test location, then write its
complement to another location (so the complement appears on the data
bus), then you read back the original test value from the original
location.
Personally, I like a simple 55/AA test - this picks up duff bits in
RAM chips (extremely rare) followed by a pseudo random fill. The P/R
fill fills the entire RAM with a pattern, than goes back to start and
reads it back. If you repeat this with just a few different seeds, the
chance of any type of fault is vanishingly small, and this is a very
easy test to write.
- Peter
Digiserve
---- ---- ---- ---- ---- ---- ----
From: jackklein@att.net (Jack Klein)
> No test can detect _all_ failures in finite time, but some get closer
> than others. Whatever you implement, give it a quick "sanity check"
> and see what kinds of failures will go undetected -- typically the
> most common failure modes are that the memory is not there at all, or
> data and/or address lines are open, shorted, or crossed.
I actually prefer reading and verifying pattern n-1 and then writing
pattern n to each location on each pass, instead of writing the whole
block then testing the whole block on each pass. Catches shorted address
lines because writing the new pattern to a location near the beginning
would overwrite the old pattern higher up.
- Jack Klein
AT&T
---- ---- ---- ---- ---- ---- ----
From: Darren Hutchinson <dbh@gbdt.com.au>
In my current project I've had to put together some simple, but fast,
memory tests. (I was inspired by an article of memory tests in Embedded
Systems programming from ~1993 (which suggested looking at the failure modes
rather than just doing things that were done in the past, and being
orthoginal about the testing to simplify problem diagnosis). I implemented
the following:
1. Simple walking 1/0 across the data bus (full width) at a single
location.
Rational: If the data bus isn't connected properly there is little
point testing anything else.
2. Simple address test (write address to each location, then go back and
read them all.)
Rational: There is no point testing the data cells until there is some
confidence that the device is correctly connected, otherwise it would
be difficult to seperate data cell errors from address line connection
faults, especially if a random sequence is used.
Also, given that the memory device connections are likely to be less
reliable than the device itself it will be much simpler to diagnose a
problem any problem found in the next test if we're sure that the data
and address lines are correctly connected!
3. Write the area with a few standard pattern (AA/55 etc).
Rational: Writes 1 and 0 to every location testing individual cells.
4. (optional) For DRAM devices it is worth writting the 'discharged cell'
value (memory failing me ...) to each location and then stopping all
DRAM access for a few seconds to test the DRAM refreshing.
Simple eh? Note that these tests don't test for every possible fault (for
example cross cell interaction in DRAM), but this can be done in
approximately 5 seconds for 4 MB of DRAM.
It's also worth considering WHY you're doing the memory test. For a go/
no go power-on test the ability to diagnose the fault isn't so important,
therefore a quick random value test may be quicker.
For production testing it is normally important to be able to diagnose
the fault. The tests above should make fault finding simple by, as far
as possible, testing a single aspect of the memory subsystem at a time.
- Darren Hutchinson
NEC Australia P/L
( ESNUG 309 Item 5 ) ---------------------------------------------- [1/99]
From: Rajendra Marulkar <rajendra@india.ti.com>
Subject: Is There Any Utility That Translates From PrimeTime To DesignTime?
Hello,
Is there any utility which functions exactly opposite to "transcript" ?
I want to convert some pt (primetime) script to dt (design time) script.
- Rajendra Marulkar
Texas Instruments
( ESNUG 309 Item 6 ) ---------------------------------------------- [1/99]
Subject: AWK, SED, Grep, An Other UNIX Utilities For DOS/windows
> Does anyone know if these utilities (sed/awk/grep) exist for PC's ?
>
From: Glenn Eng <glenneng@nortelnetworks.com>
There are many ports available. A good port of numerous Unix i.e. packaged
utilities can be found at:
http://www.reedkotler.com/toolset.htm
or
http://www.research.att.com/tools/uwin/
If you want specific packages you can try:
http://www.delorie.com/
Regards
- Glenn Eng
Nortel Networks
---- ---- ---- ---- ---- ---- ----
From: Petter Gustad <dev.null@dev.null.org>
Check out: http://sourceware.cygnus.com/cygwin/
Here you can download a package consisting of most of the popular GNU
tools running under Win32.
- Petter Gustad
---- ---- ---- ---- ---- ---- ----
From: Andy Botterill <csm@plymouth2.demon.co.uk>
If you look at site <URL:http//www.djdelorie.com/> he has DOS versions
of GNU utilities. The GNU utilities include sed, grep and gawk ( the GNU
version of awk ).
- Andy Botterill
( ESNUG 309 Item 7 ) ---------------------------------------------- [1/99]
Subject: Are There Any Other Sources For PrimeTime Examples, Scripts, Etc. ?
> I am using PrimeTime from Synopsys now. Except the Tutorial/User Guide
> provided by Synopsys, is there any Introduction/Guideline for
> HDL/Example/Tutorial in Web or ftp-site now?
>
> - Chih-Zong Lin
> National Chiao-Tung University Hsinchu, Taiwan, R.O.C.
From: Mohammed Ishaq <ishaq@my-dejanews.com>
As far as I know, that is the only source of information. Since timing
using PT is very similar to DesignTime except for the scripting interface
TCL, you can refer the manual for DesignTime.
- Mohammed Ishaq
( ESNUG 309 Item 8 ) ---------------------------------------------- [1/99]
From: "Shankar Hemmady" <hemmady@gurutech.com>
Subject: ( ESNUG 300 #3 ) The Politics Of Testing, Tools & Test Engineers
John,
In ESNUG 300 #3 (titled "Some Honest Comments On The Current State Of The
Test World"), I wrote a technical revue of many variety of test tools
and techniques. I'd like to follow up by explaining the politics of
testing, tools, and test engineers.
In the area of VLSI manufacturing testing, the praise clearly has to go to
the EDA companies. In spite of the sheer lack of interest and in many
cases, utter disgust, of the manufacturing test area from design engineers,
the EDA companies have done a reasonably good job of creating decent tools
and solutions for defect measurement and defect coverage.
There are many good reasons why a typical chip or system design company can
not and need not be interested in chip testing, fault simulation and other
related activities, such as:
* For products with a short life cycle, getting a lion's share of the
market is far more critical than getting the best test coverage.
* Test coverage usually does not play an important role in getting
samples out to customers, unless your customer really needs the
quality. In applications like space exploration, medical diagnostics,
mil-aero systems, autos, telephony, financial systems etc., getting
a reliable, fault-tolerant system is crucial. A hierarchical
manufacturing test approach may reduce and alleviate some of the
problems we see in real life. However, even in such cases, most often
the major disasters are traceable to "bugs" in the system or chips or
software, rather than to manufacturing related defects.
* In general, area (cost), timing (speed) and power will always be higher
priorities over testability and high coverage. I may not make many of
my DFT/ATPG colleagues happy by saying that. But that's the reality.
That's also the reason why many of my (potential) customers call me for
ATPG/Faultsim/DFT related work at the very last minute. The other
issues cannot be compromised. Unless volume production is at stake, and
defect rate is a major concern, manufacturing testing is compromisable
and is quite often compromised.
With all the above good reasons, it is no surprise that test automation
tools have always been undersold, under-utilized and have been considered
unnecessary by most companies except the leading-edge, quality conscious
companies, and companies that have been in areas that I have mentioned
above where the liabilities can be substantial.
So how has the EDA industry responded to such a low level of interest from
customers? Like most insurance policies, manufacturing test tools have sold
very well after disaster strikes. Without quoting any specific instances,
it should suffice to say that most companies have used EDA tools for test
only after they were desperately arm-twisted by their potential or current
customers for lack of quality, lack of relaibilty, terrible defect rates,
etc...
- Shankar Hemmady
Guru Technologies Cupertino, CA
( ESNUG 309 Item 9 ) ---------------------------------------------- [1/99]
From: klaus Gottschalk <kgott@nf.fh-nuernberg.de>
Subject: Trouble Trying To Model A Complex Cell In Synopsys Library Compiler
Hi Mr. Cooley,
I to my final year project at Fachhochschule in Nueremberg/Germany. I want
to create a new cell within the Synopsys Library Compiler.
_____
| |
A----------------------|> |
____ _____ | |---------
B---| |----| |--| FF |
|mux | |latch| | |
0---|____| | | |_____|
| | |
sel__| | |
______________|> |
|____ |
Relationship between A and B
A______--____
B__--________
I couldn't get the statetable right and have also problems with the pin
describtion. It would be very kind of you, if you can give me some tips
and tricks about this.
- Klaus Gottschalk
Fachhochschule Nueremberg, Germany
( ESNUG 309 Item 10 ) --------------------------------------------- [1/99]
Subject: Is There An Altera ABEL To Verilog Translator Anywhere ?
> Is there an ABEL to Verilog translator out there anywhere ? I'm
> particularly interested in the state machine stuff.
>
> Also a question from a (relative) Verilog newbie coming from VHDL - How
> do you do parametrizable text macros. The OVILRM seems to say that this
> should work:
>
> `define my_add(x,y) x+y
>
> ... later in the code ...
>
> count = `my_add(count,1);
>
> But the Exemplar & Synplify tools don't accept it [neither does the vbpp
> pre-processor].
>
> - Rick
> Algorithmics Ltd.
From: Swapnajit Mittra <mittra@engr.sgi.com>
OK, first I would suggest that you should use
`define my_add(x,y) (x)+(y)
instead. Parametrized macros are a new feature to LRM2.0. I believe
Verilog-XL 2.X has implemented this feature. But all simulators may not be
ready yet. Here is an alternative. I am assuming you are using UNIX.
1. Instead of keeping the macros inside Verilog file (f1.v, say),
keep them in a separate file, say prep.m4 and in a slightly different
form: define(my_add,($1)+($2))
2. Run this at the command prompt: m4 prep.m4 f1.v
(m4 is a UNIX macro utility. It is usually kept in /bin/m4.)
If f1.v looks like
module mymodule;
reg a, b, c;
initial begin
c = my_add(a,b);
end
endmodule
You will get
module mymodule;
reg a, b, c;
initial begin
c = (a)+(b);
end
endmodule
You may have difficulty if you want to override existing macros, but I leave
that as an exercise for you ;-)
- Swapnajit Mittra
SGI
---- ---- ---- ---- ---- ---- ----
From: VITO <verilog@vito.com>
There is a pre-processor that someone implemented and presented a paper at
the 1996 IVC that I think handled this addition to the Verilog standard.
I lost my copy of the proceedings, and I can't recall the author's name.
There is another way to deal with this kind of code re-use that works
for all simulators, regardless of operating system: create an include
file, and redefine macros to act as arguments.
For example, the file "myadd.v" might be:
`DEST = `A + `B;
In the file where you want to use this:
`define DEST count
`define A count
`define B 1
`include "myadd.v"
This technique is more cumbersome, but is still useful if the include
file is extensive. Some simulators will give a warning about redefining
`A if you use the file with a different argument, but that does not
prevent the simulator from producing the right result.
Another technique I have tried is to define a macro instead of an
include file:
`define MYADD `A + `B
.... later ....
`define A count
`define B 1
count = `MYADD;
This does not work on many simulators because `MYADD is bound to "+" before
`A is bound to "count", so you get a syntax error on "count=+;".
- Mark
University of Wyoming
---- ---- ---- ---- ---- ---- ----
From: Swapnajit Mittra <mittra@engr.sgi.com>
> There is a pre-processor that someone implemented and presented a paper
> at the 1996 IVC that I think handled this addition to the Verilog
> standard. I lost my copy of the proceedings, and I can't recall
> the author's name.
That would be yours truly. I made the Version1.0 of this preprocessor,
which I called VIP, sometime during 1995. But I could not maintain it
or fix all the bugs. It was written in AWK, but I later figured out that
it could have been done using m4. If anybody is still interested, send
me a mail to "mittra@engr.sgi.com", I will be happy to send the tgz file.
- Swapnajit Mittra <mittra@engr.sgi.com>
SGI
( ESNUG 309 Item 11 ) --------------------------------------------- [1/99]
Subject: ( ESNUG 304 #10 308 #1 ) Tcl/Tk Doesn't Cut It; Want Perl Instead
> If you think that this Synopsys Tcl environment is going to bring some of
> the cool features of PrimeTime, you will be disappointed. In reality, it
> is just a Tcl/Tk shell wrapped around dc_shell so the features and
> limitations of dc_shell are still there.
>
> I'm not saying Synopsys is going the wrong direction. It is that they are
> trying to save some of the dc_shell scripts for now by not *integrating*
> Tcl/Tk, just wrapping Tcl/Tk around dc_shell.
>
> - Larrie Carr
> PMC-Sierra, Inc. Vancouver, B.C., Canada
From: Don Reid <donr@hpcvcdo.cv.hp.com>
John,
Does this look like a modern scripting language?
set x [ expr $period / 2 ]
Tcl is a bit better than the current dc_shell language, but only a small
bit. Why couldn't Synopsys have picked perl or one of the other higher
level scripting languages?
I tried to write a histogram routine in tcl, for PrimeTime, it was ugly
and slow. Perl did most of the work in one line with an associatve
array (hash).
- Don Reid
Hewlett Packard, ICBD
( ESNUG 309 Item 12 ) --------------------------------------------- [1/99]
From: "Larry Melling" <larry@ikos.com>
Subject: Anyone Have Some Verilog RTL That IKOS Could Use To Test A Tool On ?
John,
We are in the middle of testing a new product and are looking for Verilog
RTL testcases - we need real RTL level design with working testbenches - any
leads?
- Larry Melling
IKOS
( ESNUG 309 Item 13 ) --------------------------------------------- [1/99]
From: Craig Kuwahara <craig.kuwahara@usa.alcatel.com>
Subject: Need To Find An Olde 1 micron Vgt300 Lib For Compass Version 8
Hi, John,
Does anyone have a 1 micron library (vgt300) for VLSI Technology, for
Compass version 8 tools? We're trying to open an old schematic design.
Thanks.
- Craig Kuwahara
Alcatel USA
|
|
