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 21750

Article: 21750
Subject: Re: VGA interface and VHDL
From: "Jan Gray" <jsgray@acm.org.nospam>
Date: Thu, 30 Mar 2000 19:56:30 GMT
Links: << >>  << T >>  << A >>
Leon Heller wrote in message <8bvg75$j9i$1@nnrp1.deja.com>...
>Anshuman Sharma <gte600f@prism.gatech.edu> wrote:
>> ... I want help with the VGA display. Basically if anyone can help me
>find
>> something on how I can build a VGA module that will interact with my
>> datapath and the game as a whole.
>
>The XSOC FPGA CPU has a VGA display. You'll find details here:
>www.fpgacpu.org/xsoc

Thanks.  First let me recommend this VGA app note by Dave Vanden Bout of
XESS: www.xess.com/vga.pdf.

The XSOC system-on-a-chip, including the VGA display, is described in the
forthcoming May 2000 (issue #118) issue of Circuit Cellar, and the
schematics (and shortly, the Verilog version) are available as part of the
XSOC distribution at www.fpgacpu.org/xsoc

Here is a brief description of the design of the XSOC video display
controller, which produces a VGA-timing compatible bilevel 576x455 display
using the XESS XS40's 32 KB of SRAM.

A video signal is a series of frames, each frame a series of lines, each
line a series of pixels. The video controller is responsible for fetching
the video data, shifting it out (serializing it), and for asserting the
horizontal and vertical sync pulses that frame the pixel stream into lines
and fields.

A video address counter is required to fetch each word of video data. Often
the video controller shares memory with another agent (such as a processor)
that writes the video data, and this usually requires an address multiplexer
to select either the video address or the writing agent address.

A horizontal pixel counter and vertical line counter are required to
generate horizontal and vertical blanking and syncs. Each counter need four
equality comparators, to determine when the counter reaches 1) start of
blanking, 2) start of sync, 3) end of sync, and 4) end of line/frame.

After first considering a software (interrupt handler) approach to fetching
video data and generating syncs, I settled on a simple, fast, low cost,
hardware approach.

1. The video address counter and the address mux are subsumed by one channel
of the DMA engine in the xr16 processor core. This engine costs only 20 LUTs
and 3 flip-flops.

2. The horizontal and vertical counters are 10-bit LFSR counters that use
only 1-2 LUTs and 10 FFs each.  (The lfsr counter design program is also
provided in the LFSR distribution.)

3. The 8 comparators are 10-bit AND trees (3 LUTs each).

4. A video word DMA staging buffer, and a parallel-in serial-out pixel shift
register, use a further 16 FFs and 16 LUTs+16 FFs respectively.

5. There are a further 6 LUTs and 5 FFs of control logic.

Total cost, including the CPU DMA engine, is about (20 LUT, 3 FF) + 2*(2,10)
+ 8*(3,0) + (0,16) + (16/16) + (6,5) = (70 LUT, 60 FF) = ~35 XC4000E CLBs.

But note, as described in issue #6 in
http://www.fpgacpu.org/xsoc/issues.html, the design currently has a defect
that causes premature blanking of the last word on each line, that we will
fix one of these days.

Jan Gray
Gray Research LLC



Article: 21751
Subject: Re: What's so good about antifuse???
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 30 Mar 2000 12:00:14 -0800
Links: << >>  << T >>  << A >>
You may get different answers from different people, and definitely
from different companies. But since there is hardly anybody else
here representing the vendors, and since Xilinx at one time designed
and even made antifuse devices, here is my answer:

Antifuse devices use higher programming voltages and additional
processing steps, which means they cannot migrate to the smallest
and fastest technologies as fast as SRAM-based FPGAs can. That means
anti-fuse devices really are not smaller, faster, and cheaper.

Programming takes a long time ( and is rarely done by the end-user
).
One-time programmability can be painful and expensive with large
chips.
Max chip capacity is a small fraction of what you can get in
SRAM-based FPGAs.

Remaining advantages: Instant-on, single-chip, and a certain degree
of radiation-resistance.

There are only two manufacturers: Actel ( the larger and older one
), and Quicklogic (the younger and smaller one ).

I think this was a reasonably unbiased and fair explanation. Let the
flames start!

Peter Alfke

fulvs@my-deja.com wrote:

> I'm trying to understand the difference between
> antifuse, SRAM and flash based FPGAs. I have 3
> questions and any comments on any of these would
> be much appreciated.
>
> 1) Antifuse is purportedly cheaper, lower power,
> higher performance. Why is this? If this is true
> - how much cheaper, lower power etc?
>
> 2) Other than military/aerospace, what
> applications are antifuse FPGAs used for? Aren't
> SRAM FPGAs much better because they're many times
> reprogrammable?
>
> 3) Who is the best antifuse vendor?
>
> Thanks in advance for your help.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Article: 21752
Subject: Re: What's so good about antifuse???
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 30 Mar 2000 12:08:33 -0800
Links: << >>  << T >>  << A >>


