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 9325

Article: 9325
Subject: Re: The case for Linux and EDA
From: Rick Kwan <rkwan@ix.netcom.com>
Date: Fri, 06 Mar 1998 10:21:31 -0800
Links: << >>  << T >>  << A >>
rk wrote:
> 
> 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.

Actually, there were a whole bunch of others, but I thought
this was a good summary.  I also admit to artificial pricing
barriers being a hot-button of mine.

> 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?!?!?!?!?!?!?!?!?!

Ummm... yeah...  we assume somewhere that they can easily fit 
into an automated design flow.

> 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.

I agree that in hardware, they are not equivalent.  (Some are
going to argue with that.)  It use to be that in OS, they
were not equivalent either.  However, with current robust
implementations of POSIX, that machine for < $1K can now run
a workstation OS; and if you put it on an Ethernet, it might
as well be a full-fledged workstation.
 
> 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.

But the 333 MHz machine doesn't come with a love seat!
(Forget the love seat; I'll take the one with the sofa. ;-)
 
> <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.

Basically, I think I agree.  But there is perhaps a difference
of perspective here.  I have been assuming a team of multiple
designers, or perhaps even multiple teams.  In that case,
automating design flows and having strong underlying network
infrastructure is important.  If your team is very small and
you are CPU-bound, then lots of things are equalized.

However, even in small networks, if you are or have a systems
wiz around, automation on a UNIX/Linux network comes very
cheaply.
Article: 9326
Subject: Re: The case for free operating systems and EDA
From: z80@ds2.com (Peter)
Date: Fri, 06 Mar 1998 18:57:03 GMT
Links: << >>  << T >>  << A >>

>No revision control ? No batch mode ?

I don't use revision control. I have used PVCS and it is OK, but
frankly I don't trust some *program* to be diving into my source files
and inserting various bits of text in them.  When I finish a
particular version, I back up the *whole* project to optical, and/or
CD, and tape.

>Most of the cpu and time consuming jobs here are done by batch
>(shell scripts, etc) overnight, e.g. Synthesis, ATPG, Simulations, 
>Analysis, etc.

Under DOS, one uses .bat files. I still use DOS a lot. In Viewlogic 4
(DOS) one can run simulations using .cmd scripts - this is probably
the same on the unix versions. I have often run overnight simulations,
although this is less common with P200+ machines.

Under windoze, batch processing is much more difficult if the app does
not have some sort of script language built-in, and this is partly why
I like the old DOS (or DOS box) tools. There are "automation" tools
for NT but I have not used them.

If you mean what I think you mean, you certainly have a point, but not
an NT-specific one. What has happened too often is that when EDA apps
moved to windoze, they lost nice features like command line entry, and
being able to run in batch mode. This is stupidity on the part of the
developers, because once one knows what one is doing, a keyboard is
much faster to use than doing click click click click click click
click with the mouse.

The other related problem is that if there is no scripting facility,
it becomes much more difficult to maintain a project over several
years. Take today's trendy Integrated Development Environments. All
the compiler & linker options are set via the GUI. One can no longer
open an old project and just type MAKE to rebuild it. But again this
is nothing to do with NT.

>Don't tell me that you turn your PC off overnight (perhaps to get
>your NT free off memory leaks ;)) and thus waste a lot of time ...

:)

>> VI is for masochists :) 
>Or for those who need a small and fast editor and don't want to 
>lose time by moving their hands to the mouse and back during 
>touch typing, e.g. to copy just one line :).

Brief?  I know several people who went from unix to DOS/etc and all
now use Brief - years after its development was abandoned. I have used
VI - it is OK but not a patch on Brief.
 


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: 9327
Subject: Re: The case for free operating systems and EDA
From: olsenc@kodiak.ee.washington.edu (Clint Olsen)
Date: 6 Mar 1998 19:00:17 GMT
Links: << >>  << T >>  << A >>
On 6 Mar 1998 11:51:14 GMT, rk <rich.katz@gsfc.nasa.gov.NOSPAM> wrote:
>
>if Linux *is* a UNIX, can i just go down to the local synopsys store,
>order me up a copy of UNIX synopsys, drop in the cd onto my linux/x86
>portable machine, and start running?

You are obfuscating the issue here.  Just because you run UNIX doesn't mean
the underlying hardware is the same.  Can I take an NT application compiled
on the Alpha and run it on the PC?

