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 3925

Article: 3925
Subject: Re: XC6200 FPGAs
From: Brad Taylor <blt@emf.net>
Date: Tue, 20 Aug 1996 15:32:55 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> In article <32116D0C.4504@club-internet.fr>, Jean-Michel Vuillamy
> <vuillamy@club-internet.fr> wrote:
> 
> > What about the much-advertised 1995 reconfigurable FPGAs,
> > and particularly the XC6200 family? Is the latter going to follow the
> > same path as the antifuse XC8100 FPGA i.e. will it also be dropped?
> >
> Here I am again, playing marketeer because nobody else does it:
> 
> There are no plans whatsoever to drop the XC6200. There is a lot of
> enthusiasm for the concept of reconfigurable computing in Xilinx.
>

I don't want to stir anything up here, but what exactly does the 
XC6200 bring to 'reconfigurable computing'?  Or what does 
'reconfigurable computing' mean?  If I take it to mean basically
traditional data processing in FPGAs (and I can define it to be 
anything, because it has no meaning),  then the 6K seems to be missing
some fundamental concepts like internal SRAM and carry chains. 

Without access to efficient internal SRAM and adders you eliminate
the bulk of data processing problems such as DSP.  These features are
however
present in your most excellent 4K architecture. Of course, the 4K
is a bit of a pig in the $$$ department.  My point is that hardwired
silicon structures like carry chains are more valuable to me
than more 'fine grain'/$.

The real battle here is 'fine-grained' vs coarse, but the 6K does 
have a few good points - a decent host port with access to internal
registers and partial reconfigureability. But these features fall more 
in the realm of bug fixes than innovation. They should be in all your
parts. 

It is an interesting question however, as to how the fine grained chips
have
fared so badly.  Lets see we have, or have had:

- Concurrent/National/Atmel/IBM 
- Crosspoint 
- Motorola/Pilkington   
- CAL/XC6200
- XC8K
- Plessey
- Toshiba


I seem to remenber all of these promised 2-4x efficiency over your
overly complex 
4LUTs.  I would like to know what their combined market share is.  If
there is 
a real efficiency to fine grained, then why haven't we seen it in the
'real world' 
of sales and production?  My guess is that the physical layout issues
are much 
more severe with fine grained architectures. This requires 'hand layout'
to 
achieve the max efficiency and that requires experts and lots of time. 
These 
structures also seem to be more brittle when an algorithm slightly
doesn't fit, 
or has the wrong pitch.  

Personally I really don't care what underlying architecture is inside
the chip. 
If it's fast and big and cheap,  I'll use it, but only if I can use
decent automatic
tools to map logic into it.  If I can't get that, then I at least need
an architecture
that my declining number of brain cells can get a handle on.  I get the
concept with
4LUTs, Tri-state lines, and carry chains, but I fail to to comprehend
reed-muller 
algebra, tricky layouts and random collections of gates.  At any rate, I
never 
understood the attraction of fine grained myself, and I'm baffeled as to
why it is 
tied to reconfigurable computing.
-

 Brad Taylor
Article: 3926
Subject: xilinx programing
From: maya@asp.co.il (Maya Reuveni)
Date: Wed, 21 Aug 1996 06:28:50 GMT
Links: << >>  << T >>  << A >>

hi everybody,
I designed a board with 5 xilinx devices 
2 xc4013E & 3 xc4005H 
I daisy chained all the parts and connected to the xchecker connector.
I made a xxx.mcs (xxx.exo too) into a 128K bytes prom
and the done signal did not go high .....
any ideas why ? 
what should I check ?
thanks
-- 

    Maya Reuveni                                  Tel: 972-9-986976
    Manager of Hardware Department                Fax: 972-9-986980
    HaTaasiya 9, Raanana 43100, Israel.           E-mail: maya@asp.co.il


Article: 3927
Subject: FPGA 97 Call for Papers: Due date about a month away!
From: hauck@eecs.nwu.edu (Scott A. Hauck)
Date: Wed, 21 Aug 1996 10:44:38 -0500
Links: << >>  << T >>  << A >>

1997 ACM/SIGDA Fifth International Symposium on
Field-Programmable Gate Arrays

Sponsored by ACM SIGDA, with support from Altera, Xilinx, and Actel

