From: Yatin Trivedi <trivedi@seva.com>
Subject: I Am Missing My ESNUG Sheep Stories ...
Hey John,
Something happened after your early April ESNUG post. I have not seen
any more, and I understand that there have been at least a couple of posts
since then. Did I get dropped? Did you decide to impose your own
sanctions due to India's nuclear tests? I know nothing about this nuclear
stuff! Honest! I swear as a US citizen. (In fact, I had to swear to
become a citizen.) So you can disclose ESNUG info to me. The INS people
say it's OK to ESNUG to me now! Honest!
- Yatin Trivedi
SEVA Technologies Fremont, CA
( ESNUG 292 Item 1 ) ----------------------------------------------- [6/4/98]
From: [ I Came, I Saw, They Conquered ]
Subject: Synopsys Should Catch Up With Avanti In In-Place Optimization
I thought you might be interested in a new product from Avanti. Saturn
(formerly their Solar & Solar II) is a post-layout synthesis & optimization
tool from Avanti that eliminates the need for IPO. Avanti claims that with
VDSM you need a very tight synthesis/layout loop (duh!) to converge and meet
timing goals. The interesting thing is that Avanti has acquired synthesis
technology and stealthily struck at a Synopsys weakness. I find it hard to
believe Avanti's claims, but they claims to support re-sizing gates, pin
swapping, buffer insertion, and boolean optimization for post-layout
optimization. They also claim to work on million gate designs in reasonable
times. They also claim to accurately output Verilog netlists and Synopsys
ECO Compiler scripts (whoa!). (If some or most of this is true, they are
way ahead of Synopsys. Maybe if someone kicks Synopsys in the pants the way
Ambit did, they will finally get their act together with links to layout the
way they did with 1998.02 for large block top-down synthesis. Maybe if you
publicize this, it will happen even faster.)
Feel free to use the previous information any way you want as long as you do
not associate my name with it. Thanks.
- [ I Came, I Saw, They Conquered ]
( ESNUG 292 Item 2 ) ----------------------------------------------- [6/4/98]
Subject: "My Universe Speaks To Me" -- The Windows NT Debate Goes Linux
> "Huh? Are you the last remaining semi-technical person in the world to not
> hear about FreeBSD and Linux? Pretty much Unix to the same extent as SunOS
> or HPUX are, but it runs on PCs." wrote Mike Albaugh of Agames.
>
> Martin Moeller at BBN wrote: "Why is it that an obvious answer is sometimes
> missed? Linux runs on those cheap PC's, is as stable as Sun's OS, comes
> with source code & probably has more developers than Sun and Microsoft
> combined. Porting from Sun or HP Unix to Linux is much easier than
> porting to NT. The most important advantage though is that it is the one
> Operating System that Bill Gates will never be able to buy and 'improve'
> since its free and can't be bought."
> - John Cooley
> Industry Gadfly
From: Todd M Kroeger <toddk@micro.ti.com>
John,
Don't you have a bigger font you could use or something? I still doubt the
"right" people are going to hear the Linix EDA tool message. The funny
thing is (my theory only) the software developers are using Linux at home
so all the major porting has already been done. Do you think there is a
way to get the EDA vendors to admit to this? (P.S. I loved your "Industry
Gadfly" column.)
- Todd Kroeger
Texas Instruments
---- ---- ---- ---- ---- ---- ----
From: [ The Artful Dodger ]
John,
No name, no nothin' please, I suffer from Synopnazicosis, fear of Synopsys
corporate reprisals.
Just read your EDA tools to Linux piece in EE Times, & I have one question:
Where am I going to find a PC that will support 1-2Gb of RAM?
In my corner of the ASIC universe, I still have tons of work to do at the
GATE level. (Eeek, I said the G-word!) I have simulations and layouts that
take the biggest, baddest Sun workstation that I can get my hands on. My
current simulations won't run with under 512 Mb of RAM for batch simulations
and interactive debug takes over that. My current Ultra 2 has 896 Mb and I
expect to break that level by next year. I haven't seen a PC that can
handle more than 256-512 Mb, and I don't know how efficiently NT or Linux
can manage that amount of RAM either.
I've run gate level sims (60K gates) on small designs on the NT box, but
once you start back annotating, you're toast from the performance side. The
delay calculation is a bummer, too.
I can't imagine any kind of efficient environment on the PC. For small
designs and FPGA's, OK. But not for the mainstream of 1 million gate plus
designs, RTL or gates.
- [ The Artful Dodger ]
---- ---- ---- ---- ---- ---- ----
From: Richard_J_McWaters@res.raytheon.com
An interesting thing about the NT port. I just got the Mentor MUG
newsletter, and Mentor wants to charge 20% more to "upgrade" your license
to NT. I don't know if Synopsys is contemplating the same scenario, but I
have to admit, it is a real "in your face" move by Mentor.
- Richard McWaters
Raytheon
---- ---- ---- ---- ---- ---- ----
> For some reason, I keep remembering a bit of wisdom I learned while
> participating in one of those trendy 90s personal growth seminars. We were
> blindfolded and spun around to a random orientation in a room. Our goal
> was to get to one specific location in the room. And our only guide was
> an ominous Voice (which came from no discernable direction) saying either
> "yes" or "no" to our random steps. Very quickly we all made it to our
> goals after some misguided steps. The moral the ominous Voice then told
> us was: "Pay attention to the feedback from your universe. Don't get
> caught up in what you think is the right way to get somewhere because many
> times you're wrong. The universe will give you the direction you need to
> get to your goal if you open yourself up to listen to it."
>
> - John Cooley
> Industry Gadfly
From: "Barry A. Williams" <bawillia@collins.rockwell.com>
John,
Here is real wisdom: Listen to the Creator, not the creation. Only from
God can good, reliable direction come. Yes, He speaks to us in many
different ways. Rejoice in your work for that is why God created you
(see Genesis 2:15). In the name of our one and only Savior Jesus
Christ, Amen.
- Barry Williams
Rockwell Avionics
---- ---- ---- ---- ---- ---- ----
From: Peter Collins <peter@exemplar.com>
John,
So you'll be looking for the EDA on Linux BOF at DAC then? (See dskoll
@chipworks.com for details.) There will also be a panel on Linux vs NT put
together by ISD magazine.
I can confirm that porting UNIX EDA tools to Linux is a breeze. Two of us
ported Exemplar's leonardo and galileo to linux in our spare time over two
weeks. I did the original NT ports in 6 Months!
I've heard through the grapevine that Synopsys has a Linux port in house
and I know that Mentor has Renoir and related tools on Linux, including
integration with Exemplar Linux Leonardo.
So we have all the engineers inside EDA companies dying to bring out Linux
ports of tools. On the other side we have a fair number of engineers who
would love to have their entire EDA flows on Linux. Yet EDA sales/marketing
and engineering managers just aren't getting the message. Maybe we could
borrow your "ominous Voice" and make a few phone calls!
- Peter Collins
Exemplar Logic
---- ---- ---- ---- ---- ---- ----
From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
John -
As my teenage daughters would put it: "way-cool article" about "My Universe
Speaks To Me". I like UNIX workstations and I like Linux on PCs. I
completely agree that Linux is a great operating system for PCs; much better
than any OS from Microsoft.
I believe, however, we are missing the point? I don't think Cadence, Mentor
or Synopsys have ported or have even announced plans to port their tools to
Linux. Or perhaps better said, I believe Cadence, Mentor and Synopsys have
I missed the point, that engineers would gladly use PC hardware if they
could run the tools on Linux instead of NT!
- Cliff Cummings
Sunburst Design Beaverton, OR
---- ---- ---- ---- ---- ---- ----
From: Ross Harvey <ross@teraflop.com>
John,
I'm sending you this letter from a PC happily running NetBSD. Total cost
for sophisticated Unix-based system software: $0.
The press tends to talk up Windows XX a lot because, well, that's what
THEY run... it's what THEY have on their desktops. They don't understand
Unix/Linux/BSD, don't even know exactly what it is. So naturally they
hype-up any kind of an NT trend. Management, also frequently knowing
nothing other than Windows XX tends to lap it up and "go with the fad".
But Windows XXX isn't what us wizards run. :-)
- Ross Harvey
Teraflop
---- ---- ---- ---- ---- ---- ----
From: [ Jean-Luc Picard of the EDA Enterprise ]
Hi John, you said my magic word - Linux! As a former EDA developer, I used
to work with a 133MHz PC, running Win for the office automation and Linux to
compile with gcc. Linux is not only stable, it's *fast*. With gcc, my PC
was twice as fast than a basic, unloaded Ultra1.
I agree there's no technical problem with portings to Linux. The fact is
that EDA vendors don't want to bother with yet another Unix flavor. Why
should they support Linux while some of them are even considering to quiting
with HPUX?
Linux is a true operating system (can you show me how run a remote shell
from a WinNT Workstation?) but industry doesn't take it seriously
(univerisities do). Maybe just because you don't have to pay for it...
or because big companies prefer to pay huge fees not to bother with
maintainance.
The real advantage of Win is the amount of pretty good sw already there (EDA
firms should learn from native-Windows programs how to do GUIs) and Linux is
not competitive in the OA market. So, sadly, I don't see a future for EDA
on Linux, even if it's more robust and performing than WinNT.
(Please keep me anonymous)
- [ Jean-Luc Picard of the EDA Enterprise ]
---- ---- ---- ---- ---- ---- ----
From: "Dr. Ralf Reetz" <ralf@verysys.com>
My quarter of a cent: check out http://www.freehdl.seul.org/ just if you
don't know it already.
- Dr. Ralf Reetz
Verysys GmbH Berlin, Germany
---- ---- ---- ---- ---- ---- ----
From: warren@poci.amis.com ( Cliff Warren )
John,
I've always been someone who has voluntarily opted for a PC over a more
expensive machine. Perhaps I have a problem with using a box that costs
nearly as much as I do, but anyway, I have always been able to have the best
of both worlds. The PC can be used for office automation software, and
then I can just "X" into a Sun to run EDA tools that only run on Unix.
The last week or so has been slow, so I decided to install Linux on half of
my 9 gig disk. Wow, I may be hooked! I was expecting some half-baked deal,
but the creators of Linux have created something technically superior to NT.
Particularly in multitasking, Linux exceeds.
Unless you have one foot in the system administrator camp, one would
probably need help getting it installed and running. After that, the sky is
the limit. I particularly like the KDE window manager, which is something
of a cross between a "Windows" window manager and the CDE window manager
used on many Sparc machines.
- Cliff Warren
American Microsystems, Inc.
---- ---- ---- ---- ---- ---- ----
From: Bill Schaffer <snowman@josey.accsyst.com>
John,
I'd like to add my voice to many pro-Linux letters you've received.
I've been using Linux for almost six years now, and have watched it grow from
a hackers toy into a very solid platform. I personally have been Micro$oft-
free for three years. Almost anything I need to do with a computer, I can do
with Linux, from software development to web surfing to word processing and
office suites.
Anyway, EDA tools under Linux, the one thing that I need to do that I can't.
I feel that Linux has proven itself to be a robust and viable platform. I
have setup some Linux systems that have been running continuously for over
year without rebooting. I talk to many engineers who openly or secretly use
Linux at home, and have been trying to get it into the workplace. If they
could just get the tools to do their jobs with Linux!!!
When there is a Linux version available of a commercial package, I always
recommend going to the Linux solution. The list is small, but growing,
recently WordPerfect 7 was released for Linux, and version 8 is on the way.
I checked out the demo, and it ran nicely on my 486-66.
Getting information about Linux is as easy as falling off a log. Easier
than paying for support from Microsoft, which seems to be making a profit
center out of their technical support department. I have included here a
brief list of Linux resources that are on the web. These are the ones that
I frequent for news and help:
Linux Weekly News, news and info
http://lwn.net/
Linux News, more news and info
http://www.ssc.com/linews
Freshmeat, software release news
http://www.freshmeat.net/
Linux Howto's, howto information and tutorials
http://sunsite.unc.edu/mdw/HOWTO/HOWTO-INDEX-3.html
Linux Docs, a good source for documentation
http://sunsite.unc.edu/mdw
Web Wanderer's Linux application list
http://www.xnet.com/~blatura/linapps.shtml
Linux for Business, Linux's inroads to corporate life
http://www.netnomics.com/linux/
Real-Time Linux, yes, an embedded real time extension
http://luz.cs.nmt.edu/~rtlinux/
And for a Unix to NT comparison, check this out:
http://www.kirch.net/unix-nt.html
Put me down as a vote for porting EDA tools to Linux. By profession, I work
as a Computer Engineer, I do software and hardware. I prefer to work under
Linux. The company that sells a Linux version of their software, certainly
gets my attention.
- Bill Schaffer
Accsyst
( ESNUG 292 Item 3 ) ----------------------------------------------- [6/4/98]
From: Benoit DURAND <benoit_durand@yahoo.com>
Subject: How Do You Force DC To Put Only One Gate Per Input ?
Hi John,
Does anyone knows the way to force dc to connect each input to only one gate
and then build a kind of tree ? I use set_drive with a huge value, but I do
not like this because it produces a huge external delay.
- Benoit Durand
Europe Technologies Nice, France
( ESNUG 292 Item 4 ) ----------------------------------------------- [6/4/98]
Subject: ( ESNUG 290 #6 291 #5 ) Hotline Lacking English/Synopsys Skills
> 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: [ Baba Fet of the Evil Empire ]
John, anonymity must be preserved...
I'm a consultant at Synopsys. I've been here a while now. I'm not
authorized to speak for the company, so what's said here is strictly my own
personal observations. I've worked beside many of the people who are being
criticized here, and I just can't let it pass.
You guys can't imagine what a chore it is, fighting my way in to work at
Synopsys every day through the ravening hoards of experienced design
engineers who are vying for the very few prized openings in Synopsys
Tech. Support, just desperate to get that choice job listening to whining,
insulting and obnoxious engineers like the above calling them on the
telephone all day, each caller taking the attitude that their project is the
only one in the world that's late, that they are Synopsys' number one
priority, and that Synopsys should send them a patch for their particular
problem yesterday, even if it can't be reproduced...
How many "experienced design engineers" do YOU know who would be willing to
take on a helpline job, full-time? And how much would we have to pay you?
If you think Design Compiler license is expensive NOW....
- [ Baba Fet of the Evil Empire ]
---- ---- ---- ---- ---- ---- ----
From: Scott Evans <scott@NPLab.Com>
John,
I feel compelled to provide some defense for the hotline. Providing
software support for a tool as complex as this is very difficult. I have
had to do similar support and even as a developer of the tool it is
extremely difficult to figure out the problem and provide a fix right
away. It is also very difficult to find the right people to do support
work. Most of the people who know or learn enough about the tool to meet
your qualifications prefer the "glamour jobs" of AE's or high price
consultants.
It is important that the people have good phone skills and a reasonable
technical background. I have found that all the people I work with at the
hotline possess these qualities (and I believe I have spoken to everyone
there at least once with all the problems I have).
Since they are the main route to someone who does know the tool much
better you need to work with them and provide what is needed so you can
get an answer in a reasonable amount of time.
It would be nice if any company could provide experienced engineer's who
know the tool inside out and could answer 90% of the questions off the top
of their head, but that is not going to happen, especially in today's job
market.
I have experienced much worse technical support from other CAD companies.
- Scott Evans
NeoParadigm Labs San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: miller@symbol.com (Wayne Miller)
John,
I read the comments on CAE hotline supprt shaking my head vigoriously.
Just as a shimmer of hope out there, Xilinx has done a fantastic job in
improving their hotline support. In my last dozen or so calls, I've always
gotten an actual person, who knows the tools, within a minute or two.
This is unprecidented in the industry and they deserve many cudos. (Plus
my Xilinx support is about 1% of my Cadence/Synopsys support.)
Keep up the good work.
- Wayne Miller
Symbol
---- ---- ---- ---- ---- ---- ----
From: "Vito J. Mazzarino" <vito@Synopsys.COM>
John,
As manager of Synopsys's North American Support Center, I would like to hear
directly from any customers having problems with our services. I was quite
alarmed to read ESNUG 290 #6. Although I take exception to this person's
choice of words, I have to look beyond that & address his (her) frustrations.
Customer Service 101 taught me to "love my complaining customers", at least
I know they still care enough to provide feedback. I want to encourage you
to email me directly to provide open constructive feedback. Communicating
directly is the most effective way for us to build a better partnership. If
I don't know the details of your specific incident, it makes it more
difficult to effect a change that will make us more successful. I'm always
eager to listen to customer needs, so let's talk: vito@synopsys.com.
Thank you,
- Vito J. Mazzarino, Manager
Synopsys Support Center & Automated Services
( ESNUG 292 Item 5 ) ----------------------------------------------- [6/4/98]
Subject: (ESNUG 290 #4 291 #4) Testing Embedded RAMs Via Full SCAN Chains
> 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?
From: samy@corp.cirrus.com (Samy Makar)
John,
1. Scan for RAMS: One thing you have to be very very very careful
about is that even if you use scan to apply patterns to your
rams, you CANNOT use an ATPG to generate the patterns. No matter
how good an ATPG tool you use, the patterns will be very poor.
The problem with is that the stuck-at model that is used for
random combinational logic doesn't cover a lot of the defects
that really occur in the rams. There are other fault models
that are often considered: transition fault, coupling faults, etc.
The good news is that there are simple algorithms for generating
patterns for RAMS, and that's were BIST comes in. Now, it's always
important to separate BIST for rams and BIST for random logic. For RAMS
the area overhead should be quite small. From what we've done here, it
ranged between 600 - 2k gates. I don't remember the size of the RAMS,
but the percentage gets smaller as RAMS get bigger. Now, how do you test
the RAMBIST... with scan of course :)
Apart from LogicVision, there is also Mentor Graphics, Gensys TestWare,
SynTest, and probably some others whose names I've forgotten.
2. Why LSI doesn't want you to insert_scan: I haven't had any
experience with LSI itself, but have dealt with the same problem.
If you do insert_scan before you know the placement of your flip-flops
then you can seriously affect placement and routing results. What
I've seen (and that's using an internal tool) that I can reduce the
stitch wire lengh by 80 to 90% by choosing the chain order after
placement is done. The guys who do the routing really appreciate this.
Of course, I'm only assuming that this is why LSI does not want you to
insert_scan, but they could have other reasons that I'm not aware of.
- Samy Makar, DFT Methodologist
Cirrus Logic
---- ---- ---- ---- ---- ---- ----
> Thank you for the pointer to LogicVision -- I was not aware of them. My
> only data 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 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
From: Charles H Small <charles.small@worldnet.att.net>
John:
I have heard from readers saying that they don't want to "waste" silicon on
BIST. I have also heard from beleaguered test types that they will spend
longer developing a test program for an ASIC that the design types spent
designing it.
Do you suppose that if this situation is true that management will, after
taking a nanosecond's look at the bottom line, try to reign in designers and
have them turn out ASICs that are more testable?
I have my doubts. Designers have been harangued since day one about
designing for test. Would you agree that such considerations -- if they
are considered at all -- go out the window in preference to performance?
- Charles H Small
Senior Technical Editor
Computer Design Magazine
---- ---- ---- ---- ---- ---- ----
From: Chuck Benz <cbenz@nexabit.com>
John,
Just in case you didn't know, and hadn't heard from anyone else, my
experience with LSI's BIST generator was that you didn't use the generated
results directly -- you needed to run it through Synopsys. This cut the
size of the logic for a 512 word by 64 bit 2 port memory nearly in half !
After the fact, an LSI engineer confirmed that this was the right thing to
do. Sounds like there's some inefficient logic generation there. This was
on a 500K design done last summer, at my previous employer, DEC.
- Chuck Benz
Nexabit Networks
---- ---- ---- ---- ---- ---- ----
From: Michael Collier <collier@anchorchips.com>
Hi John,
I have some experience doing ram testing using scan. I didn't get to the
point of automating the process but I don't think that would be to difficult
if the scan interface to the internal rams was standardized in the design
( unfortunately ours wasn't ). We controlled the write enables by not
allowing them to happen when scan enable was asserted ( i.e. when shifting
in the scan pattern). We also had to add one additional flop for each ram
to prevent double write enable pulses.
I ran the scan on a Teradyne A580 tester and I was able to successfully
read and write to the internal rams any pattern I wanted. Test time and
test vector size can become prohibitive with large rams ( we were only doing
16X32 rams) but one easy way to minimize this is to make the ram control
logic on a single short chain. This prevents wasting a lot of cycles
getting data in and out of the chip.
One side to effect to having imbalanced scan chains is that you may increase
you test vector size and test time for normal scan patterns because each
scan vector must clock in the number of cells in the longest chain. The
longest chain is minimized when all chain lengths are equal so any imbalance
creates a longer maximum chain.
It's true the ram testing is not true at speed testing but with a little
clever design and test program work you can control the access time to the
rams. In summary ram testing through scan is doable and does have a minimal
impact on area ( one extra flop per ram). The two drawbacks are no true at
speed testing and increased test time.
- Michael Collier, IC Verification Engineer
Anchor Chips San Diego, CA
---- ---- ---- ---- ---- ---- ----
From: "Michiel Ligthart" <michiel.ligthart@ieee.org>
Hi John:
I recently stumbled on a startup named Syntest who, among other scan test
offerings, does RAM test.
Product name is TurboBIST, I believe. You can find them at www.syntest.com.
- Michiel Ligthart
Ex-Exemplar, Ex-Escalade
( ESNUG 292 Item 6 ) ----------------------------------------------- [6/4/98]
Subject: ( ESNUG 289 #4 291 #2) One User Impressions of Summit's VisualHDL
> 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: ....
>
> * - 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!)
>
> ...
>
> - Ted Boydston
> Harris Government Aerospace Systems Division
From: Uri Farkash <urif@sd.co.il>
Hello, John:
With reference to Ted Boydston's remark about Visual HDL's Scheme and without
entering into any polemic about the subject, my main remark is that Scheme
is not Visual HDL's scripting language but Visual HDL's extension language.
The extension language is the layer between the underlying programming
language(s) in which the bulk of the EDA application is implemented and
the scripting languages (macros or commands).
Scheme is not a language invented by Summit. Summit's extension language
is based on Scheme and provides an extension which allows the user to
access Visual stuff.
The main pros for it:
- IEEE standardization
- belongs to the Lisp family, with extremely simple syntax to learn and
parse (there is a great deal of experience in the industry with Lisp-like
languages as SKILL, Auto-Lisp, ....)
- it was SI2 (CFI) that adopted Scheme as the standard extension language
for CAD applications
Anyway, the Visual user can write scripts in any command language (Perl,
Tcl, ...) and invoke them as part of the Visual session via the Scheme
extension layer.
- Uri Farkash
Customization & Services Manager
Summit Design Inc.
( ESNUG 292 Item 7 ) ----------------------------------------------- [6/4/98]
Subject: ( ESNUG 291 #6 ) "Synapropos" -- Equivalent Of The UNIX "Apropos"
> Hi, John, 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. ...
>
> - Peter Kamphuis
> Siemens Semiconductor Group, Munich
From: steve.ehlers@rss.rockwell.com
I just wanted to let you know that I have already found your synapropos
script useful. Thank you for sharing it!
- Steve Ehlers
Rockwell Semiconductor Systems
---- ---- ---- ---- ---- ---- ----
From: stallmann.pad@sni.de ( Juergen Stallmann )
Hallo Herr Kamphuis,
nach so einer Moeglichkeit habe ich schon immer mal gesucht. Besten Dank
fuer das Tool und die "grosszuegige Spende" ;-) an die Synopsys-Gemeinde.
Viele Gruesse aus Paderborn von den zukuenftigen Siemens-Kollegen
- Juergen Stallmann
Siemens Nixdorf Informationssysteme, Paderborn
( ESNUG 292 Item 8 ) ----------------------------------------------- [6/4/98]
Subject: ( ESNUG 291 #10 ) Synopsys VHDL Compiler Handling Of X"FF"
> 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
From: [ A Cadence ESNUG Fan ]
Hi John,
Synopsys/Cadence politics require that I be anon.
Interpreting X"FF" as 8 1's is a special compact notation provided by
the VHDL language (nee LRM) to the users for bit_vectors only. Any VHDL
compiler that allows this notation for types (which are similiar) like
std_logic_vectors is going beyond the call of duty as prescribed by the
LRM. Further, this is hardly likely to be portable.
I would suggest writing a small lexer like the one below to automatically
convert to modify the compact hex notation in the VHDL source to the bit
string literal form.
- [ A Cadence ESNUG Fan ]
---------------------------cut---here-----------------------------------
%{
#include <stdio.h>
#include <string.h>
static void expandit(char *);
%}
%%
X\"[0-9a-fA-F]+\" { expandit(yytext); }
%%
static void expandit(str)
char *str;
{
str += 2;
printf("\"");
for (;*str != '"';str++) {
switch (*str) {
case '0': printf("0000"); break;
case '1': printf("0001"); break;
case '2': printf("0010"); break;
case '3': printf("0011"); break;
case '4': printf("0100"); break;
case '5': printf("0101"); break;
case '6': printf("0110"); break;
case '7': printf("0111"); break;
case '8': printf("1000"); break;
case '9': printf("1001"); break;
case 'A': case 'a': printf("1010"); break;
case 'B': case 'b': printf("1011"); break;
case 'C': case 'c': printf("1100"); break;
case 'D': case 'd': printf("1101"); break;
case 'E': case 'e': printf("1110"); break;
case 'F': case 'f': printf("1111"); break;
default: printf("Error!!!\n");
}
}
printf("\"");
}
---------------------------till---here---to---file---lexer.l-----------
$ lex lexer.l
$ cc lex.yy.c -ll
---- ---- ---- ---- ---- ---- ----
From: dtkain@CCGATE.HAC.COM ( Dan Kain )
Dear John,
With regard to the question about converting from Hex to std_logic in your
ESNUG 291 posting, I would do the following:
library ieee;
use ieee.std_logic_1164.all;
A <= to_stdlogicvector(x"FF");
- Dan Kain
Hughes Space & Communications
---- ---- ---- ---- ---- ---- ----
From: miller@symbol.com (Wayne Miller)
Here's the fix I got for this problem from Synopsys:
If you try to assign a hexadecimal value to a signal/variable/constant of
type std_logic_vector, you will get a syntax error. The following
statement is syntactically incorrect:
constant temp1 : std_logic_vector(3 downto 0) := X"9";
This does not work since X"9" returns a bit_vector type.
You can work around this by using the "To_StdLogicVector" function
provided in the std_logic_1164 package to convert the bit_vector to a
std_logic_vector. The above statement is modified as follows:
constant temp1 : std_logic_vector(3 downto 0) := To_StdLogicVector(X"9");
(Example code snipped...)
- Wayne Miller
Symbol
( ESNUG 292 Item 9 ) ----------------------------------------------- [6/4/98]
From: Keith Calder <keith.calder@gecm.com>
Subject: DC 98.02 Makes Crappy Initial DesignWare Selections
John,
Design Compiler 98.02 seems to have a problem when selecting arithmetic
components to meet specified timing constraints.
After some experimentation, I have come to the conclusion that the part is
selected on the basis that subsequent optimizations will be able to reduce
worst case delays by a certain, predefined, amount. Unfortunately, this
predefined value appears to be incorrect and on subsequent optimizations the
DesignWare element will be optimized but not sufficiently to meet the timing
requirements.
There can be faster implementations in the Standard or Foundation libraries
but these will not be selected.
I have got around this problem by carrying out an initial low effort
synthesis with faster clock constraints, which selects the required
DesignWare implementation. On then setting the clock constraints to the
desired value a subsequent compilation will then give a design with no
timing violations.
Is there a better way other than selecting individual implementations
within the HDL?
- Keith Calder
GECM
( ESNUG 292 Item 10 ) ---------------------------------------------- [6/4/98]
Subject: ( ESNUG 291 #13 ) We Thrashed For 2 WEEKS Installing 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. ...
>
> - Brad Kelley
> Amtech Systems Corp.
From: BKELLEY@alb.asctmd.com ( Brad Kelley )
John,
One of my colleagues got a phone call from Synopsys right after post 291 was
issued. The guy from Synopsys was all upset that I was taking potshots (my
words) at them when they were trying to help us. My colleague replied that
so far their help had been limited and had yet to show results, and stood
behind me and my post.
Seems that we now have Sun and Synopsys representatives coming out of the
woodwork to help us!
Sun is sending out a new motherboard, due to the disk/file system problems,
and now an odd video problem too. We may have a Sun hardware problem at the
root of this.
- Brad Kelley
Amtech Systems Corp.
|
|
