Overview for non-technicals.

[rupertlssmith@googlemail.]

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

 

[glen herrmannsfeldt]

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

 

[rupertlssmith@googlemail.]

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.

 

[glen herrmannsfeldt]

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

 

[rupertlssmith@googlemail.]

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.

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.

 

[Chris Maryan]

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 advanced 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 how to answer these questions for the area of products that I work on because I work on those products.

Chris

 

[rupertlssmith@googlemail.]

On Jan 20, 2:34 pm, 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 - you'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 because 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?

 

[Tim Wescott]

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

 

[Tim Wescott]

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

 

[Chris Maryan]

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 Verilog or VHDL (there are a bunch of other options, including high level languages, graphical flows, 'wizard' based flows, but they are extremely limited and usually restricted to some tiny niche). The V vs V battle has been argued to death and the applicability of one or the other generally boils down to whether engineers in your area tend to know one or the other. There is for the most part no significant difference in the usability of one or the other. Once you've settled on VHDL or Verilog, the synthesis tools are all 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

 

[glen herrmannsfeldt]

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

 

[Muzaffer Kal]

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

 

[Cees Binkhorst]

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

 

[John Speth]

(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

 

[rickman]

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

 

[Jon Elson]

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

 

[glen herrmannsfeldt]

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

 

[John Adair]

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_Programmable_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 am, "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

 

[Cees Binkhorst]

Serendipity over the week-end brought this:
http://www.ccm.nl/pdf/SAXCS-UK.pdf
http://www.cybernet.co.jp/fclib/documents/example/03_MBD_Controller.pdf

Excellent examples of what I meant to say

Regards / Cees

On 01/21/2011 10:47 AM, Cees Binkhorst wrote:

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

 

[rupertlssmith@googlemail.]

On Jan 21, 5:52 pm, rickman <gnu...@gmail.com> wrote:

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

BA = Business Analyst. In this case, with a history as a developer, so
not so clueless as is sometimes the case.