Monterey Beach Hotel, Monterey, California
February 9-11, 1997
(Web page: http://www.ece.nwu.edu/~hauck/fpga97)

The annual ACM/SIGDA International Symposium on Field-Programmable Gate Arrays
is the premier conference for presentation of advances in all areas
related to the FPGA technology.  The topics of interest of this symposium
include, but are not limited to:

o Advances in FPGA architectures, including design of programmable logic blocks,
    programmable interconnects, programmable I/Os, and development of new
    FPGAs and field-configurable memories.

o New CAD algorithms and tools for FPGAs,  including new algorithms for
    sequential and combinational logic optimization, technology mapping,
    partitioning, placement, routing, and development of new FPGA synthesis or
    layout systems.

o Novel applications of FPGAs, including rapid prototyping, logic emulation,
    reconfigurable custom computing, and dynamically reconfigurable
    applications.

o Advances in field-programmable technology, including new process
    and fabrication technologies, and field-programmable analog arrays.

Authors should submit 20 copies of their original work by September 27, 1996.
Each submission should include an 100-250 words abstract, and is limited
in length to 12 pages (including figures and tables, minimum point size 10).
Notification of acceptance will be sent by November 18, 1996.
A proceedings of accepted paper will be published by ACM.
Authors must assign copyright of their accepted papers to ACM as a condition
of publication. Final versions of accepted papers will be limited
to seven pages, and must be submitted by December 6, 1996.
All submissions should include the e.mail addresses of the authors, as all
correspondence with authors will be done via e.mail.

Submissions should be sent to:

Prof. Jason Cong
FPGA'97 Program Chair
UCLA Computer Science Department
4711 Boelter Hall
Los Angeles, CA 90095
Phone: (310) 206-2775,  Fax: (310) 825-2273, E.mail:  fpga97@cs.ucla.edu

Organizing Committee:

General Chair:    Carl Ebeling, University of Washington
Program Chair:    Jason Cong, UCLA
Publicity Chair:  Scott Hauck, Northwestern University
Finance Chair:    Jonathan Rose, University of Toronto
Local Chair:      Pak Chan, UC Santa Cruz

Program Committee:

Michael Butts           Quickturn
Pak Chan                UCSC
Jason Cong              UCLA
Carl Ebeling            U. Washington
Masahiro Fujita         Fujitsu Labs
Scott Hauck             Northwestern Univ.
Dwight Hill             Synopsys
Brad Hutchings          BYU
Sinan Kaptanoglu        Actel
David Lewis             U. Toronto
Jonathan Rose           U. Toronto
Richard Rudell          Synopsys
Rob Rutenbar            CMU
Gabriele Saucier        Imag
Martine Schlag          UCSC
Tim Southgate           Altera
Steve Trimberger        Xilinx
Martin Wong             UT Austin
Nam-Sung Woo            Lucent Technologies
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|               Scott A. Hauck, Assistant Professor                         |
|  Dept. of ECE                        Voice: (847) 467-1849                |
|  Northwestern University             FAX: (847) 467-4144                  |
|  2145 Sheridan Road                  Email: hauck@ece.nwu.edu             |
|  Evanston, IL  60208                 WWW: http://www.ece.nwu.edu/~hauck   |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Article: 3928
Subject: Digital H/W Engineer (ASIC, VHDL)
From: Kevin Hawes <khawes@cadstar.com>
Date: Wed, 21 Aug 1996 13:16:42 -0400
Links: << >>  << T >>  << A >>
Job Description: 
                  Product and system definition and design
                  implementation using leading-edge
                  development tools and processes to continually
                  improve product quality. The ability to evaluate
                  hardware/software, cost/performance and
                  manufacturing tradeoffs is a critical skill needed
                  for success in this position. Other requirements
                  include strong interpersonel and
                  communication skills. 
  Requirements: 
                  BSEE/CE (MS preferred) and 5 years
                  experience in the development of digital
                  hardware for embedded real-time systems. Must
                  be experienced with multiple embedded
                  microcontrollers, VHDL, ASIC development
                  methodologies, have "big picture" perspective
                  and should be comfortable navigating the
                  multitude of design tradeoffs required for
                  successfull high volume product development. 
       Location: 
                  NY
       Duration: 
                  Contract to Direct
       Pay Rate: 
                  Open

         YOU MUST REFERENCE JOB NUMBER 1000214

            Email your resume to: khawes@cadstar.com 
                Fax your resume to: (508)649-7856 
              or Call Kevin T. Hawes at (508)649-6828

                      CADstar International
                       130 Middlesex Road
                      Tyngsboro, MA 01879
Article: 3929
Subject: Re: XC6200 FPGAs
From: peter@xilinx.com (Peter Alfke)
Date: Wed, 21 Aug 1996 10:51:26 -0700
Links: << >>  << T >>  << A >>
In article <321A3D17.27DF@emf.net>, Brad Taylor <blt@emf.net> wrote:


> I don't want to stir anything up here, but what exactly does the 
> XC6200 bring to 'reconfigurable computing'?  Or what does 
> 'reconfigurable computing' mean?  If I take it to mean basically
> traditional data processing in FPGAs (and I can define it to be 
> anything, because it has no meaning),  then the 6K seems to be missing
> some fundamental concepts like internal SRAM and carry chains. 
> 
Well, you did stir up something here.
I just answered the question: Is there an XC62000, and is there some
documentation ? And there is.
The much deeper question of fine-grained vs coarse-grained architecture,
and which one is more amenable to reconfigurable computing, and what is
really reconfigurable computing, those questions are beyond the scope of a
20-line response.

But they are interesting questions, and they might deserve their own thread.
I bet there are lots of juicy opinions around. Let's hear them ! This is
still a very young field with lots of exciting opportunities for changes
and twists.

Peter Alfke, Xilinx Applications
Article: 3930
Subject: Re: XACT6.0:prosim and routed design
From: sheynin@psc.fp.co.nz (Oleg Sheynin)
Date: Wed, 21 Aug 1996 11:55:52
Links: << >>  << T >>  << A >>
In article <4v81sl$ej5@rc1.vub.ac.be> tw38966@vub.ac.be (Rafiki Kim Hofmans) writes:
>From: tw38966@vub.ac.be (Rafiki Kim Hofmans)
>Subject: Re: XACT6.0:prosim and routed design
>Date: 18 Aug 1996 21:27:49 GMT

>Rafiki Kim Hofmans (tw38966@vub.ac.be) wrote:
>: Hi,

>: 1) If I want to simulate my routed design, all the signals connected
>: immediately to an I/O pad are unknown. How can I assign values to the
>: 'unknown signals' ?

