[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] RE: Linux kernel instructions->gates
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.
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
>On Thu, 2005-08-18 at 09:42 -0700, Mike Parrish wrote:
>>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.
>>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
>>>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.
>>>>Field Applications Engineer
>>>>Nu Horizons Electronics Corp.
>>>>2070 Ringwood Avenue
>>>>San Jose, CA 95131
>>>>(408)434-0800 - office
>>>>(415)846-5837 - cell
microblaze-uclinux mailing list
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/