best evm for virtex-4 and linux

Hi Clark,

Anonymous wrote:

> That's interesting. So if I have an FX12 part, for example, your suggestion
> is that I run uclinux in a soft core and implement my DSP code in the PPC
> core? This is the opposite of what I had expected.

As Antti says, you could invert your expectation and do the Linux on
MicroBlaze, and an ultra-controller type design on the PPC.  Or better
still, nothing beats FPGA logic for DSP performance.  Why not do your
DSP in hardware, make use of those lovely programmable gates, and do the
control/interface logic in SW on a MicroBlaze.  V4-LX parts are (will
be?) cheaper than FX, for equivalent gate counts.  The PPC does not come
for free.

> What do I give up for ucLinux versus PPC Linux? Speed? Device driver
> support?

MicroBlaze uClinux is slower than PPC Linux, but as the MicroBlaze bus
and memory architecture evolves, we are catching up.

> Also, what's your suggestion for unit control? I imagined a webserver
 interfaced to some type of CGI. Maybe perl scripts or php?

Sure, the default mb-uclinux bulid has a webserver in it, adding CGI
apps is simple.  Someone's ported PHP to uClinux before, but it might be
overkill.  I haven't tried Perl, but I did port a recent Python
interpreter to mb-uclinux - performance was pretty ordinary. Better off
in C, I think.

Feel free to contact me in "commercial mode" to discuss in more detail -
john.williams@petalogix.com

Regards,

John

John,

     Is it true that uCLinux does not have protected kernel memory?
A simple programming loop index comparision error can wipe out the
system memory including kernel.

     If this is the case, have you seen this kind of problem with
uCLinux.?
Do you think this is a real issues for uCLinux + microbraze
environment?

     I had to deal with this kind of problems in vxWorks days, it was
a nightmare.    A few bugs that is trivial (gdb the core dump) for the
protected kernel environment took a team of sw engineers 2 months
to reproduce and solved.


    I am using PPC with Linux and it has been a joy to use.  There
were one bugs shows up in test group that crash one program - first
crash in 6 months.    It is solved in 5 mintues after looking a the
core 
dump.


     -Tony

On 2006-01-16, tony.p.lee@gmail.com <tony.p.lee@gmail.com> wrote:
> John,
>
>      Is it true that uCLinux does not have protected kernel memory?
> A simple programming loop index comparision error can wipe out the
> system memory including kernel.

Yes, that's the point of uCLinux, to support machines
that have a flat address space.

> I had to deal with this kind of problems in vxWorks days, it was
> a nightmare.

Me too, man.

> I am using PPC with Linux and it has been a joy to use.  There
> were one bugs shows up in test group that crash one program - first
> crash in 6 months.    It is solved in 5 mintues after looking a the
> core dump.

So choose a processor supported by (non-uC) Linux.
There are a dozen architectures to choose from.
Leon Sparc can target an FPGA, I'm pretty sure it
has virtual memory.  Presumably slower and bigger
than microBlaze for FPGA work, but it should be more
reliable from your perspective.

      - Larry

Hi Tony,

tony.p.lee@gmail.com wrote:

>      Is it true that uCLinux does not have protected kernel memory?
> A simple programming loop index comparision error can wipe out the
> system memory including kernel.

Yes, that's true.  The "uC" in uClinux implies no MMU, so no memory
mapping or protection.

>      If this is the case, have you seen this kind of problem with
> uCLinux.?
> Do you think this is a real issues for uCLinux + microbraze
> environment?

It is no more of an issue for uClinux + MicroBlaze than for any of the
other uClinux targets out there.  You could argue that the millions of
deployed uClinux devices out there say it's not a major issue.

More helpfully, however, because it's all Linux, you can debug your app
code on a desktop machine, where coredumps etc will be able to help find
these kinds of errors.  You might need stub device drivers for embedded
peripherals, but this is not a major task.

Bugs in kernel drivers are always going to hurt.  Even with MMU a driver
bug can bring down the kernel.

>      I had to deal with this kind of problems in vxWorks days, it was
> a nightmare.    A few bugs that is trivial (gdb the core dump) for the
> protected kernel environment took a team of sw engineers 2 months
> to reproduce and solved.

The use of a desktop linux environment as a prototyping / development /
simulation environment can really help here.

>     I am using PPC with Linux and it has been a joy to use.  There
> were one bugs shows up in test group that crash one program - first
> crash in 6 months.    It is solved in 5 mintues after looking a the
> core dump.

