Subject: ( ESNUG 292 #7) "Synapropos" -- Equivalent Of The UNIX "Apropos"
> 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
From: Scott Evans <scott@NPLab.Com>
John,
Since I am "Germanically" challenged, I used AltaVista's translation
program for this post and got the following:
From: stallmann.pad@sni.de (Juergen stable man)
hello Mr. Kamphuis,
for so a possibility I looked always times. Best thanks for the
Tool and the "generous donation" ;-) to the Synopsys municipality.
Many greetings from Paderborn of the future Siemens colleagues
- Juergen stable man
Siemens Nixdorf information systems, Paderborn
Makes sense to me!
- Scott Evans
(of the "NP Lab" municipality)
( ESNUG 293 Item 1 ) ---------------------------------------------- [6/98]
Subject: ( ESNUG 288 #1 289 #9) "Crack VMC & Win $75,000" Deadline Extended
> If Synopsys was really serious, this contest wouldn't have a time limit
> of only 6 weeks. Most serious decryption challenges have a timescale of
> years.
>
> - Howard Landman
> Toshiba America Electronic Components
From: Moe Shahdad <mshahdad@Synopsys.COM>
Dear John,
We've decided -- based on feedback from both judges & contest entrants -- to
extend the SecureIP Challenge through the summer. A number of entrants
felt that the six week window of the contest didn't give them a fair amount
of time with the model. As of the official end of the contest on May 15,
we had no qualified entries, and in the interest of fairness and because we
think VMC is up the challenge, we decided that the best thing to do was to
continue the contest a bit longer.
We're convinced that VMC's protection isn't going to be cracked but we want
contestants to have a fair opportunity to try. We know the source code is
completely secure, but we also believe that it is possible for someone
dedicated to the effort to win the "alternate prize" (by providing HDL
source code that is functionally equivalent to the actual model source code
and synthesizable using Design Compiler). So, we'll continue the contest
through the summer. Same rules. Same prizes. Plenty of time.
We'll announce this on the Synopsys website starting immediately and will
contact everyone who has downloaded the model to let them know about the
extension.
- Moe Shahdad
Synopsys Simulation Tools Group
( ESNUG 293 Item 2 ) ---------------------------------------------- [6/98]
Subject: ( ESNUG 292 #3 ) How Do You Force DC To Put Only One Gate Per Input?
> 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
From: david.laing@analog.com (David Laing)
John, try
set_max_fanout 1 find(port,"name_of_input_port")
If this doesnt work check the 'fanout_load' values of your library cells in
case they are defined with fractional values, in which case in place of 1
use a minimum inverter/buffer input pin fanout_load value.
- David Laing
Analog Devices Newbury, UK
---- ---- ---- ---- ---- ---- ----
From: [ Synopsys R&D ]
Benoit,
Try: set_max_fanout 1 all_inputs() - clk
- [ Synopsys R&D ]
---- ---- ---- ---- ---- ---- ----
From: Oren Rubinstein <oren@gigapixel.com>
Hi John,
If you really want only one gate, try this:
set_max_fanout 1 all_inputs() - whatever_your_clock_name_is
What I usually use is set_max_transition, though. It gives it more freedom.
- Oren Rubinstein
GigaPixel Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: Tim McDonough <tmm@sdd.hp.com>
John,
How 'bout the "set_max_fanout" command?
- Tim McDonough
Hewlett-Packard
( ESNUG 293 Item 3 ) ---------------------------------------------- [6/98]
From: Sue_Keppie@mitel.com (Sue Keppie)
Subject: "Women In EDA" pre-DAC Conference (Sunday, June 14, 9:00 - 4:00)
John,
Thanks for sending this mail about 'Women in EDA'. It was interesting just
to read the agenda. It's even motivated me into thinking about where I
want to go with my own career! Which has taken a bit of a back burner while
I had my 2 little ones (age 4 and 1).
I don't suppose you'd know anyone going wanting to do a summary or know of a
web page or anything ?
Also this is my chance to say thanks for all the ESNUGs and mails that you
send out, what would us Synopsys users do without you !
Keep up the good work.
- Sue Keppie
Senior Apps. Support Engineer
Mitel Semiconductor Devon, UK
[ Editor's Note: I plan to also write about this part of DAC as part of
my overall DAC review. And, yes, the review will be a collaborative
work from surveying what the DAC attendees saw/thought/felt. - John ]
( ESNUG 293 Item 4 ) ---------------------------------------------- [6/98]
Subject: ( ESNUG 292 #2 ) More Letters From Users Supporting Linux
> 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: Peter Kamphuis <kamphuis@hl.siemens.de>
Hi John,
I've just read your latest ESNUG post and I really like these these
discussions on Linux - NT. I'm a great Linux fan, too, at home. When will
the "world" understand that these Micro$oft OSes are only nice for playing
games and for doing secretary jobs. When will people stop sending me
M$-Word documents instead of plain ASCII text...
- Peter Kamphuis
Siemens AG Munich
---- ---- ---- ---- ---- ---- ----
From: [ Somewhere In Symbios ]
Anonymous, Please.
Yes, a port of EDA tools to Linux would permit us to keep our UNIX scripts,
but didn't Synopsys commit only to a port to NT? I didn't hear them say
Linux was an option they are considering. But then again as Perl is the
script language of choice today and emacs is already available on the PC,
the pain to move is low. On the other hand with the price of Sun
workstations dropping the way they have, why go through even a small amount
of pain.
- [ Somewhere In Symbios ]
---- ---- ---- ---- ---- ---- ----
From: Miroslav Pokorni <mpokorni@z-ram.com>
Dear Mr. Cooley:
That new NT stuff looks pretty good if you use it for e-mail or to look up
Internet; whatever you get, you usually blame it on the site that you are
visiting (and anyway, e-mail and Internet content are not closely
scrutinized for accuracy by users.) The trouble with NT begins when you
start using an application program where results are correlated and
scrutinized, like CAD. At the first glance, an application seems to work
fine, you start the program and application window is there, you can put in
few lines, save file and use most utilities. The trouble begins when your
design grows large; all of a sudden utilities do not produce expected
results, the screen freezes, you loose some components, your files get
corrupted. At first you blame it on application vendor; their FAEs talk to
the factory, pound keyboards and usually end up suggesting to reinstall
your application.
A natural reaction to this experience is to say that you chose a lousy
supplier of EDA software or they hired incompetent FAEs. After several
iterations and scores of other failing applications you start beginning to
wonder, is it applications or it is 'Redmond' that is failing.
Time spent on recovering work lost to 'Redmond' whims never gets attention
of management, they just see this 75% less for PC vs. Workstation hardware.
As someone who has a column in a paper, Window iconoclastic as it is, you
might be able to give more exposure to Linux. The purpose would be dual, to
remind rest of us that there is a valid alternative to Windows and to get a
message to Redmond that operating system design is an engineering endeavor
not a hobby.
- Miroslav Pokorni
---- ---- ---- ---- ---- ---- ----
> The company that sells a Linux version of their software, certainly
> gets my attention.
>
> - Bill Schaffer
> Accsyst
From: Peter Denyer <Peter.Denyer@Eng.Sun.COM>
Hi John:
Regarding Bill Schaffer's list of Linux resources in ESNUG Post 292, I'd
like to add one more...
http://www.stardivision.com
For all those Linux (and Solaris, for that matter) users running a
"Microsoft free" environment but would like a well integrated Office
Productivity suite, StarOffice has a lot going for it, not the least of
which for personal use on OpenLinux it is FREE. I have used this
application on a Solaris system - word processing, spreadsheet, presentation
graphics, HTML editor, web browser, mailsystem... etc. It's worth a look.
With growing marketshare in Europe and a new office in the USA, these guys
might be able to cause a little distress to the folks in Redmond!
- Peter Denyer
EDA Market Development
Sun Microsystems
( ESNUG 293 Item 5 ) ---------------------------------------------- [6/98]
Subject: (ESNUG 291 #4 292 #5) Opmaxx's New BIST Test Approach
> 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?
>
> - Charles H Small
> Senior Technical Editor
> Computer Design Magazine
From: Cliff Whitmore <cawhitmo@ingr.com>
Charles,
I'm still glad we've stuck with our approach that we documented in your
magazine, pages 83-87, November 1996 -- it is still bearing fruit in terms
of designer productivity and reliable silicon, without degrading
performance.
- Cliff Whitmore
Intergraph Computer Systems
---- ---- ---- ---- ---- ---- ----
From: "Charles H Small" <charles.small@worldnet.att.net>
Cliff:
I just talked to Opmaxx's Bozena (Boh zhen' ah) Kaminska today about their
new BIST product. They use a single technique to test elements of a
mixed-signal design. They design in a test-only feedback path around the
element, let it oscillate, and deduce go/no-go results from the frequency of
oscillation. They are sending me copies of papers they have presented on
this subject.
- Charles H Small
Senior Technical Editor
Computer Design Magazine
( ESNUG 293 Item 6 ) ---------------------------------------------- [6/98]
Subject: ( ESNUG 292 #2 ) Not Happy About Mentor Refusing To Go To Linux
> 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
From: Michael Dantzer <Dantzer_Michael/nmpcph@nmp.nokia.com>
Hi John,
I'm absolutely thrilled to read ESNUG 292 Item 2! :-) Way to go!!
I actually had Linux as a question at MUG 96, but unfortunately I was unable
to attend and state my case. :-( When I restated my question for MUG 97
they told me that it had been asked @ MUG 96 and there hadn't been any
interest (horror!!)
I sure hope your column will pave the way for Linux.
- Michael Dantzer
Nokia Mobile Phones
---- ---- ---- ---- ---- ---- ----
From: Michael Dantzer <Dantzer_Michael/nmpcph@nmp.nokia.com>
To: [ Wally Rhines, CEO of Mentor ]
Dear Mr. Rhines,
I'm sorry to bother you, but I have to be sure that you read ESNUG Post 292
Item 2! Please read it, these are real voters^H^H^H^H^H^Hcustomers
speaking. :-)
- Michael Dantzer
Nokia Mobile Phones
( ESNUG 293 Item 7 ) ---------------------------------------------- [6/98]
Subject: ( ESNUG 292 #2 ) Letting Occassional Non-technical Views In ESNUG
> 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: "Bruce Loyer" <bloyer@bad.amd.com>
John;
I appreciate your trying to be fair and allow others their comments but I
think Barry Williams' was not commenting so much as sticking his two cents
in. ESNUG is not the place for a religious debate nor a pulpit for anyone
who does not know when it is appropriate. Please take this memo as giving
you free rein to edit out such comments in the future.
Thanks for doing such a good job. I would not bother trying to make ESNUG
better if I did not think it was great.
- Bruce A. Loyer
AMD
---- ---- ---- ---- ---- ---- ----
From: wec@mlb.semi.harris.com (Bill Clifton)
John,
I appreciate that you allowed a civil philosophical response to your
"personal growth seminar" experience. In this day of "political
correctness" and "spin doctors", this provided a refreshing objectivity
that is symbolic of the ESNUG public forum & a credit to you the moderator.
- Bill Clifton
Harris Semiconductor
( ESNUG 293 Item 8 ) ---------------------------------------------- [6/98]
Subject: ( ESNUG 292 #2 ) There Are PCs That Can Handle BIG Designs
> 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 & layouts that
> take the biggest, baddest Sun workstation that I can get my hands on. My
> current simulations won't run w/ under 512 Mb of RAM for batch simulations
> and interactive debug takes over that. My current Ultra 2 has 896 Mb & 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.
>
> - [ The Artful Dodger ]
From: Steve Sherman <steve_sherman@3com.com>
Hi, John!
I hope I don't ruffle feathers here at work. But, I do want to reply to
this one ...
We solved this problem at one time by getting PC servers. Mine had 2
processors that could share 1 GB of memory. I ran simulations on it with
Model Tech on NT and it seemd to have comparable times versus the same
design on Model Tech on our Unix boxes. (Our tests showed the PC to
actually be a little faster at the time.) We bought my server from a major
vendor, even though I offered to build it myself. (I've built my own
systems at home and it's about an evening to set one up.) To stay in line
with what the company is doing, my group eventually went completely to Unix
boxes for simulation. But, initially we were using both Unix and PCs to
simulate our designs. I found that if you stay with industry standards
(tools common to Unix and Windows/DOS, C, Verilog and VHDL) portability
between platforms & operating systems can be more or less readily supported.
My impression is that in the future, successful design environments will
readily move between platforms, operating systems, languages and methods.
Engineers need to be able to master and move with the environments. It
will all be part of establishing and maintaining the balance necessary to
successfully compete in rapidly changing markets. I think engineers need
to learn to work with all of the de facto standards to compete and not tree
hug any one standard.
- Steve Sherman
3Com Boxboro, MA
---- ---- ---- ---- ---- ---- ----
From: "Cliff Whitmore" <cawhitmo@ingr.com>
John,
In response to "The Artful Dodger", here's a personal marketing plug for a
workstation-class "PC" that is well-suited to run LINUX and NT...
We are currently running Veribest simulations (under NT!) on Intergraph
workstations outfitted with 1 GB of RAM. The simulation data structure for
our RTL code is larger than 512 MB, which makes having 1 GB of memory quite
helpful.
- Cliff Whitmore
Intergraph Computer Systems
---- ---- ---- ---- ---- ---- ----
From: Gavin Brebner <gavin_brebner@grenoble.hp.com>
John,
Answer to this question can be found at :
http://www.hp.com/kayak/
1 GB PC workstations are here.
- Gavin Brebner
Hewlett-Packard Grenoble, France
( ESNUG 293 Item 9 ) ---------------------------------------------- [6/98]
Subject: ( ESNUG 291 #10 292 #8) Synopsys VHDL Compiler Handling Of X"FF"
> 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 ]
From: Tim Davis <timdavis@tdcon.com>
Perhaps Anon is refering to the 1987 LRM in his message. Anon is however
correct that the use of such a feature is not likely to be portable
-- especially in a world where the big guns can trample on standards simply
because they feel like it.At any rate perhaps Cadence and Synopsys engineers
should read the LRM and implement the language semantics as described.
The "syntax" of the following statement is perfectly legal by the 1987 and
1993 lrm. (It parses just fine but the semantics are different for the
1993 LRM vs the 1987 LRM)
constant temp1 : std_logic_vector(3 downto 0) := X"9";
Some people seem to be confusing X"9" which is a "bit string literal" with
the built in type "bit vector". Their meanings are completely seperate. No
where in the 1993 LRM section on literals does it say that X"9" is a bit
vector or that it's elements are of type bit. (It did say that in the 1987
LRM). What the 1993 LRM says is that the bit string literal X"9" is
*equivalent* to the string literal "1001". Hence, where ever you could write
temp1 <= "1001";
you could also write
temp1 <= X"9";
The 1993 LRM modified the "semantics" of literal constants so assignments of
the type used by Svein are legal. See 1993 LRM Page 177-178. The example
is quite pertinent. See page 102, line 341 for discussion of literal
operands - it says that the type of the bit string literal must be
determinable from the context in which it appears. That tells me that the
compiler should have no trouble recognizing that the X"9" in the declaration
above as a std_logic_vector.
If the tool supplied by your EDA vendor craps out on something as simple as
literal constants I would recomend writing the President of the EDA company
a letter. (CC your own President). Include a copy of the invoice with the
purchase price circled and ask why his/her engineers didn't follow the
published standard and ask how he justifies the purchase price when they
write such poor code.
Also ask for a 25% refund. Or better yet, throw their software away and buy
some stuff that runs under Linux.
If Synopsys doesn't parse the above code correctly it would be my impression
that they have just proved that their code is from the Dark Ages (You know
-- the schematicizoic era... Or perhaps from Art's PhD thesis... :)
- Tim Davis
Timothy Davis Consulting Broomfield, CO
---- ---- ---- ---- ---- ---- ----
>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...)
From: koontz@netapp.com (David Koontz)
If Synopsys told you a bit_vector can't be assigned to a std_logic value
they were, eh, er, mistaken. Note the examples given in 13.7 or LRM93;
13.7 Bit string literals
...
Example:
B"1111_1111_1111" -- Equivalent to the string literal "111111111111"
X"FFF" -- Equivalent to B"1111_1111_1111"
O"777" -- Equivalent to B"111_111_111"
X"777" -- Equivalent to B"0111_0111_0111"
constant c1: STRING := B"1111_1111_1111";
constant c2: BIT_VECTOR := X"FFF";
type MVL is ('X', '0', '1', 'Z');
type MVL_VECTOR is array (NATURAL range <>) of MVL;
constant c3: MVL_VECTOR := O"777";
assert c1'LENGTH = 12 and
c2'LENGTH = 12 and
c3 = "111111111";
--
The value assigned a constant is an expression:
4.3.1.1 Constant declarations
A constant declaration declares a constant of the specified type. Such a
constant is an explicitly declared constant.
constant_declaration ::=
constant identifier_list : subtype_indication [ := expression ] ;
--
Appendix A:
expression
relation
shift_expression
simple_expression
term
factor
primary
literal
literal ::= [ 7.3.1]
numeric_literal
| enumeration_literal
| string_literal
| bit_string_literal
| null
7.3.1 Literals
...
String and bit string literals are representations of one-dimensional
arrays of characters. The type of a string or bit string literal must be
determinable solely from the context in which the literal appears, excluding
the literal itself but using the fact that the type of the literal must be
a one-dimensional array of a character type. The lexical structure of
string and bit string literals is defined in Section 13, Lexical Elements.
...
--
The above paragraph is changed from LRM87, where the equivalent for a
bit string literal was type BIT.
The problem isn't VHDL but the implementation being dated. Paul Menchini
has gotten rights to the VHDL87 manual because a) IEEE does not support it,
and b) Synospsys only does for their design compiler.
(To support bit string literals, pretend they are string literals)
- David Koontz
NETAPP
( ESNUG 293 Item 10 ) --------------------------------------------- [6/98]
Subject: Electromigration Failures, Reliability, & Metal Coverage
> Can someone, please, explain me OR point me to articles on the subject
> WHY metal coverage is needed. I know that if such not done, metal etching
> will cause minimum-width metals to disconect due to over-etch, BUT would
> like to understand WHY..?
>
> - Yehuda D. Yizraeli
> Zoran Microelectronics Ltd. Haifa, Israel
From: David Shain <dshain@nr.infi.net>
If Aluminimum is usually half to 1 micron thick & if there is a severe
step, like into a contact, or over some underlying topography, thinning
can occur. If you only have 10% step coverage then the metal will only
be .05 to .1 microns. There is a problem with this well before
"catastrophic" disconnect. The problem is a reliability issue associated
with high current density. Alumimum interconnects are subject to
degrading when subjected to high current densities. when a line is
thinned to 10% of it's designed thickness, that means the current
density can be 10 times higher than allowed. The aluminimum line will
fail as a result.
In the days of wet etch, over etch was a problem with thin lines, but
now with dry etch you usually will not overetch a thing line.
There are also specification on minimum step coverage for yield reasons
that must be met.
- David Shain
---- ---- ---- ---- ---- ---- ----
From: jws@billy.mlb.semi.harris.com (James W. Swonger)
Electromigration failures are the probable basis of the question. High
reliability circuits generally are designed to meet a maximum current
density in interconnect. The metal thickness and width are of interest;
typically the highest current density is found where the interconnect metal
traverses an oxide step topographic feature (contact sidewall, diffusion
oxide cut, poly+ILD, etc.).
There are really two fundamental requirements for interconnect: mechanical
integrity and electrical integrity. The mechanical (ability to hang
together through thermal cycling/shock, stress voids from creep due to
internal tensile stress, etc.) requires some minimum thickness (approx 2kA
is my rule of thumb). Electrical integrity is design & application
dependent; for a decent aluminum system you are looking for a worst case
avg. current density of 2E5 A/cm2 taking into account duty cycle,
topography, & a peak current density of no more than 10X that, maybe less.
The ability of materials to carry high currents for long periods of time
varies with:
- composition: refractory metals are not seen to fail at all; gold
and aluminum are known to electromigrate. Metals of intermediate
melting point and hardness can be expected to have some electro-
migration behavior, I think; e.g. copper will probably fall
between aluminum and molybdenum somewhere. Aluminum interconnect
often contains trace amounts (1-2%) of copper to improve its
current density tolerance. Maximum actual current density is
determined by long term life test under stress, but the Mil
specs impose a fixed limit. Thus in many cases we require only
that the process we are designing in exceeds that value.
- temperature: high temperature is a strong accelerating factor in
electromigration wearout; this mechanism is the primary reason
for most IC processes' 175C junction temperature rating. Search
"Black's Law", "electromigration" in reliability physics periodicals.
- area: notching and thinning of metal lines, designed widths and
processing nonidealities.
The Mil specs call out step coverage percentages as a means of setting some
standards for interconnect step coverage processing acceptance. This is
somewhat wrongheaded, since you can have a thin metal at 70% that's got less
cross-sectional area than thicker metal at 50%. But rules are rules, until
you negotiate.
- James W. Swonger
Harris Semiconductor Melbourne, Florida
( ESNUG 293 Item 11 ) --------------------------------------------- [6/98]
Subject: Designing A Large Circuit But Can't Really Tile With ViewLogic
> I'm designing a fairly large circuit, but only have a letter-sized
> printer, and want to be able to tile my printouts on several pages. Is
> there software anywhere that does that? Xilinx Foundation tiles your
> output, but the scales of the pages are not 100% equal, leading to a
> very annoying-looking output. Also, when I design using ViewLogic,
> tiling doesn't seem to be available at all. Using screen capture
> programs is sort of possible, but very inconvenient. Any suggestions?
> Thanks in advance.
>
> - Vitit Kantabutra
> Idaho State University
From: brian@shapes.demon.co.uk (Brian Drummond)
A cheap A3 printer (color inkjet) would be a help (B-size to you
Americans) like the Canon 4650. I saw the obsolescent 4550 for about
$200 recently, it would do fine.
- Brian Drummond
---- ---- ---- ---- ---- ---- ----
From: simon@VOID.actrix.gen.nz (Simon Peacock)
I've had good experiences with an Epson Color stylus pro xl+. Its got a
flat paper tray unlike the canon (whch hold the paper vertically).
Remember just remove the VOID.
- Simon Peacock
StarLite Design Miramar, Wellington, NEW ZEALAND
---- ---- ---- ---- ---- ---- ----
From: murray@pa.dec.com (Hal Murray)
If you can get postscript output there are probably tiling packages
available. At worst, you can get a postscript hacker to help you write your
own. I'm thinking of some postscript code that you put on the front of
the output before you feed it to the printer.
Such as: cat tile.ps design.ps | lpr
- Hal Murray
DEC Systems Research Center
( ESNUG 293 Item 12 ) --------------------------------------------- [6/98]
Subject: ( ESNUG 291 #13 292 #10 ) Synopsys Installed - Finally !!!
> 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!
>
> - Brad Kelley
> Amtech Systems Corp.
From: BKELLEY@alb.asctmd.com ( Brad Kelley )
John,
The good news: Our Synopsys DC 98.02 has been successfully installed and is
running. Thanks to the people at Sun and Synopsys who provided assistance
to make this happen.
The not so good news: There were several things that we were told to do, so
we're not exactly sure what the real solution was. We got a new motherboard
and disk drive to address the video and disk I/O issues, and we reinstalled
the OS and set up new disk partitions based on the input from Sun. We also
increased the size of the file system for Synopsys, but that was a shot in
the dark since the Synopsys install documentation doesn't state any minimum
requirements. There are also some items in the install instructions that
are very sketchy or just plain wrong, which continues to cause confusion.
The bad news: While we finally got good assistance, there were occassions
where we felt that the support people at Sun were more interested in closing
the service order than in knowing whether our problem was actually solved.
This echoes a thread that has been running the last few weeks.
Anyway, we're off and running, now the REAL work begins.
- Brad Kelley
Amtech Systems Corp.
( ESNUG 293 Item 13 ) --------------------------------------------- [6/98]
From: <plaberge@micronpc.com> Paul LaBerge
Subject: Does Anyone Have dc_perl Running On An HP Machine? Anyone?
John,
I'm still trying to find someone who is using dc_perl on an HP machine.
I'm willing to do some of the work, but need some information to get
started. Can anyone else help?
- Paul LaBerge
Micron
( ESNUG 293 Item 14 ) --------------------------------------------- [6/98]
From: John Louie <john.louie@vlsi.com>
Subject: Power Compiler Problems Involving ARM Cores & Verilog Binaries
Hi John,
What have you heard about Power Compiler? I have used it on some testcases
and it appears to do as advertised but when I try to use it on a larger
scale ...
Well the larger scale means with an ARM core where I need to recompile a
Verilog binary with the objects from the ARM and the PLI, and Synopsys
claims they do not have any customers that use Power Compiler with and ARM
in their design. I find that very hard to believe. Have you heard
differently?
I get that response when I ask for AE support in creating this new Verilog
binary.
- John Louie
VLSI Technology Irvine, CA
|
|
