embedded linux on FPGA?

One of our customers will be asking us to
implement a bunch of math functions on an FPGA-boards.
There are a lot of "decisions" that affect control
processing/algorithm selection, so they specifically
requested an FPGA with "PowerPC."  (This immediately
tells me Xilinx's marketing has done an A+ job of getting
managers and other non-technical people to subconsciously
associate 'FPGA CPU' with Xilinx's Virtex2Pro product. :))

As an engineer, for me, the problem isn't the choice of
CPU; Any embedded CPU (OpenRISC, Microblaze,
Nios, etc.) would serve the purpose; as its only going
to read/write internal status/contorl registers
every few 10,000 cycles.  The problem is 'how to run
the software app' on the CPU.

Now for my awkward question. I've never done this kind of
'embedded' development before, so I have no clue as to
the normal development flow.

In digging around a few enthusiast websites, I think I
the normal flow requires
   a) 'embedded O/S' (running on the embedded CPU target)
   b) development tools (C-compiler to target the CPU)
   c) your own custom files (for defining I/O ports,
      application hardware, etc.)

It sounds all very complicated to me.  Can I "skip" the
embedded O/S?  I'm just read/writing some registers, not
trying to access a TCP/IP network or USB-filesystem.

I'm an ASIC engineer (mostly RTL Verilog coder) by training,
so I know my way around hardware development.

So, what do you guys recommend to the novice embedded engineer?
Is the Xilinx EDK a good choice?  What about the 'OpenRISC'
CPU on opencores.org?

> There are a lot of "decisions" that affect control
> processing/algorithm selection, so they specifically
> requested an FPGA with "PowerPC."  (This immediately

When the customer hands me a hammer, this is usually a danger flag.

> As an engineer, for me, the problem isn't the choice of
> CPU; Any embedded CPU (OpenRISC, Microblaze,
> Nios, etc.) would serve the purpose; as its only going
> to read/write internal status/contorl registers
> every few 10,000 cycles.  The problem is 'how to run
> the software app' on the CPU.

Well, of course you can write down-to-the-metal code on any CPU, an OS
is not absolutely necessary. However, the "lots of math" specification
points me to you probably wanting a DSP, or custom logic implementing
the functions in question. Since this is an _F_PGA (after all...) you
can always add new algorithms later, no?

The question of OS choice generally begins "What features do you expect
to get from this OS?" and from the sounds of things, an OS would just
get in the way for you.

Lewin A.R.W. Edwards wrote:

> The question of OS choice generally begins "What features do you
> expect to get from this OS?" and from the sounds of things, an OS
> would just get in the way for you.

I would have to agree. I'm actually from a software background and from 
the sounds of what you're doing, an OS (especially something like linux) 
would be extreme overkill, extend the development, increase the product 
cost and probably result in a less robust product.

I'd stick with a small (customisable) RISC core which will allow you to 
use a smaller device and easier glue to the core if you can configure 
the I/O on it. Doing a bit of 'math' every 10,000 cycles shouldn't 
require a DSP I wouldn't have thought?!?

Regards,
Mark

Mark McDougall wrote:
> Lewin A.R.W. Edwards wrote:
> 
>> The question of OS choice generally begins "What features do you
>> expect to get from this OS?" and from the sounds of things, an OS
>> would just get in the way for you.
> 
> 
> I would have to agree. I'm actually from a software background and from 
> the sounds of what you're doing, an OS (especially something like linux) 
> would be extreme overkill, extend the development, increase the product 
> cost and probably result in a less robust product.

I agree with this but i'me not an expert (just doing research on this 
for a project currently).

The Stratix2 has some embedded DSP cells that might do the trick.

Honnestly if your doing 'lots of math' to me that means 'most likley 
floating poing'.  That can be hard to implement on an fpga.

> I'd stick with a small (customisable) RISC core which will allow you to 
> use a smaller device and easier glue to the core if you can configure 
> the I/O on it. Doing a bit of 'math' every 10,000 cycles shouldn't 
> require a DSP I wouldn't have thought?!?

I agree also.  What kind of "Math" are you doing? IS this a control 
system? If so there might be better tools to do the job.

Does it have to be exactly 10K cycles? if so linux is not a RT operating 
system (you would have to RTlinux patch it).  "Math" is a big field. 
Doing simple additions would be easy to do in an fpga.  Doing 
non-numerical integration would be very hard on an FPGA but is possible 
to do on a CPU because they are faster at doing AI stuff.

Can you give us a hint of what kind of math will be done?

Thanks
Andre,

My first bit of advice is take what you get on these
newsgroups with a grain of salt. Some of the responses
I've seen have basically advised you to tell your customer to
bugger-off with the PPC idea. Tactically, that seems
like questionable advice to me.

