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 13375

Article: 13375
Subject: Re: serial arbitration
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Mon, 30 Nov 1998 17:12:47 +0000
Links: << >>  << T >>  << A >>
Rickman wrote:
<snip good stuff re PnP arbitration>
> I am not sure, but I believe PCI also works this way.

thanks for the indicators - one of these days I must 
swallow my pride and find out how PnP and PCI work....
 
> Sounds like a good way to go if you can afford the time to shift out the
> ID number. But then if you are on a serial bus, it is a moot point.

Depends what you are doing.  Remember N bits can arbitrate among 2^N
devices (the serial arbitration scheme is, after all, just a bit-
serial magnitude comparison). 16 bits gets you a fair number of
devices, 30 bits gets you more than you could dream of. 8 bits would
do for a lot of industrial applications.  Doesn't sound like too 
dreadful an overhead to me.

CANbus exploits the arbitration number by making it carry some 
useful identity information too - OK, it limits your flexibility;
but once again the application comes to the rescue - CAN is clearly 
intended to be a low-latency, lowish-throughput bus which is expected
to be quite lightly loaded.  So arbitration contests are rare, and
it doesn't much matter that the arbitration priority is fixed by other
considerations that aren't related to arbitration.  I can easily
imagine situations where that would be grotesquely untrue.

Thanks again for the info.

Jonathan Bromley

Article: 13376
Subject: Re: Help] Altera FloorPlan Editor
From: Calvin Lee <swl00000@ms5.hinet.net>
Date: Tue, 01 Dec 1998 01:14:23 +0800
Links: << >>  << T >>  << A >>
iccra ¼g¹D¡G

> i have a problem of taget size of my VHDL project.
> i try to minimize a number of  Altera Device's and Delay.
> but my synthesized VHDL Source is larger than Altera's compiled AHDL
> source and Top gdf.
>
> i wanna know Altera FloorPlan Editor and using method.
> thank you in advance.

    If you want to reduce your resource, I suggest that your have to
considerate about your design architecture first. if you don't want to
change your architecture and your target system is focus on Altera
devices, I think, everybody knows,your coding adopt AHDL is better than
Altera's VHDL. If you want to change your coding let it after synthesis
output small than before, Notice some signal type, I suggest using
"subtype" to restract your signal range,you can get a better output.
Checking your bus width, 2^n is better. Try to change your design into
structured coding, I think that let your after synthesis output size is
very close AHDL coding . To see your synthesis constraint and try some
different synthesis method, If your target devices is FLEX series,
Synthesis style to choose the "FAST" option. generally, it let you get a
better output than " Normal" and " WYSIWYG". If MAX series devices, try
" multi. level synthesys" options, it can reduce your cell count, --but
you have to simulation your output more detail.Shared expander let you
can reduce your cell count and speed, Parallel expander let it grow up.
    Floorplan editor can't reduce your cell count any more, but If you
have to fit your design cells or pins on specify locations ,please
reference your " Getting Start "  first, and to learn how to assign your
pins on specify location on device view. To assign the cells on specify
cell location is very similar to pin assign,it defferent from pin assign
only work on LAB view, and assign object is cells not pins. of course,
you have to think about your routing resource first.
                            Good Lock!
                            Calvin.


Article: 13377
Subject: Re: Will XILINX survive?
From: peter299@maroon.tc.umn.edu (Wade D. Peterson)
Date: Mon, 30 Nov 1998 17:30:27 GMT
Links: << >>  << T >>  << A >>
>I cannot see how the continued push towards ever larger FPGAs matches
>with what people actually design. I can see why the vendors do this:
>they have absolutely nowhere else to go, except keep reducing prices
>on existing parts until they all go bust.

>But very few designs are 100k+ gates. Sure, the newsletters are full
>of such examples, but those are invariably very high cost low volume
>products where the device cost was almost immaterial. I know quite a
>few people who design FPGAs for a living, and several firms who use X.
>devices in very large numbers, and most of the designs are under 10k
>gates. Anything in the 100k-1M gate region would represent a massive
>project (in man-years), unless the device is stuffed with RAM or some
>other regular structure.

Our market research is showing four trends:

1) FPGAs will continue to follow Moore's law, much in the same way
that DRAM have done.  That means very large densities at extreamely
attractive prices in the future.

2) The system-on-a-chip market (which is in it's infancy now, at least
for FPGAs) will grow at a faster pace than the market at large.  These
parts require very large densities.

3) The FPGA market will continue to erode the classic ASIC market, and
make continued inroads into those design wins.  Interestingly enough,
the opposite seems to be true as well, with ASICs making inroads into
FPGAs in many cases.  The division between ASIC and FPGA will continue
to blur.

4) FPGA and ASIC vendors will, at some point, become commodity
producers of gates.  These companies will complete on delivery, price
and (to a smaller extent) performance, but not so much on tools (which
will become the realm of third party EDA vendors).

Wade Peterson
Silicore Corporation


Article: 13378
Subject: Is it normal to have to edit the xnf file???
From: "Steve" <reply.through.newsgroup@paranoid.com>
Date: Mon, 30 Nov 1998 17:40:16 GMT
Links: << >>  << T >>  << A >>
I just got off the phone with Xilinx support re a problem
with FPGA Express creating an xnf which generated
errors in the Xilinx tools.

