Re: [microblaze-uclinux] RE: Linux kernel instructions->gates

[Mike Parrish <mparrish@xxxxxxxxxxx>]

We're working on the Spartan 3 dev kit from NuHorizons, pending 
availability *sigh*, or perhaps a Memec solution... targetting MB/uCL.

There's no reason that any other uP/FOSS OS/HW target couldn't be 
adapted from this work. I'd imagine that system profiling would show 
similar usage of certain OS services.

We're in Morgan Hill, California.

Regards,
Mike

Matthew Rubenstein wrote:

>	Does your group have any more detailed documentation of your project?
>Is the platform the PPC/FPGA  from Xilinx + MB/uCL (or full/MMU Linux),
>the "pure" FPGA MB/uCL, or something else? Where are you working on
>this?
>
>
>On Thu, 2005-08-18 at 09:42 -0700, Mike Parrish wrote:
>  
>
>>Hi Matt,
>>
>>This is exactly what our group is in the process of doing.
>>Any OS service that bogs the processor can be removed from the SW build, 
>>replaced with a VHDL model and accessed through stub APIs that retain 
>>the original API calling conventions.
>>
>>Synchronization and pipleining are the big bugaboos to be worked out.
>>
>>This technique should vastly speed the processor and overall system 
>>performance by making large OS services concurrent and by reducing the 
>>CPU's executable instructions.
>>
>>Regards,
>>Mike
>>
>>
>>Matthew Rubenstein wrote:
>>
>>    
>>
>>>	That's an interesting resource. What I'm really looking for is an
>>>example of factoring out an "instructions" feature of uCL, like the
>>>ethernet kernel module, into a function implemented as gates in the
>>>FPGA. Then removing that module from the uCL - leaving just its stub
>>>that "calls" the gates.
>>>
>>>	That *technique* could make something like MB/uCL a "migration
>>>platform" for the OS, selectively optimizing parts of the OS, perhaps
>>>even on an application demand basis. Start with "stock" uCL, factor a
>>>driver to gates, drop the factored module from the kernel. While a
>>>PPC/FPGA uCL is a good start, MB/uCL is ultimately even better, because
>>>the interface between the uCL code and the FPGA can be expanded beyond
>>>the bottleneck, just by adding registers etc to the MB config.
>>>
>>>	It doesn't sound like anyone on this list has seen that technique yet.
>>>I'll keep filtering the traffic until I think I see its glint
>>>sometime :).
>>>
>>>
>>>On Wed, 2005-08-17 at 07:27 -0700, David Banas wrote:
>>> 
>>>
>>>      
>>>
>>>>There's a new TCP/IP stack co-processing IP core that Xilinx just released.
>>>>Supposedly, it's capable of 900 Mbps throughput.
>>>>
>>>>David Banas
>>>>Field Applications Engineer
>>>>Nu Horizons Electronics Corp.
>>>>2070 Ringwood Avenue
>>>>San Jose, CA 95131
>>>>(408)434-0800 - office
>>>>(415)846-5837 - cell
>>>>http://www.nuhorizons.com
>>>>  
>>>>


___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/