No doubt.  There are many factors to consider when choosing a CPU, and
operating system.  If board costs are tight, PPC simply may not be an
option.  You can put a MicroBlaze Linux system + app-specific logic in a
Spartan3-400 + DRAM - that can be pretty compelling.

Regards,

John

Sounds good. 

Thanks a lot for the info,  John.

-Tony

John Williams wrote:

> Hi Tony,
> 
> tony.p.lee@gmail.com wrote:
> 
>>      Is it true that uCLinux does not have protected kernel memory?
>> A simple programming loop index comparision error can wipe out the
>> system memory including kernel.
> 
> Yes, that's true.  The "uC" in uClinux implies no MMU, so no memory
> mapping or protection.

That's not true for uClinux in general. If your target has MMU uClinux
can/will use it.
Take a look at the uClinux source tree and you'll find all kinds of
targets with or without MMU.

Just to be clear: The PPC in Virtex-4 DOES have the MMU, right?

"Larry Doolittle" <ldoolitt@localhost.localdomain> wrote in message
news:slrndso1rb.d3k.ldoolitt@localhost.localdomain...
> On 2006-01-16, tony.p.lee@gmail.com <tony.p.lee@gmail.com> wrote:
> > John,
> >
> >      Is it true that uCLinux does not have protected kernel memory?
> > A simple programming loop index comparision error can wipe out the
> > system memory including kernel.
>
> Yes, that's the point of uCLinux, to support machines
> that have a flat address space.
>
> > I had to deal with this kind of problems in vxWorks days, it was
> > a nightmare.
>
> Me too, man.
>
> > I am using PPC with Linux and it has been a joy to use.  There
> > were one bugs shows up in test group that crash one program - first
> > crash in 6 months.    It is solved in 5 mintues after looking a the
> > core dump.
>
> So choose a processor supported by (non-uC) Linux.
> There are a dozen architectures to choose from.
> Leon Sparc can target an FPGA, I'm pretty sure it
> has virtual memory.  Presumably slower and bigger
> than microBlaze for FPGA work, but it should be more
> reliable from your perspective.
>
>       - Larry

Kees,

Kees Bakker wrote:
> John Williams wrote:
> 
> 
>>tony.p.lee@gmail.com wrote:
>>
>>>     Is it true that uCLinux does not have protected kernel memory?
>>>A simple programming loop index comparision error can wipe out the
>>>system memory including kernel.
>>
>>Yes, that's true.  The "uC" in uClinux implies no MMU, so no memory
>>mapping or protection.
> 
> That's not true for uClinux in general. If your target has MMU uClinux
> can/will use it.
> Take a look at the uClinux source tree and you'll find all kinds of
> targets with or without MMU.

I'm afraid that's not correct.  The uClinux source tree has all those
arches in it because it is a direct import of the most recent 2.4 kernel
(current 2.4.31).

The only real difference between a vanilla linux kernel tree, and a
uclinux kernel tree is the directory linux-2.4.x/mmnommu.  For uClinux
builds (when NOMMU is defined), this subdir is built, rather than
linux-2.4.x/mm.  Simple as that, the rest is essentially arch-specific
details.

uClinux only giveth - it taketh not away from the regular kernel :)

For 2.6, uClinux no-MMU support is in the mainline kernel -
linux-2.6.x/mm/nommu.c

It is possible to run uClinux on MMU hardware, such as i386 and ARM -
the MMU is just not enabled, and everything runs in a flat address space.

The ARM noMMU maintainer has done some interesting work comparing
uClinux vs regular Linux on an MMU-enabled ARM CPU - he found that
context switch time was an order of magnitude better using uClinux than
regular Linux:

http://opensrc.sec.samsung.com/document/uc-linux-04_sait.pdf

Anyway this is all going way OT for c.a.fpga

Regards,

John

> Yes, that's the point of uCLinux, to support machines
> that have a flat address space.

>> I had to deal with this kind of problems in vxWorks days, it was
>> a nightmare.
>
>Me too, man.

I don't think the problem is the shape of the address space, it's
the read/write protection and a user/system mode bit.

I've written a lot of code that ran without memory protection
and we didn't have any serious problems.  The trick is to use
a compiler with (very) strong type checking and that excludes
pointer arithmetic.  That catches almost all the memory smashing
type bugs at compile time.  Much easier to find/fix them that way.

I remember my early days with type checking.  I was writing code
without really understanding what was going on.  One night the
compiler slapped my wrist because I had forgotten a layer of
indirection and I (finally) figured out what was going on.
"Thank you, thank you, thank you" oh compiler.  That would
have been a real pain to debug.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.