Looks like ST Micro has been trying to unsuccessfully develop a new FPGA for many years with 100s of engineers. The good thing to come out of this project is that they are open-sourcing the EDA tools they developed for their FPGA. These tools (Synthesis, P&R etc) are available at:
This is good for researchers to play around with tools. And at first glance, looks like a true open-source license (publish any changes to source code that you make). However, ST benefits the most, since they get free tool enhancement, while they sell their FPGA fabric as an embedded FPGA fabric.
They may be able to create a viable business model using this approach, but it will require a *LOT* more than just open source tools. The key to their product acceptance is that it has to be a *GOOD* FPGA architecture. The fact that they don't say much about the hardware and the fact that it does not look like the hardware is open source says to me that the open source software won't be much of an advantage. Sure, they will get academia to work on their software for them. But much of that will be pie-in-the-sky stuff and likely the tools will not really be any better than the tools available for the mainstream vendors.
Where do you find info about the FPGA?
Rick "rickman" Collins
The key things here is that ST Micro is going after the embedded FPGA market. This is not an established market and Xilinx & Altera will have advantages only in terms of tool familiarity.
About ST's architecture, if the Logic synthesis and P&R tools are open source, it should be very easy to figure out what the architecture is. Also, I don't think its a very big innovation, otherwise, ST would go after the standalone FPGA market, instead of a non-existant embedded FPGA market.
That remains to be seen. From what I can tell, there is actually little demand for less capable chips with less capable but open-source tools. The issue is not the number of people who want this, the question is how many chips can they sell? The money is in volume and not many chip users can sacrifice the advantages of the most current technologies. It will make their products more expensive and not competitive.
In reality the current tools work and actually work pretty well. So well that college students are designing chips in junior level classes. If it ain't broke, don't fix it!
Neither of us really have any stats about the level of demand. I guess we'll find out when products roll out the door. :)
Yeah, I know. But that is a community of software people who are using software tools. I worked in construction in my youth and I saw carpenters make a lot of tools out of wood, and metal workers make tools from metal, but not much the other way around. This has been discussed many, many times here and I still don't see any open source tools that are worth using.
What is possible? That I will retire? :)
I agree that the whole package has to be right. But a good FPGA will always outweigh a good toolset because the FPGA is a recurring cost. If you have to spend a few more bucks on tools or using tools, that will have less impact on your bottom line. If your project is a lower volume run where the development cost is relevant, then it is not big enough to matter to the FPGA maker.
And the discussion goes on, and on, and on...
Rick "rickman" Collins
No they are not the first. The key here is that this is a niche market with a small total size, although growing. I doubt that an FPGA vendor can survive just supplying this one market. I expect they either see this as a way to bring in more ASIC customers or they will branch out to full FPGA chips. BTW, wasn't that Lucent's marketing strategy to acquire ASIC customers by getting them to prototype with primitive compatible Orca FPGAs? I believe they sold off the Orca line to Lattice... guess that didn't work out too well for them.
Rick "rickman" Collins
Yes, but it is a very small market still. They must have something else in mind with this as a foothold.
You may be right. Certainly you don't need the *best* FPGA to market it as a partially reprogrammable ASIC. But some FPGA vendors are saying that ASICs are loosing market share to FPGAs in a big way. Perhaps that opens up a middle ground or maybe it is the *worst* of both worlds, a long lead time ASIC that you have to configure at boot time... :)
Rick "rickman" Collins
It seems that the GOSPL project is not just focused on development of the tools, but also of the target architectures. From their website:
"It provides a platform to innovate, improve and define next generation FPGA architectures and to design optimized silicon using state-of-the-art circuit designing techniques."
The website implies that users are encouraged to also develop new FPGA architectures. There may be an opening here for alot of interesting FPGA-on-FPGA projects (synthesise your own FPGA architecture into a Xilinx, Altera, Lattice, ... device).
Something like the old "Meta Programmable Gate Array" project
BurchED, Making FPGA Prototyping Easy,
BurchED FPGA boards...
Largest number of accessible I/O pins.
Widest selection of plug-on modules.
Ideal for prototyping real-world designs.
Economical for engineering and advanced student projects.
Don't forget ST is a very big company (much bigger than X or A) and have many different areas of expertise.
I wouldn't be surprised if they start using their own FPGAs to improve where they already are pretty good.
In fact, i believe that FPGAs will ony benefit from this. ST will use them where that have not been used before, thus expanding challenging X and A on new grounds. No doubt X and A will still make, overall, the best FPGAs, but will they still make the best FPGAs for, say, the automotive market? Existing companies don't know much about the automotive market, ST knows more than most.
On the other had, if ST fail, it'll probably mean nobody is ever going to try the FPGA market. After all those failures, people will just get fed up of it.
Are you allowed to fork the code and distribute it to people that are not members of the GOSPL community (i.e., to those who haven't signed the GOSPL Community License)? If you can't, then it isn't Open Source or Free Software.
The requirement to publish any changes that you make to the code is bogus and reduces the usefulness of the code greatly.
Also, you need to apply for a license, and ST seems to be able to deny you one. That is not good, either. (And, the application form is in Microsoft Word .doc format. Way to endear oneself to the Open Source / Free Software crowd.)
I will try to get my hand on the license, I haven't found it yet on their web pages.
What is missing, in my opinion, is not 1 million lines of code with a half-assed, half-open license. We need complete and unencumbered documentation of the hardware, the way we have it for general purpose CPUs like IA-32, PowerPC, etc. If there is a need for Free Software, it will then appear. Maybe GOSPL provides these docs.
I'm fully convinced that there are people out there who are able and willing to write synthesis and P&R tools for sufficiently well documented FPGA hardware, and give these tools away as Free Software. But having to reverse engineer the hardware first is not fun and not worth it, and so it isn't done to a sufficient level.
This all is not to say that GOSPL is evil, or doomed, or the wrong strategy for ST. But in my view, it is nothing that the OpenSource / Free Software communities need to get excited about. Yet.
We had something quite close to that, I _believe_, for the XC4000 series; I believe that's why those were the chips used in the amazing evolution-of-hardware experiments in 1996 or so.
But the time taken for free software to be developed for a new architecture is at least comparable to the time for the architecture to become obsolete; and there's not the concept of generations of backwards-compatible chips that the software world is used to, because there isn't the enormous pool of software without source code. The manufacturer reserves the right to change everything under you; it's not even completely clear to me that Verilog developed with the tools around when the XC3000 appeared would compile to correct hardware if you loaded it into ISE7 and targetted an XC4VSX55.
So it's not quite clear to me that, if you'd devoted effort to reverse engineering the bitstream format on the XC3000 series, it would be any use at all for Spartan-3; whilst a compiler targetted to 386 remains a moderately useful artefact even on an Opteron, since the Opteron will run the 386 software at a useful speed.
[that 'at a useful speed' is to remove the hideous, though amusingly baroque, spectre of using a Free toolkit targetting XC3000, and running the result in an XC3000 implemented on a large Spartan-3]
: > This has been discussed : > many, many times here and I still don't see any open source tools that : > are worth using.
: You probably use a lot of open source tools allready : - spice : - espresso (which is part of ISE, IIRC) : - gcc (which is part of EDK) : - tcl (which is part of allmos every EDA tool around that does not use a : lisp dialect instead)
- make (for when you get fed up with the ISE gui or need more flexibility)
- python/perl/... (for when you get bored writing glue hdl or logic etc directly)
- cvs et. al.
- many many more
Okay some of the above are very general, but some of them form key parts of many peoples toolchains. Wouldn't it be nice if OSS could one day form a usefull part of the toolchains closer to the FPGAs...
Sorry I can't resist it :-), but have you send them a testcase? do they know what is causing it? can you reproduce the crash? have you tried 6.0b? I am not trying to give a lecture since I have been cursing some of their &^£%=&( tools as well but I do know that debugging a piece of code as complex as Modelsim/NCSim/Aldec etc must be an absolute pig. Most if not all EDA companies will quickly bring out a patch release if you find a serious bug since this is their bread and butter. Your Modelsim can't be crashing randomly for no reason unless your PC is being hit by high energetic particles :-) If you can't send your source code them consider sending them an obfuscated version, and/or a compiled version (using the -nodebug if required) and/or set up and NDA, run your code on another PC, another OS, try using the command line version (vsim -c). Write a bit of Tcl which loops around your testbench repeatedly, then during the test read your mail, play some MP3 etc and see if this might be affecting Modelsim. Alternatively, get one of the Modelsim FAE's to visit you and sit next to you for a day while you re-run your testbench, you are(?) paying maintenance for it :-)