embedded linux on FPGA?

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.

http://direct.xilinx.com/bvdocs/appnotes/xapp765.pdf
http://www.xilinx.com/bvdocs/appnotes/xapp672.pdf

- Peter



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?

rickman <spamgoeshere4@yahoo.com> wrote in message news:<4158414E.24D9E354@yahoo.com>...
> 
> 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

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

T Lee wrote:
> 
> Forth is very good for small embedded design.
> 
> -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

On Wed, 29 Sep 2004 20:57:30 -0600, hamilton
<hamilton@deminsional.com> wrote:

>> Forth is very good for small embedded design.
>
>Forth is the perfect hacker language.
>Write it once and no one else will able to read it again.
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, stephenXXX@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: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

hamilton wrote:
> 
> T Lee wrote:
> >
> > Forth is very good for small embedded design.
> >
> > -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.

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:  <415C6D4D.85048A9B@yahoo.com>
By author:    john@bluepal.net
In newsgroup: comp.arch.fpga
> 
> 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.  
> 

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.

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

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

H. Peter Anvin wrote:
>>When people refuse to work in Forth because there aren't many who work
>>in Forth, you can see how that perpetuates the problem.  
>>
> 
> 
> 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.

	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

On Thu, 30 Sep 2004 16:45:48 -0600, hamilton
<hamilton@deminsional.com> wrote:

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

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.

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

And again the problem is beginners.

>	My first forth was on a 6502 over 20 years ago.
>
>	Nothing has changed.

Just like nothing in C has changed. :-}

Stephen

--
Stephen Pelc, stephenXXX@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: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

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
 > In digging around a few enthusiast websites, I think I
> the normal flow requires
 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 (www.ucos-ii.com) 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. 

In comp.arch.embedded hol <abol@hol.com> 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.
	... look at gaisler.com. Regards
								Adam Przybyla