Re: [microblaze-uclinux] FPGA apps?

[Matthew Rubenstein <email@xxxxxxxxxxxx>]

On Thu, 2004-04-01 at 23:29, John Williams wrote:
> Hi Matthew,

Hi John, et al :).


> Matthew Rubenstein wrote:
> 
> > 	Where are the apps? Linux on FPGA is a means to an end, not an end in
> > itself: familiar development environment for new FPGA tools. Is there an
> > archive of apps that run under MicroBlaze? With MicroBlaze omitting
> > fork() in favor of vfork() (inherited from uCLinux, with no MMU), even
> > the ancient Unix multitasking patterns are unavailable. But the
> > inherently parallel FPGA architecture offers a vastly superior
> > environment for parallelism.
> 
> Currently I think the most common use of FPGAs is as a convenient dev 
> platform, rather than utilising the reconfigurable nature of FPGAs 
> themselves.

	That convenience is the best first step towards taking over the
mindshare of developers, and therefore applications, so therefore actual
human users, who finally matter. But that convenience is due to the
integration of the OS and the reconfig environment, which is the
beginning of a usable platform in which techniques of each worldview can
be brought to bear on the new applications.


> As for uClinux and its lack of fork etc, that hasn't stopped it being 
> deployed in something like 20 million embedded devices!  Numbers like 
> these are always rubbery, but uClinux is certainly finding (found?) its 
> niche.

	uCLinux is certainly appropriate to its niche, probably the most
scalable market in the computing industry. It makes many "dumber"
devices smart enough to play with the "big dogs" in a seamless computing
environment, enough to include them in the distributed object
environment that is the only viable environment for manageable
communications development and use.


> > 	Where is a "helloWorlds" app that builds multiple identical circuits,
> > each signalling "Hello World" on a different pin literally
> > simultaneously? 
> 
> I've built microblaze uClinux systems with 10 serial ports, it took 
> longer to synthesise the hardware than it did to modify the design files...

	OK, it takes longer for me to rebuild some Linux kernels than it does
to revise the code. But that only has to be done once. And with new
tools like distcc, a network of machines can quickly recompile and
resynthesize an image for redeployment to all the participating
machines. Their dinkyness is inversely proportional to their
multiplicity, scaled by their cheapness. With their inter/networking
functions and standard Linux APIs, they are the architecture most suited
to network development yet deployed.


>  > That's a template for development, which will not only
> > improve the productivity of FPGA developers, but also offer a section of
> > the vast Linux global development community as developers for this
> > superior platform. Maybe I'm jumping the gun, with a stable platform
> > less than a month old, but where are the apps?
> 
> I'm working on self-reconfiguration architectures within the uClinux 
> architecture. I've done the linux-based self-reconfiguring "hello world" 
> example, networked partial bitstream servers and all that.  This work 
> will be presented at ERSA later this year.

	I'm looking forward to reviewing that work. And helping in any way I
can on this list, in its ongoing development. BTW, how many gates on a
Virtex II (or II Pro) are available after MB is fully up and running,
for apps? How much other resources, like MHz and MB, on a typical board?
Any reason why extra FPGAs can't be glued to the main chip, for scalable
gates without segmentation?


> It's all about making platforms to build on, that's why I think the 
> uClinux thing is a good idea.  You need a platform of components, both 
> software and hardware, from which you build your apps.  It takes time to 
> develop those things, but if you do it properly, you only do it once.

	Again, this environment looks really close to primetime for accessible
FPGA development. Back in 1990, we were visionary for implementing a
rudimentary single-step debugger inhouse for our FPGA net of DSPs.
MB/uCL might have actually delivered a platform on which mb-cc can
compile main(){} C to opcodes for the CPU sim, and sub() Verilog (or
ObjectiveC, etc) to circuits for the gates. We might finally be looking
at the gates equivalent of malloc/regexp.


> Regards,
> 
> John
-- 


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