> I was wondering if you've heard of someone who successfully returned
> with one of those silly Altera pool cues? Although I took a late plane
> on Friday, I did not see any behind ticketing counters, in trash cans,
> etc., nor did I see them coming out the baggage claim shute...
>
> - Bob Carragher
> Fujitsu
From: srm@pacesetter.com ( Steven Ma )
Hi, John,
I did get my Altera pool cue back home by doing what the Altera guy said:
put it in the overhead compartment. Got a few curious stare at airport
while waiting for connecting flight. Since I don't have a pool table at
home, it works great as a spider web clean-up tool. Oh, my son wanted to
use it on pinata hitting; but, I don't think I will allow that.
- Steven Ma
PaceSetter
---- ---- ---- ---- ---- ---- ----
From: Josef Fleischmann <Josef.Fleischmann@ei.tum.de>
Hi John!
This pool cue stick definitely deserves the worst freebie award. I was
having a hard time bringing it home to Germany. Not to mention the
comments from other travelers: "Well, now you must be a professional
pool player..?"
- Joe Fleischmann
Technische Universitaet Muenchen Munich, Germany
( ESNUG 324 Subjects ) -------------------------------------------- [8/99]
Item 1: Avanti's Apollo P&R Licensing Chows Tokens Like Popcorn At A Movie
Item 2: Eleven Fundamental Troubles With Simplex's 'Thunder & Lightning'
Item 3: Converting Synopsys .lib Files to LEF To Eventually Get A TLF File
Item 4: ( ESNUG 320 #16 ) Where Can I Get A Memory Compiler For My Chip?
Item 5: We Got A Used Workstation With A Synopsys License Server In It!
Item 6: How To Count The Toggle Rate Of A Signal In A VCS Simulation Run
Item 7: What's The Best Ratio Of EDA Support Staff To Hardware Designers?
Item 8: Some Misguided Comments Concerning Asynchronous Circuit Design
Item 9: ( ESNUG 323 #3 ) Avanti Apollo P&R Restitching Scan Chains Gotchas
Item 10: Au Contraire! Magma Is Actually Growing Everywhere, Not Shrinking
Item 11: ( ESNUG 323 #17 ) OrCAD's Big Brother Infomercial eCapture Tool
Item 12: Silicon Forest Ain't A Code Coverage Tool, It's White Box Stuff
Item 13: Advantages Of Writing Synthesizable Testbenches For Your Designs
Item 14: Customer Seeks Dc_shell [Plus Other Related EDA] Vim Syntax Files
Item 15: Porting Synopsys IPO Files Into The Cadence HLD Environment
Item 16: The Software Engineers Liked We Used 'Virtual CPU' From Summit
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 324 Item 1 ) ---------------------------------------------- [8/99]
Subject: Avanti's Apollo P&R Licensing Chows Tokens Like Popcorn At A Movie
> "Avanti is 'actively' encouraging users to move to Nova-RTL by
> implementing a high maintenance fee and a 23-minute lockout license
> scheme that prevents users from accessing another license for 23 minutes
> after one use. I told Avanti in no uncertain terms that this did not
> sit well with me and I would actively search for another solution."
>
> - An Anon Engineer ( from the DAC'99 Trip Report )
From: [ The Man In The Iron Mask ]
Hey John,
Please keep me anonymous on this one.
Recently there were some disgruntled Avanti customers complaining about
Avanti licensing procedures in ESNUG. I just thought I'd add to this
discussion by letting everyone know this creative licensing isn't just
reserved for their HDL RTL tools.
In the Avanti P&R system you can add numerous options. These include HPO
(high performance option), power analysis (Mars Rail), physical opto
(Saturn), cross-talk (Mars Xtalk), and timing driven. They utilize the
flexlm licensing so each of these options have a unique set of tokens
associated with each of them.
The problem is how Apollo checks these option tokens out.
We would expect that when a function from Apollo needs additional options
that it would check them out, then return the token when finished.
Unfortunately, this is not the case. When Apollo starts it grabs
everything it can find. So even though you may only be using base Apollo
capabilities you have 5 extra, expensive tokens checked out.
A common license configuration would be to have 5 Apollo licenses, but only
3 licenses for one of the options. With the way Apollo check out licenses,
the last two Apollo users can't access any of the options if they need to
because they have already been checked out by the first three users whether
they are using them or not. Avanti markets the options for just a
configuration saying you may only need 1 HPO to every two Apollo tokens.
They don't add that the first user will always get the HPO.
There is the capability in Apollo to release keys that have been checked
out. So a savvy customer can, in effect, manage their own licenses. Some
of this can be automated in the scheme interface, BUT this precludes the
use of many of the pull down menu's.
- [ The Man In The Iron Mask ]
( ESNUG 324 Item 2 ) ---------------------------------------------- [8/99]
From: Anil Kumar <anilk@vitesse.com>
Subject: Eleven Fundamental Troubles With Simplex's 'Thunder & Lightning'
Hi, John,
I saw there were couple of references to Simplex's Power analysis tools
'Thunder & Lightning' in your DAC'99 Trip Report. I have been working with
these tools for around an year now and I couldn't resist from commenting.
Though these tools have some good features or at least they try to solve a
few problems but then they have lots of problem too. Included below are
some of the problems/bad points for these tools:
* It has too many command/scripts/tools to do the required analysis
For e.g., If I were to do static IR analysis, I will have to go
through a run of at least 12 steps (which includes generation/running
of various scripts and tools)
* It uses many mystical or hard-to-understand the scripts/command files.
Generally, I just copy the old command file (which has a lot of Pascal
type statements). I just modify the new GDS design cells and couple of
file names without really having any understanding of the effect of
other statement in the command file. (In fact, that's what the Simplex
staff recommends.)
* You can't do power tradeoff analysis with this tool -- e.g. you can't
figure out which block is consuming how much of power and what kind
of peaking is going on with the chip's power.
* You can't really use this Simplex tool alone if you are planning to
design a power sensitive design. For power sensitive designs you need
information like: how is the power consumption distribution in
different blocks, what kind of peak and avg currents are drawn by
different blocks (and if you find something fishy, the tool should
provide capability to pin-point the cause of the problem e.g. block/
instances in higher level netlist). Simplex doesn't do this.
* Simplex uses a _lot_ of RAM/CPU power/disk space:
For RAM usage in a 350K design, their database generation tool
needed ~32G memory.
For disk space in that same 350K gate design, it created ~4.5 Gbyte
files on an IR and EM analysis. However cheap hard-disk gets, it's
still an issue for me to have lots of 4.5 Gbyte files to store,
archive, update, and manage. Simplex should be more sensitive about
how much of disk space their database takes.
* Simplex wall clock run time needs help. The 'Thunder & Lightning'
manual says that it can generate a transient current waveform at the
chip level, but when I asked it to generate transient current waveform
data for ONE signal for a 300K gate design, I had following results:
Runtime : 15 hr
No of transient current waveform : 1
Simulation time progress : 46 ns
Size of the o/p data : 4.75 Giga bytes
I sent this information to them and resigned to the idea of doing any
type of transient analysis with Simplex tools. Simplex's response
to this problem was they will fix it in next release. I don't know
it's current status.
* They don't have support for multi-voltage design. Simplex's response
was to scale various part of the design accordingly, but that
doesn't give good/accurate result... first of all you might not have
a very good scaling value for various part of your design. So the
end result will be as good as your guesstimation. (Personally I
don't like their response/solution.)
* They can't support multi-clock designs unless all the the clocks have
a common base clock i.e. every clock must have a common denomination
frequency.
* I disagree with their peak current dynamic IR algorithm because it
won't give you real real-time (peak supply current) IR distribution.
* Thunder simulation does not support any type of analog element i.e you
can only use this tool with purely digital type design.
* Their user interface could use a lot of improvement e.g. reduce the
large number of steps, making command files clean and simple, make it
user friendly. I don't understand how could Simplex ignores such
important things.
You will need lot of hand-holding from Simplex's support to work with their
'Thunder & Lightning' power tools.
- Anil Kumar
Vitesse Semiconductor Corp. Camarillo, CA
( ESNUG 324 Item 3 ) ---------------------------------------------- [8/99]
Subject: Converting Synopsys .lib Files to LEF To Eventually Get A TLF File
> I have a standard cell library in LEF format. It's a physical LEF. This
> LEF library was generated after streaming in GDSII generated from Mentor.
> I am able to use Cadence Silicon Ensemble for P&R with this library.
>
> However, I do not have the TLF file (which contains the cell delays in
> look up table format) for this library. I have a Synopsys .lib file
> where I have all the cell delay information. Is there any way I can
> read in a Synopsys .lib format into Cadence? If so, can I write out
> a TLF after this?
>
> - Rajesh Satapathy
> U. Cal. Irvine
From: Grant Erwin <grant_erwin@halcyon.com>
There is a utility called something like syn2tlf which is obtainable from
Cadence itself. It reads a Synopsys timing library and writes TLF 2.0.
It's been awhile, don't hold me to the details. I'm not sure how a college
can get stuff like this, though.
- Grant Erwin
Halcyon Kirkland, Washington
( ESNUG 324 Item 4 ) ---------------------------------------------- [8/99]
Subject: ( ESNUG 320 #16 ) Where Can I Get A Memory Compiler For My Chip?
> Talk to your local ASIC vendor like LSI or IBM as a start. Memory
> compilers are typicaly a vendor supplied tool unless you are doing COT
> or Full Custom design in which case your vendor will probably suggest
> which memory compiler(s) to use and where to get them.
>
> - Tom Dejanovic
> Cisco Systems
From: Saeid Moshkelani <smoshkel@c-cube.com>
John,
If you need to develop memory compilers, take a look at Interra's MC2.
( http://www.interra.com ) We are quite pleased with the results we
obtained. It allows us to develop custom memories without paying any
royalties to a library vendor.
- Saeid Moshelani
C-Cube Microsystems
( ESNUG 324 Item 5 ) ---------------------------------------------- [8/99]
Subject: We Got A Used Workstation With A Synopsys License Server In It!
> We got a SPARC Workstation from a bankrupt client of us. By coincidence
> we found out, that this workstation was used as a file and license server
> for Synopsys tools. We don't know what this is worth, but that company
> owed us 160,000 Deutch Marks ( ~US $90.000 ) so we would like to sell
> this workstation. The best offer will get it. The license server has
> several licenses for the following Ver. 1999 packages:
>
> dc_expert ultra plus, PrimeTime
> behavioral/verilog/vhdl/test compiler
> designware developer ultra, FPGA compiler II, etc.
>
> If someone is interested in this workstation please email me.
>
> - Friedhelm R|nz
> University of Konstanz Germany
From: ryan@oscsystems.com (Ken Ryan)
If Synopsys is willing to transfer the licenses, it would be worth many
times your $90k. If Synopsys will not transfer the licenses, or will do
so for a steep fee (which I suspect is the case), then the unit is worth
a tiny fraction of the $90k...
Just my 2 cents (mostly for the benefit of EDA newbies reading this).
- Kenneth Ryan
Orbital Sciences Corp. / Fairchild Defense Germantown, MD
---- ---- ---- ---- ---- ---- ----
From: Paul Hands <phands@synopsys.com>
Please do not do this.
It is a breach of the terms and conditions of our licensing to sell or
transfer the licenses in this way. You should contact Synopsys GmbH in
Munich for further information.
- Paul Hands, District Technical Manager
Synopsys (Northern Europe) Ltd. Reading, England
( ESNUG 324 Item 6 ) ---------------------------------------------- [8/99]
Subject: How To Count The Toggle Rate Of A Signal In A VCS Simulation Run
> Does any one know how to count the toggle rate of a signal during a VCS
> simulation ?
>
> - Eran Schar'am
> Zoran Microelectronics Haifa, Israel
From: "Badri P. Gopalan" <badri@synopsys.com>
There is a product called Covermeter which comes along with VCS (pay more
of course :-)) which is a code coverage tool, and it includes toggle
coverage. If you want to do this yourself you have to write a PLI.
If you go to Stanford University web pages and search, in the past I have
seen a toggle coverage PLI posted somewhere there. It is bundled along
with the code for the "Torch microprocessor". If you search for this in
the Stanford university web pages, you can get the PLI. I don't know about
legality of using it, but since I saw it, I thought I would mention it.
- Badri P. Gopalan
Synopsys
---- ---- ---- ---- ---- ---- ----
From: Doron Nisenbaum <doron@chipx.co.il>
The simpler method I know of is to print out the signal into a file:
vsim ... ;list my_signal ; write list out.file; ...
and then use a little script to post-process it.
- Doron Nisenbaum
Chip Express (Israel) LTD. Haifa, Israel
( ESNUG 324 Item 7 ) ---------------------------------------------- [8/99]
From: Jonathan Hampton <jhamp@lucent.com>
Subject: What's The Best Ratio Of EDA Support Staff To Hardware Designers?
Hi John.
How many EDA Engineers does it take to support a group of hardware chip
designers? A colleague of mine mentioned that he recalled an ESNUG post
that recommended a ratio of EDA Engineer to hardware design engineer. (He
thought it was something like 1 EDA person for 13 designers). Do you
recall such a post and can you point me to it?
I've tried a search on the ESNUG archives at http://www.DeepChip.com, but
so far, no luck.
- Jonathan D. Hampton
Lucent Technologies
( ESNUG 324 Item 8 ) ---------------------------------------------- [8/99]
Subject: Some Misguided Comments Concerning Asynchronous Circuit Design
> "Steve Nowick of Columbia U. presented an overview of asynchronous
> circuits. He kept saying words like 'difficult' and 'complicated'
> and 'hazards'. Their experimental burst mode FSM design tools can
> synthesize about 15 gates. (Yes, it's that small. 15.) Ken Yun of
> UC San Diego talked about timed asynchronous circuits. These are
> circuits whose timing properties are very carefully analyzed. They
> can run very fast, but there are no tools for them. Overall, the two
> made asynchronous circuits seem difficult. Alex Kondratyev, U. of
> Newcastle, mentioned that more concurrency does not mean a faster
> circuit, and showed some examples. Shai Rotem and Ken Stevens, both
> Intel, discussed timed asynchronous circuits, and the EDA tools
> needed. They needed tools, since it's exploring a new territory."
>
> - An Anon Engineer (from the DAC'99 Trip Report)
From: Steven Nowick <nowick@cs.columbia.edu>
Dear John,
Very amusing comments ("can synthesis about 15 gates"), but quite misguided.
I said our burst-mode CAD tools easily handle MUCH LARGER controllers. In
fact, our tools easily handle functions with dozens of inputs,
implementations with hundreds of gates, etc.
But why build big asynchronous controllers? Very large asynchronous
controllers are naturally built by *decomposing* them into many small and
fast *concurrently communicating components*. This is PARALLEL HARDWARE,
not monolithic central control. It is a different architecture (and
mindset) from the synchronous approach.
Intel and others prefer small light-weight asynchronous controllers,
because you can build faster systems with them. Very large control blocks
can easily be built in this way!
(Anyway, some entertaining comments.)
- Steven Nowick
Columbia University New York, New York
( ESNUG 324 Item 9 ) ---------------------------------------------- [8/99]
Subject: ( ESNUG 323 #3 ) Avanti Apollo P&R Restitching Scan Chains Gotchas
> "I ran into a guy named Al Crouch at the Mentor's Design-For-Test
> booth. He clued me in on a bunch of scan chain problems, so I feel
> obliged to put in a plug for his book "DFT for Digital IC's and
> Embedded Core Systems". Al definitely had a strong opinion that
> Synopsys' Test Compiler is an inferior product. (Probably why
> Mentor Graphics hosted him at their booth).
>
> Here are the scan chain gotchas he told me to watch for if we allow
> Avanti Apollo P&R to restitch the scan chain:
>
> 1) Apollo will not recognize separate clock domains when it
> restitches. It simply routes from flop to nearest flop without
> regard to the clock. To get around this you need to put each
> clock domain on a separate scan chain and explicitly tell Apollo
> which registers are on which chain. (I think that putting each
> chain on it's own enable facilitates this.)
>
> 2) We cannot allow Synopsys to put buffers along the chain. Apollo
> ignores them, routes flop to flop, and leaves the buffers and
> inverters hanging.
>
> 3) Apollo does not have any sense of timing, so when it restitches
> and routes to the flop next door it could cause hold violations.
> Al mentioned a design he had with about 5000 flops. Apollo
> introduced 3000 hold violations.
>
> Email Al_Crouch@prodigy.net w/ questions. He was a really nice guy."
>
> - An Anon Engineer (from the DAC'99 Trip Report)
From: [ A Synopsys Test CAE ]
John,
These issues are real, but they are not as serious as may appear. We have
supported scan chain reordering using Apollo for a couple of years (in the
TestGen product line) with good results. To address the 3 issues above:
1) This workaround is unnecessarily complex. The reordering tool
is driven by commands that can be written out by the scan
insertion tool. The scan chains for reordering do not need
to match the physical scan chains at all, or have any difference
in their controls. If the insertion tool has kept the clock
domains separated, it can tell the reordering tool to do so.
2) This is indeed a problem. Sorry but we don't have an immediate
fix. But this is much less disasterous than (1) and (3).
3) This is a danger, but in the experience of our customers, and of
our test consulting group, it is not worse than the problem of
scan chain clock skew without reordering. Separating the clock
domains, using lockup latches and careful control of clock skew
within each clock domain keeps this problem under control.
As a side note, if there are that many scan shift violations, then the
clock skew is probably so large that there will also be many problems
during capture since ATPG doesn't know which direction the clock skew is
going either.
- [ A Synopsys Test CAE ]
---- ---- ---- ---- ---- ---- ----
> 3) Apollo does not have any sense of timing, so when it restitches
> and routes to the flop next door it could cause hold violations.
> Al mentioned a design he had with about 5000 flops. Apollo
> introduced 3000 hold violations.
From: Zeev Yelin <zeev@avanticorp.com>
Hi John,
I'm not a Apollo expert, so I'll answer only to the third "Gotcha" - the
issue is not a tool one but a library one and is caused by lack of delay
on the SD (Scan D) input. Or, in other words, by a negative difference
between the Clock to D and the Hold time of the driven FF ( assuming
traces of Qi-> Di+1, and Clock traces to Cpi, and Cpi+1 have equivalent
length). So, bottom line, those "violations" are proof that Apollo is
reordering the scan-chain FF in what it was meant to do as close as
possible one to another.
A remedy to this "Gotcha" is to inserting an additional delay on the SD
input as to beef-up the delay in the Qi -> SDi+1, this inflates the FF
cell area a bit. (the price of testability) .
BTW, I bet that the first 2 "Gotchas" are solvable by a more robust
Design Flow/Methodolgy... Though I may be wrong ;-))
- Zeev Yelin, Applications Engineer
Avant! (Israel) Herzelia, Israel
( ESNUG 324 Item 10 ) --------------------------------------------- [8/99]
Subject: Au Contraire! Magma Is Actually Growing Everywhere, Not Shrinking
> So, from the outside looking in, while it appears that Magma made the
> biggest customer impression at DAC - it also appears they may be grabbing
> defeat from the jaws of victory because the industry gossip is that
> Magma's VP of Worldwide Sales, Kevin Lynch (confirmed), Magma's VP of
> North American Sales, Bruce Costello (confirmed), and three of their R&D
> staff (rumored) have all quit. Other bad news for Magma is that Atiq
> Raza, the Prez of AMD, has resigned from AMD. Raza is on the Magma board
> and drove the AMD/Magma relationship. No Raza may mean no Magma at AMD.
>
> - John Cooley (from the DAC'99 Trip Report)
From: Klaus Vongehr <klaus.vongehr@infineon.com>
In Germany, Avant! consultants are leaving the company. A big deal of them
heads for Magma. So Avant! has a problem in offering expert support.
To my knowledge, Magma has impelemented a new approach to layout which so
far other vendors only promise.
- Klaus Vongehr
Infineon/Siemens Munich, Germany
---- ---- ---- ---- ---- ---- ----
From: Howard Pakosh <hpakosh@cgocable.net>
To: (Recipient list suppressed)
Subject: FINAL Avant! Update - July 1999
Ladies and Gentlemen,
I still love the company and the people. But, due to mitigating
circumstances, I must depart.
I'll be taking the Eastern Area Director position with the upstart EDA
company called Magma Design Automation (www.magma-da.com). My first day
will be Monday, August 16th.
I will not be too far away. In fact, I will continue to be based here in
Toronto, taking over the local office here. I'll also be opening a new
office somewhere along Route 128 in Boston. My Canadian phone numbers will
not change (Tel 905/634-4780 Fax 905/634-3385). I'll send you my new email
address when I have one.
I want to thank all of you for the good times I have had here. I look
forward to working with you at Magma.
Yours truly,
Howard Pakosh
---- ---- ---- ---- ---- ---- ----
From: "Robert P. Smith" <bob@magma-da.com>
Dear John,
Recently read your wrap-up of DAC 99. Always enjoyable to read your unique
view of the show. I was very pleased to see that our product name "Blast
Fusion" stuck in people's minds. I also wanted to set the record straight
on a couple of things that you had mentioned in your report. I guess these
just demonstrate how the rumor mill changes and distorts things.
It is true that our former VP of North America Sales (Kevin Lynch) and
Director of Regional Sales (Bruce Costello) recently left the company.
This was an amicable parting of ways due to differences in expectations and
styles. We are very close to announcing our new VP of North America Sales
and have already filled the Director position. Life goes on. Also, we
just recently announced that Seiji Miwa, former chairman of Cadence Japan
has just joined Magma to be chairman of Magma Japan.
It is not at all true that we have lost R&D people. This must be a rumor
that one of our competitors planted. In fact, we entered DAC with about 82
people on board; we are now up to 96. We haven't lost a single R&D person;
in fact there has been 0 turnover in R&D over the past year.
AMD is one of the many important customers of Magma. And, although Atiq
was certainly aware of what we were doing at AMD he was at least 2 levels
removed from the ongoing work that we are doing at AMD. In fact, our
results are extremely positive. So we don't see any impact there with
respect to our ongoing business relationship with AMD.
I'd be glad to host a visit with you if/when you're out in Silicon Valley
and we can share more with you about our plans and observations.
Best regards,
- Robert P. Smith, VP of Marketing
Magma Cupertino, CA
( ESNUG 324 Item 11 ) --------------------------------------------- [8/99]
Subject: ( ESNUG 323 #17 ) OrCAD's Big Brother Infomercial eCapture Strategy
> O.K., so we announced that we're giving away access to all this data to
> OrCAD users, and we're even providing a free application (eCapture) so
> non-OrCAD users can take advantage. What's the catch? When you drag a
> component from activeparts.com into your design, we keep track of it. We
> use that information to build a profile. These profiles have the same
> intent as the cards you fill out when you subscribe to magazines to
> receive a FREE subscription. They make it possible for our sponsors
> (primarily component manufacturers and their suppliers) to display
> messages specific to you about stuff they think you need to know about.
>
> - Jim Plymale, VP of Marketing
> OrCAD, Inc.
From: "Bruce A. Loyer" <bruce.loyer@amd.com>
John,
It is very sad that OrCAD is so clueless about privacy. They apparently do
not understand that programs on our computers do not have the right to
gather information of any kind and then send it out.
A better method would be to develop a database of the parts that are being
used and to ask if the user wants to do an update of what is available on
the network.
By the way, do not trust the "Privacy Notices" that you see. When read
carefully, they do not promise very much. Of course, most people do
not have time to read them carefully so they will be lulled into a false
sense of security. Which is the purpose of the notice.
Saying "We understand that the data we're collecting is highly sensitive
and we intend to protect it." could be translated to: "We charge a lot of
money to others for your email address and we will make sure no one gets
it for free."
- Bruce A. Loyer
AMD
( ESNUG 324 Item 12 ) --------------------------------------------- [8/99]
Subject: Silicon Forest Ain't A Code Coverage Tool, It's White Box Stuff
> "Silicon Forest is unusable. If I can't understand the demo for
> something as simple as functional verification coverage in 5 minutes,
> they don't understand what problem they are trying to solve.
> ( http://www.sifr.com )"
>
> - An Anon Engineer (from the DAC'99 Trip Report)
From: "Cliff Lyons" <cliff_lyons@SiFR.com>
Hello John,
Thank you for mentioning Silicon Forest Research in a recent ESNUG.
Evidently someone came to our DAC booth looking for an RTL code coverage
tool and concluded that our product wouldn't solve his problem. We
agree -- we're not in the RTL code coverage business. What we do is RTL
White-Box Verification to find hidden bugs in Verilog designs. We analyze
a design's microarchitecture, find optimal internal test points for
detecting errors, automatically synthesize assertions, and then check for
correct circuit behavior during simulation.
We apologize for the misunderstanding.
- Cliff Lyons
Silicon Forest Research, Inc.
( ESNUG 324 Item 13 ) --------------------------------------------- [8/99]
Subject: Advantages Of Writing Synthesizable Testbenches For Your Designs
> Hello, Is there any practical use of synthesized testbenches?
> Does it help simulation in any way?
>
> - Shardendu Pandey
From: rajesh52@hotmail.com ( Rajesh Bawankule )
I have seen some companies creating synthesized testbenches to test complex
hardware in short time. They design a chip, preferrably a FPGA, which
generates complex test environment scenario.
Test bench code which is synthesizable is put in tester FPGA. Benefits:
- Test bench runs with your prototype chip at much higher speed.
Generally 1-10 MHz.
- Test bench can be modified by setting different environment parameters.
This generally done with accompanying driver etc.
If your questions is regarding writing testbenches in synthesizable style
purely for simulation then I think it is waste of time. Instead of that
one should write behavioral code. Behavioural code is easy to create,
understand and maintain. It can also generate various test bench
conditions with few lines of code.
- Rajesh Bawankule
---- ---- ---- ---- ---- ---- ----
From: tims@synopsys.com (Tim Schneider)
The other thing to think about... if you're planning on targeting an
accellerator/emulator, then a synthesized tbench can be of great benefit.
Usually difficult to implement though.
- Tim Schneider
Synopsys
---- ---- ---- ---- ---- ---- ----
From: jcooley@world.std.com (John Cooley)
Yes, cycle-based simulators like Cyclone (or hybrid cycle-compiled
simulators like VCS w/ Roadrunner) run MUCH faster with synthesizable
test benches because everything's reduce-able to equation form with
NO time delays. Everything ticks on the clock edge. Have a test bench
in an event driven simulator and it all depends on the event traffic
you have to determine run time (but, generally, event-driven sims can
run as slow as 1/20th a cycle-based sim -- as a rough rule of thumb.)
- John Cooley
the ESNUG guy
---- ---- ---- ---- ---- ---- ----
From: msullivan@ti.com ( Mike Sullivan )
Adding to what John said, beyond simulation it also allows for
porting into the emulation (Quickturn) environment. As well as other
functional verification tools that require synthesizable hardware...
- Mike Sullivan
Texas Instruments
---- ---- ---- ---- ---- ---- ----
From: Jacob_Daniel <myhandle@lucent.com>
Could someone please explain to me the difference between a cycle based
simulator and an even driven one, or the relationship between the two
- Jacob Daniels
Lucent Technologies
---- ---- ---- ---- ---- ---- ----
From: mench@mench.com ( Paul Menchini )
Loosely speaking, an event-driven simulator simulates those devices whose
inputs have changed. The idea is that devices whose inputs are stable
don't change state or their outputs and therefore may be ignored at the
present simulated time. If the proportion of "active" devices is small,
simulation is faster than simulating every device at every time point.
Similarly, a cycle-based simulator tries to gain speed by simulating
devices only on the edges of clocks. Everything that occurs between clock
edges is modeled using unit delay (or no delay, depending on the tool).
- Paul Menchini
Cadence ( a la OrCAD ) Durham, NC
( ESNUG 324 Item 14 ) --------------------------------------------- [8/99]
From: Benoit.Durand@st.com ( Benoit Durand )
Subject: Customer Seeks Dc_shell [Plus Other Related EDA] Vim Syntax Files
Hi john,
I am looking for vim syntax files for dc_shell (script and log) and
others EDA tools syntax files.
- Benoit Durand
STMicroelectronics
( ESNUG 324 Item 15 ) --------------------------------------------- [8/99]
Subject: Porting Synopsys IPO Files Into The Cadence HLD Environment
> A customer is running Cadence's Design Planner (HLD) that uses some
> "synopsys.ipo" file that is supposed to contain information about the
> changes made after synopsys in-place optimization is done. Does anyone
> know how to generate this file from synopsys?
>
> - Robert K. Yu
> CadFarm, Inc. Newark, CA
From: Jean-Marc Calvez <jean-marc.calvez@st.com>
Your customer probably used:
reoptimize_design_changed_list_file_name = "synopsys.ipo"
in his/her script. Check what this variable does exactly in the Synopsys
online documentation...
- Jean-Marc Calvez
STMicroelectronics Grenoble, France
( ESNUG 324 Item 16 ) --------------------------------------------- [8/99]
Subject: The Software Engineers Liked That We Used 'Virtual CPU' From Summit
> Hi. I would like to read the impression of people who used Virtual CPU
> from Summit Design.
>
> - Yoram Stern.
From: dlsnell@my-deja.com ( Dorian Snell )
I have used VCPU for about 6 months on an ARM based project. We brought it
into the design flow late in the cycle and have been very pleased with
the results. We are a small team on a very complex chip and VCPU has
improved our productivity in two ways:
1. It reduces our simulation overhead because the ARM is not using
up cycles in our verilog simulator.
2. It removed a step in our simulation process by allowing us to
run code on a code debugger directly against the verilog (which
the sw guys like), instead of converting it to a binary image for
loading to a verilog memory model for simulation.
Perhaps more importantly, our customer (software developers) likes it
because they can develop code on their own tools in another state and
run it on our verilog with minimal interference from us (sensitive IP
issues). In my opinion, VCPU contributed significantly to our ability
to deliver functional prototype silicon to our customer ahead of their
expectation.
VCPU is not perfect, it has some inherent timing quirks because the code
is not executed on the simulation clock (bus cycles are). However, we
are aware of those issues and have not seen any problem related to them
so far.
- Dorian Snell
|
|