>Well, I finally found out what the problem was. 
>I was always setting the routing effort to it's maximum (4).
>Somehow XACT wasn't able to route some pins (let's say almost none of
>them)

>Decreasing the routing and placement effort to 3, solved the problem.



So, _decreasing_ the effort levels "somehow" improved the routing rate from 
"almost none" to all routed?! - What a feature!

Does anyone know enough about the algorithms to be able to shed more light on 
the use of the effort level assignments?


Oleg Sheynin.
 This communication is made personally by
 Oleg Sheynin who does not represent or purport
 to represent the Fisher & Paykel Group or any
 of its subsidiaries in any way.
 ---------------------------------------------------
 Oleg Sheynin           |Fisher & Paykel
 Development Engineer   |Production Machinery Ltd.
 sheynin@fp.co.nz       |PSC Section
 Phone +64-9-535 0676   |P.O. Box 58-223, Greenmount
 Fax   +64-9-535 0661   |Auckland, New Zealand
 ---------------------------------------------------
Article: 3931
Subject: Re: INDUSTRY GADFLY: EDA Goes OJ
From: Henry Spencer <henry@zoo.toronto.edu>
Date: Wed, 21 Aug 1996 20:28:10 GMT
Links: << >>  << T >>  << A >>
In article <DwG8xL.5nv@world.std.com> jcooley@world.std.com (John Cooley) writes:
>  To the question "TRUE or FALSE: As an engineer, I believe the American
>legal system is generally capable of rendering justice in technically complex
>lawsuits.", only 27 percent said TRUE.  "I worked on the AMD/Intel suit with
>Intel and the whole process was a joke.  The judge was so technically
>clueless..."

While I wouldn't quarrel with the sentiment that there is often a problem
there, it's worth remembering that some judges do their homework.  Judge
Debevoise, whose denial-of-preliminary-injunction opinion induced USL to
settle out of court with BSDI and UCB, clearly understood the issues in
detail -- that opinion was a masterful summary, surprising and impressive. 
-- 
 ...the truly fundamental discoveries seldom       |       Henry Spencer
occur where we have decided to look.  --B. Forman  |   henry@zoo.toronto.edu
Article: 3932
Subject: FPGA vs. Custom design
From: Philip Americus <americus@ruth.ece.psu.edu>
Date: Wed, 21 Aug 1996 21:02:02 -0400
Links: << >>  << T >>  << A >>
I have an FPGA design that I'm thinking of moving into a full custom
ASIC design.  Does anyone know of any sources for how much improvement
in speed I can get by making this transfer?  I don't actually want to do
the transfer, I just want to know approximately how much improvement
there will be.

Thanks,
Phil

-----
americus@ruth.ece.psu.edu
http://cobb.ece.psu.edu/americus
Article: 3933
Subject: Re: XC6200 FPGAs
From: wolf@aur.alcatel.com (William J. Wolf)
Date: 22 Aug 1996 12:16:50 GMT
Links: << >>  << T >>  << A >>
Brad Taylor <blt@emf.net> writes:
>I don't want to stir anything up here, but what exactly does the 
>XC6200 bring to 'reconfigurable computing'?  Or what does 
>'reconfigurable computing' mean?  If I take it to mean basically
>traditional data processing in FPGAs (and I can define it to be 
>anything, because it has no meaning),  then the 6K seems to be missing
>some fundamental concepts like internal SRAM and carry chains. 