HH wrote:

> Hi,
>
> I recommend you to visit http://www.optimagic.com/ .  It has a lot of
> device-independent information...
> I'm not an expert, but I'll try to answer you...
>
>
> The resistance of a "shorted" gate is much lower that when a S-RAM cell is
> used, thus less power.

Not true: The ( lower ) series resistance of an antifuse compared to the
(higher) resistance of a pass transistor has absolutely nothing to do with
power consumption. But does affect speed.

When you charge and discharge a capacitor, the series resistance of your switch
falls out of the power equation:   P = f  C  V  V
Look, no R!

Peter Alfke

Article: 21753
Subject: Re: 10 gbit/s input
From: Ray Andraka <randraka@ids.net>
Date: Thu, 30 Mar 2000 20:08:59 GMT
Links: << >>  << T >>  << A >>
Best bet would be to use an external deserializer and then present the data in
parallel.  For example, SMPTE-292M HDTV is 1.4 something Gbits/sec.  AMCC has a
deserializer for that application that includes a PLL which outputs the data as
an unframed 20 bit parallel word.  My framer/descrambler macro takes that data,
descrambles it and frames it (shifts it to align properly within the 20 parallel
bits) in a Xilinx 4K or Spartan part.  The macro is working at 75 MHz, which is
quite possible with the FPGA.

Some of the newer FPGAs will handle a 622 Mbit/sec stream on LVDS I/O, but only
if you are really careful about the design inside the FPGA.  You won't get much
beyond that with a serial stream in an FPGA without first deserializing it
outside.

Anoop Nannra wrote:

> Hi all,
>
> Anyone out there know of any references, texts or otherwise, that may give
> me an idea on how to take in a 10gbit/s serial data stream into an fpga or
> an array of fpga's ?  Also, any ideas on what I should be looking for in and
> fpga to be able to accept that kind of input ?
>
> TIA
> Anoop

--
-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: 21754
Subject: Re: FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Thu, 30 Mar 2000 20:20:05 GMT
Links: << >>  << T >>  << A >>
Greg,

I like to think that I know more than the average bear about how to make
things work, and work well within an FPGA.  Guess what,  I don't go down to
the bitstream level!  I do however use the tools provided, including the
floorplanner and the chip editor to learn about the chip.  True, these are
abstractions, but they are also close enough to the actual hardware to
understand everything you need to know to take advantage of all the FPGA has
to offer.  I maintain that if you want to learn about the FPGA, start with
what is accessible with the tools and if then if they don't meet your needs
push down lower where you need to.  If you learn how to design to the
architecture you will be far ahead of the pack, and I think if you do it
within the supplied framework, you'll get there a heckuva lot sooner than if
you start at the bitstream level.

Greg Alexander wrote:

> As easily as you dismiss my approach to learning, people who have been
> through my approach to learning completely dismiss anything learned your
> way as being inadequate and cloudy.  *shrug*  Bias can go both ways and it
> doesn't make either side right -- but if there are two sides you shouldn't
> be so sure yours is the only way.  I maintain that you don't know anything
> if you don't know how it works -- you can't learn how FPGAs in general
> work if you don't look in depth at at least one example and looking in
> edpth at the Vertex chip won't make you any stupider when you see the
> foobar chip -- if anything, it'll make you smarter because you'll see the
> historical basis for decisions and you'll see neat innovations rather than
> just an entirely new system.  If you'll never learn ANY of the chips then
> I continue to maintain that you know plenty to get most jobs done, but not
> enough for extreme excellence, which is sometimes demanded.

--
-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: 21755
Subject: Re: FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Thu, 30 Mar 2000 20:22:08 GMT
Links: << >>  << T >>  << A >>
Oops, sent it before I finished typing.  Anyway, Greg,  I heartily applaud
your enthusiasm, but I think it is slightly misdirected, at least for where
you are on the learning curve right now.

Greg Alexander wrote:

