How important are software tools while choosing FPGA

[Sumit]

Hi

How much of a consideration is the quality of design tools while
choosing the FPGA vendor/device for a design? I guess this comes down
to - are most of the tools out there almost of similar quality in
terms of leading to designs with similar performance, area (FPGA
usage), etc ? I know a lot of folks are partial to Xilinx and
Altera, but I am trying to consider others as well, and want to know
how carefully I have to look at tool offerings to evaluate all of
them.

Thanks
Sumit

 

[David Kallberg]

Sumit <gupt@hotmail.com.NOSPAM> wrote in message news:<m33c2wsz9c.fsf@agni.ics.uci.edu>...

Hi

How much of a consideration is the quality of design tools while
choosing the FPGA vendor/device for a design? I guess this comes down
to - are most of the tools out there almost of similar quality in
terms of leading to designs with similar performance, area (FPGA
usage), etc ? I know a lot of folks are partial to Xilinx and
Altera, but I am trying to consider others as well, and want to know
how carefully I have to look at tool offerings to evaluate all of
them.

Thanks
Sumit

If you try different tools you will have different results. The
built-in synthesis tools in Altera and Xilinx will probably not
generate as good results as Synplify for example. However third party
tools are always more epensive. If you are expecting high production
volumes or if you beleive it will be difficult to meet timing/area
constraints you should go for Synplify or Mentor otherwise I suggest
you start with the builtin ones.

 

[David Kallberg]

Sumit <gupt@hotmail.com.NOSPAM> wrote in message news:<m33c2wsz9c.fsf@agni.ics.uci.edu>...

Hi

How much of a consideration is the quality of design tools while
choosing the FPGA vendor/device for a design? I guess this comes down
to - are most of the tools out there almost of similar quality in
terms of leading to designs with similar performance, area (FPGA
usage), etc ? I know a lot of folks are partial to Xilinx and
Altera, but I am trying to consider others as well, and want to know
how carefully I have to look at tool offerings to evaluate all of
them.

Thanks
Sumit

If you try different tools you will have different results. The
built-in synthesis tools in Altera and Xilinx will probably not
generate as good results as Synplify for example. However third party
tools are always more epensive. If you are expecting high production
volumes or if you beleive it will be difficult to meet timing/area
constraints you should go for Synplify or Mentor otherwise I suggest
you start with the builtin ones.

 

[General Schvantzkoph]

On Mon, 09 Aug 2004 15:49:35 -0700, Sumit wrote:

Hi

How much of a consideration is the quality of design tools while
choosing the FPGA vendor/device for a design? I guess this comes down
to - are most of the tools out there almost of similar quality in terms
of leading to designs with similar performance, area (FPGA usage), etc ?
I know a lot of folks are partial to Xilinx and Altera, but I am
trying to consider others as well, and want to know how carefully I have
to look at tool offerings to evaluate all of them.

Thanks
Sumit

Software tools are very important. The Xilinx tools give you more control
then the Altera tools and they are much easier to script. If you do
everything from the GUIs they are fairly similar but once you get
proficient you'll want to start doing everything with scripts and
constraint files, that's when Xilinx pulls ahead.

With either toolset the important thing is learning what works and what
doesn't. It's for this reason that once someone has become familiar with
one or the other they tend to stick with that vendor for years.

As for synthesis tools, Synplify is 10-15% better than the XST (the Xilinx
synthesis tool). By better I mean the number of slices tends to be 10%
fewer with Synplify and par has an easier time meeting timing. However XST
has been improving at a pretty good rate, last year it didn't work at all
now it does a very credible job.

 

[Rene Tschaggelar]

Sumit wrote:

How much of a consideration is the quality of design tools while
choosing the FPGA vendor/device for a design? I guess this comes down
to - are most of the tools out there almost of similar quality in
terms of leading to designs with similar performance, area (FPGA
usage), etc ? I know a lot of folks are partial to Xilinx and
Altera, but I am trying to consider others as well, and want to know
how carefully I have to look at tool offerings to evaluate all of
them.