Please do stir up discussion on reconfigurable computing :)
Way too much noise lately :(

>... the attraction of fine grained myself, and I'm baffeled as to
>why it is tied to reconfigurable computing.

You make some good points Brad.  Even the fine-grain advocates seem to 
be going to mixed logic & SRAM parts for "System" solutions.  

I'm just guessing that engineers that developed some of the fine grain 
architectures got stuck on how well they work for select applications 
with regular structures.  Perhaps the market share numbers have something 
to do with the real world having a variety of applications, including some 
regular structures but also a lot of random glue.

-- 
- Bill Wolf, Raleigh NC
- My opinions, NOT my employer's


Article: 3934
Subject: Re: FPGA vs. Custom design
From: Russell Petersen <russp@valhalla.fc.hp.com>
Date: Thu, 22 Aug 1996 09:05:43 -0600
Links: << >>  << T >>  << A >>
Philip Americus wrote:
> 
> I have an FPGA design that I'm thinking of moving into a full custom
> ASIC design.  Does anyone know of any sources for how much improvement
> in speed I can get by making this transfer?  I don't actually want to do
> the transfer, I just want to know approximately how much improvement
> there will be.
> 
> Thanks,
> Phil
> 
> -----
> americus@ruth.ece.psu.edu
> http://cobb.ece.psu.edu/americus


My experience would suggest about 10-20 times faster, depending on what
types of operations you are doing of course.  It also depends on the
process being used for the full custom ASIC.

-- 
Russell J. Petersen            *****     *****
VLSI Design Engineer           ***  /_  __ *** 
Hewlett Packard ICBD           **  / / /_/  **  
3404 E. Harmony Rd.            ***    /    ***  Phone: (970) 229-7007 
Ft. Collins, CO 80525          *****     *****  fax:   (970) 229-6580
email: russp@valhalla.fc.hp.com
Article: 3935
Subject: Re: INDUSTRY GADFLY: EDA Goes OJ
From: jbuck@synopsys.com (Joe Buck)
Date: 22 Aug 1996 15:57:34 GMT
Links: << >>  << T >>  << A >>

jcooley@world.std.com (John Cooley) writes:
>>  To the question "TRUE or FALSE: As an engineer, I believe the American
>>legal system is generally capable of rendering justice in technically complex
>>lawsuits.", only 27 percent said TRUE.  "I worked on the AMD/Intel suit with
>>Intel and the whole process was a joke.  The judge was so technically
>>clueless..."

Henry Spencer <henry@zoo.toronto.edu> writes:
>While I wouldn't quarrel with the sentiment that there is often a problem
>there, it's worth remembering that some judges do their homework.  Judge
>Debevoise, whose denial-of-preliminary-injunction opinion induced USL to
>settle out of court with BSDI and UCB, clearly understood the issues in
>detail -- that opinion was a masterful summary, surprising and impressive. 

Similarly, the judges in the Communications Decency Act case in
Philadelphia did a masterful job; their decision's text includes one
of the best non-technical explanations of the net and its services
(WWW, FTP, telnet, e-mail, Usenet, gopher, IRC, etc) I've seen.
Once they got the facts straight the decision became obvious.

I must agree with John, though, that in many cases the courts botch it.
But when I think about the differences, in both the BSDI/UCB/AT&T case and
the ACLU/EPIC/lots-of-folks vs CDA case, at least one side had a strong
interest in educating the court.  In the AMD/Intel cases, it seems to me
that the lawyers for both sides were quite happy to spread as much
confusion as possible, working to throw out the judge just when he finally
had a clue meaning starting over with a judge who knows nothing, and it
may have been in some cases that the lawyers were acting more in their own
interests (prolong the case, collect lots of $$$) than in the interests of
the companies they were supposed to be representing.

Maybe courts need third parties without an axe to grind to educate the
judges on things like (say, in the recent EDA litigation) the modern chip
design process, what placement and routing are, an outline of which
algorithms are in the public research literature and what software was
released by universities, and all the other background technical questions
that both sides can agree to.

Me?  I have no idea whether Avant! ripped off Cadence or not.





-- 
-- Joe Buck	http://www.synopsys.com/pubs/research/people/jbuck.html

Work for something because it is good,
not just because it stands a chance to succeed.	   -- Vaclav Havel
Article: 3936
Subject: Biggest FPGA
From: Richard Schwarz <aaps@erols.com>
Date: Thu, 22 Aug 1996 22:36:31 -0400
Links: << >>  << T >>  << A >>
I currently have an ASIC simulated in 2 XILINX 4010E FPGAs & 2 4020E 
FPGAs (4 FPGAs). I am using EXEMPLAR VHDL for synthesis. I am looking 
for a larger RAM based FPGA which I could fit the entire design in for 
field trials. I will need perhaps 200 at that time. I am going to try 
the XILINX EX seris -with help from XILINX- (since the routing software 
is not out yet) and I am going to try AT&T 40,000 gate parts (I get an 
EVAL seat tommorrow). I have tried to route my desiign in ALTERA's 
FLEX 10K series but my designs extensive use of TRISTATES seem to 
require that I change the VHDL code (which I don't wish to do, since the 
design is stable!). I was wondering if anyone from the brain pool out 
there has had any experience doing something like this, and/or has had 
any experience with the chips I have already mentioned, or with any 
larger FPGAs. I would like to keep the cost below $500.00/ea but am 
willing to look at all contenders. 

Also I am very confussed on VENDOR's gate counts. I am most familiar 
with the XILINX family of chips and would like estimates based on those 
FPGA gate counts. I beleive that I only have around a 30,000 gate design 
with a lot of logic being taken up in routing resources. I have had past 
experiences with 25,000 gate parts with poor routing results (60% OF 
PART UTILIZED WITHOUT FLOORPLANNING) but those were older parts.
Article: 3937
Subject: CHEAP XILINX FPGA ROUTING SOFTWARE ?
From: Richard Schwarz <aaps@erols.com>
Date: Thu, 22 Aug 1996 22:55:45 -0400
Links: << >>  << T >>  << A >>
My company currently sells a low cost test board which has been used by 
universities and engineering firms as a training tool (amongst other 
things). I would like to find a low cost entry level synthesis/routing 
tool which would give some capability to the entry level users of the 
board. We do sell some more complex boards which are higher priced, and 
better suited for the fullblown high end tool sets, however this board 
sells for only $250.00 and uses the a XILINX 4000/5000 seris 84 pin PLCC 
on a PC board. I would really like to find a tool that is shareware or 
very low cost which get the job done. I have heard that there is some 
software out there that can do the job, but have had no luck in finding 
any. If anyone knows or has anything like this please email me its 
location and/or the zipped files. The format (VHDL/VERILOG/C/PALASM) is 
not critical. If any vendors have demo/reduced capabilty software which 
could do the job I will gladly distribute and support that tool set and 
help promote your higher priced tools. I remember when I first started 
doing FPGA SYNTHESIS, and know how much these low cost options would 
have helped me, and how I later liked working with tools which I felt 
familair with. 

Thank You in advance
Article: 3938
Subject: Re: XC6200 FPGAs
From: KWKolb@gnn.com (Kevin Kolb)
Date: Thu, 22 Aug 1996 21:21:11
Links: << >>  << T >>  << A >>
   EDN had an article on reconfigurable computing in their 3/28/96 
issue.  You can download the article, after registering, from EDN 
at their website, http://www.ednmag.com/.  The article was titled 
"Reconfigurable Logic: Hardware Speed With Software Flexibility,"  
and covered the Xilinx XC6200 FPGA, other reconfigurable FPGA's, 
and board level products.

   It was my understanding from the article that reconfigurable 
FPGA's differ from regular SRAM FPGA's and in-system programmable 
CPLD's by the speed with which they can be reconfigured, and in the 
case of the CPLD's, how many times they can be reconfigured.  A 
complete reconfiguration of the reconfigurable FPGA's normally 
requires on the order of 1 ms, partial reconfigurations are 
possible with some parts, and the parts can be reconfigured an 
infinite number of times (at least orders of magnitude more times 
than the 10,000 specified for in-system programmable flash parts 
like Lattice's). 

   I am a radar system engineer and I would be interested in 
learning from the experiences of anyone who has actually used the 
FPGA's, support products, or board level products.

V/R,
Kevin

Article: 3939
Subject: Re: XC6200 FPGAs
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 23 Aug 1996 07:22:05 GMT
Links: << >>  << T >>  << A >>
In article <321A3D17.27DF@emf.net> Brad Taylor <blt@emf.net> writes:
>Peter Alfke wrote:
>> In article <32116D0C.4504@club-internet.fr>, Jean-Michel Vuillamy
>> <vuillamy@club-internet.fr> wrote:
>> > What about the much-advertised 1995 reconfigurable FPGAs,
>> > and particularly the XC6200 family? Is the latter going to follow the
>> > same path as the antifuse XC8100 FPGA i.e. will it also be dropped?
>> Here I am again, playing marketeer because nobody else does it:

Stick to engineering peter, more meat, less dirt  :-)

Having said that, let me throw some dirt.

>> There are no plans whatsoever to drop the XC6200. There is a lot of
>> enthusiasm for the concept of reconfigurable computing in Xilinx.
>I don't want to stir anything up here, but what exactly does the 

stir, stir, stir ....

>XC6200 bring to 'reconfigurable computing'?  Or what does 
>'reconfigurable computing' mean?

Reconfigurable Computing is one of the most recent names given
to the use of FPGAs for building computing surfaces, like any
of the following products/projects have demonstrated:
Giga-ops, Metalithic, VCC, Splash, Perle [0..2] / Pammette, ...

Since all of these systems have been built, and demonstrated to
be able to give usefull results, and none use the XC6200, then
one could observe that 'Reconfigurable Computing' has managed
fairly well without the XC6200. 

Among the features that XC6200 has is partial reconfiguration,
and faster configuration through parallel transfer. Obviously
current applications have gotten by without this, but maybe
there are applications that would take advantage of this.
Do these architectures require a new architecture?

The loyal opposition says: Then why not just add partial reconfiguration
and faster parallel configuration to existing architectures like XC3000
and XC4000 that are used in all the above listed systems. You would then
have the advantage that you would still be working with an established
architecture for which there is more than ample support P&R tools, as well
as libraries and synthesis support, plus most importantly, people that
have already learned the underlying architecture.
The loyal opposition sits smugly, awaiting a rebuttal. 

>If I take it to mean basically
>traditional data processing in FPGAs (and I can define it to be 
>anything, because it has no meaning),  then the 6K seems to be missing
>some fundamental concepts like internal SRAM and carry chains. 

Yep.

>Without access to efficient internal SRAM and adders you eliminate
>the bulk of data processing problems such as DSP.  These features are
>however
>present in your most excellent 4K architecture. Of course, the 4K
>is a bit of a pig in the $$$ department.  My point is that hardwired
>silicon structures like carry chains are more valuable to me
>than more 'fine grain'/$.

The cost of a product and the price of product are separate animals.

Cost is a function of die size, process technology, package, test time
and complexity. Price is a bigger number.

In an apples to apples comparison (same process technology, SRAM 
reconfigurable FPGA, same package, similar gate count), 
then:
They got gates, we got gates. (they are about the same size)
They got FFs, we got FFs. (they are about the same size)
They got configuration bits, we got configuration bits ( ditto)
They got routing, we got routing ( ditto)
They got config logic, we got config logic (ditto)
They got global clocks, we got global clocks (ditto)
They got user RAM, whoops we left it out, but it's cheaper (stick the
				RAM outside, burn some pins, and
				bandwidth is lower)
