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

[Matthew Rubenstein <email@xxxxxxxxxxxx>]

	Any project docs? Or are you in stealth mode?


On Thu, 2005-08-18 at 19:49 -0700, Mike Parrish wrote:
> 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/
> 
> 
-- 


(C) Matthew Rubenstein

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