Software/Hardware FPGA Dev Board that runs Linux 208
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."
funny... (Score:5, Funny)
Re: REAL funny... (Score:1)
Re:funny... (Score:1, Troll)
Re:funny... (Score:1, Funny)
Re:funny... (Score:1)
Well, if you want to get technical, if you're not a certified P.E., then some people say you shouldn't call yourself an engineer.
Heck, Karma's cheap. Let's get flamed. (Score:2)
Wannabe Engineer: Application "Engineers" and Network "Engineers." Requirement: You're the guy down the street that "knows stuff about computers." A degree in IS, a diploma from ITT Tech and Certifications are all optional.
I'm not an Engineer, But I Play One At Work: Software "Engineers." Requirement: A CS degree. You think you're cool because you hack XML. You think you know stuff about computers, but you couldn't so much as recognize a K-Map if it slapped you in the face. You've heard of "assembly" programming, but you've never actually seen it.
Real Engineer (junior grade): Electrical/Computer Engineers. Requirement: A B.S. in Electrical Engineering. You actually know something. You eat Verilog for breakfast and assembly for lunch. You could probably design a power supply for your computer from scratch, but it wouldn't have good voltage regulation.
Real Engineer: Requirement: PE. You think you are a demigod, and all the Engineer(j.g.)'s simultaneously despise you and want to be you. You dream in SPICE and FORTRAN and scorn those who rely on silly schematic capture tools, since you write all of your netlists in vi.
Re:Heck, Karma's cheap. Let's get flamed. (Score:2)
Re:funny... (Score:5, Interesting)
Well that's what hardware engineers think when the software engineer disagrees to install MS-DOS 3.3 to test the hardware.
Seriously though, I've been through two board bringups, both Intel Architecture.
The first board was considered 'done' by the hardware guys, after it booted DOS. I told them that that was not really a test, and sure enough months (and numerous patch wires) later we finally were able to use _all_ the features on the board and boot Linux and Win95.
On the second board I was most impressed with the software tools hardware guys used. NOT! Although the board was more or less up and running I found a couple of places where transmits were connected to transmits and receives to receives. I asked why the schematic capture tools didn't catch such obvious mistakes. I know the software can, but quite honestly, all the software used for hardware design feels like it was written by, uh, hardware guys.
Seriously though, the software tools that hardware engineers use leave a lot to be desired (I mean, the last board I worked on was in 2002 and they used a DOS based program to do the layout for peet's sake)
In defense of the hardware engineer though, he'd use symbols provided by the manufacturer and they, for some reason, could not be bothered to indicated the type of signal a pin has properly (e.g. input, output, bidir, etc..)
Until today I never understand why they'd risk the change of having to do a new rev of a board vs the cost of spending a few minutes to create the symbols properly.
Then again, I've seen software 'engineers' do the same stupid stuff.
Re:funny... (Score:5, Insightful)
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.
Re:funny... (Score:2)
Yet - look at the Windows versions of these things. They cost 3x as much minimum, take 100x more memory to run(I get to count the OS here!).
Why - poor software engineering practice! You can put a fair amount of blame on the bloat directly at MS's feet. Fine. Still, software guys just add layer upon layer upon layer without ever cleaning up after themselves (See OSI model as proof of concept
Nowadays - I use RTL to do chip design. The tools don't advance to much for the simple fact that there is lack of competition and people are afraid of touching a big bulky piece of software that happens to work. The synthesis tool in particular has a repetition that for every feature they add, they broke three, and the new featuer won't REALLY work for two or three releases.
As for software that operates like EE's desiged them. You guys have never seen the HP500 logic analyzer user's interface. Looks like a software guy designed it. I've been griping about that for a decade too!
Re:funny... (Score:2)
Yes, we computer folk are (or should be) constantly reminded that "if ain't broke don't fix it" (or pay for it!) is a good axiom for most people.
I think some of the points you made directly apply to the rush to get EE oriented tools onto Linux. No one can ever declare an old version "obsolete", and I'm pretty sure you'll be able to get x86 hardware to run it for many, many years (i'd guess at least 50, and perhaps 100,000;).
Contrast that to Windows where "OS Design du Jour" is the rule...and there is a constant commercial push to generate churn.
Linux rocks!
Re:funny... (Score:2)
Hopefully, the seasoned old mechanic will be able to use a brand-new titanium wrench if his grandpa's old one finally gets lost. For that matter, switching to a lighter but equally strong material might be a good idea anyway.
Re:funny... (Score:3, Insightful)
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....
Re:funny... (Score:2)
Performance and quality of results are much more important than GUI niceties.
As for the price, I think you left out a zero. While there are a few tools that costs as little as $10000, prices of $100000-$400000 are not uncommon.
Re:funny... (Score:2)
Who CARES about human interfaces when all you have to do is type "verilog -f files"
Re:funny... (Score:2)
I'm a hardware engineer, and I have to agree somewhat about hardware EDA tools. They do suck much more than SW design tools.
'Compiling' (i.e. synthesising, layout, drc etc) of a hardware ASIC design is much more hands on and time consuming that compiling software (ie. type 'make'), and I guess that's why hardware design tools seem to be much more primitive.
And on top of all that, hardware is expected to work after the first full compile (i.e. taping out a chip).
Jeff
Re:funny... (Score:2)
That statement literally makes me cringe. Do you remember the growing pains that so many programs had as they transitioned between the trusty DOS versions and the first and second (and often current) Windows versions? Programs that did the job perfectly fine turned into a complete fucking mess when ported to Windows. Remember how bank tellers used to fly at keyboard entry? Now you have to watch them point and click and click and click...
Just because a program runs under DOS does not make it inferior.
Re:funny... (Score:2)
Dilbert: "You're mighty brave in cyberspace, flame boy."
Re:funny... (Score:2)
But maybe they're wrong.
Re:funny... (Score:2)
Choooo...Chooooo.....
As an electrical engineer, I know that... (Score:5, Funny)
P.S. I have similar views on the 3rd world clone chip manufacturer, AMD.
Re:As an electrical engineer, I know that... (Score:1)
(but real people still draw the geometry)
here we go again (Score:2)
Yeah, sure. (Score:5, Funny)
With a $6k price tag, it should come with a high class hooker.
Re:Yeah, sure. (Score:2)
Actually, you're the one that... oh never mind.
Re:Yeah, sure. (Score:2)
http://www.educatedescort.com/
$12K/day, 2 day min.
--jeff++
Re:Yeah, sure. (Score:3, Interesting)
Re:Yeah, sure. (Score:2)
--jeff++
Re:Yeah, sure. (Score:3, Interesting)
http://www.digilentinc.com/
Re:Yeah, sure. (Score:2)
I want to experiment with converting programming logic into hardware.
Joe
Re:How do you want to convert from programming log (Score:2)
I have recently written an SH7055 CPU emulator and I want to try to build my own CPU. I realize that a CPU on an FPGA will be slow, but I'll learn why the SH2 was designed the way it was, instead of the way I think it should have been.
I would also like to play with multiple simple dedicated use cores on a chip.
Joe
Excellent! (Score:2)
How much do production systems cost? (Score:2)
GNU tools? (Score:3, Informative)
But still, me wants! Think about it.. 4 PowerPC cores embedded in a sea of programmable logic? *drool*
Re:GNU tools? (Score:1)
So, it is not only $5k, but also $5 Sun Workstation (or BSOD interface for $300) and third party tools - such as Synopsis for $xxx,xxx
I was just hoping that Xilinx ported its tools from Solaris to Linux and sells it with an evaluation board for mere $5k!
Re:GNU tools? (Score:1)
Jason
Re:GNU tools? (Score:2)
But then I found out that the PPC cores are very slow relative to state-of-the-art standalone processors - its in the range IIRC 266-366 MHz each. Even multipling by 4 and it doesn't fare well compared to 1 GHz PPC's. Xilinx explained that the process they were using just didn't allow for fast processors, so I doubt they'll ever catch up.
What I'd like to see is a 1 GHz 4-PPC core with either no programmable logic or just a little (enough to implement some simple communications fabric and maybe a little left over for a simple coprocessor).
But, that's just me. This would be more sellable to my old company, which used a Virtex II and a discrete PPC. This combo woould save some realestate (they had 2 Virtex's, 2 ppcs, and a whole lot of other big parts on a 6U VME card; it was crowded!!)
Re:FPGA tools and Linux (was: Re:GNU tools?) (Score:3, Interesting)
As far as I know, Xilinx doesn't have a direct Linux port of their software, but say that their Windows Binaries will run under WINE. I don't know, as I haven't used Xilinx stuff in some time.
Re:FPGA tools and Linux (was: Re:GNU tools?) (Score:2)
Applications run through WindU look ugly, but all EDA tools look ugly, so I don't care. Quartus in particular has such a horrid interface that I'm looking forward to my next Xilinx-based project...
What can you do with it. (Score:3, Interesting)
Can someone with a bit of know-how point us towards some more info?
Re:What can you do with it. (Score:5, Informative)
As with software, a lot of modules exist (mostly quite expensive) for logic blocks up to and including microprocessor cores. Rather than having a chip with a single function, it is possible to squeeze multiple functions upto the limits imposed by the gate count.
FPGAs can be reprogrammable, or programmable once only. There is a often fusable link inside that once blown prevents reprogramming or designs to be read out.
If you are producing quantity, then you can go from an FPGA component to a gate array which is programmed by a photographic mask during manufacture. The mask is prepared from the same program that created the FPGA. The setup costs are high, but once you talk about big numbers of chips, the component becomes significantly cheaper than an FPGA and often better performing.
Re:What can you do with it. (Score:2, Informative)
It's a piece o hardware that you can buy to do stuff (you tell it how to map out a 'virtual processor'). If you had one large enough you could emulate an x86 cpu.
They're used mostly in applications where (price OR time to market OR development costs) are a big factor. Custom silicon for a custom purpose will always be faster, and cheaper (If you build enough to justify the development costs).
Flame away, more knowledgeable
Re:What can you do with it. (Score:3, Informative)
It is used in early stages of hardware design to verify timing and functional correctness, and heavily in education. Sometimes final production products will use FPGAs, but usually only when the production volume is low. This is because FPGAs are more expensive per individual unit than ASICs (Application Specific Integrated Circuits), but ASICs require more expense on design costs.
Re:What can you do with it. (Score:4, Informative)
But the answer your question briefly, the internal structure of the FPGA is an array of computational logic blocks. The boundary between these blocks in the array is routing logic that allows nearly arbitrary connections between the logic blocks. There are also IO blocks at the perimeter of the array. Each logic block typically consists of some combinational logic followed by a register element. The combinational logic element can be programmed to implement arbitrary logic functions of around 4-8 inputs. Thus you can configure a block to be a 1 bit adder, a mux, register, etc. By programming the CLBs and routing between the blocks, an hardware system can be built. You write the hardware description in Verilog, VHDL or schematics capture. Then a synthesizer maps your design to a bit pattern necessary to program the FPGA. You generally program this into the chip or into an external flash memory connected to the FPGA.
Re:What can you do with it. (Score:1)
I'd like to expand on this question. I've been intrigued by FPGA's since I first read about them. To my (admittedly relatively untrained) mind, they seem like the ultimate platform: an infinitely reconfigurable piece of computer hardware. It would seem like an FPGA, with its gates programmed for optimum efficiency for a given task, should be able to kick the pants off a traditional fixed architecture cpu. If this isn't the case, can someone tell me why? Someone once told me that the distances between various virtual components in a configured FPGA slowed things down; is this true? Why don't we see desktops made with these? (I suppose, if FPGAs are really expensive enough to warrant the price tag on this doo-dad, that'd be one reason.) There actually is a company called Star Bridge Systems [starbridgesystems.com] who make computers with FPGAs. They even promised a "desktop supercomupter" a few years back. But apparently, they've given up on that (or decided that selling a few multi-million dollar supercomputers is better than selling lots of thousand dollar desktops). And even if FPGAs aren't much faster than regular chips, there's something about compiling your code down to the actual gate layout (rather than for a set gate structure) that just seems really, really cool.
Re:What can you do with it. (Score:2)
FPGAs are slower than ASICs, due in part to the programmable switches used to wire up your design. FPGAs are also many times less dense than a ASIC, again due to the general purpose building blocks, and programmable switches.
Basically, they're bigger, slower and more expensive than an ASIC
Jeff
VHDL (Score:3, Interesting)
Re:VHDL (Score:5, Informative)
Verilog is more common than VHDL in the US, so this is the only open source HDL tool I've used. Primarily, we are still slaves to Synopsis and Cadence though.
Icarus (Score:2)
Re:Icarus (Score:1)
Re:VHDL (Score:1)
Of course I do not expect Open Source Synopsis any soon.
Re:VHDL (Score:2)
My guess is that verilog simulators will come out pretty soon, however VHDL will remain in infancy coz more of the hardware ppl are moving on to verilog.
Re:VHDL (Score:4, Informative)
Right now the most interesting one is a VHDL frontend for GCC called GHDL [ghdl.free.fr].
Also note that you need a lot more than a simulator to get it to work with this board: you need a synthesis tool that can map into the Xilinx part. The FPGA companies tend to keep their formats quite proprietary, so don't expect any open source tools for synthesis and tech mapping any time soon.... (unfortunately).
Re:VHDL (Score:1)
Re:VHDL (Score:3, Informative)
Certainly, Modelsim [model.com]
Jeff
Re:VHDL (Score:2)
Not quite for the masses (Score:4, Insightful)
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.
The V2Pro's are very cool parts (Score:5, Informative)
Xilinx promises that at the end of the year, in suitable quantities (>25,000), they will be $100/each.
Re:The V2Pro's are very cool parts (Score:1)
And maybe if I get off my ass, we'll have a nice language with which to program the things, too.
Benjamin
Re: The V2Pro's are very cool parts (Score:2)
Yeah, yeah, yeah... the same meaningless price quotes from Xilinx as always. Historically it's been at 100,000 pieces in their widely published literature.
At 25,000 chips, you'd probably go to the trouble to create a custom ASIC. Or at least you'd do a "hard wire" conversion of the FPGA design to an ASIC, if you used the FPGA to "get to market quickly".
If you call up one of the [insight-electronics.com] actual distributors [nuhorizons.com] where you'd actually buy this part, say at qty 1000 to 5000, the store would be different. A lot different.
TCPA (Score:2, Insightful)
Re:TCPA (Score:2)
This gives us great freedom with hardware.
One of the things that made software approaches take off was that software is easy to change. You don't need a dedicated circuit designed for each purpose. I remember as a youngster in the decade of polyester suits before popular microcomputers playing with 7400 series TTL gates to build various logic circuits. (e.g. a clock. a burglar alarm with keypad code entry.) As I looked at more sophisticated devices, the logic circuits needed to become way too comples. For instance, from PolyPaks you could order a single digit readout with a 5x7 array of LED's. You would have to multiplex drive this. I never ended up building any breadbord circuits, but I designed a few on paper. I would end up using a PROM after reading about them in Popular Electronics.
It wasn't far from here to make the jump to "programming". I finally "got" the idea when I got hold of a friend's HP25 calculator. I never went back. No longer can remember which end of a soldering iron to pick up.
The greatness of software was that you only had one universal hardware circuit. But you could control the outputs of, say, a parallel port.
Now here we are in the 21st century. Fantastic hardware. But there is the potential for us to lose control of it to powerful, greedy interests.
I would love to see the day when anyone could buy a cheap part and "burn" (or whatever) their own circuit or chip design. This would open the floodgates. Especially if the development systems were cheap, like a CD burner. Especially if your chip could fit into a standard PCI board, or dangling USB module.
This would ward off the dangers of hardware control, just as open source wards off the dangers of software control, and garlic wards off vampires who want to suck you dry through neck lock in's and licensing 6.
If this was cheaper (Score:1)
really get a nice arch (Score:4, Insightful)
now ARM a nice little design there is the same deal but with a ARM that altera do and see www [altera.com]
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 [eet.com]
the openRisc 100 project at [opencores.org]
See the FAQ at [opencores.org]
hope that helps
regards
John Jones
Re:really get a nice arch (Score:1)
It seems, that I can design on windows a system, that can run Linux and Linux kernel is included, BUT I have to have Windows/Solaris first to design compile the FPGA. Am I correct?
Re:really get a nice arch (Score:2)
Re:really get a nice arch (Score:2)
like a shiny little toy (Score:1)
Fantastic to look at, even if you had no reason to be legitimately interested.
I prefer hardwired hardware (Score:2, Redundant)
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 (Score:1)
reminds me of the time that I used an HP LaserJet 4 driver to run a Deskjet 350 in DOS...guy said it would never work...granted, only printed black and white...but still
Re:I prefer hardwired hardware (Score:5, Insightful)
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.
Re:I prefer hardwired hardware (Score:2, Insightful)
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)
you are making my point for me (Score:2)
Obviously, I have no problems with FPGAs whose programs are loaded from ROM. One would think you would be able to figure that out from what I wrote since I explained very explicitly what I don't like about field upgradability.
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.
A lot of hardware used to do this and still does this. Reviewers don't generally notice it because they just review stuff on one particular version of Windows. When the next version of Windows comes out and the vendor doesn't release a new driver, such hardware usually becomes a useless chunk of metal and plastic.
As for you digital camera example, come on, that's a deliberately stupid example. You can figure out for yourself while even the worst company is not going to release a digital camera that requires downloads from a PC every time it is switched on. Firmware upgrades for digital cameras are still a huge problem, waste of time, and dangerous practice (if you interrupt it, the camera may break and won't get fixed under warranty). For example, I have a Nikon camera that was released with serious bugs; but the ugprade program doesn't run under Windows XP (it starts the download but never finishes the firmware download), and Nikon won't fix the camera for me. Ditto with a Palm firmware upgrade. Reviewers don't get to see such hassles.
Hardware is generally as reliable as it is, because most firms are very good at hardware test and qualification,
Yes, and if hardware firms can just release bug fixes like Microsoft does, that will get worse because they will invest less effort in "test and qualification". That is my point. This is what has happened in software over the last decade or two, and it looks like it is going to happen in hardware now that hardware is "field upgradable" and "field programmable".
Re:I prefer hardwired hardware (Score:2)
1) Using a pre-standardized specification because some marketing guy wants to be the first product to hit the street. This is a marketing and not an engineering problem.
2) For some reason there seams to be a lot of FPGA designers that don't think design verification with simulation is very important. Probably because FPGAs have historically been small simple devices, and now are becoming large and complex like ASICs. ASIC designers have developed sophisticated verification and simulation environments that really help reduce the number of bugs in large complex systems. The relatively simplistic and old fashioned verification methods of the FPGA designer tend to not thoroughly verify a design. In fact if you talk to these designers, they often say "Oh, all that simulation is too slow, and requires more work to develop all the test benches. I'll just download the FPGA program into the actual device, and run it on the real thing a thousand times faster." The faster part is true. Yet, this approach is usually far from thorough since a formal verification plan has not been created, and running on hardware lacks the visibility needed to do debug. Then bugs like you've seen make it into the product, and a patch has to be delivered to the customer later.
So there's nothing wrong with the FPGA. It's just the pressure to go to market too early, or inexperience engineers brushing off the idea of thorough verification.
Re:I prefer hardwired hardware (Score:2)
There is nothing "wrong" with any correctly designed piece of hardware. I mean, unless you step on it, an FPGA by itself isn't going to hurt you.
What is wrong, IMO, is using FPGAs to build consumer products that are upgradable by the end user because that allows companies to release hardware with less testing and just have the users find and fix the bugs. Like Microsoft does with software.
Re:I prefer hardwired hardware (Score:2)
Problem: There is no defined standard yet (aside from broadcast). Studios will be slow to adopt HD production unless there is a large market of HD viewers, who won't upgrade unless it's cheap and has a lot of HD programming. Chicken/egg.
Solution: slowly seed the market. Convert early adopters on both fronts.
Problem: even they won't adopt if they think their new hardware will be obsolete soon.
Solution: you need to standardize on the a spec, or allow them to upgrade.
Problem: if the spec is marketed incorrectly or not very good, or there are competing standards, hardware developers don't want to create hardware for it.
Solution: Somebody needs to force the standard. Enter Congress.
Problem: Congress doesn't act because various producers and consumers want different things. The standard never happens because of this. Since the standard never comes, hardware makers never create HD devices. Even the early adopters don't get to adopt. Deadlock.
Solution: Hardware makers create upgradeable devices able to handle any changing standards. We now don't have to wait for "An Act of Congress" to get HD. Early adopters on both the producer and consumer side will start playing with the technologies. Through the sometimes painful process of survival of the fittest, some kind of standard will emerge victorious. It won't be perfect, but the alternative is deadlock.
There is an alternate version of this scenario. Congress does pass a standard. It is so bad nobody wants it, and is ignored.
Ignored because:
1) it's too vague or allows too many variations
2) favors one lobbying group too much
3) was never tested in the "real world" and won't really work
4) despite having a deadline for compliance, because of 1-3 is repealed before anyone actually has to do anything about it.
Re:I prefer hardwired hardware (Score:2)
Buying an HDTV that is upgradable via FPGA programming is utter folly: five years from now, when you finally get around to upgrading your hardware, the vendor won't have any software for doing so, or means by which you can load the software into your HDTV.
The way HDTVs are upgradable is by putting the HDTV decoder into one box and have a standard analog or digital interface to the video part (plasma, projector, CRT). That's solid, sound engineering for change.
So, upgradable hardware is good. Modular hardware is good. FPGA-upgradable hardware is (usually) bad.
Re:I prefer hardwired hardware (Score:2)
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.
Ah, you mean like the way software vendors handle their products.
I think there are two problems here. One is that hardware has become vastly more complex, just like software, so that it is virtually impossible to test for every possible bug. And the second is the rapid development and change of standards. Are you happy buying a new toy everytime something new (like a new, better movie format) comes out? Why not zap your old player with hardware support for the new format?
Re:I prefer hardwired hardware (Score:2)
I don't see the problem. Nothing is entirely bug free, but there is a traditional level of reliability we have had for hardware. I have never needed to upgrade my stereo before. If hardware becomes more complex then it requires more testing to achieve the same level of quality. What you seem to imply is that vendors make their hardware more complex, do the same amount of testing, and then let the users find the bugs. That's exactly what I am annoyed by. Hardware vendors should do testing commensurate with the complexity of the hardware they release.
And the second is the rapid development and change of standards. Are you happy buying a new toy everytime something new (like a new, better movie format) comes out? Why not zap your old player with hardware support for the new format?
Standards are usually not developed rapidly. MPEG4 took, what, two decades after MPEG2 to be released? What is being developed rapidly is a barrage of new, proprietary formats, formats that vendors release quickly in an effort to grab market share with minor advantages. That should be discouraged.
Here is my rule of thumb: programmability is fine if I can program it to do what I want it to do. Then, I don't have to rely on the vendor to dictate to me how and when to upgrade. But when programmability only goes as far as the vendor sending me binary-only field upgrades, then programmability is merely a means for the vendor to avoid sufficient testing the hardware before sending it out.
Re:I prefer hardwired hardware (Score:2)
wasn't something similar to this said at the conference in Kittomer?
Do they have student discounts? (Score:2)
This looks pretty cool, but no way I can afford one at $5K... You could do the slow bits of code in C targetting the PPC and the fast stuff in VHDL or Verilog...
Correct Link (Score:2, Interesting)
Linux? (Score:1)
so in this case... (Score:2)
Religious war (Score:2, Funny)
Assume that $religion means the presence of a $diety (belief systems without a $diety, like Taoism, will not be considered ${religion}s, which is to their credit).
Either $diety is hardware (real, grounded in nature, possibly via a marked green cable) or is software (virtual, made up in human minds, subject to revision and short-lived cultural fad approaches like "extreme religion" and "christianity"). Since there are and have been umpteen different $dieties, none of which has lasted, while the hardware has remained relatively stable, $diety is software. This is also confirmed by the near-universal belief that $diety is infinite, which can only be true of software (since it is virtual). As a side note when you consider the state of software this explains a LOT.
So since $diety is software and software requires hardware to run, hardware engineers are titans. They win and software engineers lose.
But since $diety is software and can thus be made and freely and infinitely revised by software engineers, they're the ones who are titans. They win and hardware engineers lose.
So I hope that's cleared things up. Now fight amongst yourselves.
Hardware/Software convergence - the real thing (Score:4, Interesting)
The xilinx parts are for embedded systems, and have no real benefits for your average PC user (hence they can market them them for $$$).
Look here [celoxica.com] for genuinely cool FPGA technology. They use transputer based technology to implement parallel algorithms in, well, parallel. The demos are very impressive - real time raytracing @50MHz anyone?
Re:Hardware/Software convergence - the real thing (Score:2, Interesting)
Its a lot faster to develop this way than more traditional methods (HDL's) as its so easy to iterate, for example being able to drag code back and forth to optimise the flow between a processor on your board and an FPGA being used as a custom parallell coprocessor is pretty cool.
As for the demos, that ray trace one is pretty cool, but I did like the space invaders demo - I think the game code was from a ROM dump - you even got an insert coin prompt!
One seriously amazing part (Score:3, Informative)
Combine this kind of power with multiple PPC processors on the same die, and the possibilities are incredible. The big difficulty is that the operation of the hardware and software can be so tightly tied together that it is difficult to program and debug. Everything is controlled by software (both the software and the VHDL or Verilog based FPGA code) and so the possibilities are limitless.
Kudos to Jim Ready and the folks at Monta Vista for supporting this kind of device with development tools for Linux.
Re:One seriously amazing part (clarification) (Score:2)
There is a Virtex II and a Virtex II Pro, which are not the same.
The article is about a demo board with the PRO version on it. The plain Virtex II doesn't have a PPC processor built-in to it.
Just wanted to clear that up.
MM
--
Nice, but... (Score:3, Insightful)
LEON (Score:2, Interesting)
Board details (Score:3, Informative)
The CPU board, that has all of the main components on it, is an 16 layer board. It comes with 8 - 3.125 gigabit capable transceivers (used as 4 gigabit fiber, two HSSDC2/Infiniband and two Serial ATA), 128 MBytes of DDR, 2 PS/2, 2 Serial Ports, Parallel Port, FireWire, two PCCard/PCMCIA slots, Compact Flash interface (for configuration and file system) PMC slot, BDM and Trace ports, JTAG port, AC97 audio codec and a kitchen sink.
The Power-I/O board, that has the TFT, most of the I/O and the majority of power regulation, is an 8 layer board, and has a 640x480 TFT, 14 I/O buttons, a multitude of LEDs and a small prototyping area underneath the TFT.
Included with the kit is a 1GB microdrive, 2 fiber cables, 2 serial cables, an HSSDC2 cable, a serial ATA cable, two flavors of firewire, a Parallel Cable 4 programming cable, Xilinx ISE software, Chipscope ILA Pro, and on and on.In addition, I would like to say that this was an exciting project to work on - between the gigabit transceivers, the DDR and the high density of components on the board, this was the hardest board I've designed (I did the majority of the schematics and parts of the layout).
Re:Board details (Score:2)
$4695 is really expensive for an FPGA (Score:2)
Doing stuff in hardware is neat because it runs real fast, you're interacting with the real world instead of living in a black box, and you can charge money for it. Other than that, it's too expensive to use in most commercial situations and you need to go back to a general purpose computer. Let's put it this way. The ML300 is $4695 in materials. A standalone FPGA with supporting electronics and PCB fabrication is $100 in materials. Pure software on a general purpose computer is $0 in materials.
Re:$4695 is really expensive for an FPGA (Score:2, Interesting)
heroine: "Doing stuff in hardware is neat because it runs real fast, you're interacting with the real world instead of living in a black box, and you can charge money for it. Other than that, it's too expensive to use in most commercial situations and you need to go back to a general purpose computer. Let's put it this way. The ML300 is $4695 in materials. A standalone FPGA with supporting electronics and PCB fabrication is $100 in materials. Pure software on a general purpose computer is $0 in materials."
The board is expensive because tech support for something like this is expensive. By charging a non-trivial amount of money, the vendor is able to weed out the non-serious players.
Re:$4695 is really expensive for an FPGA (Score:2, Informative)
If you're interested in a "standalone" development board those are also available [xilinx.com].
Re:The real question... (Score:1, Redundant)
Re:it's cheap too! (Score:1)
Just http://www.xilinx.com/ise/vii_pro/kit.htm does not mentions Linux at all.But Monta Vista claim, that _do_ they work together.
The question is, if Xilix schematic editor, VHDL compiler and xpr runs on Linux or it is only Linux for C development?
Re:Cheap shot (Score:1)
I guess that the plug-in FPGA card would be connected in a different way, so whey you submit masks for mass productions the result would be likely buggy wnd won't work.
Oh-no! Perhaps you did not think that this is for individual use?
Re:System Requirements (Score:2, Interesting)
Pehaps you have heard of a VHDL simulator called Modelsim? They have a Linux version and they have found that through test after test Modelsim runs much faster on Linux than on any other platform. That's why they are targeting Linux.