They got I/O FFs, whoops we left it out, but it's cheaper (and harder
							to use)
They got carry logic, whoops we left it out, but it's cheaper ( and
				arithmetic is slower, and requires
				more general purpose logic cells,
				and consumes routing too.)
They haven't got faster/partial reconfig, we have, and it wasn't
					  very expensive to add 
					  because it was part of the
					  original design, so was
					  basically free.

Regardless of the overall architecture, all the SRAM FPGAs (coarse
and fine, from any vendor) have about the same die size per gate
when implemented in the same silicon process, assuming there is
sufficient routing to route it. You can always build smaller chips
by not having enough routing resources. The 'user' gates delivered
per square mil of silicon in these architectures is about 1/10 as
many as you get in an equivalent process full custom chip. It is
also 2 to 10 times slower. Thats why XC4000 carry logic works
as well as it does: it is dedicated custom gates: Denser (cheaper)
and faster than a user configurable equivalent, but a 'use it or
lose it' feature. If you are using carry logic in greater than 1
in 10 logic blocks, it is a net win. Even if you don't use that much,
any use (in a fast counter for example) may enable a system design,
due to the performance advantages that would not otherwise be available.

>
>The real battle here is 'fine-grained' vs coarse, but the 6K does 
>have a few good points - a decent host port with access to internal
>registers and partial reconfigureability. But these features fall more 
>in the realm of bug fixes than innovation.

