free software/open source projects and FPGA?
Karl Berry
efforts relating to FPGA (because rms asked me to).
After searching in this group, wikipedia, etc., the one I've been able
to find is slipway/abits from Adam Megacz (Adam, are you still here?),
but from checking out the sources it seems development stalled a while
back, understandably enough since I gathered from the last post I saw
about it that the manufacturer didn't have much interest in the
hardware any more.
Are there any other ongoing projects? Any info greatly appreciated.
Thanks in advance.
Karl Berry (karl /at/ gnu /dot/ org)
Antti
AT40/AT94 is the only family with open bitstream information,
unfortunatly
Antti
Philipp Klaus Krause
Waht exactly are you looking for? Synthesis? Place & Route? While Icarus
Verilog is mostly aimed at simulation AFAIR XNF and EDIF synthesis work.
While the Icarus FAQ only mentions using Xilinx tools for subsequent
Place & Route, AFAIR someone wrote (rather primitive and inefficient)
tools for those steps, too and was able to get a simple design onto a
Xilinx FPGA that way.
Philipp
Jonathan Bromley
> 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
-jg
wrote:
<snip many points>
Besides those points, there are very important Time-Line issues :
FPGA vendors start tool research BEFORE they start the silicon, and
they are not about to tell anyone the details of their 2011 chips!.
That makes FPGA tools very different from PCB design tools, where
the target-issues have changed little and are obvious well in advance.
Because the tools are so critically coupled to the silicon, that
leaves only the silicon-agnostic areas, and there are some Open source
developments in those areas.
-jg
David Brown
There are various open source packages for FPGA programming that let you
use a high level language and generate Verilog and/or VHDL output, as
well as being useful for simulation and checking the correctness of your
design. The "big" one (a relative term) is MyHDL, which is Python based.
There are many others, often based on functional programming languages.
Functional programming is in many ways a better fit for high level
hardware design than procedural languages, but it's a niche area. And
since FPGA development is also a niche area, there are very few people
who are interested, competent, and have the time and energy to do open
source development in these languages. Thus many have come and gone
because they haven't been able to maintain a momentum of development.
Examples here include confluence (a bit unpolished, but even the
half-done development versions are usable).
Jan Decaluwe
> 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.
I agree with your analysis.
In the short and medium term, I believe that a balanced
approach like the one from www.sigasi.com is the most
sensible. The product consist both of proprietary and open
source code. Open source is used systematically whenever
possible, for maximal cost-effectiveness and productivity.
However, there is always a company behind it that does the
integration and testing, and guarantees quality and support.
In the longer term, things will depend on whether hardware design
becomes a "mainstream" software development technology.
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com
ajjc
I take it you are interested in full-up synthesis/mapping/P&R tools
and not IP.
Here are some links to look at, besides the ones already mentioned in
this thread:
http://www.verilog.net/free.html
http://sourceforge.net/projects/signs/
http://www-labsticc.univ-ubs.fr/www-gaut/
As far as the core optimization/tech mapping goes, there is ABC from
Berkeley
http://www.eecs.berkeley.edu/~alanmi/abc/
and there is VPR from UToronto for place and route
http://www.eecg.utoronto.ca/vpr/
It would be good to have an open source stack to take in
a language(Verilog,VHDL,C,SystemC,...) and produce an RTL subset
that is like a universal assembly language and that goes into the X&A
toolsets
for device specific mapping, optimization, place&route and bitstream
generation.
alan