> In article <8bv4us$7st$1@nnrp1.deja.com>, rob_dickinson@my-deja.com wrote:
> >In article <8btl68$kjh$1@jetsam.uits.indiana.edu>,
> >galexand@sietch.bloomington.in.us (Greg Alexander) wrote:
> >> In article <8bt2io$rnp$1@nnrp1.deja.com>, rob_dickinson@my-deja.com
> >wrote:
> >> >Having read most of this thread I have the following global comments.
> >> >
> >> >1)If you just want to play then surely you can understand that
> >company
> >> >A or X have better things to do than to be bothered with even a few
> >> >hundred people going "your" route.
> >>
> >> Total disagreement. As I've said before, most people competent in the
> >> field learned most of what they knew going in just playing around. The
> >> more hobbyists playing with it today the more companies buying hte
> >things
> >> tomorrow. I think Linux's commercial success proves that -- I don't
> >think
> >> managers picked it because htey liked it, I think managers picked it
> >> because their employees said "I know and like Linux, it'll do the job
> >and
> >> if it doesn't we'll make it."
> >
> >
> >Greg
> >I'm about to disapoint you.
> >FPGA's are inevitably designed by many people in such a manner that
> >they can be maintained by other people over many years and probably
> >ported easily to newer devices.  The ability to "hack" at or near the
> >bitstream level will not impress many people and I can assure you that
> >decisions to invest 10,000 (say) man hours because "Greg played with
> >bitstreams at home" will not cut it at all.  If it was "Greg is bloody
> >good at VHDL simulation using VITAL and does the job in half the time"
> >then you probably will still not influence the decision making but you
> >will get paid more than the next guy.
> >Yes one guy can probably write good code for FPGA's on his own, doing
> >it some strange weird way because X let him do it at the bitstream
> >level,  but you might go under a bus and you will almost definitely
> >change companies during the lifetime of the #CODE#.  You are therefore
> >only usefull to a company if you are competent with the tools which the
> >next guy can use.
> >The more hobyists using VHDL (which is free from the right places) the
> >better, the more people coming through degrees who still know what a
> >counter or state machine is at the gate level, even better.  A thorough
> >knowledge of the routing architecture at any level is almost useless,
> >Vertex will be almost completely superceeded in a frighteningly short
> >time and no-one will give diddly squat that you know it litterally
> >inside out.
>
> As easily as you dismiss my approach to learning, people who have been
> through my approach to learning completely dismiss anything learned your
> way as being inadequate and cloudy.  *shrug*  Bias can go both ways and it
> doesn't make either side right -- but if there are two sides you shouldn't
> be so sure yours is the only way.  I maintain that you don't know anything
> if you don't know how it works -- you can't learn how FPGAs in general
> work if you don't look in depth at at least one example and looking in
> edpth at the Vertex chip won't make you any stupider when you see the
> foobar chip -- if anything, it'll make you smarter because you'll see the
> historical basis for decisions and you'll see neat innovations rather than
> just an entirely new system.  If you'll never learn ANY of the chips then
> I continue to maintain that you know plenty to get most jobs done, but not
> enough for extreme excellence, which is sometimes demanded.

--
-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: 21756
Subject: Re: Global clock nets. Can I use it for signal other than clock.
From: Ray Andraka <randraka@ids.net>
Date: Thu, 30 Mar 2000 20:27:22 GMT
Links: << >>  << T >>  << A >>
Peter,

It would have been nice to have a faster global or high fanout distribution
for non-clock signals (like clock enables) on the Virtex part.  The existing
'secondary clock distribution' is next to useless for system clocks as low as
130 MHz, unless there is some trick I missed.  Seems the fastest distributions
you can get on these in a -4 part is about 9-10ns.



Peter Alfke wrote:

> No, there is no published research paper.
> The decisions depend on the priorities seen at the time of family
> inception:
>
> Generality is obviously nice, but burdens the clock tree with a lot of
> extra capacitance, whether the destinations are activated or not.
>
> Single-mindedness reduces capacitive loading, and thus clock delay and
> clock skew, which are important parameters at clock rates > 200 MHz. Also,
> the improved quality of the additional interconnect allows us to restrict
> the global clock lines to their original purpose.
>
> Clock distribution quality has a higher importance today than it had years
> ago, especially since the DLL can effectively eliminate the clock delay.
> Clock skew thus takes on a new significance, and clock skew is drastically
> improved by using the global nets as clocks only.
>
> Hope this is convincing.
>
> Peter Alfke, Xilinx Applications
>
> Tim wrote:
>
> > As I recall the sequence was
> >
> >    XC2000 - (I have forgotten)
> >    XC3000 - only drive clocks
> >    XC4000 - drive anything
> >    Virtex - only drive clocks
> >
> > Is there a paper on the research behind this?
> >
> > > Peter Alfke wrote:
> > >
> > > > It depends on the Xilinx family:
> > > >
> > > > In XC4000 and all its derivatives ( incl. Spartan and SpartanXL) you
> > can
> > > > use the global nets for anything you might want.
> > > >
> > > > In Virtex and its derivatives ( incl. Spartan-II) you can use the
> > global
> > > > clock nets *ONLY* as clocks.

