One issue about free hardware

[Tom Hawkins]

On Saturday 08 May 2004 05:00 pm, Richard Stallman wrote:

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:

1. Every couple of months the topic of open-source tools arise.
Generates quite a bit of discussion, then dies as quickly as it
started.

http://www.opencores.org/forums.cgi/cores/2003/09/00014
http://archives.seul.org/geda/dev/Nov-2003/msg00012.html

This thread started 4 days ago, and sums up the view of open-source in
EDA. :-(
http://groups.google.com/groups?q=comp.arch.fpga+status+open+source+tools


2. With Confluence under GPL, I have yet to receive a single bug
report or source code contribution.

http://www.eedesign.com/news/showArticle.jhtml;jsessionid=TIARDDA1PTO1CQSNDBGCKHY?articleId=18402723


3. Icarus Verilog, the foremost open-source Verilog implementation,
still only has one active developer.

http://www.icarus.com/eda/verilog/


4. The only semi-successful FPGA packing, placement, and routing
project haulted activity in March, 2000.

http://www.eecg.toronto.edu/%7Evaughn/vpr/vpr.html


5. 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.

http://neil.franklin.ch/Projects/VirtexTools/Logfile


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/

 

[Jim Lewis]

Was: Re: One issue about free hardware

Tom,

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!)

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:
http://www.synthworks.com/papers

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Andy Peters]

tom1@launchbird.com (Tom Hawkins) wrote in message news:<833030c0.0405100613.55cb6793@posting.google.com>...

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.

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.

OK, I'm done.

--a

 

[Adam Megacz]

Bassman59a@yahoo.com (Andy Peters) writes:

I would imagine that the skills required to write an effective
FPGA-fitting algorithm are beyond those of the typical open-source
hacker.

You should take a look at the source code for gcc sometime

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.

Perhaps if you were in my shoes, you would have made that choice. I
did not.

I *do* care if they don't work, or are inadequate, because I have
work to do!

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.

- a

 

[Jon Beniston]

(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!)

Yes you can.

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.

Well Magma & Synplicity seem to have got enough information to be able
to make physical synthesis tools.

What can we do to improve open-source EDA?

Nothing, hopefully. Some of us would still like to be able to earn a
decent living from writing software, you know?

Cheers,
JonB

 

[Jeff Cunningham]

Jon Beniston wrote:

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.


Well Magma & Synplicity seem to have got enough information to be able
to make physical synthesis tools.

Does Magma make tools for FPGA? I thought they were just asic oriented.
Anyone who used it for FPGA care to comment?

-Jeff

 

[Mike Treseler]

Tom Hawkins wrote:

Richard Stallman wrote:
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.

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.

As hardware becomes more complex, the same issue may arise: how do
you know what you hardware really does?

By using design rules and a simulator
you trust to generate and verify synth code.

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!)

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.

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.

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.

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:

1. Every couple of months the topic of open-source tools arise.
Generates quite a bit of discussion, then dies as quickly as it
started.

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.

2. With Confluence under GPL, I have yet to receive a single bug
report or source code contribution.

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.

3. Icarus Verilog, the foremost open-source Verilog implementation,
still only has one active developer.
4. The only semi-successful FPGA packing, placement, and routing
project halted activity in March, 2000.
5. 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.

Same answer as above.
Qualified FPGA+tool designers are rare,
and most are working for a living.

What can we do to improve open-source EDA?

Consider focusing on the front end.
Gather a few complete examples to get
FPGA guys interested.

-- Mike Treseler

 

[Jon Beniston]

Well Magma & Synplicity seem to have got enough information to be able
to make physical synthesis tools.

Does Magma make tools for FPGA? I thought they were just asic oriented.
Anyone who used it for FPGA care to comment?

They have a physical synthesis tool:

http://www.magma-da.com/c/@0GKYl0BeTX2k./Pages/PALACE.html

Cheers,
JonB

 

[ka]

On 11 May 2004 15:25:59 -0700, jon@beniston.com (Jon Beniston) wrote:

Well Magma & Synplicity seem to have got enough information to be able
to make physical synthesis tools.

Does Magma make tools for FPGA? I thought they were just asic oriented.
Anyone who used it for FPGA care to comment?

They have a physical synthesis tool:

http://www.magma-da.com/c/@0GKYl0BeTX2k./Pages/PALACE.html

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.

 

[Martin Thompson]

jon@beniston.com (Jon Beniston) writes:

(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!)