It is great when you have sufficient time to have a look at
all available tools.
I started with Maxplus2 from Altera and after endless
phonecalls over a period of 2 weeks to the support engineer
at the Altera distributor I was able to get a trivial design
going. I somehow felt never tempted to go though the same
at another manufacturers tools. Meanwhile the tools may have
evolved and are perhaps easier to use.
Just in case you test them all, a feedback on how long a
trivial design took would be welcome.

Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

 

[Subroto Datta]

"General Schvantzkoph" <schvantzkoph@yahoo.com> wrote in message
newsan.2004.08.11.16.54.45.997863@yahoo.com...

Software tools are very important. The Xilinx tools give you more control
then the Altera tools and they are much easier to script. If you do
everything from the GUIs they are fairly similar but once you get
proficient you'll want to start doing everything with scripts and
constraint files, that's when Xilinx pulls ahead.

Hello General Schvantzkoph,

While your comparison on scripting may have been true in the past itdoes not
reflect the current state of the Altera Quartus II software's
scripting capabilities.

Quartus supports two scripting methodologies:
a) Command line scripting for use with shell scripts and makefiles, similar
to the abilities available in competitive tools.
b) Tcl scripting or procedural scripting which is very powerful and allows
manipulation of design processes through a programming language which goes
beyond what is available in competitive tools.

The Quartus II software was re-architected starting with version 3.0 (June
2003) to fully support command line scripting operation and to
include a new simplified tool command language (tcl) scripting API similar
in format to the popular Synopsys SDC format. "Tcl scripting is a
defacto EDA industry standard supported by tools from Altera, Mentor
Graphics, Synplicity, Synopsys and others."

The following Quartus II software scripting resources are available to make
you familiar with the powerful scripting capabilities in Quartus II 4.1 :

Quartus II handook chapters:
Command Line Scripting Chapter:
http://www.altera.com/literature/hb/qts/qts_qii52002.pdf
Tcl Scripting Chapter:
http://www.altera.com/literature/hb/qts/qts_qii52003.pdf
Assignment Editor chapter (see Tcl interface section):
http://www.altera.com/literature/hb/qts/qts_qii52001.pdf

Tcl Design Examples:
Tcl Design Examples Page
http://www.altera.com/support/examples/tcl/tcl.html
Design Space Explorer custom exploration space example:
http://www.altera.com/support/examples/quartus/space.html

If you wish to learn more using an online format the following resources
will be available in the very near future:
Tech Online WebCast:
Enhance Your FPGA Design Flow Using Scripting, Sept. 16, 11:00 am PST
(further details to follow)

Recorded Online Training Classes: Coming Soon

Hope this helps.
- Subroto Datta
Altera Corp.

 

[Ken McElvain]

Joseph H Allen wrote:

You really need to get Synplify. Unfortunately the EDK does not work well
with a Synplicity flow. (IMHO, Xilinx should just buy Synplify). An example
of the scripting nature of the Xilinx tools is this: for Altera SOCP, the
merge of your program's .elf file with the bitstream happens magically (it's
buried in the tools, it works, so don't worry about it).

There is a nice appnote on using Synplify with the EDK.

http://www.synplicity.com/literature/syndicated/pdf/v4_i2/platform_studio_v4_i2.pdf
It was written by Milan Saini from Xilinx.

With Xilinx, it doesn't work right away (because Synplicity and EDK and
ProjNav are not integrated), but by the time you get it working you
understand how ngdbuild takes a .bmm file as input, and bitgen creates a new
.bmm file on output and you are ready to make a script, understand the .bmm
file syntax and are thinking about how to load other non-program data into
block RAMs, now that you understand how it works.

On the other hand, Xilinx's GUI is not as clear as Altera's and there is
definitely a big learning curve to master the tools.

