What tools do you use ? Why ?

[psihodelia]

Hello all,
can you please tell us what tools you prefer? Please give some
arguments, why you like them.

I currently use very intensively Linux shell and GHDL compiler for
simulations and XST for synthesis.

GHDL is very fast and powerful. You can for example colorize your
files directly into HTML, call foreign functions (e.g. from C
library), and many more.

My VHDL projects have typical Linux-way directory tree structure:
../bin/ for binaries
../include/ for includes
../work/ for generated modules
../src/ for sources

inside src directory is a Makefile, which is automatically generated
by GHDL. In order to build a binary, I use "make sim" command. If I
need to create some additional component in other language (C or
Python), I use "foreign" declarations in VHDL code and link them using
GHDL, just like with well-known GCC. For example if you need to verify
your VGA-Controller Design, you can create a special C-function which
will create JPG file with the current frame.


For synthesis I use XST from Xilinx ISE. It is very simple to type:
"make syn; make load" and bitfile will be uploaded into an FPGA. For
communication with FPGA board, real-time visualization, and so on, I
use small Python scripts.

I use VIM as a text editor. It also helps me to be very productive and
to work remotely using SSH (e.g. it's nice thing to use VIM on your
cell phone like Nokia N200 which has Linux onboard).

So, this are my tools:
GHDL, XST, GNU Tools(make, bintools, bash, libc, etc.), VIM, Python,
GCC
and of course Linux itself.

Frankly, only XST is not under Open Source license and it mostly slow-
downs hole development flow because of XST's bugs and its poor
performance. All other programs I use are previously compiled using
optimization flags targeted my server's hardware.

What tools do you prefer? Why ?

 

[MikeShepherd564]

[deleted detailed description of what the poster uses]

What tools do you prefer? Why ?

Since you appear intent mainly on telling us what you use, I wonder if
this is just an introduction for telling us why your choices are
better.

Few people have experience of several tools which achieve similar
results. Perhaps those who teach can offer useful advice, but most of
us have a very limited view, as do you, so our "preference" is likely
to be explained by "because it's all I've ever used".

 

[scottcarl]

XST is perhaps one of the worst software tools ever written and as soon as you can dump it you should. Get to Synplicity's Synplify as soon as you can afford it or switch to Altera designs where their synthesis tool is about 10x better than XST.

Aldec's Active-HDL is a very good simulator and has some good add-ons like Code Coverage and Simulation Coverage.

My 2 cents,
Scott

 

[Andy]

Hello all,
can you please tell us what tools you prefer? Please give some
arguments, why you like them.

I currently use very intensively Linux shell and GHDL compiler for
simulations and XST for synthesis.

GHDL is very fast and powerful. You can for example colorize your
files directly into HTML, call foreign functions (e.g. from C
library), and many more.

My VHDL projects have typical Linux-way directory tree structure:
./bin/ for binaries
./include/ for includes
./work/ for generated modules
./src/ for sources

inside src directory is a Makefile, which is automatically generated
by GHDL. In order to build a binary, I use "make sim" command. If I
need to create some additional component in other language (C or
Python), I use "foreign" declarations in VHDL code and link them using
GHDL, just like with well-known GCC. For example if you need to verify
your VGA-Controller Design, you can create a special C-function which
will create JPG file with the current frame.

For synthesis I use XST from Xilinx ISE. It is very simple to type:
"make syn; make load" and bitfile will be uploaded into an FPGA. For
communication with FPGA board, real-time visualization, and so on, I
use small Python scripts.

I use VIM as a text editor. It also helps me to be very productive and
to work remotely using SSH (e.g. it's nice thing to use VIM on your
cell phone like Nokia N200 which has Linux onboard).

So, this are my tools:
GHDL, XST, GNU Tools(make, bintools, bash, libc, etc.), VIM, Python,
GCC
and of course Linux itself.

Frankly, only XST is not under Open Source license and it mostly slow-
downs hole development flow because of XST's bugs and its poor
performance. All other programs I use are previously compiled using
optimization flags targeted my server's hardware.

What tools do you prefer? Why ?

NC-VHDL or modelsim, both have top-notch performance, and have
excellent source level debuggers, object "watchers", etc. (which I
tend to use more than waveforms for debugging).

For synthesis, I have been disappointed with XST compared to Symplify-
pro. Synplify covers the language better, and generally gives better
results. It's schematic generation and viewing/filtering are top-
notch, and works at both the "RTL" level (showing you higher level
objects than primitives) and the technology level, which shows the
luts, flops, etc. at the lowest level. It is also vendor independent,
so you can evaluate other targets very easily.