In fact, your posting implied that you were ok with the
PPC, and just wondering about the OS/tools. Let me address
that:

Some things to consider:
   1) What is the startup time from power-on? An OS
   like Linux can easily add several seconds to the
   power-on time-line, depending on how much
   effort you want to spend to minimize initialization.

   2) There are several OS's but Vxworks from Wind River,
   Integrity from Green Hills Software, and embedded Linux
   are probably the primary choices. If you are concerned about
   royalty costs, some flavors of Linux are probably going
   to be the cheapest approach. (You didn't say if you were
   particularly cost sensitive).

  3) It doesn't sound like your application needs much in the
  way of OS support with the possible exception of a periodic
  delay.   That can be done pretty easily with a timer channel.

  4) A nice benefit of an OS is the ease by which you can
  develop. For example, OS's often have the ability to automatically
  collect timing data, or download images via Ethernet. You can
  usually have several executables installed that you can switch between
  or even run both at the same time and compare the results. If your
  algorithm development is going to need a lot of tweaking on
  the target, an OS may have some benefit. However, if you can
  do the algorithm modeling on a development workstation,
  that is probably preferred and just use the EDK to download
  to a 'bare' the target via the parallel port.

  Do you know how many lines of software you expect to develop?
  "A bunch of math functions" could be a chess game or a robotics
  application.

-bh


"hol" <abol@hol.com> wrote in message
news:MrI5d.20255$QJ3.5247@newssvr21.news.prodigy.com...
> One of our customers will be asking us to
> implement a bunch of math functions on an FPGA-boards.
> There are a lot of "decisions" that affect control
> processing/algorithm selection, so they specifically
> requested an FPGA with "PowerPC."  (This immediately
> tells me Xilinx's marketing has done an A+ job of getting
> managers and other non-technical people to subconsciously
> associate 'FPGA CPU' with Xilinx's Virtex2Pro product. :))
>
> As an engineer, for me, the problem isn't the choice of
> CPU; Any embedded CPU (OpenRISC, Microblaze,
> Nios, etc.) would serve the purpose; as its only going
> to read/write internal status/contorl registers
> every few 10,000 cycles.  The problem is 'how to run
> the software app' on the CPU.
>
> Now for my awkward question. I've never done this kind of
> 'embedded' development before, so I have no clue as to
> the normal development flow.
>
> In digging around a few enthusiast websites, I think I
> the normal flow requires
>    a) 'embedded O/S' (running on the embedded CPU target)
>    b) development tools (C-compiler to target the CPU)
>    c) your own custom files (for defining I/O ports,
>       application hardware, etc.)
>
> It sounds all very complicated to me.  Can I "skip" the
> embedded O/S?  I'm just read/writing some registers, not
> trying to access a TCP/IP network or USB-filesystem.
>
> I'm an ASIC engineer (mostly RTL Verilog coder) by training,
> so I know my way around hardware development.
>
> So, what do you guys recommend to the novice embedded engineer?
> Is the Xilinx EDK a good choice?  What about the 'OpenRISC'
> CPU on opencores.org?

"Andre Bonin" <Yoyoma_2@[at-]Hotmail.com> wrote in message
news:4TK5d.120311$%S.55720@pd7tw2no...
> Mark McDougall wrote:
> > Lewin A.R.W. Edwards wrote:
> >
> >> The question of OS choice generally begins "What features do you
> >> expect to get from this OS?" and from the sounds of things, an OS
> >> would just get in the way for you.
> >
> >
> > I would have to agree. I'm actually from a software background and from
> > the sounds of what you're doing, an OS (especially something like linux)
> > would be extreme overkill, extend the development, increase the product
> > cost and probably result in a less robust product.
>
> I agree with this but i'me not an expert (just doing research on this
> for a project currently).
>
> The Stratix2 has some embedded DSP cells that might do the trick.
>
> Honnestly if your doing 'lots of math' to me that means 'most likley
> floating poing'.  That can be hard to implement on an fpga.
>

Floating point is not hard - fast, high-resolution, compact floating point
is hard.  If you are looking at doing "some" maths every 10,000 cycles, then
any decent 32-bit risc cpu can handle it in software without breaking a
sweat.  From the programmer's viewpoint, the software code is the same.

> > I'd stick with a small (customisable) RISC core which will allow you to
> > use a smaller device and easier glue to the core if you can configure
> > the I/O on it. Doing a bit of 'math' every 10,000 cycles shouldn't
> > require a DSP I wouldn't have thought?!?
>