Anyway to summarize: Altera is more like Borland-C and Xilinx is more like
Microsoft C (if you were a C programmer in 1989 you would understand .

 

[Joseph H Allen]

I've been comparing the tools recently:

Altera: the built in synthesis tool is quite good, almost on par with
Synplicity (xst is nowhere near as good). This makes Altera's tools a much
better value. Also, the time to get going with SOCP is less than with
Xilinx EDK. SOCP is more integrated with Quartus-II.

On the other hand, Altera does not have fpga_editor: the low level chip
editing tool. It has a tool (chip editor), but you can not modify the
routing with it. Instead to make a change you have to basically rerun the
place and route. Of course if you are substantially changing your design
with fpga_editor, you have other problems... Keep in mind that you can make
macros with fixed routing by hand with fpga_editor (useful for delay lines).

If you like scripting and hate GUIs, you will not like Altera. Sure, you
can start with the GUI and then generate a script to recompile everything,
but you can't start a new design with all scripts. For example, to use chip
features (like PLL) you run a wizard to generate or modify "megafunction"
macros which you then instantiate in your HDL design files. Also you need
the GUI to enter timing and placement constraints (theoretically you could
do it with text, but there's no documentation). For complex functions, the
wizard is probably better, but scripting people will still not like it.

Also, it's all one monolithic tool: the different functions are not really
exposed and the database is very closed. You do not get to see the output
from one function and the input to another, or where one ends and another
begins. Instead there is an integrated database which each tool accesses.
This makes a 'makefile' somewhat meaningless.

Xilinx is definitely much better for scripting: each tool in the flow
documents its input files, output files and command line options. I run
each tool in a separate directory so that I can clearly see what each one
does.

You can do an entire design with just a text editor. For simple chip
features you can usually get by looking at the black box definition in the
Synplicity "virtex2.v" file (or whichever).

You really need to get Synplify. Unfortunately the EDK does not work well
with a Synplicity flow. (IMHO, Xilinx should just buy Synplify). An example
of the scripting nature of the Xilinx tools is this: for Altera SOCP, the
merge of your program's .elf file with the bitstream happens magically (it's
buried in the tools, it works, so don't worry about it).

With Xilinx, it doesn't work right away (because Synplicity and EDK and
ProjNav are not integrated), but by the time you get it working you
understand how ngdbuild takes a .bmm file as input, and bitgen creates a new
..bmm file on output and you are ready to make a script, understand the .bmm
file syntax and are thinking about how to load other non-program data into
block RAMs, now that you understand how it works.

On the other hand, Xilinx's GUI is not as clear as Altera's and there is
definitely a big learning curve to master the tools.

Anyway to summarize: Altera is more like Borland-C and Xilinx is more like
Microsoft C (if you were a C programmer in 1989 you would understand .

--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0%79-77?1:0<1659?79:0>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 

[David Kallberg]

So to summarize if you were NOT a C programmer in 1989

If you use scripts you would prefer Xilinx and if you like GUI based
you would prefer Altera. My personal experience is that the Quartus
GUI is far better than the Xilinx ISE GUI. I have used scripts on both
and I beleive they work fine. Never tried EDK/SOCP!

David
www.FPGAworld.com

jhallen@TheWorld.com (Joseph H Allen) wrote in message news:<cfekla$a9r$1@pcls4.std.com>...

I've been comparing the tools recently:

Altera: the built in synthesis tool is quite good, almost on par with
Synplicity (xst is nowhere near as good). This makes Altera's tools a much
better value. Also, the time to get going with SOCP is less than with
Xilinx EDK. SOCP is more integrated with Quartus-II.

On the other hand, Altera does not have fpga_editor: the low level chip
editing tool. It has a tool (chip editor), but you can not modify the
routing with it. Instead to make a change you have to basically rerun the
place and route. Of course if you are substantially changing your design
with fpga_editor, you have other problems... Keep in mind that you can make
macros with fixed routing by hand with fpga_editor (useful for delay lines).

If you like scripting and hate GUIs, you will not like Altera. Sure, you
can start with the GUI and then generate a script to recompile everything,
but you can't start a new design with all scripts. For example, to use chip
features (like PLL) you run a wizard to generate or modify "megafunction"
macros which you then instantiate in your HDL design files. Also you need
the GUI to enter timing and placement constraints (theoretically you could
do it with text, but there's no documentation). For complex functions, the
wizard is probably better, but scripting people will still not like it.

Also, it's all one monolithic tool: the different functions are not really
exposed and the database is very closed. You do not get to see the output
from one function and the input to another, or where one ends and another
begins. Instead there is an integrated database which each tool accesses.
This makes a 'makefile' somewhat meaningless.

Xilinx is definitely much better for scripting: each tool in the flow
documents its input files, output files and command line options. I run
each tool in a separate directory so that I can clearly see what each one
does.

You can do an entire design with just a text editor. For simple chip
features you can usually get by looking at the black box definition in the
Synplicity "virtex2.v" file (or whichever).

You really need to get Synplify. Unfortunately the EDK does not work well
with a Synplicity flow. (IMHO, Xilinx should just buy Synplify). An example
of the scripting nature of the Xilinx tools is this: for Altera SOCP, the
merge of your program's .elf file with the bitstream happens magically (it's
buried in the tools, it works, so don't worry about it).

With Xilinx, it doesn't work right away (because Synplicity and EDK and
ProjNav are not integrated), but by the time you get it working you
understand how ngdbuild takes a .bmm file as input, and bitgen creates a new
.bmm file on output and you are ready to make a script, understand the .bmm
file syntax and are thinking about how to load other non-program data into
block RAMs, now that you understand how it works.

On the other hand, Xilinx's GUI is not as clear as Altera's and there is
definitely a big learning curve to master the tools.

Anyway to summarize: Altera is more like Borland-C and Xilinx is more like
Microsoft C (if you were a C programmer in 1989 you would understand .

 

[Subroto Datta]

Hi Joseph,

Thank you for your thoughtful reply. There are a couple of points I'd
like to clarify.

For example, to use chip
features (like PLL) you run a wizard to generate or modify "megafunction"
macros which you then instantiate in your HDL design files. Also you need
the GUI to enter timing and placement constraints (theoretically you could
do it with text, but there's no documentation). For complex functions,
the
wizard is probably better, but scripting people will still not like it.

Our experience has shown, that stamping out megafunction instances for

complex device functions like PLL's, LVDS etc. can be very error prone in
all but the simplest of cases. We have therefore provided Customized
Graphical Megawizards to help the user get their megafunction instance
correct the first time. The Megawizards provide extensive realtime error
checking and thereby allow the user to correct their design before they
start on a synthesis, place and route cycle. We feel the Megawizard approach
is important enough for all users and have it available in our free Quartus
II Web Edition. The Megawizard generates the blackbox files which can be
"cut and pasted" in your HDL, identical to what you allude to below.

Also, it's all one monolithic tool: the different functions are not really
exposed and the database is very closed. You do not get to see the output
from one function and the input to another, or where one ends and another
begins. Instead there is an integrated database which each tool accesses.
This makes a 'makefile' somewhat meaningless.

With Quartus II 3.0 the compiler engine was monolithic was rearchitected
into 5 separate executables. These executables are called quartus_map
(netlist extraction and synthesis), quartus_fit (fitter), quartus_tan
(timing analysis), quartus_asm (assembler) and quartus_eda (netlist
generator for external verification tools). When you compile through the GUI
each of these executables are called in sequence just like you would from
the a shell script. The Message Window output shows the exact commands that
you can cut and paste into a shell script for compilation. These executables
can also be invoked from the command prompt repeatedly in any order. Infact
one of the common uses is to feed different devices speedgrades as a
command line option to quartus_tan to see how timing would vary without
refitting the entire design.

Each of these tools has their own databases, and we may choose to expose
them at a later time. If the definition of a makefile is to capture the
dependencies of the source files files and settings file, and to know when
each executable is to be run with command line options, I believe that the
makefile descrption provided in the Quartus Handbook Command Line Scripting
Chapter:
http://www.altera.com/literature/hb/qts/qts_qii52002.pdf Pgs 2-14 through
2-16 reflects this ability accurately.

Subroto Datta
Altera Corp.