Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 9275

Article: 9275
Subject: Re: The case for free operating systems and EDA
From: pornin@news.ens.fr (Thomas Pornin)
Date: 5 Mar 1998 14:43:19 GMT
Links: << >>  << T >>  << A >>
In article <3501b34d.270562177@news.netcomuk.co.uk>, Peter <z80@ds2.com> wrote:
>It is not crashproof, of course. It is easily crashed when there are
>hardware-related problems. It is very hard to crash it with most
>normal windoze apps though.

This is where NT differs from Unix. NT is designed to resist standard bugs
in standard applications. Unix is designed to resist malicious attacks in
handmade applications. This is why most people experience much better
stability with Unix (especially Linux but not only) than with NT.

Of course there must be, and there are, NT configurations that truly work
and are stable. Just a matter of luck. If you are in such a situation,
consider yourself as lucky.

	--Thomas Pornin
Article: 9276
Subject: Re: Help with ViewLogic 4
From: k.rozniak@XXX.ien.gda.pl (Krzysztof Rozniak)
Date: Thu, 05 Mar 1998 14:45:00 GMT
Links: << >>  << T >>  << A >>
Thank you for reply, Gavin and Peter.

I managed to find the reason of VL malfunction. The problem was with
too long path. I had path about 180 chars long. None of old programs I
was using complained about it. VL was the first one. I had to shorten
path (now ~65 chars). Since then all works perfectly. Probably VL has
a workspace for path limited to 128 chars (DOS <=6.22 limit IIRC).
Hope it helps someone.

Regards
Chris

--
Christopher Rozniak
Gdansk, Poland, Europe, Earth
E-mail: k.rozniak@XXX.ien.gda.pl
remove anty-spam XXX. to email
Article: 9277
Subject: Re: Viewlogic file format for schematic symbols
From: husby@fnal.gov (Don Husby)
Date: Thu, 05 Mar 1998 14:59:03 GMT
Links: << >>  << T >>  << A >>
> paul:
> : I'd like to find the file format for the symbols created in Viewdraw.
> : These are ASCII files, and I've already done some reverse-engineering
> : and found some of the info. However, as long as this format has been
> : around, I'd be surprised if the information isn't already available.
> 
> rk:
> and i'd like to have a good definition of the sch and wir files too.  i'm
> writing a program to do some automagic and semi-automagic editing of a
> design.

dh:
I've written several tools that manipulate viewlogic files: symbol creators, 
extensions to put PAL-like equations directly on the schematic page, and a 
net-list flattener with mapping control.  The viewlogic file format is pretty 
straightforward and only takes a few minutes to figure out most of the
details.

If you want any of these tools, send me email.



--
Don Husby <husby@fnal.gov>                        Phone: 630-840-3668
Fermi National Accelerator Lab                      Fax: 630-840-5406
Batavia, IL 60510
Article: 9278
Subject: Re: Analog crossbar switch matrix IC?
From: "Andy Whitehouse" <awhitehouse@spambucket.ndsuk.com>
Date: 5 Mar 1998 15:16:27 GMT
Links: << >>  << T >>  << A >>


Harris have a few:

CD22100		CMOS 4 x 4 Crosspoint Switch with Control Memory High-Voltage Type
(20V Rating)
CD74HC22106, CD74HCT22106	QMOS 8 x 8 x 1 Crosspoint Switches with Memory
Control
CD22M3493		12 x 8 x 1 BiMOS-E Crosspoint Switch
CD22M3494		16 x 8 x 1 BiMOS-E Crosspoint Switch
CD22101, CD22102	CMOS 4 x 4 x 2 Crosspoint Switch with Control Memory
HA4404B		330MHz, 4 x 1 Video Crosspoint Switch with Tally Outputs
HA4314B		400MHz, 4 x 1 Video Crosspoint Switch
HA4201			480MHz, 1 x 1 Video Crosspoint Switch with Tally Output
HA4344B		350MHz, 4 x 1 Video Crosspoint Switch with Synchronous Controls
HA4244			480MHz, 1 x 1 Video Crosspoint Switch with Synchronous Enable
HA456			120MHz, Low Power, 8 x 8 Video Crosspoint Switch (14 pages)
FN4153.1

www.semi.harris.com

Andy.




Article: 9279
Subject: Re: The case for Linux and EDA
From: Paul Bunyk <paul@pbunyk.physics.sunysb.edu>
Date: 05 Mar 1998 11:54:56 -0500
Links: << >>  << T >>  << A >>
gogo@netcom.com (R. Mark Gogolewski) writes:

> Rick, 
> 
> Great points.
> 
> You are very correct on the following two things:
> 
>  [] A port from any other Unix OS to Linux is essentially cake.
> 
>  [] Unix houses can very easily switch to Linux while NT houses
>     would have more difficulty.
> 
> BTW, I _love_ the idea of Linux.  However, if I ran a pure
> Solaris group, the only $$ I would really save would be on hardware.
> The EDA software won't get cheaper on Linux.  The admin support
> won't get cheaper, etc. , etc.  In fact, I'll have to support
> both for awhile when switching, so my admin costs go up.

Well, I've been waiting for the thread like this for 4 years now! :-)