--
-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: 21757
Subject: Re: Memory cores
From: Ray Andraka <randraka@ids.net>
Date: Thu, 30 Mar 2000 20:31:33 GMT
Links: << >>  << T >>  << A >>
If you want to initialize the rams (upon configuration only) with something
other than zeros you'll have to instantiate the primitives rather than infer
the RAM.  The primitives have generics on them for the initial values
(xilinx), which default to 0.

David Kessner wrote:

>
> What Altera and Xilinx have done, however, is provide a way to
> initialize the contents of RAM to any arbitrary value during the
> normal FPGA programming process.  In other words, the initial
> contents of all RAM is included in the programming bitstream.
> This allows the RAM to be initialized to a specific value and
> used as a ROM (or something else).
>
> Unfortunately, I have no experience initializing RAM like that--
> other than I know that it can be done and have seen it done.  I'll
> have to learn how to soon, however, since it's recently come up
> on a new core design...
>
> Hope that helps!
>
> David Kessner
> davidk@free-ip.com              http://www.free-ip.com/

--
-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: 21758
Subject: Re: What's so good about antifuse???
From: Ray Andraka <randraka@ids.net>
Date: Thu, 30 Mar 2000 20:40:21 GMT
Links: << >>  << T >>  << A >>


fulvs@my-deja.com wrote:

> I'm trying to understand the difference between
> antifuse, SRAM and flash based FPGAs. I have 3
> questions and any comments on any of these would
> be much appreciated.
>
> 1) Antifuse is purportedly cheaper, lower power,
> higher performance. Why is this? If this is true
> - how much cheaper, lower power etc?
>

A little lower on power, but it isn't as much as you might think.  The
majority of power consumption in an FPGA is the dynamic power due to
nodes switching.  Since the configuration registers in an SRAM FPGA are
usually static once the device is configured, they contribute very
little to the overall power.  BTW, SRAM based FPGAs is an unfortunate
selection of terms.  The configuration is held in registers more akin to
D flip-flops than to SRAM memory cells, and slow registers at that.
What that means is the memory is more robust than one usually expects
for SRAM.  The performance claim is also questionable, but that goes
more with the architecture than the technology.  The antifuse arrays
available don't have fast carry chains, so in arithmetic applications it
is a little harder to keep up wiht the SRAM devices that have them.

>
> 2) Other than military/aerospace, what
> applications are antifuse FPGAs used for? Aren't
> SRAM FPGAs much better because they're many times
> reprogrammable?
>

Depends on the application.  You need off chip storage for the bitstream
for the SRAM devices, plus some time on system initialization to load
the bitstream.  The antifuse devices don't need that and aren't
brain-dead when the power comes on.

>
> 3) Who is the best antifuse vendor?
>

Depends on what the definition of best is :-).

>
> Thanks in advance for your help.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
-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: 21759
Subject: Re: What's so good about antifuse???
From: Ray Andraka <randraka@ids.net>
Date: Thu, 30 Mar 2000 20:41:09 GMT
Links: << >>  << T >>  << A >>


HH wrote:

> I only know Actel  (... but that does not make it the best ;-)
>

Quicklogic is also antifuse.


--
-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: 21760
Subject: Adrian Thompson's and GA work on Xilinx
From: Anshuman Sharma <gte600f@prism.gatech.edu>
Date: 30 Mar 2000 21:31:44 GMT
Links: << >>  << T >>  << A >>
Anybody who is familiar with Adrian Thompson and his work with Hardware
Evolution can help. I am trying to duplicate the experiment that he did
using the Xilinx XC6216, but my problem is that Xilinx and discontinued
that particular series. I know I am not the first one to try and do that,
so if anyone has done it or know about it being done should be able to
help. 
What I want to know is how can I duplicate it without using the
XC6216. That particular series had a very simple floorplan and it was a
research purposes-only version. If I have to use another chip then it is
very hard to just download random bit patterns on to a cell area without
frying the board, moreso, if you use the software provided by the regular
vendors, then it doesn't even let you do it. Is there another board that I
can use for the same, or is there another software that I can use to do
the same? Any help with this would be really appreciated.

thanks,

Anshuman

-- 
---------------------------------------------------
"time and space are modes by which we think...... |
they are not the conditions in which we live."    |
                                                  |
   ~~Einstein                                     |       
---------------------------------------------------


Anshuman Sharma
Georgia Institute of Technology, Atlanta Georgia, 30332
Email: gte600f@prism.gatech.edu
       anshu@abraxis.com

Article: 21761
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 30 Mar 2000 22:09:40 GMT
Links: << >>  << T >>  << A >>
In article <38E3B6BD.9858EFD1@ids.net>, Ray Andraka wrote:
>Greg,
>
>I like to think that I know more than the average bear about how to make
>things work, and work well within an FPGA.  Guess what,  I don't go down to
>the bitstream level!  I do however use the tools provided, including the

Of course nobody goes down to the bitstream level, but they should
understand it down to the XDL level.  I only want bitstream because XDL ->
bitstream is comparatively trivial and they are obviously not going to let
me use their XDL software unless I run Windows or SunOS or HP-UX.  I
vaguely suspect that they don't support Solaris x86 but that's just a
guess.

>floorplanner and the chip editor to learn about the chip.  True, these are
>abstractions, but they are also close enough to the actual hardware to
>understand everything you need to know to take advantage of all the FPGA has
>to offer.  I maintain that if you want to learn about the FPGA, start with
>what is accessible with the tools and if then if they don't meet your needs

The tools themselves aren't accessible!  I'm not going to be running
whatever OS some random company too dull to notice "oh yeah, that open
source bandwagon!" tells me to.  You think they should only write for one
platform?  Sure, why not.  The only decent bash implementation is for Unix
and I'm unwilling to give that up.  So you're saying I have to chose
between bash and Xilinx' tools.  Or do you really expect me to shell out
the ~$400 for a machine capable of barely running Win95 just so I can use
Xilinx' tools?  Or the ~$3000 for a commercial Unix workstation to run
both?  I'm using a 2 year old computer with a market value of probably
$400 as my main workstation and I have been doing so for years -- if
anyone thinks I'm going to break something that works just to develop
FPGAs in a frustrating environment that I KNOW AHEAD OF TIME WILL
FRUSTRATE ME (unavoidable with Windows software -- when there is Windows
software and some homegrown Unix program competing the homegrown Unix
program always wins: TeX vs. FrameMaker, vi vs. Notepad, bash vs. Windows
Explorer -- by not opening themselves up to more potential chip
development environments they're just removing the Unix hacked equivalent
as competition, they're not actually winning against it...even if I don't
write it).

>push down lower where you need to.  If you learn how to design to the
>architecture you will be far ahead of the pack, and I think if you do it
>within the supplied framework, you'll get there a heckuva lot sooner than if
>you start at the bitstream level.

I agree with your idea -- if those tools were as accessible for me as they
are for you I wouldn't hesitate to go that route, /I'd even pay the $100/.

They've made a mistake by targetting platforms I can't use.  They've made
a further mistake by not allowing me to target whatever platform I want.
The former mistake is unavoidable -- you can't support everything.  The
second mistake is pure corporate dumbheadedness.  From the "I have all
these secrets" side of the fence, the grass looks brown on the other side,
but once you get there -- once you share -- you find out that it's great.
You may think that we on the other side of the fence are confused, but no
amount of paradigm shifting will allow me to use their software in a
satisfactory manner.

>Greg Alexander wrote:
>
>> As easily as you dismiss my approach to learning, people who have been
>> through my approach to learning completely dismiss anything learned your
>> way as being inadequate and cloudy.  *shrug*  Bias can go both ways and it
>> doesn't make either side right -- but if there are two sides you shouldn't
>> be so sure yours is the only way.  I maintain that you don't know anything
>> if you don't know how it works -- you can't learn how FPGAs in general
>> work if you don't look in depth at at least one example and looking in
>> edpth at the Vertex chip won't make you any stupider when you see the
>> foobar chip -- if anything, it'll make you smarter because you'll see the
>> historical basis for decisions and you'll see neat innovations rather than
>> just an entirely new system.  If you'll never learn ANY of the chips then
>> I continue to maintain that you know plenty to get most jobs done, but not
>> enough for extreme excellence, which is sometimes demanded.
>
>--
>-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: 21762
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 30 Mar 2000 22:10:02 GMT
Links: << >>  << T >>  << A >>
In article <38E3B738.FAF783F5@ids.net>, Ray Andraka wrote:
>Oops, sent it before I finished typing.  Anyway, Greg,  I heartily applaud
>your enthusiasm, but I think it is slightly misdirected, at least for where
>you are on the learning curve right now.

If they didn't intentionally make it difficult to learn I wouldn't be
here.
Article: 21763
Subject: Re: What's so good about antifuse???
From: John Larkin <jjlarkin@highland_SnipThis_technology.com>
Date: Thu, 30 Mar 2000 14:55:43 -0800
Links: << >>  << T >>  << A >>
On Thu, 30 Mar 2000 18:28:03 GMT, fulvs@my-deja.com wrote:

>I'm trying to understand the difference between
>antifuse, SRAM and flash based FPGAs. I have 3
>questions and any comments on any of these would
>be much appreciated.
>
>1) Antifuse is purportedly cheaper, lower power,
>higher performance. Why is this? If this is true
>- how much cheaper, lower power etc?
>
>2) Other than military/aerospace, what
>applications are antifuse FPGAs used for? Aren't
>SRAM FPGAs much better because they're many times
>reprogrammable?
>
>3) Who is the best antifuse vendor?
>
>Thanks in advance for your help.
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.

Hi,

having used Actel (antifuse), Lattice (ee reprogrammable) and Xilinx (ram)
FPGAs, one striking difference is in development. Since all these parts are
surface mount, and the hugely-expensive fine-pitch sockets just don't work,
you pretty much have to replace an antifuse part (desolder, toss in trash,
solder new one in) every time you do a design iteration or mod. This is an
enormous pain, and 'discourages innovation'.

I think that the Xilinx parts are the easiest to use overall. The Lattice
ISP thing is OK, but those parts are actually CPLDs and don't have anywhere
near the resources of a real FPGA.

We're paying about $10 for pretty spiffy Spartan chips so, unless volume is
high, our development cost remains a major factor overall. I wouldn't go
back to Actel if they were free.

Don't know how it is to work with Altera.

John

Article: 21764
Subject: Program non-Xilinx parts with Xilinx JTAG programmer and cable?
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Thu, 30 Mar 2000 17:55:27 -0700
Links: << >>  << T >>  << A >>
Has anyone tried this?

I need a small pld on a board I'm doing, and the Lattice ISP 22V10 should be
fine.  I want ISP because I don't want sockets.  And since I already have
the Xilinx software and cables, theoretically, this should work.

Or not?

-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Money is property; it is not speech."
            -- Justice John Paul Stevens


Article: 21765
Subject: Re: MaxPlus9.5 License and Fitter problems
From: "M R Wheeler" <intell-a-sys@iquest.net>
Date: Fri, 31 Mar 2000 01:33:10 GMT
Links: << >>  << T >>  << A >>
Contacted Altera today.  They confirmed this to be a known bug and are
providing a license file to bypass the dongle until it is resolved.   

Also, they have had several calls on the Quartus fitter giving internal
applications errors.  


M R Wheeler <intell-a-sys@iquest.net> wrote in article
<01bf99ea$b3e094a0$2a3b2bd1@speedy>...
> I am evaluating MaxPlus 9.5 and am finding that often the software can
not
> seem to locate the dongle during the build process on larger designs. 
The
> software give me a license error message.  Also, when selecting the
Quartus
> fitter, I am getting internal errors (contact Altera, who never has a
> clue).  Both problems occur on two different computers.  Just wonder if
> anyone else is using this version yet.  
> 
> 
Article: 21766
Subject: Re: Adrian Thompson's and GA work on Xilinx
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 30 Mar 2000 23:49:42 -0500
Links: << >>  << T >>  << A >>
Anshuman Sharma wrote:
> 
> Anybody who is familiar with Adrian Thompson and his work with Hardware
> Evolution can help. I am trying to duplicate the experiment that he did
> using the Xilinx XC6216, but my problem is that Xilinx and discontinued
> that particular series. I know I am not the first one to try and do that,
> so if anyone has done it or know about it being done should be able to
> help.
> What I want to know is how can I duplicate it without using the
> XC6216. That particular series had a very simple floorplan and it was a
> research purposes-only version. If I have to use another chip then it is
> very hard to just download random bit patterns on to a cell area without
> frying the board, moreso, if you use the software provided by the regular
> vendors, then it doesn't even let you do it. Is there another board that I
> can use for the same, or is there another software that I can use to do
> the same? Any help with this would be really appreciated.
> 
> thanks,
> 
> Anshuman
> 
> --
> ---------------------------------------------------
> "time and space are modes by which we think...... |
> they are not the conditions in which we live."    |
>                                                   |
>    ~~Einstein                                     |
> ---------------------------------------------------
> 
> Anshuman Sharma
> Georgia Institute of Technology, Atlanta Georgia, 30332
> Email: gte600f@prism.gatech.edu
>        anshu@abraxis.com

I am not at all familiar with the work of Adrian Thompson or much
familiar with Hardware Evolution, but why can't you do the same thing in
a simulation rather than to have to work directly with a bitstream and
load a part for test?

EDIF files can be "randomly" connected and simulated to test the
functionality. Your software may crash once in awhile, but it is
unlikely to fry the computer. 

-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 21767
Subject: Re: Adrian Thompson's and GA work on Xilinx
From: Dave Vanden Bout <devb@xess.com>
Date: Fri, 31 Mar 2000 00:14:18 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------635EE6AE738F288B60AB5AEF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Rickman wrote:

> I am not at all familiar with the work of Adrian Thompson or much
> familiar with Hardware Evolution, but why can't you do the same thing in
> a simulation rather than to have to work directly with a bitstream and
> load a part for test?
>
> EDIF files can be "randomly" connected and simulated to test the
> functionality. Your software may crash once in awhile, but it is
> unlikely to fry the computer.
>

Thompson's results were heavily dependent upon parasitic effects in the FPGA chip that affected the selection of fit individuals in the population.  Software simulations could be used in the genetic algorithm feedback loop, but a lot of the interesting circuits evolved during Thompson's experiments would never emerge.  These evolved circuits often used LUTs and routing resources in ways that any logic or timing simulator (or human) would consider completely whacked.


--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||


--------------635EE6AE738F288B60AB5AEF
Content-Type: text/x-vcard; charset=us-ascii;
 name="devb.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dave Vanden Bout
Content-Disposition: attachment;
 filename="devb.vcf"

begin:vcard 
n:Vanden Bout;Dave
tel;fax:(919) 387-1302
tel;work:(919) 387-0076
x-mozilla-html:FALSE
url:http://www.xess.com
org:XESS Corp.
adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA
version:2.1
email;internet:devb@xess.com
title:FPGA Product Manager
x-mozilla-cpt:;-16464
fn:Dave Vanden Bout
end:vcard

--------------635EE6AE738F288B60AB5AEF--

Article: 21768
Subject: Re: FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Fri, 31 Mar 2000 05:35:15 GMT
Links: << >>  << T >>  << A >>
I don't think anyone is making FPGAs intentionally difficult to learn. Instead,
consider that  modern FPGAs are very complex devices capable of holding circuits
of up to more than a million logic gates.  If anything, I find the literature
available on the websites to be pretty good as far as discussing the
architecture of the FPGAs as well as how to take advantage of it.  Also,
regarding your response to my earlier post, I don't even work at the XDL level.
I do my designs at the other end of the xilinx tool flow where I can take the
most advantage of the abstraction that I can to get a design done efficiently.
You really do have enough control over the details to put together the design,
including placement and to some degree even routing at whatever level of detail
you are willing to persevere.  You can run most of the tools, enough to do the
design anyway, under DOS mode.  Of course you don't get the GUIs that way, but I
don't get the impression you like to use GUIs anyway (I'm running a place and
route right now under a bash shell, which is why I have a moment to respond).

Greg Alexander wrote:

> In article <38E3B738.FAF783F5@ids.net>, Ray Andraka wrote:
> >Oops, sent it before I finished typing.  Anyway, Greg,  I heartily applaud
> >your enthusiasm, but I think it is slightly misdirected, at least for where
> >you are on the learning curve right now.
>
> If they didn't intentionally make it difficult to learn I wouldn't be
> here.

--
-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: 21769
Subject: Re: Adrian Thompson's and GA work on Xilinx
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 31 Mar 2000 05:46:58 GMT
Links: << >>  << T >>  << A >>
Does anyone have any citations for Thompson's original work?

In article <38E4342A.4B3CD10C@xess.com>, Dave Vanden Bout wrote:
>This is a multi-part message in MIME format.
>--------------635EE6AE738F288B60AB5AEF
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>
>
>Rickman wrote:
>
>> I am not at all familiar with the work of Adrian Thompson or much
>> familiar with Hardware Evolution, but why can't you do the same thing in
>> a simulation rather than to have to work directly with a bitstream and
>> load a part for test?
>>
>> EDIF files can be "randomly" connected and simulated to test the
>> functionality. Your software may crash once in awhile, but it is
>> unlikely to fry the computer.
>>
>
>Thompson's results were heavily dependent upon parasitic effects in the FPGA chip that affected the selection of fit individuals in the population.  Software simulations could be used in the genetic algorithm feedback loop, but a lot of the interesting circuits evolved during Thompson's experiments would never emerge.  These evolved circuits often used LUTs and routing resources in ways that any logic or timing simulator (or human) would consider completely whacked.
>
>
>--
>|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
>|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
>|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||
>
>
>--------------635EE6AE738F288B60AB5AEF
>Content-Type: text/x-vcard; charset=us-ascii;
> name="devb.vcf"
>Content-Transfer-Encoding: 7bit
>Content-Description: Card for Dave Vanden Bout
>Content-Disposition: attachment;
> filename="devb.vcf"
>
>begin:vcard 
>n:Vanden Bout;Dave
>tel;fax:(919) 387-1302
>tel;work:(919) 387-0076
>x-mozilla-html:FALSE
>url:http://www.xess.com
>org:XESS Corp.
>adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA
>version:2.1
>email;internet:devb@xess.com
>title:FPGA Product Manager
>x-mozilla-cpt:;-16464
>fn:Dave Vanden Bout
>end:vcard
>
>--------------635EE6AE738F288B60AB5AEF--
>
Article: 21770
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 31 Mar 2000 05:55:50 GMT
Links: << >>  << T >>  << A >>
In article <38E43900.1F488CCC@ids.net>, Ray Andraka wrote:
>I don't think anyone is making FPGAs intentionally difficult to learn. Instead,
>consider that  modern FPGAs are very complex devices capable of holding circuits
>of up to more than a million logic gates.  If anything, I find the literature
>available on the websites to be pretty good as far as discussing the
>architecture of the FPGAs as well as how to take advantage of it.  Also,
>regarding your response to my earlier post, I don't even work at the XDL level.
>I do my designs at the other end of the xilinx tool flow where I can take the
>most advantage of the abstraction that I can to get a design done efficiently.
>You really do have enough control over the details to put together the design,
>including placement and to some degree even routing at whatever level of detail
>you are willing to persevere.  You can run most of the tools, enough to do the
>design anyway, under DOS mode.  Of course you don't get the GUIs that way, but I

Not quite.  You can run them in console Windows, which is /NOT/ to be
mistaken for DOS.  DOS does not provide access to DLLs, specifically (not
that this really matters to anyone but me, but DOSemu isn't a big hassle
for me and Windows emulation would more or less necessitate a new HDD,
bringing the total cost of ownership for what is a comparatively simple
program to about $200 -- that most people buying this software want more
than just the simple parts and consider $100 or even $1000 to be a very
reasonable price is another red herring).  That the software is capable of
doing what you think I should do, even that the software is capable of
doing what I want, remains a red herring.  "Look, I don't have an answer
to your question, but here's this red herring over here for you to look
at."  I appreciate it, but it's pretty useless.  Thanks for trying and
putting up with me and all.

>don't get the impression you like to use GUIs anyway (I'm running a place and
>route right now under a bash shell, which is why I have a moment to respond).
Article: 21771
Subject: Synthesize components within a block using FPGA compiler
From: TeikMing Goh <ming@morgan.ucs.mun.ca>
Date: Fri, 31 Mar 2000 02:47:04 -0330
Links: << >>  << T >>  << A >>
Hi all,

I have a functional block which contains 3  components i.e. adder, XOR
gate and barrel_shift.  I want to sythesize this functional block and I am
using Synopsys design_analyzer and Xilinx Design_manager.  I am wondering
about this:
/*   set_port_is_pad "*"  */
/*   insert_pads */          

Should I include this two lines when I synthesize each component
individually(I want to do timing simulation on the components)?  
I know I have to because design_manager generated error.  What kind of
parameter I should use so that it will work when I synthesize the
functional block. 
What should I do when I synthesize the functional block? I know I need to
use:
include -f -db *.db; but, I don't know what I should do regarding
"Set_port_is_pad" for the functional block. 

Thank you alot!
Regards,
Teik-Ming


Article: 21772
Subject: Re: Pipelined ALTERA LPMs - where are the registers introduced?
From: psycho333221@aol.com (Psycho333221)
Date: 31 Mar 2000 07:21:31 GMT
Links: << >>  << T >>  << A >>
The registers are placed so as to attempt to break the logic into equal sized
chunks.  So for LPM_PIPELINE = 1, the registers should be right at the center. 
If you think about it, this is the only way that makes sense if you really
intend to increase speed.
The ideal is that if it normally takes x for the signal to propagate, then with
a pipeline of n the propogation delay should be x/n.  However, in most cases
this ideal is not reached since it is difficult to break the function up
perfectly and also the delays of different routing are different.
Article: 21773
Subject: Re: Adrian Thompson's and GA work on Xilinx
From: Andreas Doering <doering@iti.mu-luebeck.de>
Date: Fri, 31 Mar 2000 09:24:33 +0200
Links: << >>  << T >>  << A >>
Greg Alexander wrote:
> 
> Does anyone have any citations for Thompson's original work?
His homepage is here with a lot of papers. 
I guess the mentioned one is among them. 
http://www.cogs.susx.ac.uk/users/adrianth/ade.html

Andreas
-----------------------------------------------------------------
                        Andreas C. Doering
                        Medizinische Universitaet zu Luebeck
                        Institut fuer Technische Informatik
                        Ratzeburger Allee 160
                        D-23538 Luebeck Germany

		        Tel.: +49 451 500-3741, Fax: -3687
		        Email: doering@iti.mu-luebeck.de
                        Home: http://www.iti.mu-luebeck.de/~doering 
                             quiz, papers, VHDL, music

"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)
----------------------------------------------------------------
Article: 21774
Subject: Actel ProASIC
From: david.miller@gecm.com (David Miller)
Date: Fri, 31 Mar 2000 08:09:32 GMT
Links: << >>  << T >>  << A >>
Does anyone have any experience of using these parts?

The ProASIC is Flash based which, to me, seems an interesting half-way
house between antifuse and SRAM.  Will it offer the best (or worst) of
both worlds?

David Miller



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