Overview for non-technicals.

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

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

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.

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

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.

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

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

rupertlssmith@googlemail.com <rupertlssmith@googlemail.com> wrote:
> On Jan 20, 10:57&#4294967295;am, glen herrmannsfeldt <g...@ugcs.caltech.edu>
> wrote:
>> But the word "software" in your statement does
>> bother me. &#4294967295;There are people that believe that FPGAs are the
>> solution to many software problem. &#4294967295;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

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

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