Where is Open Source for FPGA development?

In news:1174904051.342594.320050@e65g2000hsc.googlegroups.com
timestamped 26 Mar 2007 03:14:11 -0700, Kolja Sulimma
<ksulimma@googlemail.com> posted:
"[..]

[..] Antoher one is a recent paper on a GI workshop that show how
easy it is to extend the synthesizable
subset of VHDL. They presented a VHDL to VHDL preprocessor that
allowed you to use more constructs in your
synthesizable code than Synopsys supports. [..]

[..]

Kolja Sulimma
(I did EDA research for years)"


Hello,

Could you provide more details on this please? How does it compare to
the behavioral VHDL synthesizer advertised in Petru Eles & Krzysztof
Kuchcinski & Zebo Peng, "System Synthesis with VHDL", Kluwer Academic
Publishers, 1998?

Regards,
Colin Paul Gloster

On Mar 26, 3:19 am, psihode...@googlemail.com wrote:
[...]
>
> So, any idea, how can we change this situation?

Pick a project and help!

Just one suggestion:

http://iverilog.wikia.com/wiki/Main_Page

Cheers,

Guenter

psihodelia@googlemail.com writes:
> Today I see no alternative to use Xilinx or Alteras Web Packs. Both
> are in a very sad state. As Linux or PowerPC user you cannot develop
> your FPGA design with this tools.

I'm using the Xilinx tools on Linux (but on x86, not PowerPC), and they
seem to work fine for me.  I haven't yet used the Altera tools on
Linux, but I've been told that they work fine also.

> On x86 or on Windows they are very
> buggy, slow, and unproductive as well.

On Linux x86 they don't seem buggy, slow, or unproductive.  Well,
maybe slow, but that's a subjective thing.  What's the basis for
comparison?

> So, any idea, how can we change this situation?

I doubt that you're going to see tools natively hosted on PowerPC,
especially now that Apple has gone to x86.  But Xilinx seems to take
bugs and performance very seriously.

> Will we meet the time
> of Open Source development tools for programmable logic devices?

Maybe someday, but not soon.  Even if Xilinx and/or Altera did make the
details of the internal architecture and bitstreams public, developing a
complete FPGA tool chain appears to be a task at least three orders of
magnitude larger than building a C++ tool chain, and there aren't that
many open source C++ tool chains.

I don't want to single out anyone in particular, but there seems to be a
whole lot of relatively unfounded criticism of the Xilinx software in
this newsgroup.  It's true that I've found bugs in it from time to time,
but I've been able to work around them, and Xilinx support has been
quite helpful.  I'm not aware of any other comparably sized piece of
software that is particularly more robust.

I think constructive criticism of the software is worthwhile, but
just saying that it is too slow and buggy to use is clearly both
unhelpful and factually incorrect.

Eric

Eric Smith wrote:
>> Will we meet the time
>> of Open Source development tools for programmable logic devices?
> 
> Maybe someday, but not soon.  Even if Xilinx and/or Altera did make the
> details of the internal architecture and bitstreams public, developing a
> complete FPGA tool chain appears to be a task at least three orders of
> magnitude larger than building a C++ tool chain, and there aren't that
> many open source C++ tool chains.

Since code compilers are relatively linear, the primary difficulties are 
properly parsing the code and recognizing optimizable patterns, somewhat 
like synthesis and mapping for programmable logic. Place&Route on the other 
hand is very chaotic with many startup parameters defined as random values 
just like neural networks... the amount of work and back-pedaling that 
happens behind the scene to produce the post-PAR design is impressive and 
there probably are only a few handfuls of people world-wide who are capable 
of designing such algorithms yet retain their sanity.

> I don't want to single out anyone in particular, but there seems to be a
> whole lot of relatively unfounded criticism of the Xilinx software in
> this newsgroup.  It's true that I've found bugs in it from time to time,
> but I've been able to work around them, and Xilinx support has been
> quite helpful.  I'm not aware of any other comparably sized piece of
> software that is particularly more robust.

The ISE Navigator is a simple text editor with a few tree-views and 
miscellaneous eye-candy but it still manages to crash a few times per week. 
The Schematic editor is rather plain as well yet it crashes quite readily 
so I completely gave up on schematics after ISE 7.1. XST appears to have 
some severe syntax error intolerance and readily crashes instead of 
reporting the said syntax or malformed construct errors, leaving the user 
oblivious to the actual cause. My main complaint about PAR is extremely 
inconsistent runtimes for a given design... anywhere from 5 to 30+ minutes 
for one of my smallest projects.