The loyal opposition says: Then why not just add a decent host port to an
existing architecture like XC3000 and XC4000 that are used in all the
above listed systems. You would then have the advantage that you would
still be working with an established architecture for which there is more
than ample support P&R tools, as well as libraries and synthesis support,
plus most importantly, people that have already learned the underlying
architecture. 

The loyal opposition sits smugly, awaiting a rebuttal. 

>They should be in all your parts.

Obviously, I agree.

>It is an interesting question however, as to how the fine grained chips
>have fared so badly.  Lets see we have, or have had:

Matches my observations

>
>- Concurrent/National/Atmel/IBM 
>- Crosspoint 
>- Motorola/Pilkington   
>- CAL/XC6200
>- XC8K
>- Plessey
>- Toshiba
>I seem to remenber all of these promised 2-4x efficiency over your
>overly complex 4LUTs.  I would like to know what their combined market 
>share is.

Zip.

They also promised far better performance, easier to use, easier to
migrate to ASIC, less fattening, cures cancer,...

>If there is a real efficiency to fine grained, then why haven't we
>seen it in the 'real world' of sales and production?

An advantage of fine grained architectures is that when allocating
resources to a specific functional block, when the mapping isn't
perfect, less resources are wasted. I believe this advantage is
mitigated by the topological constraints that these fine grained
architectures have, due to the quite limmited routing resources.
(The XC8100 is not included in the above limmitation, but then
it isn't reprogrammable. I don't know about the crosspoint routing
resources versus usage)

>My guess is that the physical layout issues are much 
>more severe with fine grained architectures. This requires 'hand layout'
>to achieve the max efficiency and that requires experts and lots of time. 

I think all architectures can show greatly improved density
and performance when the designer does structural things in the
design that map to the target architecture. This is the basis of
my consulting business.

>These  structures also seem to be more brittle when an algorithm slightly
>doesn't fit, or has the wrong pitch.  

The thing that breaks these architectures the worst is that while
a carefully designed benchmark circuit can be layed out and tiled
to be very impressive, in the real world, real designs have non-
trivial control logic. These gates can't be placed 'on-pitch', and
because there may be quite a few gates (i.e. a 10K gate design is
7K gates of beautifully structured, on pitch, data path, there is
also 3K gates of random logic, state machines, decoders, and
diagnostic stuff), that are too much to be layed out by hand. As
designs get bigger, so does the problem.

>Personally I really don't care what underlying architecture is inside
>the chip. If it's fast and big and cheap,  I'll use it, but only if I
>can use decent automatic tools to map logic into it.

I do care. I don't have enough extra time to learn yet another
architecture who's only major claim to fame is that it is different.
There is a steep learning curve associated with the tools and
architectures. The reasons for having a new architecture must be
compelling rather than just different to warrant a new architecture.

>If I can't get that, then I at least need an architecture that my
>declining number of brain cells can get a handle on.  I get the concept
>with 4LUTs, Tri-state lines, and carry chains, but I fail to to comprehend
>reed-muller algebra, tricky layouts and random collections of gates.  At
>any rate, I never understood the attraction of fine grained myself, and
>I'm baffeled as to why it is tied to reconfigurable computing. 

Seems I agree with you.

>-
>
> Brad Taylor

Philip Freidin.

Article: 3940
Subject: Re: xilinx programing
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 23 Aug 1996 07:29:54 GMT
Links: << >>  << T >>  << A >>
In article <DwH602.J2w@asp.co.il> maya@asp.co.il writes:
>
>hi everybody,
>I designed a board with 5 xilinx devices 
>2 xc4013E & 3 xc4005H 
>I daisy chained all the parts and connected to the xchecker connector.
>I made a xxx.mcs (xxx.exo too) into a 128K bytes prom
>and the done signal did not go high .....
>any ideas why ? 
>what should I check ?
>thanks
>    Maya Reuveni                                  Tel: 972-9-986976
>    Manager of Hardware Department                Fax: 972-9-986980
>    HaTaasiya 9, Raanana 43100, Israel.           E-mail: maya@asp.co.il

