On Nov 7, 6:53*pm, Karl Berry <kberr...@gmail.com> wrote:
> I'm trying to look into the status of free software/open source
> efforts relating to FPGA (because rms asked me to).
Open-source efforts have not served us well in the
FPGA and electronics design/verification community.
There are a few beacons of usefulness (Icarus Verilog,...)
but, for the most part, available open-source tools just
don't provide the level of productivity and flexibility
that real users need.
There are, I think, many reasons why the match is not good.
In the software development community, there is a big
overlap between the skills of tool users and tool developers.
In EDA-land, although the users are likely to be very
software-savvy they are rather unlikely to be competent
developers. Those users, however, are (rightfully and
necessarily) very demanding of their tools; they have
deadlines to meet, products to get out the door and
businesses to run; 80%-finished tools are completely
useless to them. So there is a big mismatch between
the community's expectations of their tools, and its
ability to develop them (or to engage with developers,
or to engage with the open-source development process).
A couple of specific examples:
- ghdl
I have no idea whether it's any use or not. The fact
that there is no vigorously maintained binary distribution
means that it's useless to me. The idea of building my
tools from source code fills me with horror - I'm not
competent to do that with the kind of reliability that's
needed for tools that are critical to my daily work.
But the community of potential ghdl users is not large
enough to justify the considerable effort of maintaining
a distribution that would give me the same level of
convenience and confidence that I get with commercial
tools.
-gcc
Yes, I know gcc is fantastic. I use it all the time.
But as an
FPGA user I would love to be able to port
gcc to different, way-out embedded target architectures.
I know it can be done. I know that gcc is about as
flexible as it gets for creating new back-end targets.
But it requires guru-level expertise even to start
work on a port. I gather that lcc is easier to
port, but I've now been scared off even trying.
Once again there's a mismatch between the users'
expectations and needs, and the skills that those
users could bring to the tool development process.
I don't really know what can be done about this.
I think there's a risk of the open-source evangelists
being flushed with their own success in other fields,
and giving the impression of extreme smugness -
"all you need to fix this problem is a good Eclipse
plug-in"... yeah, right. There's certainly a risk
of the EDA community being insufficiently articulate
about the very complex requirements they have for
their development tools, and therefore failing to
communicate effectively with open-source developers.
By contrast, commercial developers respond to
revenue streams and therefore it becomes their
responsibility, not the users', to establish lines
of communication that reflect customer needs back
into the development process. In the open source
world, I suspect, this has worked primarily because
the developers are also users themselves. It is
a mistake to think that, because EDA tool users are
very technical people with a good level of software
expertise, they are also able to communicate
effectively with tool developers; it is an equally
gross error to assume that, because you're a smart
software developer, you naturally understand all the
needs of a particular user group.
Much humility and flexibility will be needed from
both sides if we are to make real progress.
--
Jonathan Bromley