Linux on Microblaze

["Followup-To:" header set to comp.arch.fpga.]
On 2008-11-10, David Brown <david@westcontrol.removethisbit.com> wrote:
> I'd like to see something like that too.  The only one I can think of is 
> Atmel's FPSLIC's, which are an FPGA with an AVR core.  But they don't 
> really do the same thing - the AVR core is like an add-on hard-core in a 
> small FPGA.  I'd prefer something that had the convenience and easy of 
> use of a normal AVR device (or similar small micro), but with some 
> programmable logic built-in to off-load the processor for fast I/O or 
> calculation acceleration.  A hundred or so CPLD macrocells would be 
> enough for many situations.

You might be interested in PSoC. I don't know much about this but from
the marketing material I've read it might have roughly the functionality
you want (even though it doesn't really have an embedded CPLD or FPGA).

/Andreas

Andreas Ehliar wrote:
> ["Followup-To:" header set to comp.arch.fpga.]
> On 2008-11-10, David Brown <david@westcontrol.removethisbit.com> wrote:
>> I'd like to see something like that too.  The only one I can think of is 
>> Atmel's FPSLIC's, which are an FPGA with an AVR core.  But they don't 
>> really do the same thing - the AVR core is like an add-on hard-core in a 
>> small FPGA.  I'd prefer something that had the convenience and easy of 
>> use of a normal AVR device (or similar small micro), but with some 
>> programmable logic built-in to off-load the processor for fast I/O or 
>> calculation acceleration.  A hundred or so CPLD macrocells would be 
>> enough for many situations.
> 
> You might be interested in PSoC. I don't know much about this but from
> the marketing material I've read it might have roughly the functionality
> you want (even though it doesn't really have an embedded CPLD or FPGA).
> 
> /Andreas

(Please don't set followup-to headers unless you really have a good 
reason for it - this thread is equally at home in both c.a.f. and c.a.e.)

The PSoC is certainly an interesting architecture.  I haven't used them, 
so I am basing my opinion on reading datasheets and application notes 
rather than experience - I hope I'll be corrected if I'm wrong here.

The PSoCs digital blocks are very limited - they are basically glorified 
8-bit timer/counters with internal connections to other blocks (the AVR 
XMega have this too).  There are also *far* too few digital blocks - 4 
8-bit timer/counters is not much, especially as a 16-bit timer takes two 
blocks, as does a full-duplex uart channel (with no extra buffering).  I 
am also not too impressed by the cpu core.

The analogue blocks are more exciting - there are not many alternative 
ways to get that sort of flexibility.  I think if you view the PSoC 
devices as configurable analogue input/output devices, in which the 
digital blocks and the cpu are simply there to enhance the analogue 
blocks, then it becomes a more interesting device.

David Brown <david@westcontrol.removethisbit.com> writes:
>
> The analogue blocks are more exciting - there are not many alternative
> ways to get that sort of flexibility.  I think if you view the PSoC
> devices as configurable analogue input/output devices, in which the
> digital blocks and the cpu are simply there to enhance the analogue
> blocks, then it becomes a more interesting device.

The analogue blocks are pretty good, if a bit slow. The whole thing eats
power like 74S was back in fashion, in our experience :-)

Also, the smallest package sizes are massively under-resourced in terms
of blocks available. 2-4 times as many and it would be a really useful
item...


-- 
rich walker         |  Shadow Robot Company | rw@shadowrobot.com
technical director     251 Liverpool Road   | skype: rich_at_shadow
need a Hand?           London  N1 1LX       | +44 20 7700 2487
http://www.shadowrobot.com/hand/

"Eric Smith":
> "guestuser1" <guestuser1@nowhere.net> writes:
>> *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II)  is so slow,
>> why would you even try to run a full Linux (MMU) kernel on it?
> 
> Sometimes you need the MMU more than you need the performance.  Otherwise
> we'd all be running uCLinux on our x86 boxes.

What's the difference between uClinux and win32?

Gruss

Jan Bruns

Jan Bruns wrote:
> "Eric Smith":
>> "guestuser1" <guestuser1@nowhere.net> writes:
>>> *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II)  is so slow,
>>> why would you even try to run a full Linux (MMU) kernel on it?
>> Sometimes you need the MMU more than you need the performance.  Otherwise
>> we'd all be running uCLinux on our x86 boxes.
> 
> What's the difference between uClinux and win32?
> 

The main differences between uCLinux and full Linux are that full Linux 
implements fork (uCLinux has just vfork, or fork+exec), it properly 
separates the memory space and resources of the kernel and each user 
process from each other, it supports virtual memory, and it has much 
more flexible and efficient dynamic memory allocation.

Mind you, when you look at Win32 (especially earlier versions, but still 
relevant for later windows versions), you don't have a proper fork, user 
processes and the kernel are not properly separated from each other, and 
the virtual memory handling is terrible.

So I see your point - there is not much difference between uCLinux and 
Win32....

"Jan Bruns" <testzugang_janbruns@arcor.de> writes:
> What's the difference between uClinux and win32?

uClinux is an operating system derived from Linux.

Win32 is not an operating system or product.  It is a set of APIs
provided by multiple operating systems from Microsoft, and in some
cases by alternative products such as Wine and Wind/U.