embedded linux on FPGA?

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

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.

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

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 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

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

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.

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

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

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

Since you have specifically been asking about embedded Linux on the embedded PPC processor in Virtex-II Pro and Virtex-4 I recommend you to read application note 765 that explains how to get started with EDK and Linux.

As additional reading I recommend the application note on UltraController that is kind of the other extreme of running a full-fledged operating system. UltraController is tiny and might be sufficient for your application.

- Peter

hol wrote:

Forth is very good for small embedded design.

Nice thing about Linux is you get the the TCP/IP, nfs, gdb, NTP, telnet, ssh, DHCP, DNS, file system, SNMP etc for free.

Debug complex software with gdb, strace, tcpdump in Linux running PPC is not any different than debug it on x86.

I am using Linux on VP2 ppc , once the linux is up, port NTP, DHCP, SNMP, gdb, strace, tcpdump take very little time, most of the time spent on integration and testing. Once it works, it works as reliable as gdb, tcpdump on your desktop PC.

-Tony

Forth is the perfect hacker language. Write it once and no one else will able to read it again.

Every time I follow up on a forth project, I have to re-write it in C so it can be read by future programmers.

Sorry Tony, I just don't by it.

hamilton AT dimensional DOT com

I've read far too much driver code in C to believe this. It is possible (and far too frequent) to write unreadable code in any language.

Professionally, I write Forth compilers and do applications consulting, mostly in Forth. I also have to read and write C code. One of the Forth applications I have to support is used all over the world and consists of 850,000+ lines of source code. MPE also supports a wide range of embedded applications, both large and small.

After using a wide range of programming languages for a very long time I have come to the conclusion that readability of source code has very little to do with the programming language. It has a lot to do with the attitude of the programmer and particularly of the management.

Here at MPE we use tools that extract documentation from source code. Similar tools exist for other languages, but are rarely used. This is a shame, as using good tools can dramatically affect coding style.

Stephen

-- Stephen Pelc, snipped-for-privacy@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time

133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: - free VFX Forth downloads

That is a self-perpetuating prophesy. There is nothing inherently incomprehensible about Forth, especially vs. C. It is a bit like saying Chinese is hard to learn because you learned English as a small child. When people refuse to work in Forth because there aren't many who work in Forth, you can see how that perpetuates the problem.

I can see some significant advantages to an interactive language that you can run on the target without an emulator.

--

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

Followup to: By author: snipped-for-privacy@bluepal.net In newsgroup: comp.arch.fpga

Personally, I don't buy that. I learned FORTH *way* before I learned C, and I still find FORTH code written by others much harder to read. The difference is that my brain just isn't capable of holding the layout of the stack in my head, especially since it changes from verb to verb. C and most other 3G programming languages at least attempts at forcing you to give your data items names.

The main advantage to FORTH, in my opinion, is that it is one of the very few languages which runs anywhere close to native speed, yet requires only a handful of bytes for its compiler. For embedded or microcontroller-class programming, that can be a *huge* win over having to cross-compile everything, especially, as you correctly point out, you can use FORTH as an interactive language, which among other things mean you can extract state and conduct experiments quickly.

-hpa

Here is the crux of the problem.

The OP stated that he was looking for help on a embedded system. ( orignal thread is gone and linix is not written in forth )

Yes, having experience with any language is going to create a better environment for development. However, a beginner using forth without a safty net ( i.e. mentor) is just crazy.

The projects I have followed up on were just that. Beginners trying to bet the farm an a "quick language".

My first forth was on a 6502 over 20 years ago.

Nothing has changed.

If forth works for you, great. But, if I follow up on one of your projects. It will be converted to C.

hamilton AT dimensional DOT com

Do you mean a beginniner programmer or a beginner in Forth? My first paid Forth job was a colour graphics picture editor completed in about five working days on a multi-CPU S100 system. Letting a neophyte programmer be the lead/only programmer on any job is going to be dangerous in any language.

And again the problem is beginners.

Just like nothing in C has changed. :-}

Stephen

-- Stephen Pelc, snipped-for-privacy@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time

133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: - free VFX Forth downloads

SNIP

I agree with some of the posters that you may not need an OS. If you decide to use one you should look at MicroC/OS-II

It has been ported to both PowerPC and MicroBlaze. If you can't find the particular flavor of PPC on the uCOS ports page we can help you with custom ports.

--
Scott
Validated Software Corp.

... look at gaisler.com. Regards Adam Przybyla