Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 150425

Article: 150425
Subject: Re: Overview for non-technicals.
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 20 Jan 2011 10:28:41 +0000 (UTC)
Links: << >>  << T >>  << A >>
rupertlssmith@googlemail.com <rupertlssmith@googlemail.com> wrote:
 
> I've googled about a bit, but not found the perfect answer yet. Does
> anyone have any suggestions for reading material (paper or web), that
> would serve as an introductory overview of FPGAs for non-technical
> managers? 

Note that FPGAs don't "do" anything that can't be done in other
ways, but they do make it faster and cheaper.  To answer that
question, you need to know what can be done in general with
digital logic.  But for a manager, cost and speed are important,
and there is no easy way to answer those questions.

> Something that gives a rough idea of what typically can and
> cannot be achieved in hardware, and a sense of the difficulties and
> effort required to do so. Thats probably a lot to ask, but if you know
> of any good introductions, I would appreciate a link.

Personally, I find the linear systolic array architecture very useful
for FPGA implementation of algorithms.  It isn't the only possibility,
but, for the cases where it works, it results in nice, efficient,
and scalable implementations.

(For those who got this far, note that a $50 FPGA can be programmed
in seconds, where an ASIC might cost millions of dollars and take
years to be produced.)`

-- glen

Article: 150426
Subject: Re: Overview for non-technicals.
From: "rupertlssmith@googlemail.com" <rupertlssmith@googlemail.com>
Date: Thu, 20 Jan 2011 02:39:25 -0800 (PST)
Links: << >>  << T >>  << A >>
I should add, in this case not really non-technicals. Ex-techies who
have moved into management/BA roles. Smart people, not dummies. Just
lacking in experience of FPGAs and coming from a software background.

When I see a BA draw a box, label it FPGA, and start putting little
boxes labelled with the names of software components in it, and alarm
bell starts ringing. I need to provide them with some sort of context
so they can begin to understand this technology more realistically.

Article: 150427
Subject: Re: Overview for non-technicals.
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 20 Jan 2011 10:57:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
rupertlssmith@googlemail.com <rupertlssmith@googlemail.com> wrote:

> I should add, in this case not really non-technicals. Ex-techies who
> have moved into management/BA roles. Smart people, not dummies. Just
> lacking in experience of FPGAs and coming from a software background.

Often a software background doesn't help much.  Digital logic design
is significantly different from software, and the implementation
of algorithms is often very different.
 
> When I see a BA draw a box, label it FPGA, and start putting little
> boxes labelled with the names of software components in it, and alarm
> bell starts ringing. I need to provide them with some sort of context
> so they can begin to understand this technology more realistically.

Well, you often have to start that way, but then you need someone
that can answer the practical question.  If you assume that every
gate in an FPGA can be used to actually compute what needs to be
computed, and can run at about 300MHz then you have an upper limit
to what the FPGA can do.  If the algorithm can be constructed using
N bit fixed point arithmetic, then it isn't too hard to find the
maximum amount of computation that can be done.  

Well, I am assuming that the goal is for a very computation
intensive problem.  If that isn't the case, then my comments might
not apply.  But the word "software" in your statement does
bother me.  There are people that believe that FPGAs are the
solution to many software problem.  In some cases they are, but
it is easy to over generalize.

-- glen

Article: 150428
Subject: Re: Prime number testing on FPGA
From: Thomas Womack <twomack@chiark.greenend.org.uk>
Date: 20 Jan 2011 11:45:29 +0000 (GMT)
Links: << >>  << T >>  << A >>
In article <b8e5e93e-22af-47d3-b397-11db7cafa26e@s5g2000yqm.googlegroups.com>,
Dennis Yurichev  <dennis.yurichev@gmail.com> wrote:
>There are another number primality tests exists, so the question is,
>is there can be such primality test which is suitable for FPGA in such
>way, when it will work much more effectively than =C9douard Lucas and
>Derrick Henry Lehmer's primality test running on generic computer?

The LL test already uses about as few multiplications as you can
reasonably hope for.

The inner loop of the primality test is a large FFT, which is the
classic non-streaming task, done in double-precision floating point,
which is another thing at which generic computers are significantly
better than FPGAs.

People have occasionally built a large FFT multiply (often a
number-theoretic transform, since arithmetic mod 2^64-2^32+1 is rather
easier to implement than double-precision FP) in FPGAs; they have to
be big FPGAs, on a board with lots of attached DDR3 or QDR SRAM
memory, and end up about as fast as a desktop PC at ten to fifty times
the cost.  

Basically, Sandy Bridge or Phenom chips are an enormously cheaper
source of multipliers and memory bandwidth than Xilinx.

Tom



Article: 150429
Subject: Re: Overview for non-technicals.
From: "rupertlssmith@googlemail.com" <rupertlssmith@googlemail.com>
Date: Thu, 20 Jan 2011 06:14:28 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 20, 10:57=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
> But the word "software" in your statement does
> bother me. =A0There are people that believe that FPGAs are the
> solution to many software problem. =A0In some cases they are, but
> it is easy to over generalize.

Yes, the software in question has one part that is CPU intensive, and
fairly obviously parallelizable. It is also the most prominent CPU
bottleneck. That should go on the FPGA.

The rest of the software is quite bulky, and a lot of sequential
logic. It could be run on a soft CPU on an FPGA, but I presume those
might typically be programmed in C, and the existing software is not
in C, so would require a port.

The most obvious solution to me, is to keep 90% of the software as it
already is, and just move the 10% parallel chunk to the FPGA, put it
on a card that has a PCIe bus, and hope that the overhead of
communicating over the bus doesn't eat away the performance advantage.

I'm trying to collect together some good resources that would help
managers from a software background get to grips with what an FPGA is,
and understand what the advantages are. I've got plenty tech resources
on the subject, and its a technical enough field that a manager is
going to have to get to grips with some of the techie stuff. As I say,
I'm looking for pointers to material on understanding where to draw
the hardware/software line, how to estimate the size of a hardware
project, and other issues not directly to do with the techie how-to
side of things.

Article: 150430
Subject: Re: Overview for non-technicals.
From: Chris Maryan <kmaryan@gmail.com>
Date: Thu, 20 Jan 2011 06:34:33 -0800 (PST)
Links: << >>  << T >>  << A >>
You wrote:
> I'm looking for pointers to material on understanding where to draw
> the hardware/software line, how to estimate the size of a hardware
> project, and other issues not directly to do with the techie how-to
> side of things.

The hardware/software line and estimating hardware size are usually more ad=
vanced topics that have to come from experience and domain knowledge - you'=
ll be hard pressed to find high level resources on this. That is, I know ho=
w to answer these questions for the area of products that I work on because=
 I work on those products.

Chris

Article: 150431
Subject: Re: Overview for non-technicals.
From: "rupertlssmith@googlemail.com" <rupertlssmith@googlemail.com>
Date: Thu, 20 Jan 2011 07:47:49 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 20, 2:34=A0pm, Chris Maryan <kmar...@gmail.com> wrote:
> The hardware/software line and estimating hardware size are usually more =
advanced topics that have to come from experience and domain knowledge - yo=
u'll be hard pressed to find high level resources on this. That is, I know =
how to answer these questions for the area of products that I work on becau=
se I work on those products.

Fair enough, and I can see that you are right to say it comes from
experience.

In software there have been studies comparing programming effort using
different systems. One notable example might be the study carried out
by Erricson, before they developed Erlang, to try and demonstrate the
programmers are more 'productive' using functional languages. Of
course, these studies are fundamentally flawed in that to be
scientific, they must measure things, and the things they try to
measure are not easily or precisely quantifiable. Sometimes its fun
look at the computer language shootout website, to try and get a feel
for the conciseness versus performance of different languages solving
the same problem. Looks like Python is very concise, but not very
performant for example, so you might choose it to do rapid prototyping
or rapid development of stuff where speed is not an issue.

Have similar studies not been carried out in the field of hardware
development, or am I just failing to find them?

Article: 150432
Subject: Re: Overview for non-technicals.
From: Tim Wescott <tim@seemywebsite.com>
Date: Thu, 20 Jan 2011 09:40:15 -0800
Links: << >>  << T >>  << A >>
On 01/20/2011 02:28 AM, glen herrmannsfeldt wrote:
> rupertlssmith@googlemail.com<rupertlssmith@googlemail.com>  wrote:
>
>> I've googled about a bit, but not found the perfect answer yet. Does
>> anyone have any suggestions for reading material (paper or web), that
>> would serve as an introductory overview of FPGAs for non-technical
>> managers?
>
> Note that FPGAs don't "do" anything that can't be done in other
> ways, but they do make it faster and cheaper.

Or faster and way more expensive -- depending on what it is you're 
trying to do.


-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 150433
Subject: Re: Overview for non-technicals.
From: Tim Wescott <tim@seemywebsite.com>
Date: Thu, 20 Jan 2011 09:43:46 -0800
Links: << >>  << T >>  << A >>
On 01/20/2011 02:11 AM, rupertlssmith@googlemail.com wrote:
> Hi,
>
> I've googled about a bit, but not found the perfect answer yet. Does
> anyone have any suggestions for reading material (paper or web), that
> would serve as an introductory overview of FPGAs for non-technical
> managers? Something that gives a rough idea of what typically can and
> cannot be achieved in hardware, and a sense of the difficulties and
> effort required to do so. Thats probably a lot to ask, but if you know
> of any good introductions, I would appreciate a link.

Find the Embedded.com website and take a look through their article data 
base.  I know that articles on FPGA design crop up periodically in 
Embedded Systems Design*.  They're at all sorts of different levels, so 
going through them may help you get an intuitive grasp.

As stated, designing for an FPGA is a lot different from writing 
software.  I do analog circuit design and embedded software quite well, 
but those two still don't give me the knowledge I need to write digital 
hardware descriptions that are competitive with even an average FPGA guy.

* Why name a magazine for a silicon based industry "ESD"?

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 150434
Subject: Re: Overview for non-technicals.
From: Chris Maryan <kmaryan@gmail.com>
Date: Thu, 20 Jan 2011 09:46:09 -0800 (PST)
Links: << >>  << T >>  << A >>

> Have similar studies not been carried out in the field of hardware
> development, or am I just failing to find them?

I don't know if there have been studies, but your options are basically Ver=
ilog or VHDL (there are a bunch of other options, including high level lang=
uages, graphical flows,  'wizard' based flows, but they are extremely limit=
ed and usually restricted to some tiny niche). The V vs V battle has been a=
rgued to death and the applicability of one or the other generally boils do=
wn to whether engineers in your area tend to know one or the other. There i=
s for the most part no significant difference in the usability of one or th=
e other. Once you've settled on VHDL or Verilog, the synthesis tools are al=
l largely the same, as are the FPGA products from the big two FPGA vendors.=
 For every person that complains about brand A or brand X, there are others=
 who will sing their praises.

If you are talking about studies of efficiency of developing in hardware vs=
 software, then this again becomes domain specific.

Chris

Article: 150435
Subject: Re: Overview for non-technicals.
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 20 Jan 2011 22:04:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
rupertlssmith@googlemail.com <rupertlssmith@googlemail.com> wrote:
> On Jan 20, 10:57 am, glen herrmannsfeldt <g...@ugcs.caltech.edu>
> wrote:
>> But the word "software" in your statement does
>> bother me.  There are people that believe that FPGAs are the
>> solution to many software problem.  In some cases they are, but
>> it is easy to over generalize.
 
> Yes, the software in question has one part that is CPU intensive, and
> fairly obviously parallelizable. It is also the most prominent CPU
> bottleneck. That should go on the FPGA.
 
> The rest of the software is quite bulky, and a lot of sequential
> logic. It could be run on a soft CPU on an FPGA, but I presume those
> might typically be programmed in C, and the existing software is not
> in C, so would require a port.

If it is really bulky, then it is probably best done as-is, and
just the CPU intensive part moved.  People have been working on
those problems for about 20 years now.  You might look at the
proceedings from the FCCM (FPGAs for Custom Computing Machines)
conference, which is one place that such devices have been
discussed over the years.
 
> The most obvious solution to me, is to keep 90% of the software as it
> already is, and just move the 10% parallel chunk to the FPGA, put it
> on a card that has a PCIe bus, and hope that the overhead of
> communicating over the bus doesn't eat away the performance advantage.

Yes, communication can be a problem.  If you can put the interface
in the place that minimizes the needed data transfer, that helps.

Also, there are some that, for example, put the FPGA on the 
hypertransport bus to make things faster.
 
> I'm trying to collect together some good resources that would help
> managers from a software background get to grips with what an FPGA is,
> and understand what the advantages are. I've got plenty tech resources
> on the subject, and its a technical enough field that a manager is
> going to have to get to grips with some of the techie stuff. 

You need someone who understands the problem domain, and the
possible FPGA implementations.  I have worked on the design of
FPGA based search processors, and can pretty quickly tell you if
a new idea makes sense or not.  For other problem domains, I would
not be able to do it quite as fast.

> As I say,
> I'm looking for pointers to material on understanding where to draw
> the hardware/software line, how to estimate the size of a hardware
> project, and other issues not directly to do with the techie how-to
> side of things.

Some of the more successful FPGA based accelerator products that 
I know about are produces by time-logic.  You might look at what
they have done.

-- glen

Article: 150436
Subject: Re: Overview for non-technicals.
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 20 Jan 2011 18:49:21 -0800
Links: << >>  << T >>  << A >>
On Thu, 20 Jan 2011 09:40:15 -0800, Tim Wescott <tim@seemywebsite.com>
wrote:

>On 01/20/2011 02:28 AM, glen herrmannsfeldt wrote:
>> rupertlssmith@googlemail.com<rupertlssmith@googlemail.com>  wrote:
>>
>>> I've googled about a bit, but not found the perfect answer yet. Does
>>> anyone have any suggestions for reading material (paper or web), that
>>> would serve as an introductory overview of FPGAs for non-technical
>>> managers?
>>
>> Note that FPGAs don't "do" anything that can't be done in other
>> ways, but they do make it faster and cheaper.
>
>Or faster and way more expensive -- depending on what it is you're 
>trying to do.

Or slower and more expensive; an FPGA is not the ideal device to
implement a large fixed function design in large quantities.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 150437
Subject: Re: Prime number testing on FPGA
From: backhus <goouse99@googlemail.com>
Date: Thu, 20 Jan 2011 23:30:46 -0800 (PST)
Links: << >>  << T >>  << A >>
On 20 Jan., 12:45, Thomas Womack <twom...@chiark.greenend.org.uk>
wrote:
> In article <b8e5e93e-22af-47d3-b397-11db7cafa...@s5g2000yqm.googlegroups.=
com>,
> Dennis Yurichev =A0<dennis.yuric...@gmail.com> wrote:
>
> >There are another number primality tests exists, so the question is,
> >is there can be such primality test which is suitable for FPGA in such
> >way, when it will work much more effectively than =3DC9douard Lucas and
> >Derrick Henry Lehmer's primality test running on generic computer?
>
> The LL test already uses about as few multiplications as you can
> reasonably hope for.
>
> The inner loop of the primality test is a large FFT, which is the
> classic non-streaming task, done in double-precision floating point,
> which is another thing at which generic computers are significantly
> better than FPGAs.
>
> People have occasionally built a large FFT multiply (often a
> number-theoretic transform, since arithmetic mod 2^64-2^32+1 is rather
> easier to implement than double-precision FP) in FPGAs; they have to
> be big FPGAs, on a board with lots of attached DDR3 or QDR SRAM
> memory, and end up about as fast as a desktop PC at ten to fifty times
> the cost. =A0
>
> Basically, Sandy Bridge or Phenom chips are an enormously cheaper
> source of multipliers and memory bandwidth than Xilinx.
>
> Tom

Hi Tom,
is there a reason why the algorithm uses floating point for the FFT
calculation?
Since the problem is the analysis of an integer number, this makes me
wonder.
Or is it just to make use of the FP-Coprocessor that is available in
the CPU anyway, and has no mathematical reason?

regards
  Eilert

Article: 150438
Subject: Re: Overview for non-technicals.
From: Cees Binkhorst <cees@binkhorst.xs4all.nl>
Date: Fri, 21 Jan 2011 10:47:47 +0100
Links: << >>  << T >>  << A >>
Have a look at http://www.mathworks.com/ and search (top-right corner)
with 'fpga' to get almost 900 leads for further reading.

There are also high-level optimization war-stories on
http://www.mathworks.com/solutions/

Regards / Cees

On 01/20/2011 11:11 AM, rupertlssmith@googlemail.com wrote:
> Hi,
> 
> I've googled about a bit, but not found the perfect answer yet. Does
> anyone have any suggestions for reading material (paper or web), that
> would serve as an introductory overview of FPGAs for non-technical
> managers? Something that gives a rough idea of what typically can and
> cannot be achieved in hardware, and a sense of the difficulties and
> effort required to do so. Thats probably a lot to ask, but if you know
> of any good introductions, I would appreciate a link.
> 
> Thanks for your help.
> 
> Rupert


Article: 150439
Subject: Re: Verilog Book for VHDL Users
From: Anssi Saari <as@sci.fi>
Date: Fri, 21 Jan 2011 17:04:11 +0200
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> writes:

> I'm curious, why are you using VHDL more now?  Is this a job
> requirement or do you prefer VHDL?  

Job requirement. Euroland is VHDLland too, with some exceptions.
Usually means customer is somewhere else, like in North America or
Asia. Even then, Verilog may be the result of autoconversion from
VHDL...

> Was there something about Verilog you didn't like?

I liked it just fine for design. Didn't much care for writing
testbenches in it. Most of my Verilog work was for telecom. For
example, generating ATM cells and sending them to the design was just
awful. Should've done it in Perl and put the data in a file. In fact,
I did that for the received data.

I'm not too keen on VHDL, but it gets the job done. I used to hate the
strong typing and required conversions, but I guess I don't mind that
much any more. Maybe it's influence from my recent interest in Python
too.

Article: 150440
Subject: Re: Verilog Book for VHDL Users
From: rickman <gnuarm@gmail.com>
Date: Fri, 21 Jan 2011 07:40:20 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 21, 10:04=A0am, Anssi Saari <a...@sci.fi> wrote:
> rickman <gnu...@gmail.com> writes:
> > I'm curious, why are you using VHDL more now? =A0Is this a job
> > requirement or do you prefer VHDL? =A0
>
> Job requirement. Euroland is VHDLland too, with some exceptions.
> Usually means customer is somewhere else, like in North America or
> Asia. Even then, Verilog may be the result of autoconversion from
> VHDL...
>
> > Was there something about Verilog you didn't like?
>
> I liked it just fine for design. Didn't much care for writing
> testbenches in it. Most of my Verilog work was for telecom. For
> example, generating ATM cells and sending them to the design was just
> awful. Should've done it in Perl and put the data in a file. In fact,
> I did that for the received data.
>
> I'm not too keen on VHDL, but it gets the job done. I used to hate the
> strong typing and required conversions, but I guess I don't mind that
> much any more. Maybe it's influence from my recent interest in Python
> too.

That was the one place where I used Verilog in the past, at a telecom
test equipment company.  I'm near Washington, DC and a lot of the jobs
around here are government.  I was in a government contractor job when
I learned HDL, so it was VHDL.  Now I want to learn Verilog as well as
I know VHDL and it is ticking me off a bit that I'm being told there
are NO good text books in it.

I've heard that Europe is very VHDL oriented.  I have no idea what
predominates in the far East.  I'm curious about that.

Rick

Article: 150441
Subject: Re: Verilog Book for VHDL Users
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Fri, 21 Jan 2011 17:24:00 +0100
Links: << >>  << T >>  << A >>
Anssi Saari <as@sci.fi> writes:

>> Was there something about Verilog you didn't like?
>
> I liked it just fine for design. Didn't much care for writing
> testbenches in it. Most of my Verilog work was for telecom. For

I'm the opposite :-) VHDL is ok for design, but not for testbenches.
SystemVerilog provides a much higher level of abstraction and features
like assertions, covergroups, and randomize classes for making
constraint random based testbenches.

//Petter

Article: 150442
Subject: Re: Overview for non-technicals.
From: rickman <gnuarm@gmail.com>
Date: Fri, 21 Jan 2011 09:52:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 20, 5:39 am, "rupertlssm...@googlemail.com"
<rupertlssm...@googlemail.com> wrote:
> I should add, in this case not really non-technicals. Ex-techies who
> have moved into management/BA roles. Smart people, not dummies. Just
> lacking in experience of FPGAs and coming from a software background.
>
> When I see a BA draw a box, label it FPGA, and start putting little
> boxes labelled with the names of software components in it, and alarm
> bell starts ringing. I need to provide them with some sort of context
> so they can begin to understand this technology more realistically.

What's a BA?  I assume this is someone who doesn't really know
anything about either software or hardware.

I guess you have figured out by now that you won't find any reading
material on this topic.  As others have said, the tradeoffs depend
greatly on the class of problem being solved.

You said your existing code is not in C.  I'm curious as to what
language it is in.  If it is a lot of code, it will likely be very
expensive to port either to C or to hardware.  What are your
alternatives with this design?  What are the BAs expecting to get out
of using FPGAs in the design?  Or do they not know enough to know what
to expect, they just think FPGAs are magic?

I am of the opinion that it is often easier to implement algorithms in
FPGAs rather than software.  Of course there is a limitation of size
when implementing things in hardware (FPGAs) and you often will find
hardware will be more effective if you use different organizations of
the solution than what you might do in software.  But I find the high
degree of design visibility in a hardware simulation to far exceed
what I get in a software simulation or emulation.  I can see every
detail of every signal.  So if I can simulate the environment
accurately, I can test my design in simulation to a high confidence
level and rapidly debug problems.

I believe you will find a wide range of opinions about where to draw
that line.  I am currently working on a small project that is
basically a time of day clock with a fancy interface to a 100 MHz
clock.  Obviously the 100 MHz interface should be done in an FPGA...
and a handful of PECL logic.  The time of day clock logic is going to
be done on a processor module called a Rabbit.  I suggested that there
is no reason that the entire project couldn't be done in the FPGA and
I know this is very easy to do.  But the engineer in charge is not so
familiar with FPGAs and sees them as large PLDs to incorporate what
you might have otherwise done with 7400 series chips if FPGAs weren't
around.  He knows enough to consider using an 8 bit embedded CPU in
the FPGA, but even that is not needed.  There is no reason at all to
not implement the full solution in FPGA logic using FSM (finite state
machines) and other functions that work equally well in both hardware
and software.

Rick

Article: 150443
Subject: Re: Overview for non-technicals.
From: "John Speth" <johnspeth@yahoo.com>
Date: Fri, 21 Jan 2011 10:35:43 -0800
Links: << >>  << T >>  << A >>
> (For those who got this far, note that a $50 FPGA can be programmed
> in seconds, where an ASIC might cost millions of dollars and take
> years to be produced.)`