Start by separating the done and init signals (if they are tied together),
and try downloading just the first device in the chain, with just its bit
stream. You do not have to disconnect the downstream parts, to do this
test. If this works, build a bit stream for the first two devices, and try
again. if this fails then you have at least localized the problem. Remember
that in daisy chain mode you need an extra trailing '1' bit that you clock
into the lead device for each additional chip in the chain. I usually throw
an FF byte in at the end just for good measure.

Let us know how your debug progresses.

Philip 'Done Grounded' Freidin



Article: 3941
Subject: Re: FPGA vs. Custom design
From: Duncan Charity <d_charity@sames.co.za>
Date: 23 Aug 1996 12:59:40 GMT
Links: << >>  << T >>  << A >>
Philip Americus <americus@ruth.ece.psu.edu> writes:
> I have an FPGA design that I'm thinking of moving into a full custom
> ASIC design.  Does anyone know of any sources for how much improvement
> in speed I can get by making this transfer?  I don't actually want to do
> the transfer, I just want to know approximately how much improvement
> there will be.
> 
> Thanks,
> Phil
> 
> -----
> americus@ruth.ece.psu.edu
> http://cobb.ece.psu.edu/americus
Dear Phil,
I will ask one of our engineers who has vast experience of this to contact you via email

Article: 3942
Subject: Re: xilinx programing
From: peter@xilinx.com (Peter Alfke)
Date: Fri, 23 Aug 1996 08:43:06 -0700
Links: << >>  << T >>  << A >>
In article <DwH602.J2w@asp.co.il>, maya@asp.co.il wrote:

> hi everybody,
> I designed a board with 5 xilinx devices 

> what should I check ?

I don't know whether your files are properly arranged in the parallel
PROM, so let me assume that they are.
The first test should be to look for the 40-bit preamble appearing at the
Dout of every device, including the last device in the daisy chain. If it
does, then the chain at least got started properly, and we have to look
for more subtle problems, including the file structure.
If it doesn't, you most likely have a CCLK distribution problem, most
likely caused by reflections and ringing due to the fast rise time.

There is a Xilinx app note called:FPGA Configuration Guidelines. It is
also reprinted in the 1996 Xilinx Data Book, pages 14-3 ff.And you can of
course download it from the web.

You can also e-mail me directly :  peter@xilinx.com

Peter Alfke, Xilinx Applications
Article: 3943
Subject: Re: CHEAP XILINX FPGA ROUTING SOFTWARE ?
From: ft63@dial.pipex.com (Peter)
Date: Fri, 23 Aug 1996 17:57:13 GMT
Links: << >>  << T >>  << A >>

Everybody is looking for cheap *Xilinx* place-route software! No luck
yet AFAIK.
Peter.
Article: 3944
Subject: Re: CHEAP XILINX FPGA ROUTING SOFTWARE ?
From: edc@cce.com (Ed Casas)
Date: Fri, 23 Aug 1996 17:57:57 GMT
Links: << >>  << T >>  << A >>
In article <321D1DB1.20F1@erols.com>, Richard Schwarz wrote:

> My company currently sells a low cost test board which has been
> used by universities and engineering firms as a training tool
> (amongst other things). I would like to find a low cost entry
> level synthesis/routing tool ... I would really like to find a
> tool that is shareware or very low cost which get the job
> done. I have heard that there is some software out there that
> can do the job, but have had no luck in finding any. ... I
> remember when I first started doing FPGA SYNTHESIS, and know
> how much these low cost options would have helped me, and how I
> later liked working with tools which I felt familair with.

For universities it isn't a problem since they can get free or
very low cost synthesis tools from most of the major players
(Synopsis, Cadence, etc) and free place/route s/w from Xilinx.

But there isn't much in the way of synthesis tools for the
individual hobbyist.  What I have found is:

- Synplicity had a demo for their nice-looking VHDL synthesizer
but it doesn't do simulation.

- There is a free ASIC design package called Alliance which
includes VHDL synthesis but it only runs on UNIX machines and the
VHDL subset is limited and rather unusual.  It has an FPGA
compiler that produces XNF but you still need the Xilinx
place/route tools.

- There's a free synthesizer for Xilinx 4000 series that uses 'C'
as the HDL.  Again, you'd need to buy the Xilinx place/route.

If you're willing to abandon Xilinx there are a couple of other
options:

- Cypress sells their Warp synthesis package for $99.
Unfortunately it only targets Cypress FPGAs which are not
reprogrammable.

- Motorola has a free place/route tool for their FPGAs (not
Xilinx).  You need something to generate the netlists first
though.

I'd be interested in any other options that people have come up
with for free or low-cost VHDL/Verilog synthesis for FPGAs.

-- 
Ed Casas (edc@cce.com)
Article: 3945
Subject: Verilog vs. VHDL
From: takashi@hpcc01.corp.hp.com (Takashi Hidai)
Date: Fri, 23 Aug 1996 19:01:52 GMT
Links: << >>  << T >>  << A >>
I have been using both Verilog and VHDL for my simple application
and like to find out which language is the best for my particular 
application.
Although, I have realized the advantages and disadvantages for both
languages by myself, I still like to hear the common sense/opinion 
about these two HDLs such as FAQ.