They said that editing the xnf to fix the error was the best
solution.  Is this normal?  There's got to be a better way.

BTW, I was going to try edif output as recommended in
answer 2866 but neither I (nor support) know how to
select edif output from Express!

This is getting a little frustrating.


Steve



Article: 13379
Subject: Re: Will XILINX survive?
From: "Austin Franklin" <dark4room@ix.netcom.com>
Date: 30 Nov 1998 17:44:18 GMT
Links: << >>  << T >>  << A >>
> I have to admit I haven't run
> into a major problems with the M1 tools yet and all in all I like
> them much better than XACT.

I'm glad to hear that, but for me, the tools are sorely lacking in both
features that previously existed, and performing their function as well as
the previous tool set.  AND that is very frustrating.

>... The conversion
> was something Xilinx had to do because, despite your (and my)
> affinity for ppr, the old tools could never have supported the new
> larger devices.

Why not?

Austin

Article: 13380
Subject: Re: Will XILINX survive?
From: "Austin Franklin" <dark4room@ix.netcom.com>
Date: 30 Nov 1998 17:50:45 GMT
Links: << >>  << T >>  << A >>
> ... Moore's law, ...

Sorry, but I can't resist...

It's not a law, it was an assertion.

Austin

Article: 13381
Subject: Re: Will XILINX survive?
From: Bob Sefton <nobody@home.com>
Date: Mon, 30 Nov 1998 18:15:58 GMT
Links: << >>  << T >>  << A >>


Austin Franklin wrote:

> 
> >... The conversion
> > was something Xilinx had to do because, despite your (and my)
> > affinity for ppr, the old tools could never have supported the new
> > larger devices.
> 
> Why not?
> 

O.k., this is what Xilinx told me. Not an unbiased source I
realize. But this came from two FAEs I've worked with a lot and I
believe them. I think some of it was algorithmic. But I also got
the impression the code for the old tools was a nightmare. I heard
Xilinx never really ever had their own internal software team, at
least not one with any continuity. I think they just brought in
contractors as needed and the code become a big patchwork. NeoCAD,
OTOH, was in the business of writing software and probably did a
much better job of it. You already noted that the new tools are
much faster and that may be a good clue as to how things would
have gone if Xilinx had stuck with XACT.

Anyone with factual knowledge about why Xilinx made this decision
out there?

Bob S.

-- 

---------------------------
 real addr:
  rsefton_@_home.com
  (remove the underscores)
---------------------------

Article: 13382
Subject: Re: Will XILINX survive?
From: peter299@maroon.tc.umn.edu (Wade D. Peterson)
Date: Mon, 30 Nov 1998 18:24:25 GMT
Links: << >>  << T >>  << A >>
"Austin Franklin" <dark4room@ix.netcom.com> wrote:
> ... Moore's law, ...
>Sorry, but I can't resist...
>It's not a law, it was an assertion.
>Austin

Okay, okay...you're right.  DRAMs (and other functions) have followed
Moore's 'assertion' pretty closely, though.  We think FPGAs will
continue to follow the same trend, and eventually end up as
commodities.

By the way...'Murphy's law' is probably an assertion too, but I find
that it works pretty consistantly.

Wade Peterson
Silicore Corporation


Article: 13383
Subject: Archiving Xilinx Foundation Projects
From: Elder V Costa <elder@dixtal.com.br>
Date: Mon, 30 Nov 1998 17:42:47 -0200
Links: << >>  << T >>  << A >>
I have projects for XC95xx that require more than 1.5Mb of disk space
when I use Foundation archiving facility and my project is not that big
to demand for such a space. Does somebody have suggestion on how to
archive only the essencial files (btw which files?)

Thanks in advance

Article: 13384
Subject: Re: Will XILINX survive?
From: husby@fnal.gov (Don Husby)
Date: Mon, 30 Nov 1998 19:54:34 GMT
Links: << >>  << T >>  << A >>
"Austin Franklin" <dark4room@ix.netcom.com> wrote:
> I disagree that NeoCAD was a problem.  They (again) created a perception of
> making a better router.  Well, it really was only better under certain
> circumstances....but when used with a design that was floorplanned, it was
> NO better, in fact, sometimes worse.  They designed it to handle regular
> structures, and the Xilinx router did not handle them at all.

The NeoCad router beat the pants off Xilinx on the chips I tried
(even floorplanned).  Also, the NeoCad router was better designed
for large chips.  The Xilinx software would have required huge amounts
of memory and time for large chips.  I'm still running NeoCad on 32 Meg.

> All the rest of the NeoCAD tools were not really very good (say, the EPIC
> editor.....).  The NeoCAD 'vision' was to make a universal set of tools for
> all programmable logic, NOT just 'another' tool for the Xilinx parts.  I
> don't believe their 'vision' was ever going to materialize, and the
> acquisition of NeoCAD by Xilinx was most fortunate for NeoCAD.

It looked like a good vision to me.  I bought the NeoCad Xilinx/Orca package
because it cost the same as a second Xilinx seat and gave me a safe way to
try Orca chips.  I tried a couple of designs on both chips and haven't used
Xilinx since.  Xilinx had a lock on customers because of expensive development
software.  NeoCad was a leak on that, providing a path to other chips.  Xilinx
made an excellent move to buy NeoCad and plug that leak.