>hmmm ... just a little old engineer here, but i seem to remember, let me
>know if it's not true, that s/w needs to be written or tweaked for
>different versions of unix.  can i take code from an hp box and run it on
>a sun box, or a dec box, or a ibm box, or an cray box, or a silicon
>graphics box (haven't followed these two too close since merger) or a
>xenix box?  anyways, that's s/w portability.

Software is very portable when it is written to adhere to standards that
all vendors support and requires very little/no "tweaking" as you say.  For
example, software written in ANSI C is highly portable.  XFree86 is
available on FreeBSD, Linux, LynxOS, NetBSD, OpenBSD, OS/2, SCO, Solaris
x86, and SVR4 which are all quite different OS breeds.  The newsreader SLRN
and the Mutt mailer compile on just about any UNIX imaginable regardless of
the underlying hardware architecture.

Now as to why Synopsys doesn't cut a release Design Compiler on Linux is
another story.  That has a lot of baggage in it, and chances are they
didn't care a lot about portability when it was first written.  We'd have
to see their software development process in a little more detail to
ascertain the cause.

-Clint
Article: 9328
Subject: Re: Whats wrong with this method
From: "Richard Iachetta" <iachetta@us.ibm.com>
Date: 6 Mar 1998 19:06:18 GMT
Links: << >>  << T >>  << A >>
Allan Redenbaugh <allan@ti.com> wrote in article
<6dpdnk$n8o@sf18.dseg.ti.com>...
> Given the following code for a control register where a single bit has to
> have
> a seperate async reset :
> (target device = Xilinx 4ke)
> 
> process ( strobe, reset, clear_bit0)
> 
> begin
> if reset = '0' then
>    cntl_reg <= DEFAULT_REG;
> elsif clear_bit0 = '1' then
>    cntl_reg(0) <= DEFAULT_REG(0);
> elsif strobe'event and strobe = '1' then
>    cntl_reg <= data;
> end if;
> end process;
> 
> I assign reset to GSR so I expect clear_bit0 to drive the reset line of a
> dff
> on bit 0 and the reset of the register bit to only have the GSR reset.
> 
> My synthesis tool (Leonardo) says that since I have nothing defined for the
> upper bits under the clear_bit0 condition it defaults to a preset which is
> not what I inteded.
> 
> I have pulled out bit 0 into its own process and everythings happy, I just
> don't
> understand why this method doesn't work.

Because the code doesn't specify what should happen to cntl_reg(1 to n) when
reset = '1' and clear_bit0 = '1';  The value of each output of the process must
be defined for all combinations of the sensitivity list.  Since all the bits of
cntl_reg are outputs, then they must all be defined for each elsif.  I think it
would have worked like this:

begin
if reset = '0' then
   cntl_reg <= DEFAULT_REG;
elsif clear_bit0 = '1' then
   cntl_reg(0) <= DEFAULT_REG(0);
   cntl_reg(1 to n) <= cntl_reg(1 to n);  -- replace n with actual number.
elsif strobe'event and strobe = '1' then
   cntl_reg <= data;
end if;
end process;

-- 
Rich Iachetta
IBM Corporation
iachetta@us.ibm.com


Article: 9329
Subject: Re: The case for free operating systems and EDA
From: Mike Palmer <mike.palmer@nospam.nospam.com>
Date: Fri, 06 Mar 1998 11:41:20 -0800
Links: << >>  << T >>  << A >>
Phil Ptkwt Kristin wrote:
> 
> In article <01bd4897$2b62d1c0$2985accf@homepc>,
> rk <stellare@erols.com.NOSPAM> wrote:
> >peter:
> >: :There are lots of stupid things in NT but none of them make it in any
> >: ;way unsuitable for EDA.
> >
> >wen:
> >: Oh yes.  For one, it prevents me from using the tools if I am not sitting
> >: in front of of the machine.
> >
> >rk:
> >solution: sit in front of the machine.
> 
> Not always possible.  For example if you can't make it into work because
> of an ice storm, you can (if you're running Linux at home) establish a ppp
> connection with a system at work and set your display to your home system
> (assuming you're running some kind of Unix at work) and do a reasonable
> amount of work.

We gave up on that. Telnet works, but X is pretty much unacceptable,
even
over a good (28.8) connection. Let me state _clearly_ that a simple X
terminal
works fine, but when I have to run the tools I use in my job, whether it
is 
a VHDL simulator or a schematic editor, we find that we need LOTS of
bandwidth.
The schematic software we run is completely unacceptable using X. Even
with 
ISDN, it's marginal. Editing a simple schematic is at least an order of
magnitude 
slower over ISDN than running locally (and we complain about the speed
when
we run locally). == Note: Don't argue yet - read the next paragraph ==

But, we do have an acceptable solution - use NT. We run an X emulator on
an NT
server, then dial up to that remotely. The NT server runs Citrix'
WinFrame 
Server, and that converts the (apparently remarkably inefficient) X into
a 
reasonably efficient system. Over a 28.8 line, the performance is
marginal, 
but over ISDN, it's quite acceptable, even for our schematic editor.
Note
that even though I said the solution is to use NT, it's because that's
what
the solution, Citrix WinFrame, runs on. It's not that NT is so much
better - 
it's that WinFrame is. There doesn't appear to be anything limiting X 
from performing as well as WinFrame - but so far it doesn't.

So, I run Win95, start up the WinFrame client, dial into an NT server,
start 
up an X emulator, connect to my Unix workstation, and run my
application. 
Sounds complicated, but it sure beats any other solution we've ever
seen.
 
> Sure, not being tied to the network might make it easier to take you
> laptop on the plane and work on a design, but the need for this is only
> 2-3 times a year for most of us.
 
> The disadvantages of not being tied to a network greatly outweigh the so
> called advantages (especially if you have multiple people on a project).
> Well, the tools for running remotely with Linux are free.  You get
> XWindows which allows you to do this sort of thing.  Now there is
> something called VNC (Virtual Network Computer) which allows PCs running
> NT, Suns running Solaris, and Linux boxen to display a desktop remotely -
> and VNC is free (GPLed).
> 
>  phil

As long as we're talking about running off the network, we really need
to divide the world into licensed tasks and unlicensed tasks. Virtually
all of the Unix software I use in my job is licensed, and requires
access
to a license server. When that server goes away, so does the
application.

So, as long as we're talking about EDA stuff, the issue of whether I 
can run my system on a plane is pretty moot - regardless of the OS. 

-- Mike --

-- Mike Palmer -------------------------------- Principal Engineer --
--                                                                 --
--   In a sad attempt to limit spam, my standard return addresses  --
-- are all invalid. Mail "mike dot palmer at tus dot ssi1 dot com" --
--            replacing 'dot's and 'at's as appropriate.           --
--                                                                 --
-- Silicon Systems, Inc. - A Subsidiary of Texas Instruments, Inc. --
-- The views expressed here are mine, and do not reflect the views --
--       of Silicon Systems, Inc. or Texas Instruments, Inc.       --
Article: 9330
Subject: Re: The case for free operating systems and EDA
From: "rk" <rich.katz@gsfc.nasa.gov.NOSPAM>
Date: 6 Mar 1998 20:21:34 GMT
Links: << >>  << T >>  << A >>
misha:
: There is a significant advantage of Linux over Windows concerning
portables.
: I was very surprised when I touched the processor inside my desktop when
: it was running Linux. It was COLD. So was the power regulator. Under
: Windows95 the processor is always hot, even when OSR2 System Monitor
shows 1%
: CPU utilisation for an hour. Same about NT.
: 
: Of course, when CPU-intensive application runs under Linux, the processor
: warms up. But for typing text on the portable Linux should give much
longer
: battery life.

interesting.  i haven't seen any of the rags that report on portables and
battery life consider this.  it would make a good benchmark since a lot of
people do x-country traveling.  now, the portables do have a lot of power
savings features and do a bunch of stuff to extend battery life so the
difference on the desktop pc may not equal difference on a lapdog.  but it
would be interesting to see, for a portable, a comparison for running a
simple text editor between: 

	a. win '95

	b. win nt

	c. linux

	d. unix/pc

	e. unix/risc (pick hp, sun, ibm, etc.)

	f. mac

may the best win!

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

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 9331
Subject: Re: The case for free operating systems and EDA
From: "rk" <stellare@erols.com.NOSPAM>
Date: 6 Mar 1998 20:25:16 GMT
Links: << >>  << T >>  << A >>
peter:
: > VI is for masochists :) 

stephan:
: Or for those who need a small and fast editor and don't want to 
: lose time by moving their hands to the mouse and back during 
: touch typing, e.g. to copy just one line :).

rk:
i use win '95 and nt (amongst other os'es) and don't have that problem at
all.  i'm not that much of a mouse fan, too, although for certain apps, it
is the way to go.

Article: 9332
Subject: Re: The case for free operating systems and EDA
From: "rk" <stellare@erols.com.NOSPAM>
Date: 6 Mar 1998 20:38:02 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.

wen:
: :: Oh yes.  For one, it prevents me from using the tools if I am not
sitting
: ;: in front of of the machine.

rk:
: :solution: sit in front of the machine.
 

wen:
: Sorry, I can't do that.  The machine I sometimes need to use would have
: so many processors, disks, and memory and powersupply that it would take
: a forklift to carry.  I also routinely use manage jobs that runs on a
: farm of workstations and I need to do it remotely and service them at
: odd hours of the day.