I think you are best looking at ready-to-run setups, and almost certainly
using a soft cpu.  Forget the Virtex embedded PPC unless you have real,
concrete figures showing that it is necessary - I'm sure there are many
applications where they are highly suitable, but the PPC is a beast of a
processor to work with, and your chips and tools are going to be very
expensive.  These particular chips are clocked at a few hundred MHz (IIRC),
but they have no floating point, so they have to use software.  If you pick
a soft cpu, you can add floating point hardware as needed in the fpga
structure, and have it running the maths much faster than the ppc.

I can't talk about Xilinx Microblaize, having never tried it, but I think
you'd find the Altera Nios II at least as easy as anything else around.  Buy
a developer kit, and you get a board and all the software and tools you
need.  I don't think you need an OS for this project - but if you want one,
there is well-integrated support for uC/OS-II (although you'd need to by a
license seperately), and you can download ucLinux support.


> I agree also.  What kind of "Math" are you doing? IS this a control
> system? If so there might be better tools to do the job.
>
> Does it have to be exactly 10K cycles? if so linux is not a RT operating
> system (you would have to RTlinux patch it).  "Math" is a big field.
> Doing simple additions would be easy to do in an fpga.  Doing
> non-numerical integration would be very hard on an FPGA but is possible
> to do on a CPU because they are faster at doing AI stuff.
>
> Can you give us a hint of what kind of math will be done?
>
> Thanks
> Andre,

hol wrote:

> One of our customers will be asking us to
> implement a bunch of math functions on an FPGA-boards.
> There are a lot of "decisions" that affect control
> processing/algorithm selection, so they specifically
> requested an FPGA with "PowerPC."  (This immediately
> tells me Xilinx's marketing has done an A+ job of getting
> managers and other non-technical people to subconsciously
> associate 'FPGA CPU' with Xilinx's Virtex2Pro product. :))
> 
> As an engineer, for me, the problem isn't the choice of
> CPU; Any embedded CPU (OpenRISC, Microblaze,
> Nios, etc.) would serve the purpose; as its only going
> to read/write internal status/contorl registers
> every few 10,000 cycles.  The problem is 'how to run
> the software app' on the CPU.
> 
> Now for my awkward question. I've never done this kind of
> 'embedded' development before, so I have no clue as to
> the normal development flow.
> 
> In digging around a few enthusiast websites, I think I
> the normal flow requires
>   a) 'embedded O/S' (running on the embedded CPU target)
>   b) development tools (C-compiler to target the CPU)
>   c) your own custom files (for defining I/O ports,
>      application hardware, etc.)
> 
> It sounds all very complicated to me.  Can I "skip" the
> embedded O/S?  I'm just read/writing some registers, not
> trying to access a TCP/IP network or USB-filesystem.
> 
> I'm an ASIC engineer (mostly RTL Verilog coder) by training,
> so I know my way around hardware development.
> 
> So, what do you guys recommend to the novice embedded engineer?
> Is the Xilinx EDK a good choice?  What about the 'OpenRISC'
> CPU on opencores.org?

Hi Hol,

After very good answers (IMO) depending your OS questions I will try to 
give You some hints about Xilinx Virtex2-Pro and EDK.

1. The EDK contains lots of IP-Cores important to build an Embedded 
System inside Your Xilinx FPGA (i.e. Microblaze, Bus-Interfaces, 
DRAM-Controller, Flash-Interface, UART, ...). The important cores are 
free, some cores have costs (i.e. Ethernet, FullFunction-UART, ...).
2. The EDK comes with the GNUCompilerConnection for PPC and Microblaze, 
including also Debug-Tools who are essentially for every SW-Developer!
3. Without the EDK You will have big trouble to implement a PPC-System 
because of missing Bus-Interfaces and other environmental things needed 
to get the PPC working. I don't say it doesn't work and it doesn't make 
sense in some cases, but it definitely makes a lot of work to build a 
PPC-System inside the XC2VP without support from EDK.
4. The EDK brings You libraries for the IP-Cores which speed up the 
Programming process. This is a good thing and works most times. But like 
every SW it has sometimes problems.
5. The EDK tries (more and more with every version :-) to keep HW- and 
SW-Designflow together which is not trivial if You do it on Your own.

Fazit: If You want to do an Embedded System on an Xilinx FPGA don't 
start without EDK. If You know exectly that some easy register moving 
and BitManipulation is everything you want to do, writing an Application 
without OS could work for you. Positive Sideeffekt: Small Applikations 
fit often in BlockRAMs (less external components). If you need things 
like networking, multitasking, graphics, ... don't try it on yourself, 
use the right OS for your type of applications.

Hope this helps,

Michael



-- 
Notice: If You want to send me an E-Mail please remove the abc and xyz 
from my address.

