1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

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

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

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

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?
>
>
> Sent via Deja.com http://www.deja.com/


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

>
>
> Sent via Deja.com http://www.deja.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: 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
>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?
>
>
>
>Sent via Deja.com http://www.deja.com/

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

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

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.

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