Our group is designing some really weird (superconductive) circuitry
and we use both our specialized tools: physical-level simulation,
inductance extractor, etc., AND standard tools that we "borrow" from
what semiconductor industry has: schematic capture, layout editor,
VHDL simulator (no synthesis yet). I have been using Linux on my
desktop machine since v0.97, and now we have a Cadence license (really
cheap since we are a university lab) to perform all standard tasks
(well, it took us probably a year and half to customize Cadence for
our technology!). Cadence runs on HP machines (HP also offers nice
educational discounts).

Anyway, my experiece shows that when you take a bare-bones HP box (or
SUN, SGI is nicer, but it is not a well-supported EDA platform either)
you have to spend lots and lots of effort (and/or money) if you want
to use it as your desktop machine. I mean, you have to install gcc (or
buy an expensive C compiler from HP), one can insist on having emacs,
TeX (hey, we need to report our achievements once in a while!),
presentation graphics software, etc, etc, and Netscape on top of that!
If you are connected to the network, you need to install all the
latest security patches, when you get a nice large monitor it might
not be supported by the proprietory X server and you need to get a
newer one somewhere (helped one EE guy to do that on his Solaris).

* The point is that when you install Linux you have all this included BY
* DEFAULT, you can easily upgrade the system or any system component
* whenever you want and as often as you want.

And you can have your familiar OpenLook or CDE or a bunch of other
window managers (including one with Win95 look-and-feel!) instantly!

And if someone wants, he can have a commercial-grade relational
database (Postgres) up and running for free. And httpd, etc.

So, it is not just hardware cost, any default distribution of Linux is
much more user-friendly (in nice UNIX meaning of this word ;-) ) than
a standard HP or SUN distribution, and you have also count the cost of
making your proprietary UNIX box as convenient!

Anyway, just sharing some experience.

> 
> I think this is one reason that we do not see large groups in
> many companies strongly pushing global adoption of Linux.  Small
> groups and individuals are pushing it because you can buy a sweet
> Linux machine for less than $5K, and a Solaris machine is going
> to be quite a bit more.

You are right!

Paul 

