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
2017JanFebMarApr2017

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 11650

Article: 11650
Subject: Re: half full flag in a xilinx async fifo?
From: "Mark Purcell" <map@NOSPAM_transtech-DSP.com>
Date: 28 Aug 1998 14:04:32 GMT
Links: << >>  << T >>  << A >>


Ray Andraka <no_spam_randraka@ids.net> wrote in article
<35E5E209.473389E2@ids.net>...
> No, you didn't miss a thing. I did.  I was recalling a design I did a
while
> back but was to lazy to go look up.  Turns out that design I was thinking
of
> was synchronous and the gray code counter was on the 2 msbs in a scheme
to make
> the full and empty flags.  The half full in that case was relatively
trivial
> since it was synchronous.  I must be getting old,  my memory ain't what
it once
> was!  Sorry for any sleep I might have caused you to lose.
> 

OK, I'll let you off! Actually the idea of using specific gray coded bits
in the counter is a nice one, however I don't think there's a way of using
it in fully asynchronous stuff. I'd be interested in how asynchronous FIFO
manufacturers actually do their half full flag decoding as the internal
pointer counters can be quite wide in those chips. Any FIFO manufacturers
out there wish to comment?

Mark.

Remove NOSPAM_ from email address

Article: 11651
Subject: NEW ENGINEERING PAGE: Please Visit
From: Scott Paul Johnston <metad@globalnet.co.uk>
Date: Fri, 28 Aug 1998 11:33:39 -0700
Links: << >>  << T >>  << A >>
http://www.users.globalnet.co.uk/~metad/eee.htm

Containing:
Introduction to EEE
Resources (over 100 web links)
Employment Statistics and newspaper excerpts
Engineering Poems, Quotations and Jokes
EEE at Glasgow University

