In the comments to an excellent Kevin Morris blog on FPGA tools, one writer calls for open-source tools. We (at Impulse Accelerated Technologies) kind of like the idea. A new technology is accepted much quicker when it has more users, particularly when they have skin in the game -- they're helping to support the infrastructure. If anyone has ideas on open-sourcing elements of the FPGA tool flow, or all of it, please contact me.
Now for the hurdles. Visual Studio costs $100 (maybe $600 if anyone out there still pays retail). It's a great tool. It lets you compile all the way to a CPU, author the next Angry Birds, and then go buy your Maserati. Alternatively, you can avail yourself of Eclipse, Intel, or other tool flows that are equally good and range from free to about the same pricing.
Open-source tools would be good for the FPGA industry.
Turning to the programmable device domain, the good news is that FPGA companies let students and small users get started for free with competent WebPack editions. Continuing the good news, the full-up versions of these tools range from free (for smooth talkers with plenty of potential sockets) to $2,995 a year. This is not as cheap as the CPU tools, but it's also not an order of magnitude worse.
Now let's talk about the ugly side of things: device independence, ease of use, and full-up cycle-accurate simulation. I'd argue that, in addition to the basic design tools, most users need all three features, and they need them for darned near free.
Device independence -- not being locked in to one brand -- typically means learning a high-level language (HLL) layer that lives above the hardware description. Open-source efforts at this include Streams C, which was the grandfather of our Impulse C. Streams C, which was developed in a national research laboratory, had more than 1,000 downloads and was paid for by your tax dollars. It was not a true product of the bazaar, but it was a darned good open-source tool. The commercial tools that arose at the same time cost anywhere from $10,000 to $120,000 per seat (that's not a typo).
Ease of use is another story. Many teams using an FPGA to offload their CPU hire some type of help in their first design. The good news is that it is generally not needed for designs beyond the first one. Still, I've sat through the tutorial on how to partition between an on-chip processor core and the chip hardware, and there are a heck of a lot of steps. Complex tools are the bane of the iPhone generation. They won't tolerate extended training courses to learn a new processor type.
Personally, I would welcome an open-source solution that enabled the number of device independent designs to explode. More designs equal more fun for engineers and quicker evolution for products. I'd love this to happen via open-source work, and I welcome a dialogue on how this could happen.
One last point: We think this may require the sponsorship of brands A and X in a common tool layer. What do you think?
@Jezzmo My experience has been the HW only solutions are much more robust -
Nothing like having a safety certified tool like Modelsim/Questa do coverage on a design to uncover hidden issues in testing/coverage, plus the much greater functional simplicity of a logic only design. In addition with HW it is possible to make buffers that do not overrun into the code space in a fault mode, while this is much more difficult with much embedded SW.
-- Open Source and Libraries -- Where this can get important is FAA/CAA or other certified software -- where one has to have every aspect of every tool used under version control for the higher levels of criticality. It can also be important where security is important. (Mil/Govt, Banking/Finance etc) Most developers are negligent when it comes to version control of every piece of code used to touch a product in development. Recall several compiler vendors going under, leaving the company no choice but to re-write a code base - the same is true for open source projects that get abandoned, or support for that tool wanes. Own the source, or pay at some point down the road has been my past experience.
Adam Taylor 1/25/2013 2:58:26 AM User Rank Blogger
Re: it would be nice
This is very true I have worked on numerous projects were we have replaced the previous software solution in a safety critical system with FPGA's. Tools like formal equivelence checking making it easy to ensure that the functionality you describe in the RTL survives through synthesis and place and route with no hidden issues.
But talk to safety critical bods and they don't like software because it fails in spectacular ways when you least need it to after many years in service because fault coverage in software simply isn't mature enough to be convincing
Many of these 'leet hackers'see moving to hardware designs as a threat to their 'leet' stnatus
Brian
I don't think that partitioning a design between processor and FPGA is particularly difficult,what is difficult is getting over the 'everything MUST be done in software because that is what we know'mentalliy, and it seems the 'leet hackers' of the software community are particularly resistant to any change
it would be awesome to have good, open source tools that ran natively on 64-bit Linux. if it needed to be compiled, then it should use readily available build chain on current distributions, not 10 year old Red Hat. really it should be platform independent for that matter. free as in beer or free as in speech, i'm not picky.
for me specifically, a modelsim se class simulator would be the first on my wish list. this would be vendor independent, support mixed language and be fast. just like modelsim now, you would have to compile the vendor libraries you are using for cores and primitives. simulation turnaround time can be just as important as implementation turnaround time.
these days there are too many silicon features used in everyday FPGA designs to have perfectly vendor independent and fully portable designs. I try to improve this situation by using generic wrappers around vendor cores when possible (FIFOs, BRAMs, I/O, clocking, Gb Xcvrs). other things you can do are to segregate all vendor IP and interfaces away from your core logic. but no solution is perfect.
i see vendor dependence (lock in) more as using vendor IP and primitives than the actual implementation tools themselves (although that is lock in in a sense as well).
implementation tools by their very nature must be target architecture aware, since they are all different to be competitive. so even if there were open source synthesis engines and P&R tools, you'd somehow have to get ahold of all of the device information needed.
synplify is a killer synthesis tool, but it also comes with an outrageous price tag. hard to justify unless you are a big company or have a big customer. As of Quartus 10, Altera now recommends their own synthesis engine over any other. Xilinx, unfortunately, can't claim the same thing with XST. although it gets the job done.
William: One of the very real things that one must cross with an open source tool that relies on open source libraries is the "Scavenger Hunt" that one may have to go through to really have all the source code checked into the company version control system, if one really needs to "take ownership of the code".
My guess is that the vast majority of open-souce software users download a binary for their OS of choice, rather than attempting to build from source.
(edit) And, seriously, most users don't care about the free-as-in-speech aspect of open-source software. They just want it to be free-as-in-beer.
Certainly, there's a very vocal group of open-source users who will only use Linux and will only use GPL software and all of that, but they're the minority. The rest of us just want to get work done.
One of the very real things that one must cross with an open source tool that relies on open source libraries is the "Scavenger Hunt" that one may have to go through to really have all the source code checked into the company version control system, if one really needs to "take ownership of the code".
Open source front end gives you device independence and portability.
Right up until you need to instantiate primitives. And who doesn't use DDR flops or LVDS pins or clock managers in a design?
Certainly the current synthesis tools should be able to infer IDDR and ODDR elements, and LVDS can be handled at the place-and-route end (single-ended pin in the port list, when doing constraints the pin can be marked as differential, and I think this can already be done).
But different clock managers get tricky to abstract. Perhaps a library which has a "clock manager element" which when compiled knows about the target architecture and chooses the proper primitive.
But then there's another layer of bullshit between the design and the designer, and really, perhaps a poll needs to be taken: how many companies are really concerned about portability between FPGA vendors or even families within a vendor?
The reason I say this is that for stuff which uses the high-speed serializer and deserializer interfaces, with the various delay elements and the rest, you really do need to be designing at the specific primitive level.
I expect that development times will continue to diminish, average engineers will use the tools without manuals, and that when anyone gets stuck on a project they will call in an expert.
Don't blame the tool if something ends up being suboptimal. Use your superior reasoning powers and knowledge to guide the tool and achieve an optimal solution.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