hol wrote:
> One of our customers will be asking us to
> implement a bunch of math functions on an FPGA-boards.
> There are a lot of "decisions" that affect control
> processing/algorithm selection, so they specifically
> requested an FPGA with "PowerPC."  (This immediately
> tells me Xilinx's marketing has done an A+ job of getting
> managers and other non-technical people to subconsciously
> associate 'FPGA CPU' with Xilinx's Virtex2Pro product. :))
> 
> As an engineer, for me, the problem isn't the choice of
> CPU; Any embedded CPU (OpenRISC, Microblaze,
> Nios, etc.) would serve the purpose; as its only going
> to read/write internal status/contorl registers
> every few 10,000 cycles.  The problem is 'how to run
> the software app' on the CPU.

I have to wonder if a DSP wouldn't be a better
and cheaper solution.

> Now for my awkward question. I've never done this kind of
> 'embedded' development before, so I have no clue as to
> the normal development flow.
> 
> In digging around a few enthusiast websites, I think I
> the normal flow requires
>   a) 'embedded O/S' (running on the embedded CPU target)
>   b) development tools (C-compiler to target the CPU)
>   c) your own custom files (for defining I/O ports,
>      application hardware, etc.)
> 
> It sounds all very complicated to me.  Can I "skip" the
> embedded O/S?  I'm just read/writing some registers, not
> trying to access a TCP/IP network or USB-filesystem.
> 
> I'm an ASIC engineer (mostly RTL Verilog coder) by training,
> so I know my way around hardware development.
> 
> So, what do you guys recommend to the novice embedded engineer?
> Is the Xilinx EDK a good choice?  What about the 'OpenRISC'
> CPU on opencores.org?

hol wrote:

> One of our customers will be asking us to
> implement a bunch of math functions on an FPGA-boards.
> There are a lot of "decisions" that affect control
> processing/algorithm selection, so they specifically
> requested an FPGA with "PowerPC."  (This immediately
> tells me Xilinx's marketing has done an A+ job of getting
> managers and other non-technical people to subconsciously
> associate 'FPGA CPU' with Xilinx's Virtex2Pro product. :))

Just get a board with the VirtexIIPro on it, and try to use
it. It is not difficult at all. I had the VirtexIIPro Eval Board
from Avnet, and I was pretty happy with it. It is less then $1000,
and includes the boards, linux and EDK, so if you have a working linux
box, you can start in few minutes compiling your own kernels.

BTW, if you don't like (I have no idea why you wouldn't, but) the 
PowerPC core, you can still use the microblaze on the same chip.

just my .0000002

hol wrote:
> 
> One of our customers will be asking us to
> implement a bunch of math functions on an FPGA-boards.
> There are a lot of "decisions" that affect control
> processing/algorithm selection, so they specifically
> requested an FPGA with "PowerPC."  (This immediately
> tells me Xilinx's marketing has done an A+ job of getting
> managers and other non-technical people to subconsciously
> associate 'FPGA CPU' with Xilinx's Virtex2Pro product. :))
> 
> As an engineer, for me, the problem isn't the choice of
> CPU; Any embedded CPU (OpenRISC, Microblaze,
> Nios, etc.) would serve the purpose; as its only going
> to read/write internal status/contorl registers
> every few 10,000 cycles.  The problem is 'how to run
> the software app' on the CPU.
> 
> Now for my awkward question. I've never done this kind of
> 'embedded' development before, so I have no clue as to
> the normal development flow.
> 
> In digging around a few enthusiast websites, I think I
> the normal flow requires
>    a) 'embedded O/S' (running on the embedded CPU target)
>    b) development tools (C-compiler to target the CPU)
>    c) your own custom files (for defining I/O ports,
>       application hardware, etc.)
> 
> It sounds all very complicated to me.  Can I "skip" the
> embedded O/S?  I'm just read/writing some registers, not
> trying to access a TCP/IP network or USB-filesystem.
> 
> I'm an ASIC engineer (mostly RTL Verilog coder) by training,
> so I know my way around hardware development.
> 
> So, what do you guys recommend to the novice embedded engineer?
> Is the Xilinx EDK a good choice?  What about the 'OpenRISC'
> CPU on opencores.org?

Now that everyone else has given you their opinion, let me offer mine. 
This is just the sort of app where I would seriously consider Forth. 
You may not need an OS, but an OS can often help ease any IO and
scheduling you may end up performing.  Forth is a language which also
includes the basic functions of an OS.  It also provides basic debug
features.  You can easily do your full development without ever needing
an emulator.  

One other feature is that a Forth kernal can include the full compiler. 
So you can boot into an embedded app, or you can boot the kernal and
quickly compile the app at startup.  Then updates can be done at a
source level!  

But the best part is that a full Forth kernal can be well under 64 KB,
even as small as 16 KB!  Try that with Linux!!!

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX