Software/Hardware FPGA Dev Board that runs Linux

bforsse writes "The ML300 allows engineers to develop hardware with HDL synthesis/simulation and software with standard GNU tools. The entire system is implemented inside one FPGA with an integrated IBM PPC processor. The board comes with all the peripherals that a standard motherboard or laptop has and then some. It currently ships with MontaVista Linux, a number of other linux flavors and OSs are in the pipeline. Maybe this new merging of the hardware and software worlds will settle some of the religious wars between hw and sw engineers?...ok, maybe not."

Comments

Let's get it overwith...

[shadwwulf]

1. Get FPGA Prototype
2. Imagine a Beowulf cluster of them
3. ???
4. Profit and note that in Soviet Russi, the PCB prototypes you!

Re:The real question...

[kirn_malinus]

If you convert the Ogg algorithms to verilog/vhdl it could...

I prefer hardwired hardware

[g4dget]

I'm sorry, but I'm getting tired of FPGAs. Many early USB peripherals had FPGAs in them. The result? You need some weird driver CDs, and the hardware becomes useless when the special drivers don't install anymore.

For hardware developers to imitate the mistakes of software development is a mistake. Hardware should conform to well-defined interfaces, it should be carefully designed, debugged, and tested, and then it should not require "upgrades" or "installation" later on, it should just work. If it hooks up to computers, it should only require generic drivers.

Re:I prefer hardwired hardware

[g4dget]

In fact hardware implemented in an FPGA is no different from the users point of view from hardware implemented any other way, or from embedded software running on a micro-controller for that matter.

Ummm--no. The "FP" in "FPGA" stands for "field-programmable", and it is field programmability that I'm arguing against. Field programmability usually means that I, the user, need to do something to the device.

As a user, I don't want to have to "field upgrade" my stereo, television, camera, portable music player, car, or other device, I want them to work exactly as advertised; if they don't work as advertised, it should be the vendor's responsibility to fix them, at his cost. Making me download and install drivers, hot fixes, updates, or other stuff is an attempt to cut corners on testing and to off-load maintenance and repair costs onto me.

And if that kind of corner cutting takes hold, soon no vendor will be able to compete anymore with high-quality products and decent service. It's the same thing we have seen in software: Microsoft has initiated a race to the bottom in terms of software quality, immature releases, and testing and driven pretty much all other vendors out of the market through corner cutting. Hardware is trying to repeat the same thing, by letting companies avoid proper testing and allowing them to fix immature products after the fact.

The choice of using FPGAs for an emerging standard is good engineering, because if the standard changes before maturing the hardware does not then become instantly obsolete.

That's the attitude I'm arguing against. There shouldn't be "emerging standards". Define standards correctly and so that they stand the test of time, then implement them correctly. Don't ship products before the standard is defined. 802.11g is an example of this kind of bad behavior.

Of course, for some custom equipment, field upgradability makes sense. But that's already covered. My point is: expansion of field programmability into computers, peripherals, appliances, and comsumer electronics is undesirable as far as I'm concerned.

programmable hardware probably wouldn't be open

[Kynde]

If your USB peripherals didn't work properly, its because they were poorly designed. This has nothing to do with the choice of using an FPGA to implement the interface.

With programmable hardware the hardware engineers won't have the same scrutiny in testing as they would with hardwired hardware. Period.

So what, one might say? Programmable hardware can be upgraded afterwards. So isn't that a good thing? Depends on who you ask I suppose.

My stand on this would be NO, because I couldn't do jack shit for it incase something doesn't work. From a software developers point of view it's essential that you can trust your platform (os and compiler) and most importantly if you think there's bugs there, you can look it up from the source and try finding it. I doubt that I'd have the possibility of doing so with programmable hardware.

No, clean CPU specs for me please. Let it be shite like the 386 we're still mostly struggling with, but atleast I have good specs for that and ALL of the software on top of it is GPL'd. Thank you.

Besides if you think of BIOSes and HW drivers in general. They're so shite that linux and many other OSes won't even use them. Thank god one can bypass them in most of the cases. People have been asking bios sources, but in vain. My guess is that what we have with bioses now is what we'll be facing with future programmable hardware. Crap and proprietary. I wonder why M$ hasn't gotten into that yet...