Slashdot Mirror
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."
This looks interesting, but way too expensive to break down any barriers in the short term. Actually, being hardware (ASIC) designer, many of the embedded software guys know their hardware as well as the designers. Some, however, need their hands held every step of the way and can't understand why we put all those damned interrupt capabilities in there. Just makes the software harder to write!
I'd love to see something like this out in the market in a lower price range. It's great to have GNU software tools to write code inexpensively, and to have hardware as well would really be fun and useful. Sharing cool hardware accelerator HDL with others would be great. I've used Icarus recently and it is becoming quite a useable open source alternative to vcs, verilog xl, nc verilog, etc.
Maybe this new merging of the hardware and software worlds will settle some of the religious wars between hw and sw engineers? ...or maybe this will provide an architecture that's free of DRM? If TCPA ends up being as insidious as we think it will be, an alternative architecture will be in order for those who want to actually USE their PCs (as opposed to their $1500 multimedia toaster that they bought from Intel). This is good. This is very good.
god I hate PPC infact I nearly hate it as much as x86 but...
now ARM a nice little design there is the same deal but with a ARM that altera do and see www
and MIPS have been doing a dev board with a hard and soft core mix for a while
well you never guess they ALL come with GNU tools and as they use standard arch that linux is already ported to
really what you want to get into is a CPU on a FPGA and one that you dont have to pay a licence for this is what opencores.org is about and credit to them flextronics have started looking at it for a solution see
news about the use of open hardware at
the openRisc 100 project at
See the FAQ at
hope that helps
regards
John Jones
Using an FPGA does not in any way require "weird driver CDs". Nor do they prevent the hardware developers from implementing clean well defined, standard interfaces. 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.
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.
To say that hardware engineers are immitating the mistakes of software engineers is ridiculous, (although obviously some are making the same mistakes). Is it therefore perfectly acceptable for software engineers to implement poorly designed interfacesand neglect testing and quality control? I don't think so, but perhaps we have become numb to this issue. Bad engineering is bad engineering. 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. This is why FPGAs are popular in mobile telecoms base stations, and rightly so. Being able to upgrade hardware is a good thing. Releasing an immature design is bad, both in hardware and software.
If I seem short sighted, it is because I stand on the shoulders of midgets
I work in circuit design all the time, and I use DOS based tools for schematic, PCB layout, and circuit analysis (spice). Why?
Most of the stuff I do links to stuff I have done before. I have no trouble with my DOS tools re-opening files say 10 years old. I also know that I will be able to see my files 10 years from now if I play my cards right and do *not* "upgrade".
Processors change. Although my schematic capture program requires an 8088 or better, both the PCB layout and circuit analyzer require at least an 80386. As processors changed, I simply copied the files to a directory on the new machine and they run. No "installation" or registry entries, authorization codes, or the like. They just run.
The libraries on all of the programs are user configurable. As any new parts come out, I simply enter the configuration into the library.
No user authentication. These programs were coded in a day where there was not all this emphasis on piracy - I am free to move these programs around to any machine I get my hands on. And because the family of machines I use all run the exact same software, the files can be read/modified/written on any machine without need of version controls. It was common in those days to buy a "site license".
The programs are quite small. The schematic editor, along with all its libraries, and a good sized project's worth of files will all fit on a 1.4 Megabyte bootable floppy! The spice analyzer requires 1 floppy, and the PCB layout program requires three floppies. None of the programs require any sort of "installation", per se. Just make a subdirectory for them, copy them over, and run the appropriate .exe file and start work.
But the part I like best is that I intimately understand what these programs are doing. If something goes amiss somewhere, I know where to look. Their file structures are pretty simple; if something goes amiss, I can usually patch it with a hexadecimal file editor.
If I want the file in another format, its usually not all that difficult to pull up the C++ compiler and code a little file converter.
The schematic editor and spice analyzer are wide open to debuggers, but the people who made the PCB editor got crafty and made theirs hard to debug- just thank goodness they coded it well and there was only one instance where their program needed debugging. ( For those of you who have ever had to use what passes for technical support, you may find the time better spent learning how to fix it yourself.) But this was five years ago.. today fixing it yourself is illegal in many cases as a result of the congresscritters foisting DMCA on us.
I know its fashionable for me to say I run the latest systems. If the later systems actually gave me better results, I would gladly switch, but all I see out there is I would be throwing away a trusted and faithful system to get more problems than I could shake my proverbial stick at.
My take on this is that my tools are precisely that: tools. It took me 12 years of education before I could even emit a coherent sentence in English. It took me 5 years in front of a keyboard before I typed halfway worth a damm. What I am trying to say is that although hardware and software complexity has grown by leaps and bounds, I have not. It still takes me a helluva long time to learn how to use this stuff. If I spent all this time learning how to play a piano fluently, I feel foolish going onto stage with a clarinet. My job is not learning new tools all the time, its applying what I know to get a job done. Would you want a seasoned old mechanic using his grandpa's wrench on your car, or somebody with the latest 200HP pneumatic tool seating the oil-drain plug? ( I use that as an example because they did it to me... that car never stopped leaking oil once they improperly used that power wrench on my car.)
If what I am doing is bad, I guess it won't matter much - as this is my last decade I think I will be in the job force. This grandpa is about ready for pasture.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
Hardware design tools tend to be extremely poor. Doing an EE degree, you get to use quite a few of them, and soon realise that no proper software engineer could have been involved in the design of these tools.
Shall I show some examples?
Essentially, there are so many stupid, small mistakes in the user interfaces in these pieces of software, that it leads to people making mistakes. The less time you have to spend using them the better, so designs don't get tested or verified fully....
System Requirements: Microsoft Windows NT 4.0 (SP4), Windows 2000, Sun Solaris 2.7/5.7* or 2.8/5.8, Solaris 2.7/5.7
Bwahahaha, no development tools for linux, suckers! Seriously though there is a severe lack of decent open source EDA tools unfortunatly. There are a few that exist yes, but they are of very low quality or are very slow developing (some vaporware?). Yes, I know, now a bunch of you will go google now, find a bunch of open source EDA tools you've never used, and try to prove me wrong (I'm guesing the vast majority here don't even use EDA tools anyway).
It would be nice if someone tried to organize the different open source EDA projects together as there seems to be disjointed, repeat work out there (and some seem to be going nowhere so they need someone to give them a good kick in the rear).
<rant>Also a bunch of projects advertise that they are trying to create their EDA tool(s) for linux, I mean WTF is up with that? Seriously, I hate to rant but this really deserves it. What's with all the idiots creating linux specific open source projects when they do absolutely nothing that would need linux specifically. People doing that should be shot, if you gave the slightest bit about portability would at least target *nix.</rant>
Anyway, this is harder than it seems, as it is more than just a technical effort (the technical aspect being difficult enough as it is). There needs to be good "managers" and PR type people to organize and advocate this project, so it's not just a bunch of random momos submitting code on occasion that may or may not work with the rest of the program.
I'd much prefer a native port of their FPGA development tools. They list compatibility with Redhat 7.2 but if you read the fine print that means that you use WINE to run them. Better yet, release specifications on programming your CLBs and routing. You would then see some real innovation in tools come out. FPGA's should be the electronics hobbiests component of choice much like PROMs and 7400 series TTL logic was a couple of decades ago. Instead you're forced into using their tools, which the last time I used (admittedly ~7 years ago) were about as much fun as extracting your molars with a spoon.
Chris Kuivenhoven is a thief, beware
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.
"Field programmable" does not mean that you have to program it, any more than it means that you have to design it. The most common way of programming an FPGA is from a PROM chip on board. FPGAs are used as much in applications where ASICs are too expenensive as where field programmability is actually needed, if not more. If your digital camera manufacturer expects that you load an FPGA bitstream from your PC everytime you switch it on then, well, you should have read some reviews before you parted with your cash. Anyway, what's better, a device which is buggy and can't be upgraded, or a device which is buggy and can be upgraded? If you think traditional hardware designs are bug-proof, or can be exhaustively tested to ensure reliability, I'm sorry to dissapoint you. Hardware is generally as reliable as it is, because most firms are very good at hardware test and qualification, and there are well developed methodologies. This doesn't mean that bugs don't slip through. (Hint: don't buy the really cheap stuff)
If I seem short sighted, it is because I stand on the shoulders of midgets