In addition my homepage (http://www.users.globalnet.co.uk/~metad/)
contains:

A section about me
My CV
A James Bond Section
A guestbook
500+ cool links in the "new look" bookpage
Cool background MIDI and graphics
Literary quotations
Photo Album
Awards Page
Poems...

Basically, something for everyone!

PLEASE VISIT VIA MY MAIN HOMEPAGE ADDRESS!

Please send you comments via the guestbook or by Email (containing
your full name and Email and webpage addresses) and visit via 
http://www.users.globalnet.co.uk/~metad/.

Thanks 
Scott Johnston
metad@globalnet.co.uk


Article: 11652
Subject: Re: FPGA Manufacturer's gate counts
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 28 Aug 1998 18:14:56 -0400
Links: << >>  << T >>  << A >>
I consider using gate count to measure the size of FPGAs to be like
using MHZ to measure the speed of processors. Gate count is a very rough
measure of an FPGA capacity. There are too many variables to be able to
directly compare different lines of FPGA this way. The manufacturer's
fudge factor is only one of the variables. The others include, but are
not limited to; loss of usable gates due to design not fitting the FPGA
architecture,  unused gates due to routing limitations, timing
constraints requiring logic to be duplicated. 

The bottom line is that trying to put all FPGAs on a single scale of
capacity is not easy or especially useful. The real question is in what
size part will your design fit? 


Bryn Wolfe wrote:
> 
> Does anybody have a reference that discusses some or all of the FPGA
> vendor's equations for determining gate count? The only one I've found
> so far is for Altera, who say that each of their LE's equates to 12
> usable gates. I've determined that this equates their 100,000 gate part
> to having only 59,904 logic gates (4992 LE x 12), unless you use the
> embedded RAM blocks. I'd like to do similar reality checks on the other
> vendors, namely Xilinx and Actel, but the more, the merrier.

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Reply-To: "Shane Mincer" <smincer@engineerworld.com>
Article: 11653
Subject: Embedded Systems Engineer(s) jobs from all levels (60-130K)
From: "Shane Mincer" <smincer@email.msn.com>
Date: Fri, 28 Aug 1998 16:32:58 -0700
Links: << >>  << T >>  << A >>
Dear Future Candidate

5 Embedded Software Engineering vacancies in MA, ranging from "Member of
Technical Staff" (2-4 years experience / @60K) to "Staff Engineer-Architect"
(10+ years experience / @100+K). All of these positions have four common
requirements:
1. Software Development Experience
2. C/C++
3. Real-Time Operating System Experience
4. Embedded Development

Any resume with those four bases covered, we want to see! All of the other
factors are spelled out on the attached checklist in order of priority. The
more hits that your resume has, the more likely it is that we will be highly
interested in that candidate and the higher the position level that we would
be looking at. This is the same checklist that we use internally when
reviewing resumes. So now you know, in advance, exactly what we will be
looking for. You will notice that the highest rated "Desired Factor" on the
checklist is "Telecom Experience". Likely candidates
are probably going to be found at Lucent, Nortel, Qualcom, Bell, GTE, or
other Telecom companies.  They consider exceptionally qualified Contractors
for these positions.Apply top

2  Embedded Software Engineer vacancies in NY   Same as the Above  This is
the same checklist that we use internally when reviewing resumes. So now you
know, in advance, exactly what we will be looking for. You will notice that
the highest rated "Desired Factor" on the checklist is "Telecom Experience"
Apply top

SoftwareTest Engineer in NY, responsible for writing unit test plans,
assisting in integration testing, writing scripts, and conducting tests
using DSET Toolkit's Agent Tester tool. Requires a minimum of 2 years
experience with software development in C and 2 years experience with
software testing and test script writing. Desirable factors include DSET
experience, Software Methodology and Development Lifecycle, Configuration
Management (Clearcase), and Debugging Tools, emulators, etc.Apply top

Contract Engineers in NYC / CT area, we are looking for Contract Lab
Technicians and a Hardware Test Engineers for a NY lab.
When submitting a resume to SMA please include the job code found at the
beginning of the job posting(s) you are interested in. Send your resume and
salary history to:
E-mail: smincer@engineerworld.com

Address: Shane Mincer & Associates
5333 Balboa Blvd Suite 157.
Encino CA 91316
(818)501-2208
Fax: (818) 501-2960

Women, minorities and disabled persons encouraged to apply.




Article: 11654
Subject: Re: CPLD/FPGA software
From: "Daniel K. Elftmann" <elftmann@ix.netcom.com>
Date: 29 Aug 1998 01:13:35 GMT
Links: << >>  << T >>  << A >>
http://www.actel.com/software/free.html

VHDL Synthesis, Place-n-Route, Static Timing Analysis

Download it off of the WEB or contact local Sales Rep or FAE the free
version comes with a CD-ROM Data Book
 
Article: 11655
Subject: Re: FACTS: Evolutionary Electronics Book
From: Joseph Legris <jlegris@sympatico.ca>
Date: Sat, 29 Aug 1998 03:49:57 GMT
Links: << >>  << T >>  << A >>
This is a fascinating line of inquiry - keep up the good work!

Regards,

J. Legris
Article: 11656
Subject: Re: New Evolutionary Electronics Book
From: "Clifton T. Sharp Jr." <agent150@spambusters.ml.org>
Date: Sat, 29 Aug 1998 04:00:19 -0500
Links: << >>  << T >>  << A >>
Kendall Castor-Perry wrote:
> As it happens, I've always found the asexual algorithms much more
> tractable!

Maybe so, but most of us like to work with the sexy designs.

-- 
+---------------------------------------------------------------------------+ 
|   Cliff Sharp  | Hate spam? Join The Great American Pink-Out!             |
|     WA9PDM     |  http://www.ybecker.net/pink/                            |
+---------------------------------------------------------------------------+
Article: 11657
Subject: Re: New Evolutionary Electronics Book
From: "David G. Horsman" <d_horsman@sunshine.net>
Date: Sat, 29 Aug 1998 03:30:47 -0700
Links: << >>  << T >>  << A >>
Re: "are highly efficient in their use of silicon" does the author refer to the
operation of the circuit, amount of silicon, or the "synthesis" of the circuit
(important).

RE: "real genetic circuits are large, and very flakey"
     Your point is well made and probably applies to existing systems.  However,
natural evolution appears to have miriad positve and negative feedback
(fitering?) systems that are applied, first, in selecting which monkeys gets a
typerwriter. ie:
- immediately - immune system responses to the egg/zygote?
- very early dev. - biochemistry rules
- early development - in the womb
- survival rules, growth and development issues, etc.
These examples are a bit vague but my point is all of these feedbacks are not
only highly selective but are also very pragmatic.  Selection for effeciency and
compatability with the surrounding environment are, to a large degree, "built
in".
     Certainly, most of the circuits might be large and flakey, and we should
recognise that.  But we need generate a few million of these, weeding out the bad
ones early, and then choose from among the top ten.
     A more accurate and fair thesis would be if we selected the ten best monkeys
each year, and put them to work for a few billion years.  However, experience has
taught us that you are more likely to get the "National Enquirer" out of that.

Dave Horsman <d_horsman@sunshine.net>

ems@nospam.riverside-machines.com wrote:

> On 24 Aug 1998 02:28:59 GMT, adrianth@cogs.susx.ac.uk (Adrian
> Thompson) wrote:
>
> And while we're kicking Adrian... :)
>
> >A series of experiments is used to explore the
> >practicalities, culminating in a simple but non-trivial application. The
> >circuits may seem bizarre, but are highly efficient in their use of silicon.
>
> Not to mention:
>
> >it is shown that evolution can produce `bizarre but useful'
> >circuits, beyond the scope of conventional design.
>
> Simple, yes, bizarre, certainly, highly efficient use of silicon,
> dream on.
>
> The circuits might be useful if they were correctly designed by a
> competent engineer. What's bizarre is that real genetic circuits are
> large, and very flakey, and yet are still described as highly
> efficient or useful.
>
> Here's an idea for another Phd thesis. Simulate a billion monkeys with
> a billion typewriters, with their output being selected and
> reprocessed by a genetic algorithm, in an attempt to generate a new
> Shakespeare sonnet. In another corner of the lab, put Shakespeare in
> front of a desk with a pen and paper. The monkeys' output may well be
> "beyond the scope of conventional design". But which sonnet do you
> think is going to be more readable?
>
> Evan



Article: 11658
Subject: Re: CPLD/FPGA software
From: Gerald Coe <gerry@see-sig.co.uk>
Date: Sat, 29 Aug 1998 11:55:51 +0100
Links: << >>  << T >>  << A >>
In article <01bdd2e9$f30d7400$34d8bbcd@w95-elftmannd>, Daniel K.
Elftmann <elftmann@ix.netcom.com> writes
>http://www.actel.com/software/free.html
>
>VHDL Synthesis, Place-n-Route, Static Timing Analysis
>
>Download it off of the WEB or contact local Sales Rep or FAE the free
>version comes with a CD-ROM Data Book
> 

We looked at the actel parts some time ago, and rejected them because
they are one-time-programmable antifuse devices. To use them we needed
to buy a programmer or send the files off to the chip vendor for
programming with the inherant delays that involves. And if it did not
work - in the bin with it and start again.

What would be very nice is an ISP-FPGA based on flash technology. I
don't think there are any! Earlier this year I went to one of the Atmel
40K seminars they held in the UK (won the go on the flight simulator as
well - great!) and put this question to them. They said the flash cell
was larger than the sram cell, but that ignores the cost of the config
eprom or extra space in the cpu rom. Vantis use the flash cell in the
mach cpld's, so I don't see why it can't be done. That said, I notice
philips are going the sram route with their cpld's - oh well!

At the moment (Vantis) cpld's are meeting our needs. When they don't, I
think I will be heading the Xilinx route. We have the $95 foundation kit
and it looks good. Atmels 40k software is a nightmare by comparison.

-- 
Kindest Regards | gerry@devantech | We manufacture Pic programmers, 8031,
Gerald Coe      | .demon.co.uk    | 68302, 64180, 80C188EB cpu modules. 
http://www.devantech.demon.co.uk  | Full custom uP control systems designed.
Article: 11659
Subject: Re: New Evolutionary Electronics Book
From: "David G. Horsman" <d_horsman@sunshine.net>
Date: Sat, 29 Aug 1998 04:14:17 -0700
Links: << >>  << T >>  << A >>
I am a software developer that has spent the last two years
forced into a course on "how to write specs. in plain language".
The comments below in defense of obfuscation are bang on.
Our one page overviews when compared to the 100 page specs
are tough reading for this very reason.

By the way, if he meant "obscure", why did he use
"obfuscated bullshit".  The tone of this exchange seems to
get a bit....<burp>... "personal" if you know what I
mean.....

Dave Horsman<d_horsman@sunshine.net>

Gordon Coulson McNaughton wrote:

> A moment of your time please, Tom...
>
> Tom Kean (tom@algotronix.com) wrote:
> : Mike McCarty wrote:
> : > )->In reconfigurable hardware, the behaviours and interconnections of the
> : > )->constituent electronic primitives can be repeatedly changed. Artificial
> : > )->evolution can automatically derive a configuration causing the system to
> : > )->exhibit a pre-specified desired behaviour. A circuit's evolutionary
>
> [snip]
>
> : > Let me translate this little bit into English.
> : >
> : >         Hardware which can be changed can be changed more than once. It
> : >         is sometimes possible to make the hardware configure itself.
>
> [snip]
>
> : <FLAME>
> : Actually, its not 'obfuscated bullshit' its precise scientific english: you
> : just have to turn off the TV, put down your beer and engage your brain
> : before reading it.
>
> I enjoy drinking beer.  I also enjoy thinking.  Are the two mutually exclusive?
> Most of my friends are philosophical drunks. ;)
>
> Actually, the summary is obfuscated.  That's not necessarily bad, that
> just happens to be a side-effect of the type of summary being written: a
> dense, high information-per-sentence paragraph that attempts to explain a
> general concept (which takes an entire book to fully describe, or so one
> infers) in a short amount of space -- hence, a summary of the concept.  In
> order to explain such a wide concept in precise terms in a short summary,
> dense language is used which must be read carefully.  Obfuscation (as webster
> says, "to make obscure") is not the purpose of such language, rather it is a
> side effect of the concept-condensing process.
>
> This is not the only kind of summary which could have been written.  It was
> written thoughtfully and deliberately.  Alternatively it could have been a
> topical overview of the specific discussions within the text, etc.  However,
> the author of the summary believed that this sort of dense conceptual
> specification would engage people who would be interested in reading the book.
> The summary is obviously not bullshit, since it imparts very precise and
> accurate information to the people who extract it.
>
> I sincerely hope that your flame against anyone not willing to extract that
> information was just a knee-jerk reaction (careful with those, now).  There
> was a pointed comment that the summary could have be written in a more
> accessible fashion: you disagree (maybe the book itself is not accessible,
> and such a summary would be misleading?).  Fine, disagree, but don't
> automatically light up a blowtorch (care with those, too!).
>
> : For example:
> :
> : 'Hardware that can be changed can be changed more than once' FALSE
> : what about fuse technologies?  The original text does not make this claim.
>
> The original text (as quoted by my newsreader, tin) says:
>   "In reconfigurable hardware, the behaviours and interconnections of
>    the constituent electronic primitives can be repeatedly changed."
>                                                 ^^^^^^^^^^
> The use of the word "repeatedly" implies that the hardware can be changed
> more than once.  It may be false to infer that the *same* behavior or
> connection can be changed more than once, but it is very clear that the
> hardware in general can be.  Do you disagree with this interpretation?
>
> : 'It is sometimes possible to make the hardware configure itself'
> : The text does not say this either - what it says is that a configuration
> : can be derived from artificial evolution.
>
> From the quoted portion of the message I saw, I would agree.
>
> It is interesting to note that the summary uses the phrase "a circuit's
> evolutionary..."  If this refers to the evolutionary capabilities of the
> entire system in redesigning a specific circuit, you are right.
>
> If this refers to the *physical* circuit, stating that the *physical* hardware
> circuit(ry) has evolutionary capabilities (outside of the context of a
> surrounding system), then one would assume that the circuit has the ability
> to modify itself (since it can evolve outside of a system, when there is
> nothing else to modify it!).
>
> : </FLAME>
>
> </rebuttal>
>
> : Tom.
>
> With respect, Gordon.
>
> ------------------------------------------------------------------
> Common sense and a sense of humor are the same thing, moving at
> different speeds.  A sense of humor is just common sense, dancing.
>                 -- Clive James



Article: 11660
Subject: Re: CPLD/FPGA software
From: Achim Gratz <gratz@ite.inf.tu-dresden.de>
Date: 29 Aug 1998 13:52:49 +0200
Links: << >>  << T >>  << A >>
Gerald Coe <gerry@see-sig.co.uk> writes:

> We looked at the actel parts some time ago, and rejected them because
> they are one-time-programmable antifuse devices. To use them we needed
> to buy a programmer or send the files off to the chip vendor for
> programming with the inherant delays that involves. And if it did not
> work - in the bin with it and start again.

Actel has now more or less bought GateField (the rest of GateField is
held by Siemens, who is also fab'ing the new generation chips).  That
should clear up their problems with having no reprogrammable devices
in the next year or so.

The cost of the programmer for Actel is an issue, I agree.  On the
other hand, the Actel software works rather well (ViewLogic is a
different story, but it's not in the free package anyway), so
depending on your design habits you may not have to throw out that
many parts.  One plus for Actel is that they really route to 100% as
advertised.  Getting good placement and timing requires wrestling with
the constraints.  I give them a minus for having no good solution to
floorplan a design (if there is one, I'd really like to know).


Achim Gratz.

--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW:    http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone:  +49 351 463 - 8325
Article: 11661
Subject: Re: New Evolutionary Electronics Book
From: rk <stellare@erols.com>
Date: Sat, 29 Aug 1998 12:06:56 -0400
Links: << >>  << T >>  << A >>
hmmm ... seems to be an interesting topic.  here's an abstract for a presentation
being given at MAPLD in september.

rk

__________________________
PCD2: Adrian Stoica, Carlos-Salazar Lazaro, Raoul Tawel
JPL

"Evolvable Electronic Systems"

Increasingly more flexible reconfigurable devices bring closer the perspective of
dynamically reconfigurable, adaptive
information processing. An automated self-reconfiguration of these devices would be
very useful. Evolvable hardware is a new
research area in which search algorithms, in particular evolutionary algorithms, are
applied to automatically determine/
synthesize/reconfigure programmable devices. In this paper we review current work in
evolving analog circuits and present our
results on simulated evolution of analog circuits on programmable transistor arrays.
__________________________

Article: 11662
Subject: Re: Digital PLL
From: msimon@tefbbs.com
Date: Sat, 29 Aug 1998 16:25:30 GMT
Links: << >>  << T >>  << A >>
The Zilog SCC has an interesting digital PLL. 

Simon
============================================================
mrizwan@rocketmail.com wrote:

>I am in search of  information about the  digital phase lock loop, can	any
>one send me  information that can help me  in designing  a  digital phase
>lock loop, I want to design it by using FPGA  Altera  chip, or give me hint
>about the material finding  about digital phase lock loop.
>
>-----== Posted via Deja News, The Leader in Internet Discussion ==-----
>http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.
Article: 11663
Subject: Re: [Fwd: FGPA-express : is there a way to use scripts ?]
From: Nick Hartl <"nhartl[no spm]"@earthlink.net>
Date: Sat, 29 Aug 1998 12:19:42 -0500
Links: << >>  << T >>  << A >>
As I understand it today one cannot make a script files in Express.
However in the future (This is software release time so the future date
is not fixed and will move forward in time...This is a fundimental law
of nature.) Design Compilier type scripts will be availible in Express.

Have FUN
Nick

Koenraad Schelfhout wrote:

> --
>
>  Koenraad SCHELFHOUT
>
>  Alcatel Telecom
>  Switching Systems Division          http://www.alcatel.com/
>  Microelectronics Department - VA21     _______________
> ________________________________________\             /-___
>                                          \           / /
>  Phone : (32/3) 240 89 93                 \ ALCATEL / /
>  Fax   : (32/3) 240 99 88                  \       / /
>  mailto:koenraad.schelfhout@alcatel.be      \     / /
> _____________________________________________\   / /______
>                                               \ / /
>  Francis Wellesplein, 1                        v\/
>  B-2018  Antwerpen
>  Belgium
>
>    ----------------------------------------------------------------
>
> Subject: FGPA-express : is there a way to use scripts ?
> Date: Fri, 28 Aug 1998 09:04:04 +0200
> From: Koenraad Schelfhout <koenraad.schelfhout@alcatel.be>
> Organization: Alcatel
> Newsgroups: comp.cad.synthesis
>
> I just started playing with Synopsys FPGA-Express.
> Now there is a very user friendly user-interface, however, what I lack
>
> is that there does not seem to be some kind of script-interface.
>
> For FPGA-Compiler and Design-Compiler, I am used to create some kind
> of script file (.dc) which can be used to run a job in batch mode.
> Does anyone know (and can explain me) how to run FPGA-Express jobs in
> batch mode (in the Unix environment) ?
>
>
> --
>
>  Koenraad SCHELFHOUT
>
>  Alcatel Telecom
>  Switching Systems Division          http://www.alcatel.com/
>  Microelectronics Department - VA21     _______________
> ________________________________________\             /-___
>                                          \           / /
>  Phone : (32/3) 240 89 93                 \ ALCATEL / /
>  Fax   : (32/3) 240 99 88                  \       / /
>  mailto:koenraad.schelfhout@alcatel.be      \     / /
> _____________________________________________\   / /______
>                                               \ / /
>  Francis Wellesplein, 1                        v\/
>  B-2018  Antwerpen
>  Belgium
>
>



Article: 11664
Subject: Re: FPGA Manufacturer's gate counts
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Sat, 29 Aug 1998 12:43:15 -0700
Links: << >>  << T >>  << A >>

--------------E7F51751BADE63B4E7C3564F
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

Bryn Wolfe wrote:

> Does anybody have a reference that discusses some or all of the FPGA
> vendor's equations for determining gate count? The only one I've found
>
> so far is for Altera,  I'd like to do similar reality checks on the
> other
> vendors, namely Xilinx and Actel, but the more, the merrier.
>  
>  

A few months ago, I described the Xilinx XC4000xx gate-count
methodology.This can be a very controversial subject, so let's not start
a flame war, but rather take gate count for what it is: a gross
oversimplification, applying ASIC methods to a totally different
architecture.

Peter Alfke, Xilinx Applications

Logic Cells and  System Level Gates

Let me explain the
    10,982 Logic Cells,
    147 k bits of RAM and
    265,000 max logic gates  claimed for the XC40125XV
 
This is a mixture of engineering specifications and marketing.
 

Engineering specifications:

The XC40125XV has a 68 x 68 array of CLBs = 4624 CLBs
Each of these CLBs has 32 RAM bits = 147 ,968 RAM bits total.
Simple math, no ifs and no buts.
 
 
Now we get into marketing:

Since this is a competitive world, our users want to compare different
manufacturers,
but the structures are not the same. Altera puts eight LUTs in a block,
Lucent puts
four, and Xilinx puts two LUTs into an XC4000 CLB, but everybody's LUTs
are more or less identical.

So Xilinx decided to standardize the nomenclature and emphasize not CLBs
but
rather Logic Cells, as a lingua franca for FPGAs. Good idea!

Then marketing remembered the third LUT in the Xilinx CLB and gave it a
value of 3/8 of a Logic Cell, so the whole CLB is worth 2.375 LCs.
Obviously, we can argue enlessly about this addition, but it is true
that one can use the third LUT for some really nice and efficient
solutions. :-)

Multiply the 4624 CLBs by 2.375 and you get 10 982 Logic Cells.
 

What is that in ASIC gates?

There is no scientific answer, because it depends on the design.
What is the LUT being used for,
is the flip-flop being used at all,
and what if you use the LUT as RAM ?

Assume that every LUT is statistically worth 6 gates and every flip-flop
is worth 6 gates, then every Logic Cell is worth 12 gates ( sometimes
more, sometimes less ). 
12 gates times 10 982 LCs makes a bare-bone gate-count of 131 784, and
that is reflected in the name of the device. We are conservative and
round it down a little. :-)

But there is the RAM in the Xilinx LUT:
If only 25% of them are really used as RAM,
these LUTs are not worth 6 gates, but rather 64 gates ( 16 bits with 4
bits per RAM cell,
again, very conservative, ignoring the select structure and the
read/write circuitry).
That means, we must add another 58 gates times 25% of 9248 LUTs, which
means
another 134 096 gates, for a total of 265 880 logic gates. And we say
explicitly that this
assumes 20 to 30 % of the CLBs being used as RAM.

That's how the XC40125XV got its name and its gate-count range of
125,000 to 265,000
gates. It is an attempt to bring some sanity to the gate-count
confusion.

Users will never agree about these assumption, and if you don't want to
compare
different manufacturers, then you can forget the whole thing and just
stick with CLBs
and RAM bits, for they are physical and thus non-controversial.

Hope this helps.
Peter Alfke
 
 

>  

--------------E7F51751BADE63B4E7C3564F
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<HTML>
<BODY BGCOLOR="#FFFFFF">
Bryn Wolfe wrote:
<BLOCKQUOTE TYPE=CITE>Does anybody have a reference that discusses some
or all of the FPGA
<BR>vendor's equations for determining gate count? The only one I've found
<BR>so far is for Altera,&nbsp; I'd like to do similar reality checks on
the other
<BR>vendors, namely Xilinx and Actel, but the more, the merrier.
<BR>&nbsp;
<BR>&nbsp;</BLOCKQUOTE>
A few months ago, I described the Xilinx XC4000xx gate-count methodology.This
can be a very controversial subject, so let's not start a flame war, but
rather take gate count for what it is: a gross oversimplification, applying
ASIC methods to a totally different architecture.

<P>Peter Alfke, Xilinx Applications

<P><B>Logic Cells and System Level Gates</B><B></B>

<P>Let me explain the
<BR>&nbsp;&nbsp;&nbsp; 10,982 Logic Cells,
<BR>&nbsp;&nbsp;&nbsp; 147 k bits of RAM and
<BR>&nbsp;&nbsp;&nbsp; 265,000 max logic gates&nbsp; claimed for the XC40125XV
<BR>
<BR>This is a mixture of engineering specifications and marketing.
<BR>

<P><B>Engineering specifications:</B>

<P>The XC40125XV has a 68 x 68 array of CLBs = 4624 CLBs
<BR>Each of these CLBs has 32 RAM bits = 147 ,968 RAM bits total.
<BR>Simple math, no ifs and no buts.
<BR>
<BR>
<BR><B>Now we get into marketing:</B><B></B>

<P>Since this is a competitive world, our users want to compare different
manufacturers,
<BR>but the structures are not the same. Altera puts eight LUTs in a block,
Lucent puts
<BR>four, and Xilinx puts two LUTs into an XC4000 CLB, but everybody's
LUTs are more or less identical.

<P>So Xilinx decided to standardize the nomenclature and emphasize not
CLBs but
<BR>rather Logic Cells, as a <I>lingua franca</I> for FPGAs. Good idea!

<P>Then marketing remembered the third LUT in the Xilinx CLB and gave it
a value of 3/8 of a Logic Cell, so the whole CLB is worth 2.375 LCs.
<BR>Obviously, we can argue enlessly about this addition, but it is true
that one can use the third LUT for some really nice and efficient solutions.
:-)

<P>Multiply the 4624 CLBs by 2.375 and you get 10 982 Logic Cells.
<BR>

<P><B>What is that in ASIC gates?</B>

<P>There is no scientific answer, because it depends on the design.
<BR>What is the LUT being used for,
<BR>is the flip-flop being used at all,
<BR>and what if you use the LUT as RAM ?

<P>Assume that every LUT is statistically worth 6 gates and every flip-flop
is worth 6 gates, then every Logic Cell is worth 12 gates ( sometimes more,
sometimes less ).
<BR>12 gates times 10 982 LCs makes a bare-bone gate-count of 131 784,
and that is reflected in the name of the device. We are conservative and
round it down a little. :-)

<P><B>But there is the RAM in the Xilinx LUT:</B>
<BR>If only 25% of them are really used as RAM,
<BR>these LUTs are not worth 6 gates, but rather 64 gates ( 16 bits with
4 bits per RAM cell,
<BR>again, very conservative, ignoring the select structure and the read/write
circuitry).
<BR>That means, we must add another 58 gates times 25% of 9248 LUTs, which
means
<BR>another 134 096 gates, for a total of 265 880 logic gates. And we say
explicitly that this
<BR>assumes 20 to 30 % of the CLBs being used as RAM.

<P>That's how the XC40125XV got its name and its gate-count range of 125,000
to 265,000
<BR>gates. It is an attempt to bring some sanity to the gate-count confusion.

<P>Users will never agree about these assumption, and if you don't want
to compare
<BR>different manufacturers, then you can forget the whole thing and just
stick with CLBs
<BR>and RAM bits, for they are physical and thus non-controversial.

<P>Hope this helps.
<BR>Peter Alfke
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>&nbsp;</BLOCKQUOTE>

</BODY>
</HTML>

--------------E7F51751BADE63B4E7C3564F--

Article: 11665
Subject: Spartan and VHDL-design "Problem"
From: "Daniel T. Schwager" <danny@dts-s.de>
Date: Sat, 29 Aug 1998 22:15:07 +0200
Links: << >>  << T >>  << A >>
Hi together,

i have to design a VHDL-based FPGA which
have to contact an uC-Databus (DB0..DB15).
In my design, there's an FPGA internal tristate
bus named "db". 
My problem is, that i don't know how to connect 
a bidirectional and tristate bus "db" to the FPGA pads.
Should i use some library-objects like "ibuf16" ? 

Maybe somebody has an example-vhdl code for solving this
"small" problem !

regards

Danny

P.S.: i use the Xilinx Foundation Express Software and
the Synopsys FPGA-Express. The FPGA is a Xilinx Spartan
Chip (XC10)
-- 
------------------------------------------------------------
DTS Computer Schwager, Am Schnarrenberg 1, D-70376 Stuttgart
Tel: +49-711-5094390                    Fax: +49-711-5094391
WEB: http://www.dts-s.de/           email: schwager@dts-s.de
Article: 11666
Subject: Re: PROM alternative
From: "Daniel T. Schwager" <danny@dts-s.de>
Date: Sat, 29 Aug 1998 22:20:09 +0200
Links: << >>  << T >>  << A >>
Wade D. Peterson wrote:
> 
> jcvilleneuve@hotmail.com wrote:
> 
> >Hello there!!!
> 
> >Is anybody has used something else than a PROM for the configuration cycle of
> >their FPGA (example direct CPU to fpga)?
> 
> Yep.  It works pretty good too.  Did it with a Xilinx part once.  I
> had to 'hack into' their bitstream file to do it, though.  Wrote up a
> program to create a 'C' array file from the Xilinx bitstream file
> (automatically), and then downloaded it to the FPGA part from a CPU at
> boot-up time.
> 

Hi Wade,

i wrote such a code also (Xilinx Foundation Base). My perl
script converts the hex-FPGA file to a C-File.

I use the xilinx-Spartan FPGA's. The download routine 
does work correct (CRC is OK), but if i try to
verify my FPGA design whith the READBACK-Option, about
100Bits are not correct. I thinks my verify-function is
not correct. Yould you email me your verify-function ??

regards

Danny


-- 
------------------------------------------------------------
DTS Computer Schwager, Am Schnarrenberg 1, D-70376 Stuttgart
Tel: +49-711-5094390                    Fax: +49-711-5094391
WEB: http://www.dts-s.de/           email: schwager@dts-s.de
Article: 11667
Subject: Re: Video 256 colors interface HELP!
From: "Dj" <dejan@versilia.toscana.it>
Date: Sun, 30 Aug 1998 00:39:27 +0200
Links: << >>  << T >>  << A >>

Ray Andraka ha scritto nel messaggio <35DCC871.9D08A46C@ids.net>...
>Dj wrote:
>
>> I am New on fpga programming and I try to implement
>> simple video interface whitch I already do it with real componets, is
there
>> somebody can help me with some
>> very simple examples.
>
> Soo, FPGA's aren't real components??  Shhh, don't tell my clients!
>As far as your problem, can you be more specific.  I doubt anyone is going
to
>post a complete video controller design as an example.
>
>--
>-Ray Andraka, P.E.
>President, the Andraka Consulting Group, Inc.
>401/884-7930     Fax 401/884-7950
>email randraka@ids.net
>http://users.ids.net/~randraka
>
>

Ok OK OK  : )

So I just implement one vga in traditional way so I use pcb and
logic logic logic ..............ok
My simple vga just functioning in 13h mode 320x200 256colors
witch is the only mode that I need on my 80186 board.
So one day I see that I can copy all to one fpga chip but I am
newbbbbbbbbbbbbbbie on vhdl language.
Maybe after all I can implement sync controll, dram refresch and palete
logic just on one fpga?

For now I stady vhdl from my book OK.
And finaly I want to experiment with all this but I dont know whitch
fpga I have to use for start and is there some shareware or cheap
vhdl compiler for a poor man.

Thank

ps
Shhhhhhhhhhh don't tell anybody that I write about "real" and "unreal"
components.




Article: 11668
Subject: Here is my page of DIRTY PICTURES
From: jacks343@msn.com
Date: 29 Aug 1998 20:17:33 -0500
Links: << >>  << T >>  << A >>
Check out my new home page with free xxx pics.

http://www.angelfire.com/ar/jackstone



Article: 11669
Subject: Re: PROM alternative
From: Ashok Mahadevan <amahadev@oakland.edu>
Date: Sun, 30 Aug 1998 00:43:56 -0400
Links: << >>  << T >>  << A >>
> > >Is anybody has used something else than a PROM for the configuration cycle of
> > >their FPGA (example direct CPU to fpga)?

I use the parllel port of the PC to bit bang the configuration into an Altera 10K100
FLEX chip (actually 2 chips). For those familiar with
Altera, I download an "rbf" file about 290K bytes in length and it takes
me about 20 seconds.

Ashok


Article: 11670
Subject: Re: CPLD/FPGA software
From: APS <resp@associatedpro.com>
Date: Sun, 30 Aug 1998 09:20:26 -0400
Links: << >>  << T >>  << A >>
They are both good tools. The XILINX parts are a bit more powerful and can do
XILINX CPLDs and or FPGAs. The 95 dollar price for XILINX does not include VHDL.
If you just need CPLDs then look at the Cypress. If you want CPLDs and FPGAs and
don't mind using schematic capture, look at the XILINX 95.00 kit. If you want
XILINX with the VHDL capabilities you can get it for around 899.00. This is the
XILINX Foundation series. You also get a free debug FPGA board with VHDL examples
and C control code if you order the XILINX kits from APS at
http://www.associatedpro.com. The APS is also a good website to see VHDL and
programmble logic examples in general. There is an on-line VHDL synthesis tutorial
and some good tech solutions.


tigerz@my-dejanews.com wrote:

> Hello,
>
> I would like to learn about CPLD/FPGA programing.  I found that there are two
> low cost tool from Cypress and Xilinx for $95.  Can someone give me suggestion
> on which one to purchase and why?  Any other low cost alternative?  Thanks in
> advance for feedback.
>
> Tiger
>
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum



--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 11671
Subject: Re: (req)I'm looking for foundation
From: APS <resp@associatedpro.com>
Date: Sun, 30 Aug 1998 09:24:24 -0400
Links: << >>  << T >>  << A >>
check at http://www.associatedpro.com

念 wrote:

> Hello,
>
> I'm looking for xilinx tool, foundation.
>
> If any one have that tool(evaluation version, OK), please post the tool.
>
> thank you



--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 11672
Subject: Re: CPLD/FPGA software
From: z80@ds2.com (Peter)
Date: Sun, 30 Aug 1998 18:47:18 GMT
Links: << >>  << T >>  << A >>

I suggested to Xilinx (at some seminar years ago) that they should use
FLASH for the config. It would have all the advantages of SRAM, and be
nonvolatile. No good reason was given to me for not using FLASH.

I think they don't like mixing EEPROM cells with their normal fast
logic. This is also why it is very hard to find ASIC CPU cores with
EEPROM.

I really don't like devices which need to be programmed *before* PCB
placement. If it is a thin-package device (e.g. TQFP), it needs to be
unpacked, programmed, and repacked with silica gel - all within 8-16
hours. And the Atmel parts don't program fast either, so you have to
find something to do while programming them, otherwise you waste a
huge amount of time waiting. Then you HOPE that who-ever is doing the
placement (a subcontractor, these days, with most small company FPGA
users) takes notice of this. So, a device which can be configured
*after* soldering to the PCB is much better for production.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.
Article: 11673
Subject: Re: CPLD/FPGA software
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Sun, 30 Aug 1998 18:16:55 -0400
Links: << >>  << T >>  << A >>
What's wrong with designing your off FPGA storage to be in-circuit
programmable?  Mine nearly always are.  The reason Xilinx doesn't put EE
cells on the die is because it adds several steps to the manufacturing
process and lowers the yield.  No need to substantially raise the price of
the parts, not to mention losing the reconfigurable advantage that some of
use use extensively.

Peter wrote:

> I suggested to Xilinx (at some seminar years ago) that they should use
> FLASH for the config. It would have all the advantages of SRAM, and be
> nonvolatile. No good reason was given to me for not using FLASH.
>
> I think they don't like mixing EEPROM cells with their normal fast
> logic. This is also why it is very hard to find ASIC CPU cores with
> EEPROM.
>
> I really don't like devices which need to be programmed *before* PCB
> placement. If it is a thin-package device (e.g. TQFP), it needs to be
> unpacked, programmed, and repacked with silica gel - all within 8-16
> hours. And the Atmel parts don't program fast either, so you have to
> find something to do while programming them, otherwise you waste a
> huge amount of time waiting. Then you HOPE that who-ever is doing the
> placement (a subcontractor, these days, with most small company FPGA
> users) takes notice of this. So, a device which can be configured
> *after* soldering to the PCB is much better for production.



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 11674
Subject: Re: New Evolutionary Electronics Book
From: mzenier@netcom.com (Mark Zenier)
Date: Mon, 31 Aug 1998 04:11:38 GMT
Links: << >>  << T >>  << A >>
In article <35E82720.E1EEBC2F@erols.com>, rk  <stellare@erols.com> wrote:
>hmmm ... seems to be an interesting topic.  here's an abstract for a presentation
>being given at MAPLD in september.

There was also a writeup in New Scientist for 15 November 1997.
"Creatures From Primordial Silicon", the cover story, no less.

Since what they are doing is feeding random crap into the configuration
of a boardfull of FPGAs, and then using a scoring function to act as
the selection, and then using the genetic algorithm to select flavors
of the random crap that work better according to the scoring function,
you end up with a set of bits that does unknown things in the FPGAs.
It's not working as a digital circuit.  There's no clock provided to
the FPGA.  Operation depends on circuit strays, and will only work 
in a 10 degree C temperature range.

Sounds like a great way to build a phase of the moon detector.  And
scare the pants off of anybody that has to do a reliability audit.

Mark Zenier  mzenier@eskimo.com  mzenier@netcom.com  Washington State resident



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
2017JanFebMarApr2017

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