rk:
for an application like that, at the high end, you need the high end
horsepower.  that's not a good spot for NT.  but that has nothing to do
with suitability of nt for eda, as peter pointed out.  it only has to do
with the suitability of nt for a particular class of job.  don't think
there's any disagreement there.  and i've bought some big machines for big
jobs (and spent big $).


wen:
: The problem is not with NT, the problem is with how Microsoft is having
: an effect on how EDA programs were written.  There is absolutely no
reason
: why EDA vendors couldn't compile their program on NT but link them with
: X-window libraries so that the NT machine would be useful as a remote
: compute engine within a network of unix workstations.  NT still has a
: long way to go to match Unix for networking and user interface.  

rk:
yup, microsoft monopoly, which is not good [see my earlier post on
competition and open standards].  and, i believe, microsoft does care about
you; well about your $, anyways.  for some networking features, the
microsoft stuff is pretty good (and win 3.11 was horrible); on others it's
a pain and not up to unix or another of other os'es.  their user interface
is not bad, very mac-like, and it's easy to write your own programs with
nice, easy to use and understand humanoid interfaces.  having programmed
both, i'd go with the win '95/nt interface.

wen:         
:                                                                 By making
: it so that engineers either has to choose between inexpensive EDA
software
: and versatile and mature networked user environment, Microsoft is causing
: us a lot of pain.

rk:
not sure m-soft has anything to do with it, but the pc and it's software
has made available inexpensive that is readily affordable, easy to use and
learn, and is capable of performing good engineering.  does it solve all
problems.  no way.  but it's capable of good engineering as is dos and a
number of other systems.  

of course, as one unix or linux fanatic put it, the pc's are only good for
secretary's.  i would, er, disagree there.

wen:
: <snip stuff on eda s/w structure>
:                                 But Microsoft won't do that because they
: don't care about you.  They care about market share. They are a monopoly.

rk:
obvious to the most casual observer.
 
--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------

Article: 9333
Subject: Re: The case for free operating systems and EDA
From: "rk" <stellare@erols.com.NOSPAM>
Date: 6 Mar 1998 20:55:00 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.

wen:
: >: Oh yes.  For one, it prevents me from using the tools if I am not
sitting
: >: in front of of the machine.

rk:
: >solution: sit in front of the machine.
 
phil:
: Not always possible.  For example if you can't make it into work because
: of an ice storm, you can (if you're running Linux at home) establish a
ppp
: connection with a system at work and set your display to your home system
: (assuming you're running some kind of Unix at work) and do a reasonable
: amount of work.

rk:
hmmm ... work from home all the time.  and can do *more* than a reasonable
amount of work running '95 both home and at the office.  sometimes (ok, a
lot of times) it seems that i get a lot more done at home than at the
office.

but anyways,

for any graphics intensive application, running over the 28.8 bps line
interactively just won't work.  now, you might say, as my neighbor across
the street say, you can get a cable modem.  well, her company pays for that
that and it's expen$ive.  but then again, her company just lost their
company and were bought out (dec).


rk:
: >i think nt (and probably linux) is winner here over unix since with nt,
you
: >can simply fold up the machine, put it in your backpack, hop on the
plane,
: >wait for the announcement that you can pull out your 'puter, and get
back
: >to work.  i travel a modest amount on business, 6-8 times per year, and
i
: >do some personal travelling.  i see a lot of pc's with windows and mac's
: >being used everywhere.  never saw anybody doing unix on the plane.  and
i
: >frequently pack up a pc, stick it in a box, get to where i'm going, take
it
: >out, turn it on, don't miss a beat.  NOT being tied to the network makes
it
: >the portable computer and i don't lose any of the environment i'm used
to. 
: >can you do this with unix box?  can't with the way ours are setup but
not a
: >unix guru, just a key tapper.


phil: 
: Sure, not being tied to the network might make it easier to take you
: laptop on the plane and work on a design, but the need for this is only
: 2-3 times a year for most of us.

rk:
for a lot of people it's a lot more.  but i was just addressing wen's
complaint that he wants to work w/out sitting in front of the machine.  not
a restriction for pc (win, linux).


phil: 
: The disadvantages of not being tied to a network greatly outweigh the so
: called advantages (especially if you have multiple people on a project).


rk:
i do a lot of multiple person design work.  not being tied down hard to a
network hasn't been a problem.  at work, we're really well networked.  and
from home, i can just email myself or other team mates files at the end of
the night and weekend and we're ready to go.  no muss, no fuss.  this
includes joint projects for chip, board, and s/w design.

now, one of the complaints that i have about the networked environment, for
a large system, is that you lose control.  admins do s/w updates, database
updates, etc.  surprise!  and you're working late at night, weekend, etc. 
gotta get the job done.  that's why you're there late at night or a weekend
or a holiday.  something goes wrong with network, server, etc.  it's not in
your lab.  you don't have the key.  don't even know where the stuff is. 
your stuck.  this is NOT hypothetical and is a big complaint.  with pc,
easy to fix anything with the hardware (always keep some spare parts laying
around) and can usually recover from any disaster in just a few hours.  and
don't have the surprise s/w updates.  being able to control your destiny
*IS A REALLY BIG ADVANTAGE!!!!!!!!!!!!!!!!!!!!!*

rk:
: >then again, tools for pc are cheap.  got a set for home pc.  don't gotta
go
: >to work.  and can upload/download files no prob over the internet. 
hooking
: >up drag and drop from home pc to work 
: >pc now, it'll be even easier to communicate.

phil:
: Well, the tools for running remotely with Linux are free.  You get
: XWindows which allows you to do this sort of thing.  Now there is
: something called VNC (Virtual Network Computer) which allows PCs running
: NT, Suns running Solaris, and Linux boxen to display a desktop remotely -
: and VNC is free (GPLed).

rk:
how well does xwindows run over 28.8? and you gotta tie up phone line,
that's a pain.  and can't get the software for linux.  

perhaps that'll change.  but back to one of my original questions:

	why did synopsys announce all tools going to NT and not linux, with no
	customer demand for linux?

dunno, perhaps you do.

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

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 9334
Subject: Re: The case for Linux and EDA (Take Discussion Offline !)
From: "William D. Billowitch" <wdb@vhdl.com>
Date: Fri, 6 Mar 1998 16:02:54 -0500
Links: << >>  << T >>  << A >>
Maybe its time to take this personal discussion between
the 3 folks off-line and out of the VERILOG, VHDL, Synthesis, FPGA
etc groups its being SPAMMED to...

This has little to do with the subject of the groups and the cross-posting
is nothing more than SPAM.

Anyone agree?

--
Bill



Article: 9335
Subject: Re: The case for Linux and EDA
From: "rk" <stellare@erols.com.NOSPAM>
Date: 6 Mar 1998 21:12:52 GMT
Links: << >>  << T >>  << A >>
rick kwan:
: > : > 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: 
: Actually, there were a whole bunch of others, but I thought
: this was a good summary.  I also admit to artificial pricing
: barriers being a hot-button of mine.

rk:
didn't notice ;)


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.
 
r. kwan:
: I agree that in hardware, they are not equivalent.  (Some are
: going to argue with that.)  It use to be that in OS, they
: were not equivalent either.  However, with current robust
: implementations of POSIX, that machine for < $1K can now run
: a workstation OS; and if you put it on an Ethernet, it might
: as well be a full-fledged workstation.

rk:
you can do fine engineering with unix.  
you can do fine engineering with nt.  
you can do fine engineering with 95.  
you can do fine engineering with dos.  
3.11 was a pain in the ass, when on a network <poke in peter's ribs>.  ran
fine standalone, but on the network, everytime they'd mess with the net,
doing something, every machine would lock up.  and for critical runs, like
programming parts, had to do the reboot to dos or the windows run with
networking disabled.

of course, different systems are capable of solving different problems and
with different efficiencies when they leave their domains.

don't know why people think you can't do good work with non unix/linux
systems and delegate "lesser" systems to secretaries.  if they're that
dependent on a particular os they must be poor engineers. ;)  