If I could buy a universal development package today for the cost of another
Lucent seat, I would.  I might even try the new chips from Altera and Xilinx.

Article: 13385
Subject: Re: Will XILINX survive?
From: husby@fnal.gov (Don Husby)
Date: Mon, 30 Nov 1998 20:01:58 GMT
Links: << >>  << T >>  << A >>
Bob Sefton <nobody@home.com> wrote:
> O.k., this is what Xilinx told me. Not an unbiased source I
> realize. But this came from two FAEs I've worked with a lot and I
> believe them. I think some of it was algorithmic. But I also got
> the impression the code for the old tools was a nightmare. I heard
> Xilinx never really ever had their own internal software team, at
> least not one with any continuity.

I've heard the same thing.  I think another issue was that since the
NeoCad software was designed to support multiple device families
and was written for NT and Unix, then it was much easier to adapt to new
chips.  Some of the Xilinx software was device-specific, and so took
huge effort to port to new chips or new platforms.

Article: 13386
Subject: Re: Will XILINX survive?
From: SimonBacon@NOTtile.demon.co.uk (Simon)
Date: Mon, 30 Nov 98 20:26:23 GMT
Links: << >>  << T >>  << A >>

nobody@replay.com "Anonymous" writes:

<snipped a long rant, pitched to lighten a dull Monday morning>

> ... heart-breaking stories with 8000, 6200, 5200 series!

Does anyone in the know have a brief summary of the fate of the 5200?

I guess that it was a good idea at the time, but the combination of
the extra costs of another line of software and the sinking costs of
4000E silicon finished it off.  Is it formally dead?
 

Article: 13387
Subject: Re: Will XILINX survive?
From: Tim Tyler <tim@BITS.bris.ac.uk>
Date: Mon, 30 Nov 1998 21:49:10 GMT
Links: << >>  << T >>  << A >>
Bob Sefton <nobody@home.com> wrote:
: What an absolute crock of shit. Save this crap for
: misc.invest.stocks where somebody might buy into it.

Unlikely - it's easy to ignore anonymous posters trying to diss companies
- they could equally well be from the backers of the competition.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  tt@cryogen.com

It's not hard to meet expenses - they're everywhere.

Article: 13388
Subject: Re: Will XILINX survive?
From: "Austin Franklin" <dark4room@ix.netcom.com>
Date: 30 Nov 1998 21:57:44 GMT
Links: << >>  << T >>  << A >>
>  The Xilinx software would have required huge amounts
> of memory and time for large chips.  I'm still running NeoCad on 32 Meg.

I have seen that too.  I never really cared about memory use, so it wasn't
as important to me as it would be to some...
 
> > All the rest of the NeoCAD tools were not really very good (say, the
EPIC
> > editor.....).  The NeoCAD 'vision' was to make a universal set of tools
for
> > all programmable logic, NOT just 'another' tool for the Xilinx parts. 
I
> > don't believe their 'vision' was ever going to materialize, and the
> > acquisition of NeoCAD by Xilinx was most fortunate for NeoCAD.
> 
> It looked like a good vision to me.

I completely agree.

> I bought the NeoCad Xilinx/Orca package
> because it cost the same as a second Xilinx seat and gave me a safe way
to
> try Orca chips.  I tried a couple of designs on both chips and haven't
used
> Xilinx since.  Xilinx had a lock on customers because of expensive
development
> software.  NeoCad was a leak on that, providing a path to other chips. 
Xilinx
> made an excellent move to buy NeoCad and plug that leak.

Valid point, but, er, cough, cough, isn't VHDL supposed to give you that
ability today?  I believe you still needed to buy the vendors tool set for
each architecture....
 
> If I could buy a universal development package today for the cost of
another
> Lucent seat, I would.  I might even try the new chips from Altera and
Xilinx.

Completely agree.

I have a different way of doing 'universal' development.  I create my
designs using hierarchical symbols from my own library (er, Viewlogic).  It
contains all variants of registers, muxes etc, and all I need to create for
a new technology is a new lowest order element (say, for a 32 bit register,
I need to create a 1 bit register).  Now I understand there are some items
that are quite architecture dependant....so that takes a bit to do for each
technology.  This has worked fine for me for the past 8 years...

Austin
 

Article: 13389
Subject: Re: Archiving Xilinx Foundation Projects
From: Alexander Sherstuk <Sherstuk@amsd.com>
Date: Tue, 1 Dec 1998 00:58:43 +0300
Links: << >>  << T >>  << A >>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE1CAC.98EBEFB7
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable


Hi Elder,
=A0
I am using Microsoft SourceSafe to store Foundation Projects=20
(as well as Viewlogic projects). Most of Foundation files
are binary, some are - text. But SourceSafe successfully
handles all of them.
=A0
At the end of this message please see the list of the files,=20
which should be kept in SourceSafe for the sample=20
project: "exdXPa".
=A0
There are several useful tricks:
=A0* Synopsys EXP-files should be explicitly declared
=A0=A0 as binary files for MS SourceSafe.
=A0=A0 For the rest of XILINX-related files SourceSafe's=20
=A0=A0 automatic binary/text distinguishing works well.
=A0* use NTFS system (WinNT) with compression=20
=A0=A0 enabled for SourceSafe DATA directory
=A0=A0 Win95 compressed volume can also do the job
=A0* use PKZIP to save the whole SourceSafe database
=A0=A0 on removable media
=A0* use SSARC utility (part of SourceSafe) to=20
=A0=A0 reduce database size and to save very old versions=20
=A0=A0 of your design
=A0* if needed, delete your local copy of the project
=A0=A0 as soon as you are sure, it was checked into SourceSafe
=A0=A0=20
=A0
Regards,
=A0=A0 Alex Sherstuk
=A0=A0=A0=A0=A0 sherstuk@amsd.com <mailto:sherstuk@amsd.com>=20
=A0=A0=A0=20
=A0--------
=A0
Here is the list of files for the sample Foundation project:=20
=A0
$/EXD/XIL=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Root directory for XILINX =
chips,=20
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 related to EXD =
card=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

exdXLc.pdf=A0=A0=A0=A0=A0=A0=A0=A0=A0 Project definition file for =
"exdXLc" chip
exdXPa.pdf=A0=A0=A0=A0=A0=A0=A0=A0=A0 Project definition file for =
"exdXPa" chip
$/EXD/XIL/exdXPa=A0=A0=A0 Project directory
ARCV.xnf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Results of VHDL synthesis for =
the ARCV macro
ARCV.xsf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Input and output signal names =
for the ARCV macro
AXMT.xnf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Results of VHDL synthesis for =
the AXMT macro
AXMT.xsf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Input and output signal names =
for the AXMT macro
exdXPa.ncd=A0=A0=A0=A0=A0=A0=A0=A0=A0 Result of XILINX chip routing
exdXPa.ucf=A0=A0=A0=A0=A0=A0=A0=A0=A0 Design constraints
exdXPa1.SCH=A0=A0=A0=A0=A0=A0=A0=A0 Schematics, sheet 1
exdXPa2.SCH=A0=A0=A0=A0=A0=A0=A0=A0 Schematics, sheet 2
LOGIBLOX.INI=A0=A0=A0=A0=A0=A0=A0 Saved settings for the LogiBLOX tool
$/EXD/XIL/exdXPa/EXPRESS=A0 Root directory for VHDL subproj for exdXPa
$/EXD/XIL/exdXPa/EXPRESS/ARCV=A0=A0=A0 VHDL subproject for ARCV macro
ARCV.EXP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 VHDL (Synopsys) project description
ARCV.VHD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 VHDL source text for the ARCV macro
$/EXD/XIL/exdXPa/EXPRESS/ARCV/FILES=A0=A0=A0=A0=A0=A0=A0=A0 empty =
directory structures
$/EXD/XIL/exdXPa/EXPRESS/ARCV/WORKDIRS=A0=A0=A0=A0=A0 empty directory =
structures
$/EXD/XIL/exdXPa/EXPRESS/ARCV/WORKDIRS/WORK empty directory structures
$/EXD/XIL/exdXPa/LIB=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 "ad hoc" symbols (Library)
EXDXPA.BLK=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 all library files
EXDXPA.DIR=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 must be stored
EXDXPA.FIG=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in SourceSafe
EXDXPA.FLG=20
EXDXPA.GNR=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
EXDXPA.HDR=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
EXDXPA.ID=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
EXDXPA.INI=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
EXDXPA.MAP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
EXDXPA.MOD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
EXDXPA.NET=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
EXDXPA.PIN=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
EXDXPA.SYM=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
EXDXPA.SYN=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
EXDXPA.VIS=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
=A0

=A0

-----Original Message-----
From: Elder V Costa [ mailto:elder@dixtal.com.br
<mailto:elder@dixtal.com.br> ]
Posted At: Monday, November 30, 1998 10:43 PM
Posted To: comp.arch.fpga
Conversation: Archiving Xilinx Foundation Projects
Subject: Archiving Xilinx Foundation Projects


I have projects for XC95xx that require more than 1.5Mb of disk space
when I use Foundation archiving facility and my project is not that big
to demand for such a space. Does somebody have suggestion on how to
archive only the essencial files (btw which files?)

Thanks in advance



------_=_NextPart_001_01BE1CAC.98EBEFB7
Content-Type: text/html;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1251">



<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY>
<DIV><BR><FONT color=3D#0000ff size=3D2>Hi Elder,</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2>I am using Microsoft SourceSafe to =
store=20
Foundation Projects <BR>(as well as Viewlogic projects). Most of =
Foundation=20
files<BR>are binary, some are - text. But SourceSafe =
successfully<BR>handles all=20
of them.</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2>At the end of this message please =
see the list=20
of the files, <BR>which should be kept in SourceSafe for the sample =
<BR>project:=20
&quot;exdXPa&quot;.</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2>There are several useful =
tricks:<BR>&nbsp;*=20
Synopsys EXP-files should be explicitly declared<BR>&nbsp;&nbsp; as =
binary files=20
for MS SourceSafe.<BR>&nbsp;&nbsp; For the rest of XILINX-related files =