-- 
  ("`-''-/").___..--''"`-._   UNIX *is* user-friendly, he is just very 
   `6_ 6  )   `-.  (     ).`-.__.`) picky about who his friends are...
   (_Y_.)'  ._   )  `._ `. ``-..-'      Paul Bunyk, Research Scientist
 _..`--'_..-_/  /--'_.' ,'art by           (and part-time UN*X sysadm)
(il),-''  (li),'  ((!.-' F. Lee http://pbunyk.physics.sunysb.edu/~paul
Article: 9280
Subject: Re: The case for free operating systems and EDA
From: Rick Kwan <rkwan@ix.netcom.com>
Date: Thu, 05 Mar 1998 09:00:04 -0800
Links: << >>  << T >>  << A >>
rk wrote:
> 
> someone said:
> : >>4) Stability. Linux typically has uptimes measured in months while NT
> : >>crashes about twice a week (in my experience, and in the experience of
> : >>others I've talked to).
> 
> peter:
> : This is simply not true. I am the last one to defend MS but NT is very
> : reliable. I use it all day. If you find regular crashes, as some
> : people indeed do, you very probably have hardware problems, or you
> : need a decent UPS.
> 
> rk:
> at day job, i'm running two NT machines.  basically never shut them off and
> rarely do they get in trouble.  however, bad software can crash them, it's
> NOT crashproof, but that's another story.

I am primarily a UNIX developer; so I have had to rely on NT experts to
get me past some wicked problems.  They made an interesting observation:
if you develop your application within the strict confines of the
"Microsoft path," you should have no problem; but if you try to do
something really innovative that they haven't thought of, you are going
to get into lots of trouble (which apparantly was why my problems were
so wicked :-).

I draw from that:  if you basically build an app based on Microsoft's
MFC classes, you're okay.  If you try to use their POSIX personality
(I tried), you get into a lot of trouble (which I've had).  In spite of
commercial portability packages for UNIX->NT, people tell me that you
ultimately will have to your UNIX/POSIX interfaces to use WIN32, or
face big performance losses.

> someone said:
> : >>5) Performance.  When NT is doing any kind of disk access it seems to
> be
> : >>very unresponsive.
> 
> peter:
> : Not true.
> 
> rk:
> we haven't witnessed this problem.  in fact, our #1 test engineer (day job)
> remarked positively how fast the NT machine seemed to run.  was using it
> for real-time data acquisition and storing to disk (and we considered just
> adding more memory and storing to ram but having the disk grind away wasn't
> an observed problem).

NT can be very fast.  If you machine constantly focused on
doing the same thing repeatedly, and your program and data
buffers are paged/swapped in, yes, it will be very fast.
(But then, under those same conditions, any modern demand paged
OS with eough memory will be fast.  This argues that simulation
should run equally well on both UNIX and NT, given enough memory.)

But when you try to switch between tasks, or worse
still, create new ones, there is a marked sluggishness.  Here,
Microsoft will argue that you should be using threads.  But now
we're talking about debugging asynchronous behavior... which
I started to write about, but I'll spare you... for now. :-)

--Rick
Article: 9281
Subject: Re: The case for Linux and EDA
From: eli@netcom.com (interHDL Inc)
Date: Thu, 5 Mar 1998 17:11:06 GMT
Links: << >>  << T >>  << A >>
In article <01bd47c5$c95a2720$6e84accf@homepc>,
rk <stellare@erols.com.NOSPAM> wrote:
>andrew:
>: I suspect that part of the problem is that EDA companies want to charge 
>: UNIX CAD prices for Linux software, rather than NT CAD software prices 
>: which seem to be much less (for less functionality in most cases).
>
>rk:
>thought i just read in ee times that synopsys will charge same $ for unix
>and NT (marvelous).  also said they would not do linux, no customer demand.
> 

interHDL supports all of its products including Verilint and the
Verilog/VHDL bidirectional translators on Linux.

Eli


-- 
Eli Sternheim
interHDL, Inc.
4984 El Camino Real, Suite 210
Los Altos, CA. 94022-1433
phone: 650-428-4200
fax:   650-428-4201
email: eli@interhdl.com
Article: 9282
Subject: Re: The case for Linux and EDA
From: Rick Kwan <rkwan@ix.netcom.com>
Date: Thu, 05 Mar 1998 10:04:46 -0800
Links: << >>  << T >>  << A >>
rk wrote:
>
> unix versions of software have traditionally cost far more than the dos/win
> versions.  yes, same code and all (in principle).  but it is a different
> market.  and, i believe, it will continue to be a different market.

The embedding of posts were getting kinda long, so I'll
apologize up front.
      
Pricing.  This is an interesting artificial, obsolete separator
between UNIX and PC platforms.  I am arguing here for equivalent
application pricing for UNIX and NT systems.

When PCs were limited to 4 MB of memory, there was a case
for it.  However, Microsoft is clearly trying to tell us that
UNIX and NT are of the same class.  For software licensing 
purposes, we should take their word for it.  (Clearly, that
is where their design objectives are.)

In earlier times, the key principal for what to charge was
amount of work your system could do.  (Ideally, equal dollars
for equal work.)

About 20 years ago, on centralized mainframes, you could
rent out a large application, and charge the computer center
according to metered usage.  Alternatively, you could lease
it according to the power of the mainframe.

The latter model continued onto Sun workstations.  Of course,
the software was licensed against a particular hardware key that
you had to report.  Built into the key was the class of machine.
As a result, the vendor could verify you were really running
on a Sun-3/50 and not a 3/280, and charge you accordingly.

With PCs, this model has broken down.  PC manufacturers
want us to believe that their machines perform as well as
traditional worktations.  Furthermore, today you might have
a 150 MHz machine; tomorrow, it might be 333 MHz.  You can no
longer base a software license fee on machine power. 

Furthermore, human productivity is increasingly the gating
item.  The speed of your machine is less a factor than
the functionality of your OS and toolset.  (Yes, I know.
Those really big simulations will forever be CPU-bound.)

If we believe Microsoft, this argues that tools for NT and
UNIX should have equivalent pricing.  Take *that* message to
your software vendor.  (Hmm... can of worms here.  You bought
the cheaper PC product, you say?)

>From the software vendor's point of view, pricing should reflect
development and support costs.  If it is the same on both NT
and UNIX, then it should be priced the same.  If it is not,
you are getting ripped off on one platform or the other.

(Oh, BTW, compilers and debuggers come free on Linux and
FreeBSD, not to mention the OS. :-)

--Rick Kwan
  humble developer (today, anyway :-)
Article: 9283
Subject: Re: ++ TMS320C6x DSP info website ++
From: Jeff <me@home.sleeping>
Date: Thu, 05 Mar 1998 12:32:28 -0600
Links: << >>  << T >>  << A >>
Andrew Phillips wrote:
- 
-Hi,
-
-Are you looking for information about the Texas Instruments TMS320C6x
-digital signal processors? Please check out my website:
- 
-http://www.scs.ch/~andrew/c6x.html
- 
-Here you'll find the latest documentation and silicon availability
-information. There is plenty of stuff about doing hardware and software
-design with these processors, some application notes and a
comprehensive
-bug list. Also, stacks of info about commercially available 'C6x
-processor boards and lots of other stuff .....
- 
-Have a look and please send me any comments. Don't forget to join my
-mailing list if you want to be notified when the site is updated ...
- 
-Cheers,
- 
-Andrew Phillips
-Supercomputing Systems AG
-Zurich, Switzerland

How about a valid URL?
Article: 9284
Subject: Re: ++ TMS320C6x DSP info website ++
From: clang@mindspring.com (Casey Lang)
Date: Thu, 5 Mar 1998 14:36:52 -0500
Links: << >>  << T >>  << A >>
In article <34FEEFBC.2530@home.sleeping>, me@home.sleeping says...
> Andrew Phillips wrote:
> - 
> -Hi,
> -
> -Are you looking for information about the Texas Instruments TMS320C6x
> -digital signal processors? Please check out my website:
> - 
> -http://www.scs.ch/~andrew/c6x.html
> - 

<snip>

> 
> How about a valid URL?
> 

URL works fine for me. 

-- 
Casey Lang
clang@mindspring.com

Opinions expressed are mine alone... unless you agree.
Article: 9285
Subject: Using Java for PLI?
From: Jian_Zhang <jzhang@optilink.dsccc.com>
Date: Thu, 05 Mar 1998 11:59:07 -0800
Links: << >>  << T >>  << A >>
Hi, all,

Does anyone know if there exist tools or even it's possible to use Java
as verilog PLI?  How about using C++ classes in  the code for PLI.  I
need them to model some complex telecomm devices and it's very AWKWARD
to use C and downright impossible to use vhdl/verilog.

As an observation: EDA languages (vhdl/Verilog) and tools (Modelsim,
VSS, Cadence's tools) seem way behind the software world.  Formal
analysis tools are useful to verify the gate level against rtl designs. 
But to do system modeling or verify rtl designs, more powerful languages
such as Java or C++ will be greatly helpful.

Any info or leads will be greatly appreciated.  Commends are also
welcomed.

Jian Zhang
ASIC Designer
Petaluma, CA
Article: 9286
Subject: Re: The case for free operating systems and EDA
From: "rk" <stellare@erols.com.NOSPAM>
Date: 5 Mar 1998 20:46:39 GMT
Links: << >>  << T >>  << A >>
rk:
: >at day job, i'm running two NT machines.  basically never shut them off
and
: >rarely do they get in trouble.  however, bad software can crash them,
it's
: >NOT crashproof, but that's another story.
 
peter:
: It is not crashproof, of course. It is easily crashed when there are
: hardware-related problems. It is very hard to crash it with most
: normal windoze apps though.

rk:

hi peter,

in this case, it was software.  learning how to access our custom hardware
on the isa bus, had some oopses.  but if the software is good, the machines
seem to be quite stable, don't have many problems at all.  and the crash
protection in nt is normally quite good.

--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 9287
Subject: Re: The case for free operating systems and EDA
From: "rk" <stellare@erols.com.NOSPAM>
Date: 5 Mar 1998 20:55:24 GMT
Links: << >>  << T >>  << A >>
peter:
: >It is not crashproof, of course. It is easily crashed when there are
: >hardware-related problems. It is very hard to crash it with most
: >normal windoze apps though.

thomas: 
: This is where NT differs from Unix. NT is designed to resist standard
bugs
: in standard applications. Unix is designed to resist malicious attacks in
: handmade applications. This is why most people experience much better
: stability with Unix (especially Linux but not only) than with NT.
 
rk:
perhaps current unix implementations are.  back in the '80s, when unix
wasn't exactly a spring chicken, unix security and stability and system
availability was basically a joke.  but over the years things get better. 
and, most likely, they will for nt too.  but my observations is that
working hardware with working software on NT results in a stable system
that runs without problems, the original point of this sub-thread.


thomas:
: Of course there must be, and there are, NT configurations that truly work
: and are stable. Just a matter of luck. If you are in such a situation,
: consider yourself as lucky.

rk:
well, guess i'm lucky then. ;)
Article: 9288
Subject: Re: The case for Linux and EDA
From: gogo@netcom.com (R. Mark Gogolewski)
Date: Thu, 5 Mar 1998 21:05:59 GMT
Links: << >>  << T >>  << A >>
In article <34FEE93E.9EC4786F@ix.netcom.com>, Rick Kwan  
  <rkwan@ix.netcom.com> wrote:

>Pricing.  This is an interesting artificial, obsolete separator
>between UNIX and PC platforms.  I am arguing here for equivalent
>application pricing for UNIX and NT systems.

  <snip>

>From the software vendor's point of view, pricing should reflect
>development and support costs.  If it is the same on both NT
>and UNIX, then it should be priced the same.  If it is not,
>you are getting ripped off on one platform or the other.

That is definitely the crux.  As to "rk"'s points, there is certainly
a market out there to lower performance/cheaper software.  That
makes the development/support costs much less.  You should get what 
you pay for.


>(Oh, BTW, compilers and debuggers come free on Linux and
>FreeBSD, not to mention the OS. :-)

Yeah, and that represents < 5% of development costs.  I would
find it difficult to argue that any specific platform significantly
changes the development costs vis-a-vis compilers, debuggers,
etc...

Mark

Article: 9289
Subject: Re: The case for free operating systems and EDA
From: Mark Willey <willey@etla.ml.org>
Date: 5 Mar 1998 21:06:41 GMT
Links: << >>  << T >>  << A >>
In comp.arch.fpga Peter <z80@ds2.com> wrote:

: There are lots of stupid things in NT but none of them make it in any
: way unsuitable for EDA.

I would have to disagree with that statement for the following reason:

When you do EDA, you don't just use a tool in isolation.  You use it with a
host of other tools, and those tools are either broken, nonexistent, or
occasionally present on an NT box.  They work on UNIX.  (I use NetBSD UNIX,
www.netbsd.org for more info.)

The tools I refer to are:

CVS
diff
gcc
emacs/vi
make
perl
shell scripts
screen
grep
and many more...

One of the most important tools I use is X windows.  It does me absolutely
no good to have an NT box or server across campus.  However, if I have a
UNIX box, I just log in remotely and run my CAD tool while displaying the
application GUI on my local X server.

Also, the beauty of the UNIX system is that you can quickly build tools
from smaller tools.

Case in point, while I was typing this to you, I am debugging a physical
layout by extracting a netlist from it, running the simulator based on a
model which I created in Verilog.  The Verilog is written by hand and also
automatically generated by a perl script.  We also automatically run
regressions on the design to ensure that DRC is satisfied and that our new
changed still agree with the spec.  The whole process is automated
by "make", and we use CVS to coordinate work between developers.  Our
results are on the web page in real time - all UNIX.  And I set it up
myself in a few hours time.

I think this is the real NT/UNIX issue.  And now that UNIX (Free UNIX) is
as capable on the workstation and small server level as the big UNIX iron,
it's accesable to a small company or single consultant/developer.  If the
CAD vendors build it, they will win that (perhaps small margin) market.  Do
they want it?

To me, an NT port makes no sense and I can't imagine how anyone coordinates
a full design on one of thos boxes.  Is it actually being done?  Every
company that I have worked for or looked into is using UNIX for all things
related to design and doesn't appear to be wanting to change.

Questions that I have:
  Is there any chip maker that is using NT?  Who?  What project?
  Can one coordinate a whole design on NT?  How do you do DA with so many
    missing or buggy ports?
  What about compute servers?  Can you fill a machine room with headless
    NT and have people farm jobs off to them?
  Is the cost actually effective?  The incremental admin cost has got to
    be so much greater than a UNIX box...  is that true?

Mark

Article: 9290
Subject: Re: The case for free operating systems and EDA
From: "rk" <stellare@erols.com.NOSPAM>
Date: 5 Mar 1998 21:10:31 GMT
Links: << >>  << T >>  << A >>
<snip>

: > rk:
: > at day job, i'm running two NT machines.  basically never shut them off
and
: > rarely do they get in trouble.  however, bad software can crash them,
it's
: > NOT crashproof, but that's another story.

rick kwan (also an rk) 
: I am primarily a UNIX developer; so I have had to rely on NT experts to
: get me past some wicked problems.  They made an interesting observation:
: if you develop your application within the strict confines of the
: "Microsoft path," you should have no problem; but if you try to do
: something really innovative that they haven't thought of, you are going
: to get into lots of trouble (which apparantly was why my problems were
: so wicked :-).
: 
: I draw from that:  if you basically build an app based on Microsoft's
: MFC classes, you're okay.  If you try to use their POSIX personality
: (I tried), you get into a lot of trouble (which I've had).  In spite of
: commercial portability packages for UNIX->NT, people tell me that you
: ultimately will have to your UNIX/POSIX interfaces to use WIN32, or
: face big performance losses.

rk:
our application was written in pascal (delphi version).  got into a tad of
trouble, worked out relatively quickly (< 24 hours of clock time),
interfacing to our custom h/w on the backplane.  it ran well and faster
than we expected.  and handled rather large volumes of data.


someone said:
: > : >>5) Performance.  When NT is doing any kind of disk access it seems
to be
: > : >>very unresponsive.

peter:
: > : Not true.
 
rk:
: > we haven't witnessed this problem.  in fact, our #1 test engineer (day
job)
: > remarked positively how fast the NT machine seemed to run.  was using
it
: > for real-time data acquisition and storing to disk (and we considered
just
: > adding more memory and storing to ram but having the disk grind away
wasn't
: > an observed problem).
 
rick kwan (the other rk):
: NT can be very fast.  If you machine constantly focused on
: doing the same thing repeatedly, and your program and data
: buffers are paged/swapped in, yes, it will be very fast.
: (But then, under those same conditions, any modern demand paged
: OS with eough memory will be fast.  This argues that simulation
: should run equally well on both UNIX and NT, given enough memory.)

rk:
i would expect that a large simulation run would have the app in electronic
memory as well as the data.  and an emphasis, i would think, should be in a
good, large cache as LOTS of ram, since a simulation wouldn't have locality
properties for the data.  and swapping will be death.  these assumptions
correct?  if you have enough ram, the OS shouldn't really make that much of
a difference, as i would hope it would do what it could to just stay out of
the way.  interestingly, in the integrated system design article, "testing
the viability of eda applications on a pc," they cited the compaq machine
as the leader in pc's, saying it's boost in preformance was from its memory
controller.

Article: 9291
Subject: Re: The case for free operating systems and EDA
From: Mark Willey <willey@etla.ml.org>
Date: 5 Mar 1998 21:14:29 GMT
Links: << >>  << T >>  << A >>
A datapoint on the speed of OSes:

TR-09-95 J. Bradley Chen, Yasuhiro Endo, Kee Chan, David Mazieres,
      Antonio Dias, Margo Seltzer, and Michael Smith. 1995. <a href=
      "ftp://deas-ftp.harvard.edu/techreports/tr-09-95.ps.gz">
      The Impact of Operating System Structure on Personal Computer
      Performance</a>.

Check it out and see what conclusions they came to.  Any well-tuned system
will be fast.  And some OSes are inherently a little faster due to their
organization.

This report is a little dated, and in the near future, you will see some
even better performance from the PC UNIX world, I believe.

Mark

In comp.arch.fpga Rick Kwan <rkwan@ix.netcom.com> wrote:
: rk wrote:
:> 
:> rk:
:> we haven't witnessed this problem.  in fact, our #1 test engineer (day job)
:> remarked positively how fast the NT machine seemed to run.  was using it
:> for real-time data acquisition and storing to disk (and we considered just
:> adding more memory and storing to ram but having the disk grind away wasn't
:> an observed problem).

: NT can be very fast.  If you machine constantly focused on
: doing the same thing repeatedly, and your program and data
: buffers are paged/swapped in, yes, it will be very fast.
: (But then, under those same conditions, any modern demand paged
: OS with eough memory will be fast.  This argues that simulation
: should run equally well on both UNIX and NT, given enough memory.)

: But when you try to switch between tasks, or worse
: still, create new ones, there is a marked sluggishness.  Here,
: Microsoft will argue that you should be using threads.  But now
: we're talking about debugging asynchronous behavior... which
: I started to write about, but I'll spare you... for now. :-)

: --Rick
Article: 9292
Subject: Re: The case for free operating systems and EDA
From: z80@ds2.com (Peter)
Date: Thu, 05 Mar 1998 21:27:14 GMT
Links: << >>  << T >>  << A >>

>I am primarily a UNIX developer; so I have had to rely on NT experts to
>get me past some wicked problems.  They made an interesting observation:
>if you develop your application within the strict confines of the
>"Microsoft path," you should have no problem; but if you try to do
>something really innovative that they haven't thought of, you are going
>to get into lots of trouble (which apparantly was why my problems were
>so wicked :-).

Not sure what this means in specifics. All apps end up calling the
API, one way or another. Maybe some version of unix does more rigorous
checking on the entry parameters than NT, so a dodgy app is less
likely to crash under it.

>NT can be very fast.  If you machine constantly focused on
>doing the same thing repeatedly, and your program and data
>buffers are paged/swapped in, yes, it will be very fast.

This is IMO the major problem with NT: its virtual memory
implementation is poor. I have 128MB RAM, and still I get lots of
swapfile accesses. In contrast, good ole windoze 3.11 never touches
the swapfile if there is enough RAM to hold everything.

>But when you try to switch between tasks, or worse
>still, create new ones, there is a marked sluggishness.  Here,
>Microsoft will argue that you should be using threads.  But now
>we're talking about debugging asynchronous behavior... which
>I started to write about, but I'll spare you... for now. :-)

Unix has a far longer pedigree in real time control than NT. It is
only now that people are starting to use NT in factory automation. And
NT was originally designed as a file server O/S. This is its other
major problem: it does not properly multitask. If a DOS app goes round
in a tight loop, it will grab 99%of CPU time. There is no way to tell
NT "this app is to get max 35% CPU time".

In most ways, NT is a product which could have been delivered by the
likes of Digital Research, 10 years ago. I therefore particularly
dislike MS being continually pushed as an "innovative" company, with
BG being a "brilliant" programmer. But DR failed, MS are still there.
*That* is what matters if you use it in a commercial situation.


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.
Article: 9293
Subject: Re: The case for free operating systems and EDA
From: pornin@news.ens.fr (Thomas Pornin)
Date: 5 Mar 1998 21:35:58 GMT
Links: << >>  << T >>  << A >>
In article <6dn451$b0c$1@nntp.Stanford.EDU>,
Mark Willey  <willey@etla.ml.org> wrote:
>The tools I refer to are:
[...several useful tools...]
>One of the most important tools I use is X windows.  It does me absolutely
>no good to have an NT box or server across campus.  However, if I have a
>UNIX box, I just log in remotely and run my CAD tool while displaying the
>application GUI on my local X server.

Actually, all (or almost all) the tools you describe are available for NT
for free; the "export DISPLAY" one exists also and is called NTrig (or
something like that)(and it costs much !)(there is also something free I
saw once, but it was not very efficient in terms of network consumption).

So you can get many posix tools and make your NT look like a Unix. The
point is: if you want something like Unix, why do you use NT ? Get Linux,
it is faster and cheaper, and at least as reliable as NT.

Anyway, I once met a guy who was doing some development on FPGAs using
only NT -- and he was quite happy and efficient, more than he could be
with a Unix shell. I think I represent the opposite: I am painfully slow
with a mouse, but I am also some god of the keyboard, and a strong Linux
user and advocate.

To sum up: some people prefer NT, other prefer Unix. So it is a pity that
tools are not as available under Unix as they are under NT.

	--Thomas Pornin
Article: 9294
Subject: Re: The case for Linux and EDA
From: "rk" <stellare@erols.com.NOSPAM>
Date: 5 Mar 1998 21:37:07 GMT
Links: << >>  << T >>  << A >>
rk:
: >
: > unix versions of software have traditionally cost far more than the
dos/win
: > versions.  yes, same code and all (in principle).  but it is a
different
: > market.  and, i believe, it will continue to be a different market.

rk:
one little paragraph generated a large response!  ok, let's move ahead.

rick kwan: 
: The embedding of posts were getting kinda long, so I'll
: apologize up front.
:       
: Pricing.  This is an interesting artificial, obsolete separator
: between UNIX and PC platforms.  I am arguing here for equivalent
: application pricing for UNIX and NT systems.

rk:
me argues for lowest pricing period, regulated by the laws of supply and
demand and competition.  and what helps this is avoiding proprietary
formats and tools to avoid getting locked in.  a nice example is edif.  now
i can generate an edif netlist from any number of different tools from a
number of different manufacturers, and, as an example, move it into
viewlogic, run my low level logic simulations, cut another composite
netlist, pop into my p&r tool, and i'm off and running.  typically, i take
3 different types of input and put it into my designs (schematic, macro
generators, and vhdl).  and edif is the glue that makes it happen.  if a
tool is too expensive, then i have the choice to possibly go with some
other manufacturer.  like the mentor $35,000 station vs. the orcad $500 pc
package for card-level design and netlisting from a while back.  and there
are a number of companies in between.

obviously, sales volumes will make prices drop, since the design and
maitenance cost of a tool are fixed per version but the manufacturing costs
are really quite low.  support costs should be linear w.r.t. the # of
users.  if the tools are well designed and has good doc the support costs
should be low and the users happy.  and we're all happy,
right?!?!?!?!?!?!?!?!?!



rick kwan: 
: With PCs, this model has broken down.  PC manufacturers
: want us to believe that their machines perform as well as
: traditional worktations.  Furthermore, today you might have
: a 150 MHz machine; tomorrow, it might be 333 MHz.  You can no
: longer base a software license fee on machine power. 

rk:
well, i run on both unix and pc but don't think the two are equivalent. 
they're not.  but if the pc is good enough for an app, and some studies
have shown better performance / $, then it makes sense.  it won't make
sense for the million gate asics.  but it probably will for 100,000 gates
and less.  and for < $1k, you can go down to the store, pick up a new
motherboard and cpu and memory, and have something that really flies.  lots
of m-board competition, and with the amd k6 and others, there's getting to
be some real competition for cpu slots.  and the cpu market is now
unbelievable w.r.t. performance and it's accellerating, with prices
dropping.  intel can no longer decide when to put out a new cpu and control
pricing.  somebody else will come along and beat them.

an interesting aside.  you can go down to the local hole in the wall shop
and pick up a m-board+cpu that runs at 333 MHz.  that's a 3 nanosecond
cycle time.  here's a quote from one of my architecture books, (c) 1980.

	... we cannot fail to mention that the clock cycle of 12.5 nS could only
	be achieved through some amazing technological advances in LSI ... and the
	cooling system.  ...

this is a description of the cray-1 supercomputer.

<snipped lots of good stuff>

i don't think unix or linux or domain or win '95 or win nt or dos (yes,
people still do good engineering in dos) or exec 8 or rt-ll or vms or mvs
or whatever is really what's important.

it's staying away from proprietary models that lock you in.  a good healthy
market with competition will lower prices while improving efficiency and
performance.  some comapnies will want to stay on top.  and startups will
want to take the market and money away from them.  gotta beat the standard
and convince people to change.

--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 9295
Subject: Re: The case for free operating systems and EDA
From: "rk" <stellare@erols.com.NOSPAM>
Date: 5 Mar 1998 21:51:20 GMT
Links: << >>  << T >>  << A >>
peter:
: : There are lots of stupid things in NT but none of them make it in any
: : way unsuitable for EDA.

mark: 
: I would have to disagree with that statement for the following reason:
: 
: When you do EDA, you don't just use a tool in isolation.  You use it with
a
: host of other tools, and those tools are either broken, nonexistent, or
: occasionally present on an NT box.  They work on UNIX.  (I use NetBSD
UNIX,
: www.netbsd.org for more info.)
: 
: The tools I refer to are:
: 
: CVS
: diff
: gcc
: emacs/vi
: make
: perl
: shell scripts
: screen
: grep
: and many more...

<snip some good points esp. for large designs>

rk:

ok, i do eda, but i also do engineering and, well, regular office work too.
 here's a list of the tools/apps/whatever that i use, and sort of need to
have on the pc.  is the pc good for everything?  nope, so we get big
unix/sun machines to use too, for when it's needed.  perhaps we can write
down what people use and what is doable on linux.  but, as peter said,
pc/win are fine for eda.  not for designing the pentium 99 or whatever.

here's a list:
	
	eudora for mail
	ms office - standard format for passing lots of documents and info
	spss sigma plot for graphics
	actel designer and programming - for fpga
	quicklogic tools
	borland delphi - for lab apps and analysis
	viewlogic - have pc and unix, no linux
	synopsys - have unix, moving to NT, no linux
	ftp and www servers - available for all
	statecad - pc and unix
	dos programs - got a lot of them i still run
	drivers for my national instrument hpib cards
	isa bus for all of the custom cards we bought and built ourselves
	adobe acrobat writer
	adobe photoshop
	vendor support for chip express
	orcad

made lots of chips using dos and windows.  and unix works too.  but it's
not the only way for many jobs.

--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 9296
Subject: Re: Questions about creating personal package
From: Garry Allen <garrya@abc.gov.au>
Date: Fri, 06 Mar 1998 09:07:52 +1100
Links: << >>  << T >>  << A >>
Jan Zegers wrote:
> 
> > The Questions are:-
> >
> > 1)      What file name should I use to contain the listing given above? Should
> > it be my_pkg.vhd, comp1.vhd, comp2.vhd or something else?
> 
> There is no relation between the filename and the VHDL object(s)
> in a filename. So, a very bad idea could be to put everything
> in one file. Best is to have a "convention" and to split in
Except with the Altera tool where there is a direct link betweeen the
entity name and the file name. I think it was to make it easier to enter
the entity into an altera schematic design or to instantiate it into a
gdf file or.. Anywat Altera requires you to nmae the file with the same
name as the entity if you use their tools for synthesis.

quoting from page 126 of the Max+Plus VHDL manual for version 8
In the hierarchy display window, a filename along with the file icon and
filename extension, represents a file in the current hierarchy tree.

As a further comment, this really annoys me. I have a package containing
generic declarations for things like synchronizers that I use as
required. Whne I ported the design to an Altera CPLD and attempted to
use the Altera tools i started to get error messages telling me that I
had not named the file the same as the entity within it. So a file which
I managed to successfully compile using the Xilinx foundation tools,
Warp from Cypress, Viewsynthesis and Synplicity was suddenly
unacceptable to the Altera tools. Did I feel stupid for not following
the apporopriate design guidelines from the LRM or did I start looking
to blame Altera for their particular implementation?
<stuff deleted>
Garry Allen
ABC Technology Research and Development
Ultimo AUSTRALIA ph +61-2-93335248
Article: 9297
Subject: Re: The case for free operating systems and EDA
From: wen-king@myri.com (Wen-King Su)
Date: 5 Mar 1998 15:54:52 -0800
Links: << >>  << T >>  << A >>
In a previous article z80@ds2.com (Peter) writes:
:
;
:>>4) Stability. Linux typically has uptimes measured in months while NT
;>>crashes about twice a week (in my experience, and in the experience of
:>>others I've talked to).
;
:This is simply not true. I am the last one to defend MS but NT is very
;reliable. I use it all day. If you find regular crashes, as some
:people indeed do, you very probably have hardware problems, or you
;need a decent UPS.
:
;>>5) Performance.  When NT is doing any kind of disk access it seems to be
:>>very unresponsive.
;
:Not true.
;
:There are lots of stupid things in NT but none of them make it in any
;way unsuitable for EDA.

Oh yes.  For one, it prevents me from using the tools if I am not sitting
in front of of the machine.
Article: 9298
Subject: Re: Using Java for PLI?
From: Bob Beckwith <beckwith@NOSPAM.whinny.tdh.qntm.com>
Date: Thu, 05 Mar 1998 19:22:42 -0500
Links: << >>  << T >>  << A >>
Jian_Zhang wrote:
> 
> Hi, all,
> 
> Does anyone know if there exist tools or even it's possible to use Java
> as verilog PLI?  How about using C++ classes in  the code for PLI.  I
> need them to model some complex telecomm devices and it's very AWKWARD
> to use C and downright impossible to use vhdl/verilog.
> 
> As an observation: EDA languages (vhdl/Verilog) and tools (Modelsim,
> VSS, Cadence's tools) seem way behind the software world.  Formal
> analysis tools are useful to verify the gate level against rtl designs.
> But to do system modeling or verify rtl designs, more powerful languages
> such as Java or C++ will be greatly helpful.
> 
> Any info or leads will be greatly appreciated.  Commends are also
> welcomed.
> 
> Jian Zhang
> ASIC Designer
> Petaluma, CA

I don't know of anyone currently using Java (sort of a back burner
project
of mine :), but people DO use C++ for PLI/FLI code (also for system test
and verification).

There will be presenting a paper one method of "hooking up" tests 
written in C (or C++) to Verilog at the upcoming IVC conference in
Santa Clara. 

There's also a commercial product available that pretty much does the
same thing (VCPU from SimTech).
 
Is this what you're talking about?

  --Bob

-- 
Bob Beckwith
To reply, remove NOSPAM. from the email address above.
Article: 9299
Subject: Re: Help with ViewLogic 4
From: gavin@cypher.co.nz (Gavin Melville)
Date: Fri, 06 Mar 1998 00:28:55 GMT
Links: << >>  << T >>  << A >>
On Thu, 05 Mar 1998 14:45:00 GMT, k.rozniak@XXX.ien.gda.pl (Krzysztof
Rozniak) wrote:

>Thank you for reply, Gavin and Peter.
>
>I managed to find the reason of VL malfunction. The problem was with
>too long path. I had path about 180 chars long. None of old programs I
>was using complained about it. VL was the first one. I had to shorten
>path (now ~65 chars). Since then all works perfectly. Probably VL has
>a workspace for path limited to 128 chars (DOS <=6.22 limit IIRC).
>Hope it helps someone.

Oh -- THAT version.   I had not read the original post very carefully.
It is actually a little more subtle than that -- not only must the
path be less than 127 characters long, but ALL the directories in that
path must exist.
--
Gavin Melville
gavin@cypher.co.nz


Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search