me, basically agree with you.  but it's the app s/w that's the big
difference now for a majority of jobs.  of course there are exceptions,
like the guy earlier who requires a whole pile of machines for his runs.
  
rk shows his age with his history books (ok, college text book):
: > 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.
 
rick kwan:
: But the 333 MHz machine doesn't come with a love seat!
: (Forget the love seat; I'll take the one with the sofa. ;-)

rk:
;)


rk:  
: > <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.
 
rick kwan:
: Basically, I think I agree.  But there is perhaps a difference
: of perspective here.  I have been assuming a team of multiple
: designers, or perhaps even multiple teams.  In that case,
: automating design flows and having strong underlying network
: infrastructure is important.  If your team is very small and
: you are CPU-bound, then lots of things are equalized.

rk:
wow, possible agreement.  must be a conspiracy of the rk's. ;)

i generally work in small teams (generally 3 engineers at a time - and do
work with a number of others, but more of a boundary there - can keep a
real fluid flow with 3 people.  after that, communications is a real
problem.  size of ideal group, gotta be another thread there).  there are a
lot of engineers who work in small teams, i have found.  small is defined
as from 1 to 3.  after that, integrate at the card or box level.  of
course, for the state-of-the-art-stuffed=to-the-gills asic, it's another
story.  and a different model.  and you need a different story.

we do put a lot of emphasis on having a good network.  all of our machines
are linked together with drag and drop.  we share common libraries.  we all
have identical setups, s/w revisions, tool sets.  we can all sit down at
one or the other machines, drag a directory over and work.  we can finish a
section of a design and pass it over.  no muss, no fuss.  '95/nt is good
for that, we don't need more power.


rick kwan:
: However, even in small networks, if you are or have a systems
: wiz around, automation on a UNIX/Linux network comes very
: cheaply.

rk:
ah, the wiz, gotta have one for unix, that i know (and i hear the same
about linux).  me, not a unix wiz, key tapper, know how to yell for help! 
but for pc/win, any idiot can setup and maintain a decent, functional
networked environment.  don't even need a network, can just string the
'puters together with some cable, t's and 50 ohm resistors.  that's what i
like.  see earlier note (prob. in previous post) about controlling one's
destiny.  important when it's you *ss on the line.  and i just don't have
the time to become unix wiz.  friends i know says it takes 1 year of pain
to get there.
-- 
--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
 
Article: 9336
Subject: Re: The case for free operating systems and EDA
From: "rk" <stellare@erols.com.NOSPAM>
Date: 6 Mar 1998 21:21:09 GMT
Links: << >>  << T >>  << A >>
someone said:
: >No revision control ? No batch mode ?
 
peter:
: I don't use revision control. I have used PVCS and it is OK, but
: frankly I don't trust some *program* to be diving into my source files
: and inserting various bits of text in them.  When I finish a
: particular version, I back up the *whole* project to optical, and/or
: CD, and tape.


rk:
i never use revision control.  set up a back up machine out of spare parts
- and it doubles as a www server to boot.  we save on each other's disks. 
backup to backup of choice at time.  storage is cheap, fortunately, as this
is the '90s.  and this eliminates any possible confusion about what version
is what.

 
someone:
: >Most of the cpu and time consuming jobs here are done by batch
: >(shell scripts, etc) overnight, e.g. Synthesis, ATPG, Simulations, 
: >Analysis, etc.

peter: 
: Under DOS, one uses .bat files. I still use DOS a lot. In Viewlogic 4
: (DOS) one can run simulations using .cmd scripts - this is probably
: the same on the unix versions. I have often run overnight simulations,
: although this is less common with P200+ machines.

rk:
still the same for viewlogic.  most sims are done < 10 minutes.  rarely
more than a half hour anymore.  haven't run an overnight one in years,
although chip designs are getting bigger.

 
peter:
: Under windoze, batch processing is much more difficult if the app does
: not have some sort of script language built-in, and this is partly why
: I like the old DOS (or DOS box) tools. There are "automation" tools
: for NT but I have not used them.

rk:
the scripting tools are starting to come in.  for designer, for example,
they give you a simple c-like programming language.  generally, things
happen fast enough don't really need them.  and with viewlogic .cmd files,
just load them and go.
 
peter:
: The other related problem is that if there is no scripting facility,
: it becomes much more difficult to maintain a project over several
: years. Take today's trendy Integrated Development Environments. All
: the compiler & linker options are set via the GUI. One can no longer
: open an old project and just type MAKE to rebuild it. But again this
: is nothing to do with NT.

rk:
ah, depends on the s/w.  for viewlogic, as we discussed, i do all of my
final simulations via file commands.  and they are compatible with current
versions.

for my actel work, they do a good job of remembering your settings.  for
their vhdl compiler, for example, you can save your configuration which
controls clickable options so as optimization and effort settings, chip or
block mode, etc.  not sure about the other manufacturers s/w.  their macro
generator stores the entire state of the macro in a file, and you can
easily call it up and look at it or mod it.


Article: 9337
Subject: Re: The case for free operating systems and EDA
From: Petter Gustad <pegu@computer.orgNOSPAM>
Date: 06 Mar 1998 13:32:10 -0800
Links: << >>  << T >>  << A >>
z80@ds2.com (Peter) writes:

> >No revision control ? No batch mode ?
> 
> I don't use revision control. I have used PVCS and it is OK, but
> frankly I don't trust some *program* to be diving into my source files
> and inserting various bits of text in them.  When I finish a
> particular version, I back up the *whole* project to optical, and/or
> CD, and tape.

I guess if you don't interact with other people it might be OK to do
without some source of revision/source control system. If you're in a
group of several people working on a design it's a different story. I
personally use revision control for designs that I do by myself too. I
store the RCS tags into each source file and output them into the SST
(or VCD/VPD) files (simulation dump files) using the following snippet
in each of my source files:
 
// synopsys translate_off
reg [639:0]RCS_ID;
initial begin
    RCS_ID = "$Id: compu.v,v 2.4 1998/01/06 22:29:23 pegu Exp $";
end
// synopsys translate_on

