One of the reasons free software is important is so that you can
> control your computer and make sure you know what it does.
> It's not enough to be able to see what someone claims is the
> source code for the program you are using. To trust it, you have
> to be able to compile it yourself.
>
> As hardware becomes more complex, the same issue may arise: how do
> you know what you hardware really does? Free hardware designs
> could be part of the solution, but we can't all afford fab lines,
> so could we really solve the problem completely?
The bigger problem is the complete lack of an open-source flow from RTL to implementation. There is simply no GCC equivalent for compiling digital logic -- every ASIC and FPGA designer is at the mercy of commercial tools on the font-end. (My biggest pet-peeve is FPGA synthesis. FPGAs have had dual-port RAMs for ~7 years now, yet we still can't infer dual-port block RAM from HDL. Arggh!)
One hurdle to open-source synthesis and place&route is proprietary architectures. The major FPGA vendors refuse to disclose the underlying details needed to for a quality PAR tool or physical synthesis.
But oddly enough the biggest roadblock to open-source EDA is ourselves. For some reason or another, there is an apparent lack of interest and motivation. Just a few examples:
Every couple of months the topic of open-source tools arise. Generates quite a bit of discussion, then dies as quickly as it started.
formatting link
formatting link
This thread started 4 days ago, and sums up the view of open-source in EDA. :-(
formatting link
With Confluence under GPL, I have yet to receive a single bug report or source code contribution.
formatting link
?articleId=18402723
Icarus Verilog, the foremost open-source Verilog implementation, still only has one active developer.
formatting link
The only semi-successful FPGA packing, placement, and routing project haulted activity in March, 2000.
formatting link
The one person who came the closest to reverse engineering the Virtex bit stream -- the critical step for physical synthesis -- became frustrated with the lack of support and interest from the FPGA community, and finally closed shop on 12/24/2003.
Merry Christmas.
formatting link
What can we do to improve open-source EDA?
Regards, Tom
--
Tom Hawkins
Launchbird Design Systems, Inc.
Home of the Confluence Logic Design Language
http://www.launchbird.com/
The problem is not just getting RAM inference, it is getting all synthesis tools to accept the same code and produce the same hardware semantic (similar enough in implemenation so they function the same).
You will be happy to know that both VHDL (IEEE 1076.6) and Verilog (IEEE 1364.1) have standardized modeling styles that support RAM inference.
The next step is to get EDA vendors to implement these standards. When EDA vendors support a standard they are making an investment. They need to know their investment is important and will get them a return.
The only way for an EDA vendor to know if a feature is important is for their users to tell them it is important. So while open standards/tools are important, I would encourage all to take a breather and let your current vendors know what is important to you. A real good time to do this is when you are renewing your maintence or buying new licenses ($$$ tend to amplify your message).
Unfortunately IEEE standards are not published for free, however, I have written a couple of papers on 1076.6 and they are free available at:
formatting link
Cheers, Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Perhaps the reason is that hardware guys don't have the skill sets to create these tools? I know that my attempts are writing even the simplest programs for Windows and for Mac OS X are pretty lame, and the learning curves are quite steep. I mean, it took waaaay too long for me to write a simple Mac OS X GUI program that sent a report to a USB device when I clicked a button. It's not that I don't know C -- I use C for embedded micros all the time -- but the APIs for each OS present a significant hurdle.
It's not that we can't learn how to do this. I think it's simply a matter of time and priorities. Most FPGA engineers are designing hardware for a living and there's simply not enough time in the day to take on a major programming effort.
Contrast this to the (stereotype of the) open-source software developer. Linus Torvalds started writing Linux as a college student, and a lot of open-source programmers are in (or got their start) in university. The student's motivations (beer, girls/boys hacking) certainly differ from those of the professional engineer (paying the mortgage, paying the car payment, paying the insurance, paying the rest of the bills). To be honest, I've never really understood the motivation behind giving away one's work.
I would imagine that the skills required to write an effective FPGA-fitting algorithm are beyond those of the typical open-source hacker. If such a hacker exists, then it seems to me (s)he'd be better off working for Altera or Xilinx (or Mentor or Synplicity or Synopsys) getting paid real money.
As as for "free" vs "open source" -- they ARE two different things. Obviously, I have no problems with either; I depend on emacs as an editor and I use Mozilla for web-browsing and e-mail. However, I don't particularly care if EDA tools are free OR open source. I *do* care if they don't work, or are inadequate, because I have work to do! Of course, I also care about "reasonably priced," since if I can't afford the software, I can't afford the software. A couple of years ago, I looked into sdcc because the Keil 8051 compiler is expensive. However, sdcc simply didn't work, and it didn't look like there was any active development happening, so I sprung for the Keil tools and haven't looked back.
A common argument is "I'm a starving college student and I can't afford to pay the $$$$ for FPGA tools." A very valid argument, too, at least in the old days, although the argument was weakened when Brands A and X released their free tools. Both have "university programs." Part of the cost of software is the support and I would guess that the support staffs of A and X don't want to waste their time answering newbie questions (hence, the web support stuff and the newsgroups) when there are serious customers with serious concerns to be addressed.
You mention Icarus Verilog. I downloaded and installed the IVIonOSX packaged, and was immediately frustrated. (The open-source community really needs to get its shit together regarding documentation!) Plus, the command-line iverilog wouldn't compile some V2001 code, which makes it useless. I suppose I could send Steven the offending code and ask him to support whatever feature breaks things, or I suppose I could hack the code myself and submit my patches to Steven. As for the former, that's laziness on my part, although Steven indicates that V2001 support is limited. As for the latter, IANAP!
To be honest, there's really no point in fussing with with this when I can use the free (as in beer) Xilinx version of ModelSim. Yes, it's "limited" but for the simple things I do at home there isn't any real penalty.
As for FPGA tools, I'm not sure whether the push for open-source tools is about the cost of the tools, access to the source, or simply because people want to run the tools on their Linux box. (I'll wager that Option 1 is the real reason. Running on a Windows box is a detail.) I've always believed that you buy the computer (and install the OS) that runs the software you need to do your job, rather than trying to make do with inadequate tools because you have a moral or idealogical viewpoint.
(Aside: Hey, Mentor Graphics, Xilinx and Altera: I hate Windows! I want you to write your software for Mac OS X! Seriously!)
Finally, an argument FOR free FPGA tools. These tools are a MEANS TO AN END, not an end in themselves. One uses X's FPGA tools ONLY because they are going to buy a boatload of X's FPGAs, and for that reason it makes sense to provide the software for free (but charge for direct tech support). Of course, the Real Big customers get the software for free and buy enough chips to make 'em cheap; it's the small guys who eat the cost of the software and pay more for the same chips.
Don't get me started on that abomination known as FlexLM.
You should take a look at the source code for gcc sometime ;)
Perhaps if you were in my shoes, you would have made that choice. I did not. ;)
If you're really pushing the limits of what reconfigurable logic can offer, the tools will *never* do everything you want. The question then becomes whether or not you will get sued for improving the tools to meet your needs.
I trust software as long as it works and doesn't bite. I trust GNU software, not because I can compile it, but because it works better than any alternative for many of the things that I do.
By using design rules and a simulator you trust to generate and verify synth code.
I agree that is annoying. But there is more than one way to skin a cat. If I can't infer a primitive from code, I have the option of not using it. A pseudo dual-port works fine for synch fifos and is portable across brands.
I agree that this is a problem for open-source tool designers, but at least one FPGA designer spends most of his time at the front end, not in PAR. The vendor tools are adequate for some designs as is.
Tool development and QA is a full-time job. While I agree with the open-source philosophy, until I am retired, trying out beta level tools is just a hobby.
A simple Confluence reference design worked all the way through simulation and synthesis might help FPGA guys "get it". The same example done in vhdl or verilog would be a plus.
Same answer as above. Qualified FPGA+tool designers are rare, and most are working for a living.
Consider focusing on the front end. Gather a few complete examples to get FPGA guys interested.
In this context physical synthesis still means technology dependent placement and it doesn't require much more internal knowledge than wiring information on the fpga (in addition to lookup table programming and placement configuration which is somewhat exposed in data sheets already). The result is yet another partially placed netlist which still requires placement finalization and detailed routing (and of course bit file generation). These last two steps do really expose what's going on in the chip and I don't think any FPGA company is going to let anyone write such tools.
Ok, maybe not that particular case, but most other configurations of dual-port RAM can be infered. In Verilog at least, isn't this a problem with the language rather than the FPGA tools (i.e. you can't write to the same variable from two different processes)?
Sure. I was more refering to that fact that due to the quality & size of some open source/free software projects, the bar has been raised significantly.
:-) I'm slightly bitter - as that's just what I want to do right now... Coregen is not an option ... Grrr..
In VHDL you could maybe do it with shared variables, but I've always avoided them to avoid shooting myself in the foot!
OK.. I thought you were saying that releasing software as either free or open-source implies you can't get revenue from it. There are an enormous number of people managing it though!
Cheers, Martin
--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt
Depending on the sort of work you do, it can sometimes be directly economically benificial for your employer if particular code is released as open source (for example, if you release something that other people will use and enhance, you get the benifits of their enhancements). Everything you write for your employer is owned by them, and in some contracts that also includes things you write in your own time that are related to your job (I guess this is some sort of protection against you moonlighting), but if you want to release some code as open source, you can always ask your employer for permission.
That can be a problem, as can NDAs and other such red tape.
Verilog does not have this restriction. I've searched the LRM and I've run testcases through two reputable implementations without complaints (ncverilog, icarus).
Hence my frustration. We can precisely describe a dual port block-ram in Verilog, yet the tools draw a blank. We can even preset RAMs with values, but most, if not all, completely disregard initial statements.
Given the size of their development staff and the prices they are able to charge, how can they still ignore important parts of the language standard?
I've asked Synplify, and they can infer two-read, one-write, two-clock RAMs currently. They plan to support the full two port functionality in future...
Initials are another thing though!
Cheers, Martin
--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt
You are correct. Although it is only ever supported for simulation. I can kind of understand why though. Take the following:
module test(c1, c2, a, b, d); input c1, c2, a, b; output d; reg d; always @(posedge c1) d in Verilog, yet the tools draw a blank. We can even preset RAMs with
Isn't this fixed in v200x? I do agree it's all a bit crap. Cheers, JonB
For some tools it can take a very long time to build a userbase. Step 1. You need to know about it. - I know about Confluence. Step 2. You need to have something suitable to try it with. - Maybe this summer... Step 3. It needs to be good enough. No idea... since I have not tried it yet. Step 4a. It needs to have bugs to give you bug reports :-) Step 4b. It needs to be incomplete to give you feature requests. Step 5. Bugs or feature requests that you can't easily fix might generate source code contributions. Take care when accepting contributions... When added you can not dual license (contribution is copyrighted by their author). But most contributors won't have a problem with that...
Compare with:
MySQL
Qt
Erlang (functional programming language, GPL:ed by Ericsson) and they have lots of people internally that uses it. - it slowly builds momentum... But there are a lot more people that use databases, create user interfaces, ...
GCC et al deal with this by requiring contributors to assign copyright, and it hasn't been a problem for them.
How many FPGA/ASIC designers do we reckon are out there? I'm sure I've heard Xilinx saying they have a couple hundred thousand installations of their s/w. That's quite a big target audience.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.