Yes you can.

With two clocks and two write ports!? Which tool does this and what is
the template HDL one has to use?

What can we do to improve open-source EDA?

Nothing, hopefully. Some of us would still like to be able to earn a
decent living from writing software, you know?

Open-source doesn't *have* to mean no-cost... and neither does free-software.

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

 

[Jon Beniston]

With two clocks and two write ports!?

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)?

Open-source doesn't *have* to mean no-cost...

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.

Cheers,
JonB

 

[Joe]

Tom Hawkins wrote:

What can we do to improve open-source EDA?

Regards,
Tom

For me, and I guess for a lot of people in this industry, contribute to
open source could be a legal minefield:

- In my job contract, it stated my employer own the copyright of designs
I done. So officially I cannot post any IP design/source code to public.

- Patent issues. Some of my knowledge might relate to patented products.
Release of such information could mean I could get sued.

And of course, usually I am too tired after work anyway ;-)

Joe

 

[Martin Thompson]

jon@beniston.com (Jon Beniston) writes:

With two clocks and two write ports!?

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)?

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!

Open-source doesn't *have* to mean no-cost...

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.

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

 

[David Brown]

"Joe" <joe_y@invalid_address.nospam.com> wrote in message
news:c7uafp$5cl$1$830fa17d@news.demon.co.uk...

Tom Hawkins wrote:

What can we do to improve open-source EDA?

Regards,
Tom


For me, and I guess for a lot of people in this industry, contribute to
open source could be a legal minefield:

- In my job contract, it stated my employer own the copyright of designs
I done. So officially I cannot post any IP design/source code to public.

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.

- Patent issues. Some of my knowledge might relate to patented products.
Release of such information could mean I could get sued.

That can be a problem, as can NDAs and other such red tape.

And of course, usually I am too tired after work anyway ;-)

And that is invariably a problem :-(

Joe

 

[Roger Larsson]

Tom Hawkins wrote:

2. With Confluence under GPL, I have yet to receive a single bug
report or source code contribution.

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, ...

/RogerL

--
Roger Larsson
Skellefteĺ
Sweden

 

[Jon Beniston]

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...

GCC et al deal with this by requiring contributors to assign
copyright, and it hasn't been a problem for them.

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, ...

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.

Cheers,
JonB

 

[Mike Treseler]

Jon Beniston wrote:

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.

That sounds a little inflated to me.
I would guess only 5-10 thousand in the US.

-- Mike Treseler

 

[Jon Beniston]

Roger Larsson <roger.larsson@skelleftea.mail.telia.com> wrote in message news:<HN7pc.59087$mU6.238562@newsb.telia.net>...

Tom Hawkins wrote:

2. With Confluence under GPL, I have yet to receive a single bug
report or source code contribution.


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 4c. It needs to be programmed in a language that your small
target audience have heard of! How many Verilog/VHDL coders also know
OCaml? C or Java and you might have a chance...

Cheers,
JonB

 

[David Brown]

"Jon Beniston" <jon@beniston.com> wrote in message
news:e87b9ce8.0405141709.5ef4798f@posting.google.com...

Roger Larsson <roger.larsson@skelleftea.mail.telia.com> wrote in message
news:<HN7pc.59087$mU6.238562@newsb.telia.net>...
Tom Hawkins wrote:

2. With Confluence under GPL, I have yet to receive a single bug
report or source code contribution.


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 4c. It needs to be programmed in a language that your small
target audience have heard of! How many Verilog/VHDL coders also know
OCaml? C or Java and you might have a chance...

That's certainly a point when you are looking for code contributions, and
for many open source projects it makes sense to consider that when choosing
the language. But for something like Confluence, I don't think that Tom is
looking for so much in the way of direct coding help at the moment -
feedback and ideas are important, along with contributions to the library,
examples and documentation (how many good Verilog/VHDL coders are also good
at "normal" software development, especially something as specialised as
implementing functional programming languages, regardless of the language?).
I am a great supporter of choosing the right language (or right tool of any
kind, for that matter) for the job - popularity might be one consideration,
but it's not the only one. In fact, why would anyone be interested in
confluence in the first place if they were not happy to consider new
languages? The choice of ocaml makes a lot of sense here, actually - it is
a functional programming language itself (with bits of imperitive language
added - sort of the opposite of Python, but for the same reasons), so it
matches the style of confluence programming well. It was actually top of my
"languages to learn when I have the time" list, but confluence sneaked in on
top...