You could also throw a $display in there to write the RCS_ID to the
log file. I use a script which will iterate over all the source files
and do a what/ident to dynamically build a Verilog module which writes
out the source files and version numbers in a cleaner format.

So when you find a SST or simulation log file on your hard disk after
a week of vacation (or a month of simulation) you can track the
version numbers back to the source. This is also useful when you have
other people responsible for the functional testing, e.g. "please run
the CAM test on the 2.278 release". Or something suddenly stopped
working, and you realize that it's been broken for the last two
months, but it worked before Christmas. Then it's great to have a way
to track back and see what changed. I'm addicted, I use it in all my
programs, scripts, documentation or whatever. It gives me a feel of
control which is greater than the fear of RCS/CVS/SCCS screwing up the
substitution of a couple strings in my source files. It integrates
beautifully with emacs too. And of course, I still do backups.

I'm sorry for getting little off topic. This is really not an argument
in the UNIX/Linux/NT debate since RCS/CVS are available under W95/NT.

Petter
-- 
________________________________________________________________________
Petter Gustad     8'h2B | (~8'h2B) - Hamlet     http://home.sol.no/~pegu
Remove the obvious from my reply address to send mail -- sed s/nospam//g
Article: 9338
Subject: Re: Leonardo/Xilinx BUFGLS question
From: s_clubb@die.spammer.netcomuk.co.uk (Stuart Clubb)
Date: Fri, 06 Mar 1998 22:51:23 GMT
Links: << >>  << T >>  << A >>
On 6 Mar 1998 04:36:07 GMT, janovetz@ews.uiuc.edu (Jacob W Janovetz)
wrote:

>   I read in the Xilinx documentation that the 4000XL series allows
>mapping an internal signal to an available BUFGLS.
>(page 4-43 9/96 databook).  I have not been able to do this, however.
>In Leonardo, I have tried assigning a BUFGLS to the signal and 
>even tried mapping a component in.  However, when it comes time for
>the Xilinx tools to place and route, I get the following error:

Buffer_sig BUFGLS clk
pad IBUF clk

should do it.

By forcing the IBUF, you'll gain access to the BUFGLS via internal
resources, rather than being forced to the fixed pins.

What happens to your clk2q when you do this?

Stuart

Article: 9339
Subject: Re: Version Control for schematics?
From: "Jeff Stout" <jstout@ncon.com>
Date: Fri, 6 Mar 1998 16:52:41 -0600
Links: << >>  << T >>  << A >>

Check out SourceSafe...by Microsoft.  SourceSafe understands
files and directories.  It works under a varity of OS's.  It does not
embed stuff in your files, unless you ask it to.

I'm just a satisfied customer.

David Decker wrote in message <34fc3a8b.3807785@news.jps.net>...
>I would like to use a version control system to support multiple
>FPGA designers doing ViewLogic schematic capture to
>Xilinx in under Win95. PVCS and similar programs are designed
>to support software developers. As I am discovering, the main
>deficiency of these systems when trying to use them for schematics, is
>their inability to check directories in and out of version control.
>They want to work with file lists.
>
>
>
> snip description of lots of need features


Jeff Stout
Sorry,





Article: 9340
Subject: Re: The case for free operating systems and EDA
From: "rk" <stellare@erols.com.NOSPAM>
Date: 6 Mar 1998 23:45:04 GMT
Links: << >>  << T >>  << A >>
rk:
: >if Linux *is* a UNIX, can i just go down to the local synopsys store,
: >order me up a copy of UNIX synopsys, drop in the cd onto my linux/x86
: >portable machine, and start running?
 
clint:
: You are obfuscating the issue here.  Just because you run UNIX doesn't
mean
: the underlying hardware is the same.

rk:
well, after consulting my dictionary, i don't think so.  going back up the
thread we see that the discussion started about linux and eda and etc.,
etc., etc.  well, we have discussed that, advantages and disadvantages of
different configurations, requirements of different applications, etc.  and
there's a nice thought here about the advantages of unix software and pc
hardware.  it's a nice model.  however, for the model to useful, there has
to be application software.  my requirement is that i need to run synopsys.
 because that's what the foundries that i need to go to take.  i have no
choice.  that's why i purchased (day job) synopsys and big unix machine and
got boss to sign big pr to go along with that.