ISE tools crashing instead of reporting errors (like declaring an entity 
inside an entity because I forgot to swap 'entity' for 'component' in a 
black box component declaration) is the most obscure and annoying time 
waster in my book, inconsistent runtimes is a close second. Most other 
obscure crashes I have encountered were cleared by rebuilding everything, 
this makes design partitioning very much pointless.

> I think constructive criticism of the software is worthwhile, but
> just saying that it is too slow and buggy to use is clearly both
> unhelpful and factually incorrect.

I have not played with Quartus much but building a 95% full EP2C8 on a 
2.4GHz Celeron took a steady 10-12 minutes while building a 15% full V2P30 
on a 3GHz P4 takes a random amount of time over 20 minutes and sometimes 
would not even complete overnight. Given the much higher vacancy rate and 
lower system clock target on the V2P along with the faster computer, I 
would have expected ISE to complete faster for a similarly sized design. I 
have tried tweaking ISE options to make builds quicker but ~20 minutes is 
pretty much the best I have ever been able to get for that build.

Quartus and its back-end tools have never crashed on me for any reason 
whatsoever over the few months I used them while ISE still crashes on me 
for random reasons even though I have been learning to work around its 
shortcomings for the last three years. If I had to pick FPGAs based on 
vendor tools alone, I would seriously consider focusing on Altera's... but 
I generally prefer Xilinx's architectures so I really wish Xilinx would 
catch up in back-end maturity/stability... without sacrificing even more 
wall-clock performance.

Daniel S. wrote:
> The ISE Navigator is a simple text editor with a few tree-views and
> miscellaneous eye-candy but it still manages to crash a few times per
> week.

I haven't had a crash in Navigator in perhaps 1000 hours of using various
releases.  I have had other ISE tools abort with internal errors.

> The Schematic editor is rather plain as well yet it crashes
> quite readily so I completely gave up on schematics after ISE 7.1.

I've never used the Schematic Editor, so I can't comment on its
quality (or lack thereof).  It's clear that HDL support is a higher
priority for Xilinx than schematic entry.

> XST appears to have some severe syntax error intolerance and readily
> crashes instead of reporting the said syntax or malformed construct
> errors, leaving the user oblivious to the actual cause.

I used to see that in 7.x, but haven't seen it much in 8.x and 9.1.
Maybe 7.x trained me not to do things that it didn't like.

Although it is obviously desirable for a tool to provide a good report
of a syntax error rather than crashing, I'm much more concerned about
ensuring that the tool does not crash for valid input.

> My main complaint about PAR is extremely inconsistent runtimes for a
> given design... anywhere from 5 to 30+ minutes for one of my smallest
> projects.

I haven't experienced that much variation; I've only seen about a 2:1
range.  However, I'm not convinced that expecting consistent timing
is realistic; a small change to your input may cause a siginficant
difference in the routing difficulty, especially if you have tight
timing constraints.

Eric

Eric Smith wrote:
> Daniel S. wrote:
>> The ISE Navigator is a simple text editor with a few tree-views and
>> miscellaneous eye-candy but it still manages to crash a few times per
>> week.
> 
> I haven't had a crash in Navigator in perhaps 1000 hours of using various
> releases.  I have had other ISE tools abort with internal errors.

The bulk of these crashes happened when I (mostly accidentally) click ERROR 
or WARNING links that cause PN to open a browser tab... and when these tabs 
do not crash PN, I usually get no answer record for the error or warning in 
question.

>> The Schematic editor is rather plain as well yet it crashes
>> quite readily so I completely gave up on schematics after ISE 7.1.
> 
> I've never used the Schematic Editor, so I can't comment on its
> quality (or lack thereof).  It's clear that HDL support is a higher
> priority for Xilinx than schematic entry.

Back then, I used schematics only to avoid having to code boring top-level 
VHDL port maps... but the frequent crashes and other annoyances (like zero 
portability) quickly convinced me that I would be better off wrapping 
everything up in VHDL.

>> XST appears to have some severe syntax error intolerance and readily
>> crashes instead of reporting the said syntax or malformed construct
>> errors, leaving the user oblivious to the actual cause.
> 
> I used to see that in 7.x, but haven't seen it much in 8.x and 9.1.
> Maybe 7.x trained me not to do things that it didn't like.
> 
> Although it is obviously desirable for a tool to provide a good report
> of a syntax error rather than crashing, I'm much more concerned about
> ensuring that the tool does not crash for valid input.

An extra semicolumn at the wrong place can crash XST but these are often 
hard to spot since any other programming language would silently accept 
them. Over the last two or three years, I wasted over a month hunting down 
syntax-induced crashes, about a week of it last summer because XST got 
confused while processing BRAM inferences... it took me a few days to 
figure out the link between crashes and memory inferences and many more 
tweaking the inference until I got what I wanted without crashing XST or MAP.