SourceSafe's <BR>&nbsp;&nbsp; automatic binary/text distinguishing =
works=20
well.<BR>&nbsp;* use NTFS system (WinNT) with compression =
<BR>&nbsp;&nbsp;=20
enabled for SourceSafe DATA directory<BR>&nbsp;&nbsp; Win95 compressed =
volume=20
can also do the job<BR>&nbsp;* use PKZIP to save the whole SourceSafe=20
database<BR>&nbsp;&nbsp; on removable media<BR>&nbsp;* use SSARC =
utility (part=20
of SourceSafe) to <BR>&nbsp;&nbsp; reduce database size and to save =
very old=20
versions <BR>&nbsp;&nbsp; of your design<BR>&nbsp;* if needed, delete =
your local=20
copy of the project<BR>&nbsp;&nbsp; as soon as you are sure, it was =
checked into=20
SourceSafe<BR>&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2>Regards,<BR>&nbsp;&nbsp; Alex=20
Sherstuk<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A=20
href=3D"mailto:sherstuk@amsd.com">sherstuk@amsd.com</A><BR>&nbsp;&nbsp;&=
nbsp;=20
<BR>&nbsp;--------</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT><FONT=20
face=3D"Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2><FONT face=3D"Courier New">Here is =
the list of=20
files for the sample Foundation project: </FONT></FONT><FONT=20
face=3D"Courier New"></FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2><FONT face=3D"Courier =
New"></FONT></FONT><FONT=20
face=3D"Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2><FONT=20
face=3D"Courier =
New">$/EXD/XIL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
Root directory for XILINX chips,=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
related to EXD=20
card&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>exdXLc.pdf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Project=20
definition file for &quot;exdXLc&quot;=20
chip<BR>exdXPa.pdf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Project=20
definition file for &quot;exdXPa&quot;=20
chip<BR>$/EXD/XIL/exdXPa&nbsp;&nbsp;&nbsp; Project=20
directory<BR>ARCV.xnf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;=20
Results of VHDL synthesis for the ARCV=20
macro<BR>ARCV.xsf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
Input and output signal names for the ARCV=20
macro<BR>AXMT.xnf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
Results of VHDL synthesis for the AXMT=20
macro<BR>AXMT.xsf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
Input and output signal names for the AXMT=20
macro<BR>exdXPa.ncd&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Result=20
of XILINX chip=20
routing<BR>exdXPa.ucf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
Design=20
constraints<BR>exdXPa1.SCH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
Schematics, sheet=20
1<BR>exdXPa2.SCH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Schematics,=20
sheet 2<BR>LOGIBLOX.INI&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Saved =
settings=20
for the LogiBLOX tool<BR>$/EXD/XIL/exdXPa/EXPRESS&nbsp; Root directory =
for VHDL=20
subproj for exdXPa<BR>$/EXD/XIL/exdXPa/EXPRESS/ARCV&nbsp;&nbsp;&nbsp; =
VHDL=20
subproject for ARCV=20
macro<BR>ARCV.EXP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
VHDL (Synopsys) project=20
description<BR>ARCV.VHD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
VHDL source text for the ARCV=20
macro<BR>$/EXD/XIL/exdXPa/EXPRESS/ARCV/FILES&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
empty directory=20
structures<BR>$/EXD/XIL/exdXPa/EXPRESS/ARCV/WORKDIRS&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
empty directory =
structures<BR>$/EXD/XIL/exdXPa/EXPRESS/ARCV/WORKDIRS/WORK empty=20
directory=20
structures<BR>$/EXD/XIL/exdXPa/LIB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&quot;ad hoc&quot; symbols=20
(Library)<BR>EXDXPA.BLK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
all library=20
files<BR>EXDXPA.DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
must be=20
stored<BR>EXDXPA.FIG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
in SourceSafe<BR>EXDXPA.FLG=20
<BR>EXDXPA.GNR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>EXDXPA.HDR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>EXDXPA.ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>EXDXPA.INI&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>EXDXPA.MAP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>EXDXPA.MOD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>EXDXPA.NET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>EXDXPA.PIN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>EXDXPA.SYM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>EXDXPA.SYN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>EXDXPA.VIS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</FONT></FONT><FONT face=3D"Courier New"></FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2><FONT face=3D"Courier =
New"></FONT></FONT><FONT=20
face=3D"Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT><BR>&nbsp;</DIV>
<P><FONT size=3D2>-----Original Message-----<BR>From: Elder V Costa [<A =

href=3D"mailto:elder@dixtal.com.br"=20
target=3D_blank>mailto:elder@dixtal.com.br</A>]<BR>Posted At: Monday, =
November 30,=20
1998 10:43 PM<BR>Posted To: comp.arch.fpga<BR>Conversation: Archiving =
Xilinx=20
Foundation Projects<BR>Subject: Archiving Xilinx Foundation=20
Projects<BR><BR><BR>I have projects for XC95xx that require more than =
1.5Mb of=20
disk space<BR>when I use Foundation archiving facility and my project =
is not=20
that big<BR>to demand for such a space. Does somebody have suggestion =
on how=20
to<BR>archive only the essencial files (btw which files?)<BR><BR>Thanks =
in=20
advance<BR></FONT></P></BODY></HTML>

------_=_NextPart_001_01BE1CAC.98EBEFB7--

Article: 13390
Subject: Re: Will XILINX survive?
From: Tim Tyler <tim@BITS.bris.ac.uk>
Date: Mon, 30 Nov 1998 22:01:03 GMT
Links: << >>  << T >>  << A >>
Peter <z80@ds2.com> wrote:

[Re: moving to ever larger FPGAs will not provide future growth...?]

: I cannot see how the continued push towards ever larger FPGAs matches
: with what people actually design. I can see why the vendors do this:
: they have absolutely nowhere else to go, except keep reducing prices
: on existing parts until they all go bust.

Power consumption, size and speed are also factors in need of attention.

FPGA manufacturers will need to design their chips using reversible logic
in the long term to cope with the former.  They may well be better
positioned to do this than traditional processor manufacturers.

I'd rather have computing machinery that went twice as fast than twice as
much of it.

: But very few designs are 100k+ gates. [...]

Prototyping designs by hand is one thing, evolving populations of designs
is quite another.  People involved in evolutionary strategies on FPGAs may
not currently constitute a large segment of the market, but they are one
that will never be at a loss for what to do with more speed, or more
gates.

: I don't think Xilinx will go bust. [...]

Indeed - I suspect only trolls would suggest otherwise.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  tt@cryogen.com

Terminal error.  You're dead.

Article: 13391
Subject: Editing XNF file
From: Alexander Sherstuk <Sherstuk@amsd.com>
Date: Tue, 1 Dec 1998 01:03:23 +0300
Links: << >>  << T >>  << A >>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE1CAD.53477E7B
Content-Type: text/plain;
	charset="koi8-r"

By the way, editing an XNF file appears also to be a 
simple method for keeping different timing constraints for
several Express macros belonging to one project.

------_=_NextPart_001_01BE1CAD.53477E7B
Content-Type: text/html;
	charset="koi8-r"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=koi8-r">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0">
<TITLE>Editing XNF file</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>By the way, editing an XNF file appears also to be a </FONT>
<BR><FONT SIZE=2>simple method for keeping different timing constraints for</FONT>
<BR><FONT SIZE=2>several Express macros belonging to one project.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE1CAD.53477E7B--

Article: 13392
Subject: Re: Will XILINX survive?
From: "Ken Coffman" <kcoffman@intermec.com>
Date: Mon, 30 Nov 1998 16:18:07 -0800
Links: << >>  << T >>  << A >>
Yes.

That's the simple answer to your question. Xilinx has good silicon products
and I don't blame them that I have to buy an HDL compiler from Exemplar or
Synplicity and a simulator from ModelTech in order to get a good development
environment. A more self-serving company would try to kill third-party
software vendors, but as far as I can tell, Xilinx has a good relationship
with these vendors. This assures their continued success as an IC
manufacturer. Don't worry, Altera will be fine too.

A more interesting (sad though it may be) question is whether the other
manufacturers will survive on their own, like Vantis, Lattice, Actel,
Quicklogic, Atmel, et al.

Too bad you don't have the cojones to sign your message, we would have
enjoyed looking up your number in the Altera telephone listing.

Anonymous wrote in message <199811290840.JAA25405@replay.com>...
>This thought should be worrying not only XILINX shareholders,
>but also, - XILINX users, who have invested a lot of efforts
>and money into mastering XILINX tools.
>
>Why should we expect XILINX shutdown in the foreseeable future?
>
>1) XILINX has started as successful innovative company and won
>essential part of the market. But that's in the past ...
>Recent history of XILINX is a sequence of disastrous failures
>to deliver satisfactory quality at reasonable price.
>Remind heart-breaking stories with 8000, 6200, 5200 series!
>Lacking new ideas, XILINX is trying to sell their old 4000
>series wrapped into Spartan envelope. And now Virtex becomes
>too late answer on Altera designs.
>
>2) XILINX applies tremendous efforts to reduce the price and ...
>the quality of its development tools.
>It was reported by many customers in this particular newsgroup
>that XILINX Foundation is worse than XACT, and each subsequent
>version of Foundation is worse than previous.
>Currently the quality of development tools is so bad that XILINX
>almost gave up any attempts to fix endless stream of bugs.
>The bugs are just stored until next version of Foundation :
>
>3) XILINX support service became some sort of psychoanalyst to
>keep users calm and to avoid bodily damage (and chip damage)
>caused by desperate customers. XILINX is afraid to reveal
>an obvious thing: there is no support for ALDEC software
>that constitutes the principal part of Foundation (design flow,
>schematics and simulation).
>
>4) And now the last news:
>MARSHALL does not sell XILINX chips any more.
>Obviously, they are feeling where the things go.
>
>Good bye XILINX ...
>
>*************
>
>
>


Article: 13393
Subject: Re: Will XILINX survive?
From: Froilan P Montenegro <froilan+@andrew.cmu.edu>
Date: Mon, 30 Nov 1998 20:49:05 -0500
Links: << >>  << T >>  << A >>
comp.arch.fpga: 30-Nov-98 Re: Will XILINX survive? by Wade D. Peterson@maroon. 
> Our market research is showing four trends:
>  
> 1) FPGAs will continue to follow Moore's law, much in the same way
> that DRAM have done.  That means very large densities at extreamely
> attractive prices in the future.
>  
> 2) The system-on-a-chip market (which is in it's infancy now, at least
> for FPGAs) will grow at a faster pace than the market at large.  These
> parts require very large densities.
>  
> 3) The FPGA market will continue to erode the classic ASIC market, and
> make continued inroads into those design wins.  Interestingly enough,
> the opposite seems to be true as well, with ASICs making inroads into
> FPGAs in many cases.  The division between ASIC and FPGA will continue
> to blur.
>  
> 4) FPGA and ASIC vendors will, at some point, become commodity
> producers of gates.  These companies will complete on delivery, price
> and (to a smaller extent) performance, but not so much on tools (which
> will become the realm of third party EDA vendors).

  What about reconfigurable computing and systems-on-a-chip with
programmable logic on the same die?  Something like a processor core and
an FPGA on the same chip with some an interface for the two to
communicate with each other.  That way if you need basic general
processing abilities along with some custom logic, this might allow you
to build a smaller, cheaper, faster implementation than current
processor/FPGA combinations.  I'm no expert but these are two
possibilities I've heard.
 
 - Froilan


Article: 13394
Subject: ASIC to FPGA conversion, low NRE
From: "Michelle Tran" <icommtek@fpga-design.com>
Date: Mon, 30 Nov 1998 21:39:29 -0500
Links: << >>  << T >>  << A >>
The FPGA Design Center provides the followings services:

(I) FPGA to ASIC conversion:
    (1) Fastest time to market: 4-8 weeks for production and prototype
    (2) Low NRE charges
    (3) Highest quality and world-class manufacturing
    (4) Fast production
    (5) Technologies: 20K gates/mm2 in 0.35 micron

(II) FPGA Design Services:
    (1) HDL Synthesis (VHDL and Verilog)
    (2) FPGA Implementation
    (3) IP Cores libraries, such as FFT engine, decimate-by-N FIR
        engine, FEC engine, Turbo Codes engine, Multipliers, etc..
    (4) Quick-Turn and friendly services



--
===========================================================
Michelle Tran                                                     IComm
Technologies, Inc.
icommtek@fpga-design.com                         http://www.fpga-design.com/
===========================================================



Article: 13395
Subject: Re: Which parts are fastest for 3-state enables?
From: "Daniel K. Elftmann" <dan.elftmann@actel.com>
Date: Mon, 30 Nov 1998 21:47:11 -0500
Links: << >>  << T >>  << A >>
Take a look at the Actel A54SX08 and contact your local Actel FAE, sounds
like a good FAE Challenge.

http://www.actel.com/products/devices/SX/chall.html

Steve wrote:

> I'm interfacing to a Motorola MPC 860 @50Mhz.  I need to provide an
> acknowledge signal in <10ns after the Clock.  To do this my PLD/FPGA
> needs to have a (Clk-Q + comb delay + tristate enable) < 10ns.
>
> So far I haven't found a CPLD to do it.  What small FPGA's have the best
> crack at it???  ... or prove me wrong on the CPLD issue?
>
> So far my only practical solution is an XCS05XL-4.
>
> Comments?
>
> Steve

Article: 13396
Subject: Re: Which parts are fastest for 3-state enables?
From: rk <stellare@NOSPAMerols.com>
Date: Mon, 30 Nov 1998 23:04:40 -0500
Links: << >>  << T >>  << A >>
got a few minutes, ran a quick design (schematics), sim (viewsim)

here's what i got:

1. used a54sx16/pl84 - released r2-1998 s/w doesn't have entry for a54sx08,
unless there's a patch that i missed

2. temp = 70C

3. voltage = 3.0V

4. fully automagic place and route

5. regular layout [not timing driven]

6. pin to pin delays: clkpin -> clock buffer -> flip-flop -> tri-state enable
-> outpin

        i don't know what the comb delay in original post was

7. i used hclk, the faster clk

8. trivially makes 100 MHz, path through output enable:

        std die = 7.7 ns

        -1 die = 6.6 ns

        -2 die = 5.8 ns

9. have the actelians donate watch to charity, i don't wear 'em

10. lots of fast fpga's out there, i have these tools at home, so i ran them:
which is "world's fastest fpga?"

rk

========================================================

Daniel K. Elftmann wrote:

> Take a look at the Actel A54SX08 and contact your local Actel FAE, sounds
> like a good FAE Challenge.
>
> http://www.actel.com/products/devices/SX/chall.html
>
> Steve wrote:
>
> > I'm interfacing to a Motorola MPC 860 @50Mhz.  I need to provide an
> > acknowledge signal in <10ns after the Clock.  To do this my PLD/FPGA
> > needs to have a (Clk-Q + comb delay + tristate enable) < 10ns.
> >
> > So far I haven't found a CPLD to do it.  What small FPGA's have the best
> > crack at it???  ... or prove me wrong on the CPLD issue?
> >
> > So far my only practical solution is an XCS05XL-4.
> >
> > Comments?
> >
> > Steve