ok, here's the previous quote:

     mark:
     The key point of the message:  PC != Windows.  Linux/*BSD = UNIX. 
UNIX !=
     workstation.  UNIX runs on a PC, too.  Only faster/better.  :)

     Mark "Not a fanatic, really! ;-)" Willey

perhaps i misunderstood the quote but it says that linux and *bsd both
equal unix.  so, we can assume mark meant linux = *bsd (mark correct me if
i'm wrong).  unix != workstation implies that unix doesn't equate with
having to be on a workstation (can't argue that one).  then, with unix
running on a pc (this means linux and *bsd) it says linux or *bsd can run
on a pc too.  did i miss something here?

now, this is a nice model.  pc hardware is cheap and portable and
reasonably powerful for a nice class of jobs.  now, for programming, there
are two things that have to happen.  1, as you point out, the generated
binary code must run on the 'puter of choice.  2, the software must make
calls to the OS for services and humanoid-interface.  1 is done by the back
end of the compiler.  2 is done by the humanoids for a lot of programs
although with delphi, for example, we're getting shielded from that
although that's another story.

so, can linux (unix) + pc hardware do the job?  we've seen lots of comments
about lots of the pieces.  but if there's no software it can't, no matter
how much people like the model.  so we have to look at the model a bit
closer and we might be able to say that linux ~ *bsd.  and various people
have pointed out that sys admin retraining, for example, will not be too
bad going from unix to linux.  and this may be a factor in where the
industry is going over the next several years.

also note the intel + hp alliance for the cpu.  and the intel + rambus deal
for memory.  speed, speed, and speed.  rambus is fast and high density,
basically same as regular dram.  and hp has a lot of unix experience.  and
they're going to 64-bits.  clearly, they are going after workstations.  but
there is one more piece of the puzzle that hasn't received that much
attention, and may address what another poster talked about, needing a big
pile of machines.  that is, hp is working on chip set for large numbers of
cpus to work together, targeting the high end.  and with almost every major
workstation vendor (believe there is one holdout, sun) hedging their bits
on cpus, it'll be interesting to see what will happen on the high end of
processing.

so, i obfuscate nothing.

i need to run synopsis.  that means, from what i hear, unix.  not linux. 
seems pretty clear.


:                                                 Can I take an NT
application compiled
: on the Alpha and run it on the PC?

dunno, didn't ask, and it doesn't really matter in this discussion.

but, i shall ask you this:

will it be easier to port an NT/alpha program to NT/pentium II?

     or

will it be easier to port a unix/sun program to linux/pentium II?


rk: 
: >hmmm ... just a little old engineer here, but i seem to remember, let me
: >know if it's not true, that s/w needs to be written or tweaked for
: >different versions of unix.  can i take code from an hp box and run it
on
: >a sun box, or a dec box, or a ibm box, or an cray box, or a silicon
: >graphics box (haven't followed these two too close since merger) or a
: >xenix box?  anyways, that's s/w portability.
 
clint:
: Software is very portable when it is written to adhere to standards that
: all vendors support and requires very little/no "tweaking" as you say. 
For
: example, software written in ANSI C is highly portable.  XFree86 is
: available on FreeBSD, Linux, LynxOS, NetBSD, OpenBSD, OS/2, SCO, Solaris
: x86, and SVR4 which are all quite different OS breeds.  The newsreader
SLRN
: and the Mutt mailer compile on just about any UNIX imaginable regardless
of
: the underlying hardware architecture.

rk:
well, for eda i need synopsys.  no choice.  but, as i asked earlier, why is
synopsys porting to nt and not to linux? let's find out, below.


clint: 
: Now as to why Synopsys doesn't cut a release Design Compiler on Linux is
: another story.  That has a lot of baggage in it, and chances are they
: didn't care a lot about portability when it was first written.  We'd have
: to see their software development process in a little more detail to
: ascertain the cause.

rk:
it seems to me that if the code isn't written that portably, then moving to
nt instead of linux will increase their work load.  gotta make sure no
oopses in the coding style.  gotta change os calls.  gotta change tools. 
gotta make sure the humanoid interface works ok.  gotta retrain support
staff.  gotta write more app notes.  gotta those slashes pointing the wrong
way all over the place.  linux would make a lot more sense technically, if
they want to get on cheap hardware with minimal investment in s/w
development and support costs, if linux and unix are that close.  also,
it's curious to note, synopsys just bought viewlogic.  and their tools, to
a large extent, run on both unix and '95/nt.

==> perhaps nt just isn't so bad, is usable for eda, not just for
secretaries.

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

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 9341
Subject: Re: The case for Linux and EDA (Take Discussion Offline !)
From: "rk" <stellare@erols.com.NOSPAM>
Date: 6 Mar 1998 23:46:59 GMT
Links: << >>  << T >>  << A >>
William D. Billowitch <wdb@vhdl.com> wrote in article
<6dpo45$c5o$1@news1.fast.net>...
: Maybe its time to take this personal discussion between
: the 3 folks off-line and out of the VERILOG, VHDL, Synthesis, FPGA
: etc groups its being SPAMMED to...
: 
: This has little to do with the subject of the groups and the
cross-posting
: is nothing more than SPAM.
: 
: Anyone agree?
: 
: --
: Bill


OH, SH*T, IT'S THE NET POLICE.  RUN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Article: 9342
Subject: Re: The case for Linux and EDA (Take Discussion Offline !)
From: "rk" <stellare@erols.com.NOSPAM>
Date: 7 Mar 1998 00:03:11 GMT
Links: << >>  << T >>  << A >>
William D. Billowitch <wdb@vhdl.com> wrote in article
<6dpo45$c5o$1@news1.fast.net>...
: Maybe its time to take this personal discussion between
: the 3 folks off-line and out of the VERILOG, VHDL, Synthesis, FPGA
: etc groups its being SPAMMED to...
: 
: This has little to do with the subject of the groups and the
cross-posting
: is nothing more than SPAM.
: 
: Anyone agree?
: 
: --
: Bill


                 TOP TEN THINGS THAT MAKE THIS THREAD RELEVANT
                 =============================================

1. IT'S MORE THAN THREE FOLKS.  IT'S NOT PERSONAL.  IT'S A NICE DIVERSE
GROUP RANGING
	FROM DOS USERS ALL THE WAY UP TO GUYS RUNNING REALLY POWERFUL MACHINES
THAT YOU
	NEED A FORKLIFT TO MOVE.

2. ER, WHAT'S SPAM?  DOESN'T SOUND GOOD.  I THOUGHT IT WAS ANNOYING
COMMERCIAL E-MAIL.
	THIS IS A TECHNICAL DISCUSSION COVERING A LOT OF RELEVANT TOPICS.  AND
WE'RE 
	NOT DOWNLOADING E-MAIL INTO YOUR E-MAIL BOX, FORCING YOU TO WATCH THE
LITTLE
	LIGHTS BLINK ON THE MODEM.

3. WE ARE, HOWEVER, FORCING YOU TO WAIT UNTIL THE 50 OR SO CHARACTERS FOR
THE HEADER
	TO DOWNLOAD AND GET PUT UP ON YOUR SCREEN.  SOMEHOW THAT DOESN'T SEEM TOO
BAD.
	AND, TO AVOID WASTING MORE OF YOUR TIME, JUST DON'T CLICK ON THESE HEADERS
	ANY MORE.

4. WHO STARTED THE CROSS-POSTING ANYWAYS?  PROBABLY SOMEONE WHO THOUGHT
THAT IT WAS
	RELEVANT AND IN THESE GROUPS THIS HAS BEEN ONE OF THE BETTER DISCUSSIONS
I'VE 
	SEEN RECENTLY.  LEARNING STUFF.

5. FPGA: YUP, THIS HAS SOMETHING TO DO WITH FPGA.  AS THEY GET BIGGER AND
THEIR
	CAPACITY INCREASES, THESE ISSUES WILL BE *MORE* RELEVANT.  AND WITH XILINX
AND
	ALTERA BEATING THEMSELVES OVER THE HEAD FOR MAKING BIGGER FPGAS, AND TALK
OF
	MILLION GATE FPGAS (OR LETS SAY EVEN SEVERAL HUNDRED THOUSAND GATES FOR
THE
	NON-MARKETEERS) IT'S IMPORTANT TO SEE WHERE WE'RE GOING IN THE NEXT FEW
YEARS.

6. SYNTHESIS: YUP, WHAT H/W-S/W ENVIRONMENTS ARE WE GOING TO USE FOR
SYNTHESIS.  WHAT
	IMPLICATIONS DOES THIS HAVE FOR PERFORMANCE, USABILITY, TOOLS, FLOW,
REMOTE
	OPERATIONS, ETC.  SOUNDS RELEVANT.

7. VHDL: YUP, THIS IS ABOUT HDL'S, NOT STRICTLY SCHEMATIC CAPTURE.  THE
VHDL FOLKS
	KEEP TELLING US DEVICES TOO BIG FOR SCHEMATICS.  BUT THAT MEANS WE NEED
SOFTWARE.
	AND OSES TO RUN THEM ON AND HARDWARE FOR THEM TO RUN THEM ON.  AND THIS IS
A
	VERY RELEVANT TOPIC.  OR, PERHAPS IT'S ALL B.S. AND WE SHOULD GO BACK TO
THE
	DRAFTING TABLE <DAMN, THEY WOULDN'T LET ME KEEP MINE ANYMORE, NO ROOM>. 
ANYWAYS,
	IT'S RELEVANT.

8. VERILOG? DIDN'T NOTICE IT UP THERE.  DON'T DO VERILOG.  BUT LIKE 7,
ABOVE, IT PROBABLY
	IS RELEVANT.  I GUESS A LOT OF PEOPLE NEED TO RUN VERILOG FOR THEIR
SIMULATIONS.
	I HEAR IT'S A LANGUAGE OF CHOICE AND IMPORTANT.  SIGNOFF OF CHIPS AND
STUFF.

9. IT'S INTERESTING, GETTING THE DIFFERENT DISCUSSION GROUPS TO INTERMIX,
AS WE'LL BE
	GETTING CLOSER IN THE FUTURE, AS SEMICONDUCTOR TECHNOLOGIES MATURE. 
ALTHOUGH
	I DO MOSTLY FPGAS, I USE VHDL AND SYNTHESIS IN ALMOST EVERYONE OF MY
DESIGNS.
	AND FOR THE ASICS, WELL, THAT SPEAKS FOR ITSELF.

10. IF YOU'RE STILL READING THIS, YOU REALLY MUST SECRETLY ENJOY IT.  OR AT
LEAST ENJOY
	THE NET COP ROLE, GLORIOUS PROTECTOR OF INTERNET BANDWITH.

RK

P.S. LIGHTEN UP, RELAX, THIS IS SUPPOSED TO BE FUN!  PERHAPS YOU WISH TO
CHIME IN ON SOME OF YOUR OPINIONS AND EXPERIENCES.

P.S.S. I GUESS THIS MEANS THAT I DON'T AGREE WITH YOU.
Article: 9343
Subject: Re: The case for free operating systems and EDA
From: olsenc@kodiak.ee.washington.edu (Clint Olsen)
Date: 7 Mar 1998 00:45:27 GMT
Links: << >>  << T >>  << A >>
On 6 Mar 1998 23:45:04 GMT, rk <stellare@erols.com.NOSPAM> wrote:
>
>dunno, didn't ask, and it doesn't really matter in this discussion.

I'm just trying to distinguish the OS from the hardware underneath.  I
think I made that pretty clear.

>will it be easier to port an NT/alpha program to NT/pentium II?
>
>     or
>
>will it be easier to port a unix/sun program to linux/pentium II?

I'm only speculating that the NT port from hardware->hardware would be
slightly easier, but I've never performed software development on NT.  But,
I don't think it would be very time consuming at all to migrate a portable
piece of code from sun->linux/pII.

>it seems to me that if the code isn't written that portably, then moving
>to nt instead of linux will increase their work load.

Synopsys is in the business to make money just like everyone else.  This is
purely a marketing maneuver.  They clearly see that they can sell more
bundles on NT than they ever could for Linux.  This is probably true given
the lemming syndrome of most people.  When is the last time you saw a Linux
commercial on TV?  But, I would advise EDA companies not to underestimate
the power of "word-of-mouth".  At times this can be more powerful than any
marketing tool.  Hell, it's done wonders for Linux so far :)

The Linux/FreeBSD model is very similar.  Someone says they want to run
UNIX in the home.  The first thing that pops into their mind is: Linux
(surprise!).  Technical issues/merits aside, Linux has it's inertia in the
free OS marketplace as NT does commercially.

-Clint
Article: 9344
Subject: Re: Correlation implementation...
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Fri, 06 Mar 1998 19:49:45 -0500
Links: << >>  << T >>  << A >>
Rick Collins wrote:
> 
> Hi,
> 
> In addition, a Correlation typically is used with a variable sequence in place
> of the fixed FIR coefficients. The FPGA design utilizes a lookup table to
> impliment the multiplier by a fixed coefficient. This would not be easily
> programable for a variable Correlation pattern.
> 
> To impliment a multiplier of two variables requires a very large amount of
> resources in an FPGA. If on the other hand, you only have a small number of
> Correlation patterns you need to use, then you can use a separate download for
> each pattern.
> 
I don't remember what the application here is.  The coefficients in a
distributed arithmetic FIR or COrrelator can be changed on the fly, but
it is a little painful and takes some time.  If the rate is high, but
the number of sets is limited (for instance, in radar we might use a
correlator with ten sets of coefficients corresponding to evenly spaced
fractions of a range cell - the reference waveshape is constant but with
different subsample arrival times) you can get away with switching which
table is used.  THis does grow the filter by quite a bit as the number
of coefficient sets increases however.  

This may be one of those cases where you need to look at the overall
problem to see if another approach might yield a better answer.  For
instance, if this is a case where the arrival time is predictable for
future samples once it has been found for one, you can introduce a
subsample delay in the input signal to align the correlator sample clock
to the incoming data.

-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka
Article: 9345
Subject: Re: Die Size Comparison of competing FPGAs
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Fri, 06 Mar 1998 20:00:52 -0500
Links: << >>  << T >>  << A >>
Stuart Clubb wrote:
> 
> On Tue, 03 Mar 1998 12:28:12 -0800, Peter Alfke
> <peter.alfke@xilinx.com> wrote:
> 
> >Don't  believe what Marketing says about its competitor. You can be sure
> >that the facts have been massaged. There are hundreds of ways of
> >manipulating the truth without necessary creating outright lies,
> >although even that happens. ( Would you be so naive to  believe what
> >Ford says about Chevrolet, or Toyota about Honda, or McDonald about
> >Burger King or vice versa ? )
> 
> Amen to that, but a sticky wicket approaches...
> 
> >Be careful when you evaluate "equivalent" devices. One observer's
> >equivalence is another one's big difference.
> 
> You could always just cut to the chase and count the number of 4ip
> LUTs. Or maybe the number of registers? Imperfect, but better than the
> marketing "specmanship" that has been going on recently.
> 
> Let's try it shall we?....
> 
> Xilinx XC4062 - 4608 4ip LUTs, and a total of 5376 registers, of which
> 768 are internal. I/O is 384 maximum.
> 
> Altera FLEX10K100A - 4992 4ip LUTs, and a total of 5398 registers, of
> which 406 are in the I/O blocks. I/O is 406 maximum.
> 
> Similar devices yes?
> 


Well not for arithmetic.  See to use the carry chain the altera 4 lut is
broken into a pair of 3 luts, one for the carry function, one for the
bit function.  One input to each of those 3 luts is the carry in, so you
are left with a maximum of 2 inputs for arithmetic functions if you want
to stay in one level of logic.  Xilinx, on the otherhand has dedicated
carry logic, so you get a 4 lut for your bit function whether you use
the carry or not (one input is used for the carry in).  Thus for
arithmatic functions, the xilinx 4 lut and the altera 4 lut are not the
same!

What is worse with the Altera, is that if you are using the carry, the
second layer of logic can't be in the same LAB (in the 10K) because the
carry chain snakes thru all the LE's in the LAB (you could put a buffer
in as one of the carry LUTs to do this, but then you double the carry
chain delay).  The result is the signal from the first level of logic
has to go on the global row routing to get to the second level of logic
with the attendant delay and routing resource penalty.

This is significant, because in DSP there are many times when you need
more than two inputs.  Examples are adder-subtractors, multiplexed
inputs on adders, and and gates followed by adders such as those used in
multiplication.

I do however agree about not using marketing gates to evaluate devices. 
My point is that you really have to look at the architecture an evaluate
it for your application.

-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka
Article: 9346
Subject: Re: The case for free operating systems and EDA
From: "rk" <stellare@erols.com.NOSPAM>
Date: 7 Mar 1998 01:11:06 GMT
Links: << >>  << T >>  << A >>
rk:
: >dunno, didn't ask, and it doesn't really matter in this discussion.
 
clint:
: I'm just trying to distinguish the OS from the hardware underneath.  I
: think I made that pretty clear.

rk:
yes, that was clear before.  however, a requirement (mine) is run synopsys.
 and in this case, linux <> unix.  it would be nicer if it did, but that's
not the case.


rk: 
: >will it be easier to port an NT/alpha program to NT/pentium II?
: >
: >     or
: >
: >will it be easier to port a unix/sun program to linux/pentium II?
 
clint:
: I'm only speculating that the NT port from hardware->hardware would be
: slightly easier, but I've never performed software development on NT. 
But,
: I don't think it would be very time consuming at all to migrate a
portable
: piece of code from sun->linux/pII.

rk:
question is, how portable is code?  when i was writing c, we looked at what
we had to do to make it truly portable.  well, there'e books written on the
subject.  i wouldn't be surprised it most code is not that portable, but
i've been out of c for a number of years.

if one company wrote a 'nt' compiler for both intel and dec hardware, i
would imagine that the port would be easy, as they would switch out the
back end of the compiler.  the os calls would be the same.  that's a
biggie.  the commands for compilation would be the same.  that's a biggie. 
and the back end would be handled once, by the manufacturer, transparent to
the user if done well and the code isn't too bad.  perhaps someone current
in c and nt could comment on some real specifics.

rk: 
: >it seems to me that if the code isn't written that portably, then moving
: >to nt instead of linux will increase their work load.

clint: 
: Synopsys is in the business to make money just like everyone else.  This
is
: purely a marketing maneuver.  They clearly see that they can sell more
: bundles on NT than they ever could for Linux.  This is probably true
given
: the lemming syndrome of most people.  When is the last time you saw a
Linux
: commercial on TV?  But, I would advise EDA companies not to underestimate
: the power of "word-of-mouth".  At times this can be more powerful than
any
: marketing tool.  Hell, it's done wonders for Linux so far :)

rk:
totally agree here.  and with the news release for synopsis saying that
they will charge the same, small and medium users will be tempted to go
with cheaper alternatives (independent of linux or 95 or nt).  their stuff
is expensive.  they will get some more wins from people who want the same
tools on nt and unix even if it costs a bit more.  and they will get
probably a few more wins from people who have to have synopsys and the cost
of the unix hardware and admin was blocking their entry.  i would expect
this number to be small as this business is really expensive, and even the
expensive unix h/w is not the big-ticket item.

word of mouth is important and getting users to know the tool.  leaves the
door open for someone selling a $5k tool and a lot of copies.  once there's
a lot of people using it, then it can get critical mass.  like bell labs
giving away unix+c+source to universities in the '70s to run on dec
machines.  we all know what happenned.

also, it's interesting to see how agressively ambit is advertising.  and
synplicity in the pc world, amongst others.

clint: 
: The Linux/FreeBSD model is very similar.  Someone says they want to run
: UNIX in the home.  The first thing that pops into their mind is: Linux
: (surprise!).  Technical issues/merits aside, Linux has it's inertia in
the
: free OS marketplace as NT does commercially.

rk:
yeah, but there are a lot of people who want to run lots of programs at
home, and their are a lot of them.  and eda people are drop in the bucket. 
like now-adays can't communicate w/ anyone unless you have ms office.  and
systems need to be trivial to set up and use.  and most people (like me)
who can afford multiple machines at day job when necessary, will not be
able to do that at home.  perhaps a dual-boot system will be somewhat
popular.  but that's a bit messy.
-- 
--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 9347
Subject: Re: Announce - Stuart jumps ship
From: "David Rinehart" <dave@aldec.com>
Date: 7 Mar 1998 01:11:13 GMT
Links: << >>  << T >>  << A >>

Stuart Clubb <s_clubb@die.spammer.netcomuk.co.uk> wrote in article
<34fddb0c.1321474@nntp.netcruiser>...
> It gives me great pleasure to announce that I now have no ties to any
> programmable logic vendor. As some of you will recall, I have been
> working for a Lucent distributor, Eurodis Bytech, but following my HDL
> 'convictions', I have (this week) changed jobs to work for the HDL
> solutions company, Saros Technology.
> 
> Hopefully my views on programmable logic can now be treated with a
> slightly less sceptical view than they may have been in the past. ;-)
> 
> Naturally, I look forward to working with all vendors, and their UK
> distributors in the provision of HDL solutions for ASIC and PLD to
> their customers, both present, and future.
> 
> www.saros.co.uk
> 
> Modelsim, Exemplar Leonardo/Galileo, Turbowriter, IP cores, TransEDA,
> etc.
> 
> Stuart
> For those who don't give a stuff, sorry for the time-waste.

Best of luck, you could not have made a better choice for the UK market.

David
 
Article: 9348
Subject: Re: The case for Linux and EDA
From: pornin@news.ens.fr (Thomas Pornin)
Date: 7 Mar 1998 01:42:30 GMT
Links: << >>  << T >>  << A >>
In article <01bd4944$4106a440$1e83accf@homepc>,
rk <stellare@erols.comNOSPAM> wrote:
>don't know why people think you can't do good work with non unix/linux
>systems

A mere problem of interface. With Linux you can get the interface you want
(it can look like NT if you really want). With NT you have to be happy
with what Bill Gates has made for you. If you dislike the NT interface,
you are out of luck.
The "keyboard guys" who do not use the mouse, neither the arrow keys (they
are too far on the right), have real difficulties to use efficiently
mouse-driven interfaces. About the same difficulties as what a Mac user
feels when he sits in front of a DOS prompt.

>and i just don't have the time to become unix wiz.  friends i know says
>it takes 1 year of pain to get there.

It has been true. It still is with some unixes. But not with modern Linux
distributions. Actually, they seem to be simpler to install than Windows.
The reason why the average PC user has Windows and not Linux is that he
got it on his harddisk when he bought his computer, and does not want
to (re)install any OS.

	--Thomas Pornin
Article: 9349
Subject: Re: The case for free operating systems and EDA
From: pornin@news.ens.fr (Thomas Pornin)
Date: 7 Mar 1998 01:54:00 GMT
Links: << >>  << T >>  << A >>
In article <35005160.69CE@nospam.nospam.com>,
Mike Palmer  <mike.palmer@nospam.nospam.com> wrote:
[things about X11 too slow on a 28.8 connection]

You may try dxpc: it's a free X11 protocol compressor. It works really
well and costs nothing.

It should be easily found in many ftp sites.

	--Thomas Pornin


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