I've used jGrasp, Ultra-edit, and xemacs with vhdl-mode. I had to
upgrade the UE vhdl syntax description to get it to do a better job on
formatting. JGrasp has excellent formatting, etc. and displays
graphical structural cues in the LH whitespace. However, nothing
compares to the shortcuts, or formatting and beautification
capabilities, of vhdl-mode for xemacs. Getting past some of the
keyboard acrobatics is a pain though. I mostly use xemacs now. Somehow
I can't see being productive writing/editing vhdl on a cell phone...

Andy

 

[psihodelia]

What I don't fully understand is why so many people use ModelSim ? I
did try it but it is slow and it has many bugs. On the other side, I
see many people use emacs with vhdl-mode. Emacs is one of the best
text editors and I think in the 21st century it would be not too bad
to teach some widely recognized Open Source tools already at the
middle school. Today's complexity of the software is so huge that
almost all Closed Source Solutions are predefined to be buggy,
unproductive, short-living. The same arguments are applicable to the
current situation about synthesis tools. I wonder if current situation
will start slowly change. Commercial interests depend on the
technological progress. Progress will be faster if Open Source will be
more important. For example, many Universities could provide more
intensive research on VHDL behavioral synthesis if synthesis tools
will be Open Source.

 

[Mike Treseler]

What I don't fully understand is why so many people use ModelSim ? I
did try it but it is slow and it has many bugs. On the other side, I
see many people use emacs with vhdl-mode. Emacs is one of the best
text editors

Emacs vhdl-mode is the best editor available for vhdl design entry.
Modelsim SE is the best simulator available for vhdl debug.
One is open source, the other isn't.
Each has its annoyances and delightful surprises.

-- Mike Treseler

 

[emeb]

What I don't fully understand is why so many people use ModelSim ? I
did try it but it is slow and it has many bugs. On the other side, I
see many people use emacs with vhdl-mode. Emacs is one of the best
text editors and I think in the 21st century it would be not too bad
to teach some widely recognized Open Source tools already at the
middle school. Today's complexity of the software is so huge that
almost all Closed Source Solutions are predefined to be buggy,
unproductive, short-living. The same arguments are applicable to the
current situation about synthesis tools. I wonder if current situation
will start slowly change. Commercial interests depend on the
technological progress. Progress will be faster if Open Source will be
more important. For example, many Universities could provide more
intensive research on VHDL behavioral synthesis if synthesis tools
will be Open Source.

Looks like (e-mail address removed) called this one.

That said, since I use Verilog, GHDL isn't an option for me. I use
Nedit (when it's working on Fedora) or Scite for text, Modelsim, Cver
or Icarus for simulation and XST for synthesis.

I don't know what problems you've had with Modelsim, but it's worked
well for me. It's faster than Cver and more reliable than Icarus on my
designs (YMMV). I do appreciate the open-source/free simulators though
and try to keep current with them.

The advantages of GHDL you cite sound useful. Reading up on that tool
suggests it supports an older rev of the VHDL standard though. If
that's true, have you found it to be an issue?

EB

 

[Kim Enkovaara]

What I don't fully understand is why so many people use ModelSim ? I
did try it but it is slow and it has many bugs. On the other side, I

Maybe because it is one of three big simulators that are known to
support reliably the language standards and are fast. Also one
critical thing in current world is support for mixed language
designs. I have not seen pure vhdl for a while, usually there
are some verilog blocks embedded to the designs. And in the future
designs with systemc, systemverilog, vhdl and verilog are going
to be normal.

Also I have found that modelsim is very fast simulator. But you
can't compare something like Modelsim XE and SE, they are different
tools in terms of optimization capabilities. Also I have not seen
more bugs in Modelsim than in other tools, and I have used it
since 5.5 version, there have been few bad versions (for example 6.0
series).

And many times the original source code has the bug, not the tool.
Especially verilog based behavioral models many times seem to rely
on how VerilogXL executed code, not on the language standard.
And it might be that the tool did correct optimization, but the
code was relying on execution order of the processes etc.

middle school. Today's complexity of the software is so huge that
almost all Closed Source Solutions are predefined to be buggy,

And also open source software is buggy. The big problem with
open source is support, for commercial EDA tools you actually
get good support. Even if you have the code, you need people
who really understand it, "here is the code, fix the problem
yourself" does not usually work with complex codebases.

unproductive, short-living. The same arguments are applicable to the
current situation about synthesis tools. I wonder if current situation
will start slowly change. Commercial interests depend on the
technological progress. Progress will be faster if Open Source will be
more important. For example, many Universities could provide more

Synthesis tools are even more complicated than simulators, and
today there are even no good simulators at opensource side
(multilanguage support, integrated gui, coverage support,
assertions etc.) I'm fan of opensource, but it is not always
the best way to develop tools. At synthesis side one problem for
example is that the tool support for upcoming fpga-famimilies
need to be started early on, and at that phase all information
is under very strict NDAs.

--Kim