Article: 13397
Subject: Re: Will XILINX survive?
From: "Mike & Jen" <rebane@enter.net>
Date: Mon, 30 Nov 1998 23:26:29 -0500
Links: << >>  << T >>  << A >>
I agree with Wade's statement:
>>I cannot see how the continued push towards ever larger FPGAs matches
>>with what people actually design.

What is the difference between a 500k/1M gate FPGA design and an ASIC in
terms of design time and time to market?  Not much that I can see.  An FPGA
will always be slower and consume more power than the ASIC.   Why re-invent
the wheel for 75% of a 1M gate FPGA design that uses common
cores/interfaces/functions in support of, on average 25% of the design for
actual custom IP requiring re-programmable  logic?  Devices of that size do
not show me any enhanced value from a designer's perspective.

>2) The system-on-a-chip market (which is in it's infancy now, at least
>for FPGAs) will grow at a faster pace than the market at large.  These
>parts require very large densities.

I agree.  The densities will need to be very large to implement standard
cores in FPGA logic and still have programmable logic left over to do
something custom with.  That is why I believe that the only vendor who, to
date, has actually displayed the ability to merge ASIC cores (dedicated
silicon) with surrounding FPGA logic is Lucent Technologies (ORCA).  That is
what I would define as true "systems on a chip"; not just a bigger array
block.  They seem to have the designers in mind.

>3) The FPGA market will continue to erode the classic ASIC market, and
>make continued inroads into those design wins.  Interestingly enough,
>the opposite seems to be true as well, with ASICs making inroads into
>FPGAs in many cases.  The division between ASIC and FPGA will continue
>to blur.
>
Absolutely.

>4) FPGA and ASIC vendors will, at some point, become commodity
>producers of gates.  These companies will complete on delivery, price
>and (to a smaller extent) performance, but not so much on tools (which
>will become the realm of third party EDA vendors).

If just producing larger arrays of the same ( although renamed) architecture
is the direction X and A are going to take, then FPGAs will become as you
put it "... become commodity producers of gates."   However, I do not
believe it will be reduced to quite that simplistic a level (e.g.. DRAMS).
Just because a lot of gates fill a device does not qualify it as ASICish
(forgive my new word).  I feel it would be a mistake for the marketing
departments of the FPGA vendors to promote their larger devices as ASIC
like.  To do so would insult the intelligence of most designers (I hope).
FPGAs are used to implement specific system capabilities as do ASICs.
I believe we are in store for the usual ASIC bidding wars with an FPGA
twist.  The vendors that can successfully merge the technologies will offer
true value and will set themselves apart from the traditional FPGA/ASIC
vendors.

Mike.







Article: 13398
Subject: Re: Will XILINX survive?
From: Tim Davis <timdavis@tdcon.com>
Date: Mon, 30 Nov 1998 21:44:54 -0700
Links: << >>  << T >>  << A >>
Here is my oppinion (in response to your bullets).

1. Virtex looks pretty hot to me. According to our local (biased) rep
the Xilinx tools will support Virtex long before Altera gets their software
up with their new parts and I believe him.

2. I have experienced numerous bugs with Xilinx tools but always
seem to get my work done on time.

3. Xilinx support is the best I've experienced in the last ten years from
an EDA vendor. Their support people have always worked hard to find
me an answer to my question. They seem to be the only company that
can pass you from one technical person to the next without losing
continuity and the original support person has always followed up to
see that I was properly helped. And yes, like all vendors, they have
told me, "wait until the next release".

4. Who cares about Marshall?

5. Goodbye Anonymous.

IMHO: Xilinx Epic (even when buggy) makes it possible to  make
design tweaks without total recompilation. That is a GIANT plus when
working on big parts. A compatriot was completely stymied by the
Altera tools working on a 4062 size design when he couldn't make
a few quick bug fixes with an Epic like editor. If you are trying to do
a reasonable size FPGA design (> 50k gates) then Epic can cut hours
and hours off your design cycle by letting you experiment with a possible
problem solution.

--

Tim Davis
Timothy Davis Consulting

TimDavis@TDCon.com - +1 (303) 426-0800 - Fax +1 (303) 426-1023

+-------------------------------------------------------------------+
: Engineering is like having an 8 a.m. class and a late afternoon   :
:          lab every day for the rest of your life.                 :
+-------------------------------------------------------------------+


Article: 13399
Subject: Re: Will XILINX survive?
From: jonathan@canuck.com (Victor the Cleaner)
Date: 1 Dec 1998 06:39:51 GMT
Links: << >>  << T >>  << A >>
Tim Tyler (tim@BITS.bris.ac.uk) wrote:
: Bob Sefton <nobody@home.com> wrote:
: : What an absolute crock of shit. Save this crap for
: : misc.invest.stocks where somebody might buy into it.

: Unlikely - it's easy to ignore anonymous posters trying to diss companies
: - they could equally well be from the backers of the competition.

Or from a disenchanted employee wanting to get the "truth" out and fearing
reprisals.

Me, I'm looking for any frank discussion (anonymous or not; scattershot or 
not), as I'm on the verge of selecting Xilinx for a new design.

--
    jonathan@canuck.com
 Canada Connect Corporation    | Jonathan |    Survival Research Laboratories
        Calgary, AB            |  Levine  |          San Francisco, CA
   403-705-2025, fax 2026                           vox/fax 415-641-8065



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