You certainly must agree that that's not a useful comparison.  The 
development cost (time and wages) is roughly comparable for ASICs and FPGAs. 
Foundry costs for ASICs is where most of the cost will typically be.  Add to 
that the extra expense of pre-foundry testing to ensure the first design 
works and you get a very pricey alternative to FPGAs.

JJS



Article: 150444
Subject: Re: Overview for non-technicals.
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 21 Jan 2011 19:36:25 +0000 (UTC)
Links: << >>  << T >>  << A >>
John Speth <johnspeth@yahoo.com> wrote:
>> (For those who got this far, note that a $50 FPGA can be programmed
>> in seconds, where an ASIC might cost millions of dollars and take
>> years to be produced.)`
 
> You certainly must agree that that's not a useful comparison.  
> The development cost (time and wages) is roughly comparable for 
> ASICs and FPGAs. 

Well, you snipped out what came before, but, yes, the development
time and costs that are about the same, and so is the design
process.  

> Foundry costs for ASICs is where most of the cost will 
> typically be.  Add to that the extra expense of pre-foundry 
> testing to ensure the first design works and you get a very 
> pricey alternative to FPGAs.

Consider that I have one computer, and want to build a special
purpose processor to speed up a computational task.  I can do
it with an FPGA fairly fast, or with an ASIC much more slowly
and it will be more expensive.  When I wrote that, I even
considered dynamic reconfiguration (for the FPGA), and for
the ASIC (with the fab time included).  

The partiton between hardware and software, the digital logic
design, the speed of the resulting system, and the management
required to do the design are about the same.  Once the design 
is finished, you can, as I said, either load it into an FPGA or 
send it out to fab.

-- glen


Article: 150445
Subject: Re: Overview for non-technicals.
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 21 Jan 2011 14:20:38 -0600
Links: << >>  << T >>  << A >>
On 01/21/2011 12:35 PM, John Speth wrote:
>> (For those who got this far, note that a $50 FPGA can be programmed
>> in seconds, where an ASIC might cost millions of dollars and take
>> years to be produced.)`
>
> You certainly must agree that that's not a useful comparison.  The
> development cost (time and wages) is roughly comparable for ASICs and FPGAs.
> Foundry costs for ASICs is where most of the cost will typically be.  Add to
> that the extra expense of pre-foundry testing to ensure the first design
> works and you get a very pricey alternative to FPGAs.
But, you can't ignore RISK!  If an FPGA design doesn't work, it can be 
debugged, and unless some really fundamental design errors were made 
(not enough equivalent gates, speed too slow, etc. the design can be 
fixed, recompiled and retested, often within hours.

If there is a serious flaw in an ASIC, it may not even be possible to 
test it far enough to know where the problem is.  When your design is 
complete for an FPGA, testing can begin that day.  With an ASIC, you 
send it to the foundry and wait possibly six months or more before you
get the first part.

Jon

Article: 150446
Subject: Re: Overview for non-technicals.
From: John Adair <g1@enterpoint.co.uk>
Date: Fri, 21 Jan 2011 14:30:50 -0800 (PST)
Links: << >>  << T >>  << A >>
It's very old and still a little technical but have a look at
www.enterpoint.co.uk/seminar/Adding_Zest_To_Your_Electronics_With_Programma=
ble_FPGA_Technology.pdf
and see if that helps.

There may be some new materials later this year. It's been a long time
since we ran the last set but we are planning to run a new set of 1/2
day seminars and there will be materials for the manager level out of
that.

John Adair
Enterpoint Ltd.

On Jan 20, 10:11=A0am, "rupertlssm...@googlemail.com"
<rupertlssm...@googlemail.com> wrote:
> Hi,
>
> I've googled about a bit, but not found the perfect answer yet. Does
> anyone have any suggestions for reading material (paper or web), that
> would serve as an introductory overview of FPGAs for non-technical
> managers? Something that gives a rough idea of what typically can and
> cannot be achieved in hardware, and a sense of the difficulties and
> effort required to do so. Thats probably a lot to ask, but if you know
> of any good introductions, I would appreciate a link.
>
> Thanks for your help.
>
> Rupert


Article: 150447
Subject: Re: I Give Up!
From: Frank GOENNINGER <dg1sbg@googlemail.com>
Date: Sat, 22 Jan 2011 01:31:27 +0100
Links: << >>  << T >>  << A >>
Brian Drummond <brian_drummond@btconnect.com> writes:

> Change is probably inevitable, and maybe it's getting time for Usenet
> to go the way of the morse amateur bands, and the telegraph.
>
> Sadly.
>
> - Brian

Actually, signal to noise ratio is still a lot better here in Usenet
newsgroups because it is quite easy to filter spam with bio-visual
methods. It's a bit like morse - this is still quite alive despite the
availability of Internet and other "modern" modes...

73, Frank DG1SBG (ham radio call from Germany)


Article: 150448
Subject: Xilinx news
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sat, 22 Jan 2011 18:20:55 -0800
Links: << >>  << T >>  << A >>
http://www.eetimes.com/electronics-news/4212400/Xilinx-to-shutter-French-R-D-operation

Yikes, this explains some stuff. I wonder how long it will take to
undo the damage. Our latest projects are using Altera parts, purely
because the Xilinx software is such a train wreck.

John



Article: 150449
Subject: Re: Xilinx news
From: "krw@att.bizzzzzzzzzzzz" <krw@att.bizzzzzzzzzzzz>
Date: Sat, 22 Jan 2011 23:03:16 -0600
Links: << >>  << T >>  << A >>
On Sat, 22 Jan 2011 18:20:55 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

>http://www.eetimes.com/electronics-news/4212400/Xilinx-to-shutter-French-R-D-operation
>
>Yikes, this explains some stuff. I wonder how long it will take to
>undo the damage. 

Damage?  The damage caused by closing a software development lab?  Given their
software, it's probably a good thing.  I just tried downloading their 12.4
software last week.  It wouldn't even install.  The Avnet folks got me a DVD,
so I'll probably try that next week.

>Our latest projects are using Altera parts, purely
>because the Xilinx software is such a train wreck.

I'm using a Xilinx Coolrunner part for a very simple application, mostly
because they have package better suited to the application and our SMT line
(small and not a CsBGA).  ISE WebPack 11.1 works reasonably well but I'm not
pushing it very hard (32 flops and a half dozen I/O @ 14.7456MHz clock isn't
much of a stretch ;-).  




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search