The last time I ran into simple syntax errors I was unable to spot within 
2-3 minutes, I simply ran the thing through ModelSim's compiler... both a 
fair bit faster and much more reliable.

>> My main complaint about PAR is extremely inconsistent runtimes for a
>> given design... anywhere from 5 to 30+ minutes for one of my smallest
>> projects.
> 
> I haven't experienced that much variation; I've only seen about a 2:1
> range.  However, I'm not convinced that expecting consistent timing
> is realistic; a small change to your input may cause a siginficant
> difference in the routing difficulty, especially if you have tight
> timing constraints.

I have two ~15% designs targeted to the same 2VP30, one has ~100ps slack on 
a 5ns timespec while the other has ~1ns slack on a 10ns timespec. In both 
cases I get similarly volatile 5-30 minutes PAR runtimes even if I simply 
"Rerun All" - the only thing that changes between runs in this case is 
random initialization values within the PAR algorithms.

Thankfully, computers get faster and the C2D-E6850 is only a few months 
away... that would be a substantial improvement over my current P4-3G.

On Mar 25, 6:19 pm, psihode...@googlemail.com wrote:
> Many engineers today have Linux on Desktop as main-OS. Many engineers
> today use Open Source products because of their quality, stability,
> and configurability.
>
> Today I see no alternative to use Xilinx or Alteras Web Packs. Both
> are in a very sad state. As Linux or PowerPC user you cannot develop
> your FPGA design with this tools. On x86 or on Windows they are very
> buggy, slow, and unproductive as well.
>
> So, any idea, how can we change this situation? Will we meet the time
> of Open Source development tools for programmable logic devices?

Here we go again ...

=a

On Mar 27, 12:06 am, "Daniel S."
<digitalmastrmind_no_s...@hotmail.com> wrote:

> Back then, I used schematics only to avoid having to code boring top-level
> VHDL port maps... but the frequent crashes and other annoyances (like zero
> portability) quickly convinced me that I would be better off wrapping
> everything up in VHDL.

emacs VHDL mode to the rescue.

oh, yeah, it's open source.

> An extra semicolumn at the wrong place can crash XST but these are often
> hard to spot since any other programming language would silently accept
> them.

I take it that you don't simulate much, if at all ...

> Over the last two or three years, I wasted over a month hunting down
> syntax-induced crashes, about a week of it last summer because XST got
> confused while processing BRAM inferences... it took me a few days to
> figure out the link between crashes and memory inferences and many more
> tweaking the inference until I got what I wanted without crashing XST or MAP.
>
> The last time I ran into simple syntax errors I was unable to spot within
> 2-3 minutes, I simply ran the thing through ModelSim's compiler... both a
> fair bit faster and much more reliable.

you should have used ModelSim FIRST !

-a

Andy Peters wrote:
> On Mar 27, 12:06 am, "Daniel S."
> <digitalmastrmind_no_s...@hotmail.com> wrote:
> 
>> Back then, I used schematics only to avoid having to code boring top-level
>> VHDL port maps... but the frequent crashes and other annoyances (like zero
>> portability) quickly convinced me that I would be better off wrapping
>> everything up in VHDL.
> 
> emacs VHDL mode to the rescue.
> 
> oh, yeah, it's open source.

My primary OS is WinXP... but for all my boring regexable copy-paste jobs, 
I started using remote-X'd Nedit sessions about a year ago. Regex replace 
is definitely a godsend for portmaps and batch portmap signal declaration.

>> An extra semicolumn at the wrong place can crash XST but these are often
>> hard to spot since any other programming language would silently accept
>> them.
> 
> I take it that you don't simulate much, if at all ...
 >
 > you should have used ModelSim FIRST !

It depends on what I am doing and why.

Until my larger designs are sufficiently advanced to start producing 
meaningful simulation results (I call this the approximation phase), I am 
more interested in tracking resource utilization and static timing 
evolution than correctness: achieving absolute correctness in the first 
pass (the one most susceptible to typos and syntax errors) is useless if 
the implementation fails to meet target timings or exceeds the logic 
budget. It is during these passes that XST&all die on me the most and 
Modelsim as a simulation tool is irrelevant - that's why it took me so long 
to think of using it as a syntax checker.

> > emacs VHDL mode to the rescue.

> My primary OS is WinXP... but for all my boring regexable copy-paste jobs,
> I started using remote-X'd Nedit sessions about a year ago.

That sounds very cumbersome. Are you aware that Emacs (and other FOSS
editors) is
available for WinXP? (Of course than you must to call it GNU/WinXP)

Kolja Sulimma