Editor's Note: There's an English proverb: "He who laughs last, laughs the
hardest." Man, is that true! For the past few years at the farm I'd get
an occassional phone call around dinner time from someone claiming to be
from the "Holliston Police Benevolence Society" or the "Holliston Fireman's
Friends Association". Of course, they were asking for money. And, of
course, I gave them nothing. (Everybody knows these things are scams,
you know...) But this wasn't without it's price, though.
Every time I'd say no to these requests, part of me would be left wondering
if I was secretly now on some list to get crappy police or fire protection
when I needed it the most. It would be one of those quasi-conscious fears
that would lurk in the back of my mind until something else distracted me.
"John, you should have given! You'll pay later..." Not fun.
But I got the last laugh when I finally read in the local newspaper that
these "charities" actually turned out to be telephone scams and the
District Attorney had them under investigation! SEE, I TOLD YA! :^)
- John Cooley
the ESNUG guy
( ESNUG 291 Item 1 ) ----------------------------------------------- [5/98]
From: <plaberge@micronpc.com> ( Paul LaBerge )
Subject: DC 98.02 Has Memory Leaks With Set_driving_cell, & Wide Vectors
Hi, John,
I recently found a new 1998.02 bug.
Seems like 1998.02 has a problem with a large number of inputs (thousands)
and the set_driving_cell command. Most of my inputs are unused. A large
vector is passed in (to transfer configuration information from a central
point) to various sub-modules of my design. FWIW I ran into the problem
using lsi logic's lcbg10p library and the following command.
set_driving_cell -cell N1A -pin Z all_inputs()
There is a memory leak that occurs during mapping. 1997.08 works just fine,
but 1998.02 uses all available memory before completing mapping. Synopsys
knows of the problem, but no fix yet. (Star 54794) The -1 patch does not
fix the problem.
- Paul LaBerge
Micron
( ESNUG 291 Item 2 ) ----------------------------------------------- [5/98]
From: "Sujatha V. Sundararaman" <ssundara@ececs.uc.edu>
Subject: How Do You Convert An NCD File W/ P&R Info Into An Xnf File?
Hello gurus of M1 tools,
I have a question on converting an ncd file to an xnf file. I have an xnf
file in which I have a few RLOC specifications. I have edited the EPIC
layout that this xnf file gives me. Now after saving this EPIC file as a
layout.ncd file I want to retrieve the xnf file with the placement changes.
How can I do this?
In short, how do I convert an ncd file with placement and routing info
back to an xnf file?
- Sujatha Sundararaman
University Of Cincinnati
( ESNUG 291 Item 3 ) ----------------------------------------------- [5/98]
From: Peter.Denyer@Eng.Sun.COM ( Peter Denyer )
Subject: Bad Assumption, Cooley -- UNIX Boxes Are No Longer That Expensive!
John:
As you previously wrote in EE Times:
"Earlier this year, I wrote a column mocking the hoopla Synopsys raised
about porting its tools to Windows NT." (see March 2, page 60) "We
already have lots of Unix boxes, know Unix pretty damn intimately and
have a zillion man-hours invested in Unix-based scripts. OK, so PC
hardware is 75 percent cheaper, but we'll have to climb an ugly learning
curve to use NT well, and porting our hard-earned scripts will be a royal
pain. And either way, EDA software pricing stays the same ... Sounds
like a wash to me."
The "75% cheaper" is an out of date assumption, I think. With the entry
price of an Ultra 5 sitting at $2495, I'd say that an adequately configured
NT box and Ultra/Solaris box are about the same price these days and times.
So, with the software the same price and the platform price just about the
same, the issues seem to come down whose machine is the most stable for
doing those "mission critical" EDA jobs. I lean towards Solaris as an
answer. Of course, I am biased by definition, but with 90% of the new EDA
license revenue going to UNIX, I think a substantial piece of the EDA market
agrees.
Arguments abound as to which platform an engineer should use, but I think a
simple answer is that what ever machine helps you get quality product out of
the door fastest might be a way to think about it.
- Peter Denyer
Sun Microsystems
( ESNUG 291 Item 4 ) ----------------------------------------------- [5/98]
Subject: (ESNUG 289 #13 290 #4) Testing Embeded RAMs Via Full SCAN Chains
> I'm curious if anyone in the chip CAD market can test the embeded RAMs
> through the full scan chain. Are there EDA products/tools that do this?
> Theoretically, you should be able to accomplish this since there are
> Flip-Flops all around the RAMs, which the scan chain has complete control
> over. Plus, I don't really care how many vectors it takes, as long as the
> process is automagic.
>
> - Victor J. Duvanenko
> Truevision
From: [ Kenny from South Park ]
John, I gotta be anon.
Depending on the size of the ram, this is alot of overhead. What I've been
working on lately is an independant RAM BIST test (which LSI can generate
for you automatically) and then I mux in an XOR tree to bypass the RAM
during internal Scan.
For smaller RAMs, I just used the DW RAMs and did an insert_test.
This brings up a good question. LSI is currently saying that they don't
want the scan chain hooked up in the netlist because they can do a better
job or routing if I just do a:
set_scan_configuration -style multiplexed_flip_flop -route false
insert_scan
remove_license Test-Compiler
Does anybody have any experience with this?
- [ Kenny from South Park ]
---- ---- ---- ---- ---- ---- ----
> The problem for trying to test an embedded RAM with a simple full-scan
> chain is that you have side-effect when you are scanning your vector in.
> You need to be able to stop your write-enable to the RAM while you are
> scanning the vector, otherwise every time there is an "active" bit in the
> FF, you will be writing something to the RAM. It would be a very clever
> bit of software that could get around this! Basically you would need a
> pad in test-mode that either directly controlled the write enable or
> allowed a boundary-scan like shadow register update. This latter option
> might break your ATPG software, though.
>
> - Andrew R MacCormack
> SGS-Thomson Microelectronics UK
From: Victor_Duvanenko@truevision.com
Thanks Andrew for pointing out the "write enable problem". However, let's
get creative! I'd be perfectly willing to make "minor/trivial" modifications
to my circuits to make automagic testing of embeded RAMs possible. I'd be
willing to add a test mode during which a certain pin controlled the write
enables on all of my embeded RAMs at the same time. I may even be willing
to place the write enable at the end of a scan chain, so that it doesn't get
effected by other bits when they are shifted in. Maybe clever software could
insert the "minor/trivial" changes. The beauty of testing through externally
generated patterns is that you can change them later if you discover that
there is a failure machanism that the current set of vectors does not catch
(this could be a bit hard with BIST).
Plus, the cost is absolutely minimal in terms of silicon area overhead.
- Victor J. Duvanenko
Truevision
---- ---- ---- ---- ---- ---- ----
From: <charles.small@worldnet.att.net> ( Charles H Small )
I believe that the eventual solution to testing on-board RAM, ROM, and FIFOs
will be little BIST machines that generate the test vectors and addresses on
board rather than using externally applied vectors -- sending in a bunch of
memory test vectors though a JTAG port would take a lot more time.
- Charles H Small
Senior Technical Editor
Computer Design Magazine
---- ---- ---- ---- ---- ---- ----
From: Victor_Duvanenko@truevision.com
Charles,
I believe that you're wrong on this, because whenever I looked at BIST it
just cost too much in silicon area (as a percentage of the RAM) plus the
patterns that the BIST produced were limited. This is where I believe
"software" solutions will win. They will use the existing full-scan chain
(not JTAG as you suggest) and test the embeded RAMs with test patterns.
But, as will everything else it is a trade-off between space and time. But,
I personally prefer the solution of testing embeded RAMs through the
full-scan chain, since it requires no additional gates, but will require
additional CAD tools and tester time.
- Victor J. Duvanenko
Truevision
---- ---- ---- ---- ---- ---- ----
From: <charles.small@worldnet.att.net> ( Charles H Small )
Victor:
Thanks for the reply. If one talks to LogicVision (Canadian BIST firm),
one gets the "BIST is great" pitch. I really don't know who to believe and
appreaciate hearing from an actual user. Have you looked at LogicVision's
products? They claim thorough pattern-based testing. And they claim that
their circuitry is tiny and runs real fast.
Are you familiar with pattern-based testing? It looks for charge leaking
from one RAM cell to another and is based on the actual physical
location of the cells in relation to one another A static test like
scan-chain might not pick up such faults.
Also, testing dynamic RAM at system speeds will reveal more possible faults.
What do you think?
- Charles H Small
Senior Technical Editor
Computer Design Magazine
---- ---- ---- ---- ---- ---- ----
From: Victor_Duvanenko@truevision.com
Charles,
Thank you for the pointer to LogicVision -- I was not aware of them. My
only data point has been LSI's BIST offerings, which are expensive in gates.
I sent a note to LogicVision and will let you know what I think of their
products. My idea of using full-scan chain that's already there to test the
RAMs still stands, since it would have zero-gates of overhead. However, I
don't know if it is feasible in terms of pattern length or pattern
capabilities. Are there any other BIST companies that you know of that I
could contact. Also, I'm very familiar with pattern-based RAM testing,
since I used to design SRAMs.
- Victor J. Duvanenko
Truevision
( ESNUG 291 Item 5 ) ----------------------------------------------- [5/98]
Subject: ( ESNUG 290 #6 ) Hotline's English & Synopsys Skills Lacking
> I am getting really fed up with the Synopsys hotline. Invariably I call
> with a problem and talk to someone who is a poor communicator and who
> seems to have little practical experience with Design Compiler (thankfully
> I am using mainstream tools). I don't understand how Synopsys can accept
> putting someone on the hotline who has trouble communicating verbally and
> in writing. In the last ten years I have worked with engineers who were
> born in India, China, Ireland, U.K., Malaysia, Israel, the former Soviet
> Union, Taiwan, and the U.S. and none has had as much trouble communicating
> as some of the folks on the Synopsys hotline. Once I do get through to
> people they seem to be little more than grunts who need a test case to
> reproduce my problem. I have not found engineers who can take a problem
> description and hypothesize causes and/or solutions. Most don't even try.
From: [ Father Knows Best ]
I concur 1000%! I avoid the hotline and use the Solvit submittals. Although
response times range from a record 4 hours to 36 hours. I also have to
describe the problem in the same manner that I describe things to my 8 year
old son. I always assume that the support personnel have NEVER designed a
circuit in their life and don't have a clue as to what the tools are for.
If I give them sufficient information for the error to be reproduced, they
will then locate a knowledgable engineer to get a resolution. After another
couple of e-mail exchanges I can usually even get them to file a STAR. It
appears to be official Synopsys policy that if a work-around can be found,
then the problem does not need to be fixed!
In short, Synopsys support sucks like a category 5 tornado.
Obviously, I need to be annonymous to keep even the trivial level of
support from Synopsys.
Thanks for all of your effort in running this unbiased Synopsys forum!
- [ Father Knows Best ]
---- ---- ---- ---- ---- ---- ----
From: [ Lawrence of Arabia ]
John,
In response to ESNUG 290 #6, I agree 100% with the writer. I have the same
problem with the hot line. It takes a lot of effort and time to explain the
problem and let them understand the issues. When they do understand,
sometime the problem is worst by trying to understand what they are saying.
I guess that is enough, all I want to say is that, I share the frustration
with the writer. Just for the record I am not fluent in english language
either but I am not answering phones.
Pleae keep me anonymous,
- [ Lawrence of Arabia ]
---- ---- ---- ---- ---- ---- ----
From: [ Abe Lincoln Wannabe ]
Hi, John,
Please keep me anonymous.
I AGREE, but Synopsys is not the only offender. Cadence is worse by my
experience. Worse than their command of English is the lack of real
understanding of the tools. Most of these guys have never done a real
design, and don't know why anyone would even care. Often they relay
messages from customer to factory and back along with a liberal dose of
translation noise (in both directions). Most effective engineers find
other ways to deal with EDA vendors to get around the so called support
centers.
QUESTION: How should an EDA vendor distinguish novice user questions
from experienced users with serious technical bugs?
Also, how much would we the EDA tool using community be willing to pay for
support personel with real knowledge and a good command of communications?
- [ Abe Lincoln Wannabe ]
( ESNUG 291 Item 6 ) ----------------------------------------------- [5/98]
From: Peter Kamphuis <kamphuis@hl.siemens.de>
Subject: "Synapropos" -- A Synopsys Equivalent Of The UNIX "Apropos" Command
Hi John,
Recently I had the problem that I didn't know exactly what Synopsys
synthesis command to use. For UNIX commands one could find something with
the "apropos" command. I have a paper version of the synthesis quick
reference available, but I thought there must be another way. I wrote
together a few lines of Perl code (see below) and what I got was a kind of
"apropos" command for the Synopsys synthesis commands: "synapropos". It
extracts data from the Synopsys man pages and I think it might be useful
for many other Synopsys users.
If, for instance, you want to know what command to use to report loads
on nets, try
synapropos net load
You'll see what you were looking for was "report_internal_loads". You'll
also get a short description of the possible commands found. If you also
want to know the syntax of commands you could use "-s". In this way you can
also directly find out the syntax of specific commands:
synapropos -s optimize_registers
Within DC or DA you could use the alias "alias apropos sh synapropos".
Oh, maybe it is possible to create a so-called "whatis" or "apropos"
database for the Synopsys man pages and use the UNIX "apropos" command,
but I didn't want to change our Synopsys installation.
- Peter Kamphuis
Siemens Semiconductor Group, Munich
#!/usr/local/bin/perl
#
# synapropos - Apropos for Synopsys synthesis commands
#
# May-98, Initial version by
# Peter Kamphuis, Siemens AG Semiconductor Group, Munich
# kamphuis@hl.siemens.de
# Command line
require 'getopts.pl';
$pname = substr($0,rindex($0,"/")+1);
$usage = "Usage: $pname [-s] search_string...\n (-s prints syntax)\n";
die($usage) if !&Getopts('s') || scalar(@ARGV) == 0;
@search = @ARGV;
# Get man file directory
die("$pname: \$SYNOPSYS not set\n") unless length($ENV{'SYNOPSYS'});
$manpath = $ENV{'SYNOPSYS'} . "/doc/syn/man/cat2";
# Get man files sorted
die("$pname: Can't cd to $manpath\n") unless chdir($manpath);
opendir(DH,"."); # Would `/usr/bin/ls` be better?
@manfiles = readdir(DH);
closedir(DH);
@manfiles = sort(@manfiles);
shift(@manfiles); shift(@manfiles); # Get rid of "." and ".."
# Process all man files
fe: foreach $manfile (@manfiles) {
$ARGV[0] = $manfile;
$inname = $insyntax = $found = 0;
$name = $syntax = "";
# Collect in NAME (and SYNTAX) section of each man file
wl: while (<>) {
next wl if /^\s*$/ && !$insyntax; # No newlines, except in SYNTAX
last wl if /ARGUMENTS/; # Expected after SYNTAX
$insyntax = 1, $inname = 0, next wl if /SYNTAX/; # End NAME, start SYNTAX
$syntax .= $_ if $opt_s && $insyntax; # Collect SYNTAX
$inname = 1, next wl if /_N_A_M_E/; # Start NAME
$name .= $_ if $inname; # Collect NAME
}
next fe if !$insyntax; # Skip man file if no SYNTAX
# Check for all search words in NAME section
foreach $search (@search) {
$found++ if $name =~ /$search/i; # Case insensitive
}
# Output NAME (and SYNTAX) section if all search words were present
if ($found == scalar(@search)) {
print("\n$name");
print("\n$syntax") if $opt_s;
}
}
exit;
# EoF
( ESNUG 291 Item 7 ) ----------------------------------------------- [5/98]
Subject: ( ESNUG 288 #11 ) What's The Skinny On Aspec, Leda, and Virage?
> To reduce the risk involved in this project, we're leaning towards a
> library provider (Standard cell, I/O and RAM/ROM) that can also provide
> the design services. (No library-integration-finger-pointing, missing
> views, learning curves, etc.) Unfortunately this limits the field to
> just Aspec. .. Are there any designer references out there willing to
> praise [punish] Aspec and their library and/or design service offerings?
> Reasons to use libraries from Leda Systems, and RAM/ROM from Virage?
From: [ Beetlejuice ]
John -
I too would also like to keep my company name anonymous because we are still
in the process of evaluations. We are in a similar position in that our
company would like to work with a library vendor which provides "backend"
ASIC services along with standard cells, I/O and memory library components.
We like this model because:
1: We are a small brand new startup so the traditional ASIC providers are
reluctant to give us a good deal, if they even return our calls
2: We get good pricing from IBM, Charter, UMC ... if we give them masks
and just buy wafers
3: We are really aggressive so we need very responsive "backend" services.
If something needs tweeked or customized to squeeze every last ns out
of a path, we need to have a way to put those polygons exactly where
they need to go.
I'd like to point out that in addition to Aspec, NurLogic Design provides
the full service "backend" capability, too. Regarding library performance,
we've evaluated several std cell libraries and NurLogic's library is by far
the best library we have seen at .35 and .25. Their 1000+ std cell library
cell set consistently achieves better area and timing results than other
libraries with Design Compiler. We also like the fact that we can get the
IOs, Rams, DACs, ADC, PLLs, custom cells... that we need from them. Getting
the traditional ASIC guys to do anything special for you is much tougher.
- [ Beetlejuice ]
[ Editor's Note: Besides this e-mail, I recieved 5 other e-mails from sales
and marketing types recommending their own company. Of course, I'm not
going to bother reprinting their ads here in ESNUG. (I figure if there's
no customer writing about how "great" they are, they're not worth
listening to themselves.) I just wanted to point out that there are
quite a few companies hungry to offer such services. In addition, you
may want to read ESNUG 276 #8, 278 #6, and 280 #3 for more actual *user*
opinions about specific companies/services in this design niche. - John ]
( ESNUG 291 Item 8 ) ----------------------------------------------- [5/98]
Subject: ( ESNUG 290 #0 ) Want To Copy Source Code From Inside Microchip
> I got a microchip, its width and length is about 5mm(millimetres), and
> it has probably 40 pins. I want to copy out the source program (set of
> microinstructions) written inside it, and write the codes to a new
> microchip. Because this microchip is so small, it's difficult to find
> the matched tools. Do anyone know what equipment should I use to
> accomplish this job? And what's the type of the equipment, where can
> I get it? Or if any company can do this, would you please let me know.
> Your helps would be highly appreciated.
>
> - Wenqiang
> Chinese Linux User Group Guangzhou, China
From: Sy Wong <sywong@hermix.markv.com>
Wenqiang,
I hope that you are not playing a joke about your need to read the
microcode and also not necessrily intent on stealing. The ESNUG readers
probably will laugh at me also because my experiences were so old.
Actually I did look at a 16-bit microprocessor chip in the mid-70s to
trace the signal progress to find metal breaks. That chip was on
sapphire substrate and had only one metal layer. Modern chips with many
layers may not be possible. I was not stealing design because I designed
that chip myself, all 4400 transistors. The joksters will probably also
laugh at such small transistor counts but that was almost quarter of a
century ago.
That chip had 48 pads in a leadless carrier with top open for
observations. First a very thin layer of gold had to be sputtered on the
chip, cannot be too thin or too thick, which shorts out everything. The
chip was put at an angle in a SEM on special holder with all leads
brought out. When the accelerating voltage was adjusted just right, the
signal voltage will cause different secondary emissions to be collected
and showed up as different contrasts. Very ticklish adjustments. The
processor was asynchronous so that we could single step some test program
through to trace the signal from pads to the inside. With that we did
find the metal breaks and corrected the etching process with new
equipment.
I imaging you can check the microcode or instruction codes in internal
memories also if it is single metal and not obscured. Most
microprocessors are not asynchronous and none I know even in early 80s
used only a single metal layer. Also, my features were humongous by
today's standards, 7.5u. Today's features may be too small and layers
too many. The problem is also you need several chips to adjust the gold
thickness just right. I had entire wafers (huge 2" dia!) to play with.
Also, I had a Ph.D SOS expert from Rockwell as my one-man processing lab
with SEMs to show me how. You probably do not have such help. Needless
to say, it was very, very time-consuming.
Hope this will cool your desire to read the micro-code. I cannot think
of a good reason why anybody wants to do such reverse engineering. If
you are designing a chip with the same instruction set, the time would be
better spent in designing your own microcode or even hardwire it.
May be the ESNUG jokesters were trying to give you good advice but they
need not be so crude.
- Sy Wong
MarkV
( ESNUG 291 Item 9 ) ----------------------------------------------- [5/98]
Subject: ( ESNUG 290 #8 ) The Differences Between RTL & Behavioral Code ?
> Behavioral code is more abstract than RTL (Register Transfer) code.
> Language constructs like loops (for), initial-blocks or events are pure
> behavioral Verilog. RTL code is written with synthesis in mind, since
> tools like Synopsys can map RTL code much better than behavioral (most
> synthesis tools accept only a subset of an HDL).
>
> - Lars Rzymianowicz
> University of Mannheim Germany
From: Dyson.Wilkes@swi055.ericsson.se (Dyson Wilkes)
John:
It seems the discussion about RTL vs. behavioural was mixing up semantic
domains. Most HDLs (e.g. Verilog, VHDL) were defined to have a simulation
semantic (i.e. meaning). Their meaning was defined in terms of what a chunk
of code does when it runs in a simulator.
When the term RTL is introduced and we start to talk about synthesisable
code then we are talking about a synthesis semantic. That is, what the code
means in terms of a hardware implementation.
Between these two we have behavioural synthesis (BS). Given that we do not
(yet) have a standard and open synthesis semantic for RTL synthesis it is
going to be a while before we have one for higher levels of abstraction. The
tricky thing with BS is defining not only what we want the h/w to do be
under what constraints (e.g. how many clock cycles, when to input data
arrives, when do you want the output and in what form).
Current BS tools infer an FSM, a set of operation units and storage units.
RTL infers registers, latches and combinational logic blocks.
Current HDLs as they were defined infer a set of interacting processes
commicating via events on signals.
We need a new language or extensions to the existing HDLs before we can
fully exploit the possibilities of BS technology. One key issue is
the separation of interface from function:
// interface
@(posedge A)
@(posedge clock)
@(posedge clock)
@(posedge clock)
// function
b = !b
The big question is: do we extend or start afreesh. Given the reluctance
of h/w designers to change language, I would assume we are looking at
extensions. In a sense, imposing a synthesis semantic on a simulation
based language constitues an extension. What do the other ESNUGers think?
- Dyson Wilkes
Ericsson
P.S. I was highly ammused to see all the different views on the simulation
sematics of a small chunk of Verilog code. Not one e-mailer quoted the
LRM? I now question anyone who says Verilog is easy to learn!!
( ESNUG 291 Item 10 ) ---------------------------------------------- [5/98]
From: svh@networks.nera.no (Svein Haustveit)
Subject: Synopsys VHDL Compiler Handling Of X"FF" Literal Syntax
When synthsizing VHDL code originally written for AutoLogic II we find that
Synopsys does not support assignments like A <= X"FF" when A is a
standard_logic_vector(7 downto 0). VHDL compiler interprets X"FF" as a
bit_vector and gives an error message because of the difference in types.
We have used this literal syntax in many files and would not like to
rewrite all VHDL. Does anyone have a hint for workaround ?
- Svein Haustveit
NERA
( ESNUG 291 Item 11 ) ---------------------------------------------- [5/98]
Subject: ( ESNUG 288 #2 289 #7 290 #9) Yes, VCS *DOES* Wait For Licences !!
> I want to say that we have NOT removed this feature, and we haven't planned
> to remove it in the next releases either. It's one of those free features
> that VCS users have come to like. Another is the ability to free up a
> license by pressing CTRL-Z.
>
> Our plan is simple, add features/performance without charging for new
> upgrades and to take market share from other simulators. This has been a
> very successful strategy. Anything else simply doesn't make economic sense.
>
> If "Abe Lincoln" and "Neelix" still have trouble with this feature, please
> give us more details on ESNUG so we can help you.
>
> - [ VCS Technical Support ]
From: [ Neelix of the Voyager ]
Hi John,
The story goes something like this: We got VCS4.1.1 and installed it and
tested it against our short regression suite; it passed so everyone was told
that it was ok to use (it's also faster than 4.0). Some of us started to use
it, others were still using 4.0 It was at this time that we discovered
that the wait-for license feature was definitely not working with VCS 4.1.1.
It was repeatable. Unfortunately, I did not note which of the machines
were seeing this failure, i.e., which version of the two revs of Solaris
we were running. I also did not note which versions of the two revs of
gcc we were running. But we had a hard repeatable failure - I thought.
A few days later, the licensing was working. I don't know whether it was
rebooting machines, restarting FLEXlm, or standardizing on one version of
gcc. In any event, the wait-on-license feature is working now. It seems
that the OS, gcc, FLEXlm, and VCS interact in some complex way. So, if you
have a license problem, rebooting and restarting may fix it.
John, I still need to be anonymous.
- [ Neelix of the Voyager ]
---- ---- ---- ---- ---- ---- ----
From: [ Abe Lincoln Wannabe ]
Woops! Unbelievably, we can't reproduce the problem now. I am beginning to
think it had something to do with the flexlm setup (which incidently had
some problems in the time period when we noticed the problem). Me thinks
I spoke too quickly and chopped down the cherry tree with my new axe.
Suspicions with the Synopsys merger (Is Synopsys becoming a Cadence?)
probably didn't help.
- [ Abe Lincoln Wannabe ]
( ESNUG 291 Item 12 ) ---------------------------------------------- [5/98]
Subject: ( ESNUG 289 #4 ) Escalade vs. Summit and Mentor Renoir vs. Speed
> Generally, experienced VHDL users are not very receptive to the use of
> graphical tools, except perhaps for doing complex state machine design.
> Most will concede that it is a lot easier to share information if it
> graphical than textual. Personally. I am for whatever one feels to be
> the most effective. I advocate a mixed approach, with **overall**
> productivity (which includes documentation and reuse) being the objective.
> I consider HDLs as a means to an end, not an end in themselves. The ability
> to easily switch between graphics and text or between languages is IMHO
> the goal.
>
> - John Vincent
> Eastman Kodak Company Rochester, New York
From: Premysl Vaclavik <tnepva@neuroth.co.at>
John,
I tried several times to use graphical entry for a state machine, test
bench and behavioral description of an analog-digital environment but my
efficiency was very poor. I spent simply more time to have it really
readable on the graphical level and to get what I really wanted. I tried
to summarize some points why I do not like this approach:
- unlike VHDL or VERILOG, graphical entry is sw vendor dependend
(Try to port graphical database)
- graphical entry can not use full VHDL capability (I wrote my "last"
VERILOG 4 years ago, so i can not discuss it)
- graphic is human readable only up to certain level of complexity.
(HDL code is more compact)
- instead of HDL i have to learn also available constructs and GUI of
graphical entry tool to get HDL code again.
- synthesizer uses HDL code, not graphic. Why to add more steps to
HDL code - synthesis cycle ?
- graphical description MUST BE complete.
There are always used simplified block/circuit diagramms to highlite
and better understand design concept. These were no more readable if
they had to contain ALL details.(I know, this is problem to keep
consistency between a HDL and simplified graphical objects)
- It increases seat/designer costs without increasing a productivity.
Vendor marketing told us to use graphical entry because of documentation,
but if we are quite restrictive, we can keep our VHDL also readable and good
documented. It is strange, that specification/data sheet entry for a chip
design with some kind of formal checks is out of a sw vendors' scope.
- Premysl Vaclavik
Neuroth
---- ---- ---- ---- ---- ---- ----
From: tboydsto@su102s.ess.harris.com (Ted Boydston)
John,
Well, well, well. Sounds like another religous war is about to start.
Another emacs vs vi, VHDL vs Verilog, NT vs Unix. Well, let me throw my
hat in...
First, let me state that I have actually USED one of these tools (Summit
VisualHDL to be exact). And when I mean used, I don't mean "I sat down
and tried to draw a schematic/state-machine, got frustrated, and decided
that the whole tool was not worth it!" Nope, what I mean is our ASIC team
did a multi-bus "traffic-cop" type chip consisting of 170K gates COMPLETELY
in VisualHDL. Let me give you my minuses and pluses on the process.
Minuses:
* - Hated it when I first started, thought it was too cumbersome (sound
familiar)
* - Logic table entry is poor....Summit should take a lesson from Excel.
* - State Machine entry has some limitations, but can be easily overcome.
* - Flowchart editor sometimes produced code that was incorrect when the
flowchart shared pieces of code.
* - Some features were obviously designed by software engineers without
the input of hardware folk. I will not list them, but can tell you
that any hardware person could figure out what I'm talking about.
* - Links to external simulators are limited right now. We use VSS, and
I had to write Perl scripts to manage the process. Summit will be
including VSS and other simulators in future releases. Current support
includes VisualHDL's simulator, QuickVHDL, V-System, and Vantage.
* - It has a scripting language based on Scheme--YACK!!! That's all I
need is to learn a scripting language that only one tool is ever going
to use. Come on guys, how about TCL (smaller YACK), or better yet
Perl (big cheer!)
Pluses:
* - Forces designers into a team environment managed by version control.
The version control feature is implemented in RCS. If the user
wishes, they may use their own version control, including ClearCase.
* - Allows efficient top-down design of code graphically.
* - Allows complex state machines to be represented hierarchialy. This is
a cool feature in that Summit allows any state to be linked to another
state machine. The code then can be generated in the hierarchial
format you drew or flattened for speed. Flowcharts can also be
represented hierarchialy.
* - State machines, with a click of a button, may be represented grey,
one-hot, one-cold, or enumerated. You may, of course, create your
own encoding.
* - Your code is your document. This is a great plus. Now you can print
out your design from VisualHDL and take it to a review without
re-drawing it so others can understand it.
* - Allows more efficient reuse. Once a designer creates a component,
another designer can simply instantiate it into their design from the
library. Although designers can say they can do this with textual
entry, with VisualHDL, the designer has an instant picture (along with
a description) of exactly what the component does.
* - Team design is easier with Visual. The task leader can easily add
signals to your design by simply attaching them at the top level and
updating your design. These new signals then appear in your design
automatically.
* - Ah, yes, no more screwing around with VHDL port maps. This is a
god-send. In the pre-VisualHDL days, we had scripts which would try
to automate the connecting of port-maps, but you always had to go in
and clean up. Now you just draw your schematic and your done.
* - Cool testbenches using VHDL generics can be created with ease. This
plus leads back to the re-use issues. In VisualHDL, generics become a
breeze and most testbench elements can become fully configurable to
most situations.
* - Can easily integrate complex models. Our testbench used Souce Models,
Smart Models, and Hardware Models. As stated before, I wrote scripts
that managed the link between VisualHDL and VSS.
* - Summit's built in simulator allows cause-and-effect analysis. When
you click on an edge on a sim waveform it takes you to the diagram/code
that caused the event. Its great for diagnosing state machine
contention, because it highlights what state your in when the problem
occured.
* - Greatly eases the creation of behavioral code through the use of
flowcharts. Linked with the cause-and-effect simulation capability,
I was able to create behavioral models quickly and with a minimal
amount of code. (Behavioral, in this case, means coding through
loops and waits).
I know, I know, there will be the text-based nay-sayers out their. To them
I say, try it for a complete design cycle, then judge. I myself was one of
those nay-sayers and thought that the tool was awful, till I discovered what
benefits I was really gaining.
Overall, I believe the pluses did out-weight the minuses by good margin. I
hope that other designers have the opportunity I did to try VisualHDL (or
some other GUI-based entry) and get past the initial distain, because I
believe you will come to enjoy using the tool.
- Ted Boydston
Harris Government Aerospace Systems Division
( ESNUG 291 Item 13 ) ---------------------------------------------- [5/98]
From: BKELLEY@alb.asctmd.com ( Brad Kelley )
Subject: HELP -- We've Thrashed For TWO WEEKS Trying To Install DC 98.02 !!!
Please, John,
We are having tremendous difficulty installing our Synopsys Design Compiler
1998.02 release. At a repeatable point in the install script, a directory
is not being created properly, after that things really goes to hell.
Eventually, the UNIX file system for our drive partition gets corrupted,
which causes all sorts of other problems. The first time we were able to get
the UFS restored, now the second time it looks like things are locked up real
good. Not unexpectedly, Synopsys says this is an OS problem, Sun says this
is an application install problem.
Admittedly, we are not UNIX or Synopsys power users, but we're not stupid
either, we've been following the directions and doing prudent things. This
is getting to be very frustrating, it's taken us two weeks to come full
circle, and it's not long before installing the tool is on our critical
path. Neither Sun nor Synopsys has come through with a lot of help yet.
Anybody else seen a similar problem? Any hints on getting either of these
companies to help us with our whopping ONE license each?
- Brad Kelley
Amtech Systems Corp.
|
|