Did anybody know any of the discussion/article/whatever talking about 
those two languages ?

Thanks,
Takashi

*******************************************************************************
*                   * Hewlett Packard                                         *
*  Takashi Hidai    * Optical Communications Div. * Phone:    (408) 435-5829  *
*                   * M/S 90UA                    * Telnet:       1-435-5829  *
*  Senior Design    * 370 W. Trimble Road         * Fax:    (1/408)-435-6286  *
*    Engineer       * San Jose, CA 95131                                      * 
*                   * Email: takashi_hidai@sj.hp.com                          *
*******************************************************************************




Article: 3946
Subject: Low cost or shareware into-level routing/synthesis softwae
From: Richard Schwarz <aaps@erols.com>
Date: Fri, 23 Aug 1996 19:17:35 -0400
Links: << >>  << T >>  << A >>
Our company sells (among other things) a low cost($250.00) XILIX FPGA 
board which a lot of universities and entry level engineers use. I am 
currently looking for a low cost or shareware tool which will synthesize 
a XILINX 4000/5000 type FPGA which we could distribute with the board. I 
have heard that there is shareware out there of this nature, but have 
not been able to find any.If anyone knows of any please send me the 
location and or the files.  VHDL/Verilog/C/palasm formats are all ok. We 
would not charge any money for the distribution and will promote and/or 
support the software. We currently sell a higher priced FPGA system 
which would use a higher end/complete software tool and any company 
willing to offer a reduced capability demo version will also get our 
support on the higher end toolset.

Thanks in advance

Richard
Article: 3947
Subject: Low Cost/Shareware XILINX synthesis software?
From: Richard Schwarz <aaps@erols.com>
Date: Fri, 23 Aug 1996 19:19:41 -0400
Links: << >>  << T >>  << A >>
Our company sells (among other things) a low cost($250.00) XILIX FPGA 
board which a lot of universities and entry level engineers use. I am 
currently looking for a low cost or shareware tool which will synthesize 
a XILINX 4000/5000 type FPGA which we could distribute with the board. I 
have heard that there is shareware out there of this nature, but have 
not been able to find any.If anyone knows of any please send me the 
location and or the files.  VHDL/Verilog/C/palasm formats are all ok. We 
would not charge any money for the distribution and will promote and/or 
support the software. We currently sell a higher priced FPGA system 
which would use a higher end/complete software tool and any company 
willing to offer a reduced capability demo version will also get our 
support on the higher end toolset.

Thanks in advance

Richard
Article: 3948
Subject: BIGGEST FPGA
From: Richard Schwarz <aaps@erols.com>
Date: Fri, 23 Aug 1996 19:36:18 -0400
Links: << >>  << T >>  << A >>
I am currently designing an ASIC and testing it using 4 XILINX FPGAs (2 
4010s and 2 4020s). I am going to field trials soon which will require 
100 prototypes. I am already familiar with FPGA conversion companies. 
What I would like to find out from the folks in the news group is if a 
there are any ram based FPGAs out there big enough to fit the design. I 
have gotten an AT&T/LUCENT ORCA system which I will try to place the 
design into a 2c40 type chip. I have also tried a FLEX 10k ALTERA chip 
which software could not convert my VHDL tristates (ALTERA has no 
internal tristates). ALTERA is still trying though (thank you ALTERA). 
XILINX is also trying to get me into one of their new XE series chips 
(thank you QUANG@XILINX). I am wondering if there are any other RAM 
based (I like the flexibility of downloadable behavior) options which I 
am missing. Also I would like to hear about any other similar 
experiences from members in the newsgroup. The chip vendors mentioned 
above have all been very helpful, but there's nothing like hearing the 
story from someone who has been there.


Thanks in advance,

Richard
Article: 3949
Subject: BIG FPGA
From: Richard Schwarz <aaps@erols.com>
Date: Fri, 23 Aug 1996 19:37:01 -0400
Links: << >>  << T >>  << A >>
I am currently designing an ASIC and testing it using 4 XILINX FPGAs (2 
4010s and 2 4020s). I am going to field trials soon which will require 
100 prototypes. I am already familiar with FPGA conversion companies. 
What I would like to find out from the folks in the news group is if a 
there are any ram based FPGAs out there big enough to fit the design. I 
have gotten an AT&T/LUCENT ORCA system which I will try to place the 
design into a 2c40 type chip. I have also tried a FLEX 10k ALTERA chip 
which software could not convert my VHDL tristates (ALTERA has no 
internal tristates). ALTERA is still trying though (thank you ALTERA). 
XILINX is also trying to get me into one of their new XE series chips 
(thank you QUANG@XILINX). I am wondering if there are any other RAM 
based (I like the flexibility of downloadable behavior) options which I 
am missing. Also I would like to hear about any other similar 
experiences from members in the newsgroup. The chip vendors mentioned 
above have all been very helpful, but there's nothing like hearing the 
story from someone who has been there.


Thanks in advance,

Richard


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