Angela O
Guest
Wed Aug 04, 2010 6:23 am
A project I am considering undertaking would require that an FPGA's
implementation flow (synthesis through bitgen) be routinely run in a
scripted form at customer locations by the end customer, likely a non-
engineer. The RTL input can be assumed to be good. All aspects of
the vendor tools would be hidden from the end user via scripts or GUI.
The stability of the vendor tools are the biggest concern in this
project. I am not tied to any vendor. The performance specs are such
that almost any current or last generation FPGA could handle the
load.
I would appreciate hearing your thoughts on which vendor to consider
for this application. Unpredictable errors and crashes are something
that must be avoided.
Thank you in advance.
Angie
Gabor
Guest
Wed Aug 04, 2010 4:43 pm
On Aug 3, 11:23 pm, Angela O <angieoak...@gmail.com> wrote:
Quote:
A project I am considering undertaking would require that an FPGA's
implementation flow (synthesis through bitgen) be routinely run in a
scripted form at customer locations by the end customer, likely a non-
engineer. The RTL input can be assumed to be good. All aspects of
the vendor tools would be hidden from the end user via scripts or GUI.
The stability of the vendor tools are the biggest concern in this
project. I am not tied to any vendor. The performance specs are such
that almost any current or last generation FPGA could handle the
load.
I would appreciate hearing your thoughts on which vendor to consider
for this application. Unpredictable errors and crashes are something
that must be avoided.
Thank you in advance.
Angie
Having worked with Xilinx tools and devices for many years, I would
say that it is possible to have very stable results as long as you
know what to avoid. Generally speaking, a design with one system
clock and no special feature usage almost never has any issues
through the tool chain. Start adding too many clock resources
or other special features and you can run into issues where the
tools need to be guided to complete the design. I don't know
enough about your application to say whether Xilinx tools are
stable enough for your purposes. Whichever chip vendor you
pick, you will have some things you need to avoid. Only the
synthesis portion of the tool chain can be de-coupled from the
chip vendor. It would really help if you had extensive experience
working with your vendor of choice before going into your own
tool implementation. Most of the annoying bugs from Xilinx
are not in the actual synthesis / place / route / build, but in the
GUI wrapper.
Regards,
Gabor
Rob Gaddi
Guest
Wed Aug 04, 2010 6:49 pm
On 8/4/2010 6:43 AM, Gabor wrote:
Quote:
On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote:
A project I am considering undertaking would require that an FPGA's
implementation flow (synthesis through bitgen) be routinely run in a
scripted form at customer locations by the end customer, likely a non-
engineer. The RTL input can be assumed to be good. All aspects of
the vendor tools would be hidden from the end user via scripts or GUI.
The stability of the vendor tools are the biggest concern in this
project. I am not tied to any vendor. The performance specs are such
that almost any current or last generation FPGA could handle the
load.
I would appreciate hearing your thoughts on which vendor to consider
for this application. Unpredictable errors and crashes are something
that must be avoided.
Thank you in advance.
Angie
Having worked with Xilinx tools and devices for many years, I would
say that it is possible to have very stable results as long as you
know what to avoid. Generally speaking, a design with one system
clock and no special feature usage almost never has any issues
through the tool chain. Start adding too many clock resources
or other special features and you can run into issues where the
tools need to be guided to complete the design. I don't know
enough about your application to say whether Xilinx tools are
stable enough for your purposes. Whichever chip vendor you
pick, you will have some things you need to avoid. Only the
synthesis portion of the tool chain can be de-coupled from the
chip vendor. It would really help if you had extensive experience
working with your vendor of choice before going into your own
tool implementation. Most of the annoying bugs from Xilinx
are not in the actual synthesis / place / route / build, but in the
GUI wrapper.
Regards,
Gabor
I've had nothing but problems with stability of Xilinx designs,
actually. Routinely in going from one version of the toolchain to the
next, command line options are changed or deprecated, forcing me to
tweak the settings in my Makefile. Right now I'm in the process of
opening a Webcase because a design which, under 12.1, was willing to
respect IOB=FORCE to push some input flip-flops into the ILOGIC cells
for timing reasons, it no longer will under 12.2.
--
Rob Gaddi, Highland Technology
Email address is currently out of order
KJ
Guest
Thu Aug 05, 2010 2:32 am
On Aug 3, 11:23 pm, Angela O <angieoak...@gmail.com> wrote:
Quote:
The stability of the vendor tools are the biggest concern in this
project. I am not tied to any vendor.
Fewer people here complain about brand A tools than brand X...the two
companies are the two largest in the FPGA world. Maybe that's because
there are more users of brand X tools, or maybe it's because the brand
A tools are better. Take both out for a spin and see for yourself.
The other way to keep tools stable is simply to not let them change.
Lock it down to a specific tool revision and you'll minimize the tool
migration issues.
Quote:
I would appreciate hearing your thoughts on which vendor to consider
for this application.
Brand A = Altera
Brand X = Xilinx
Brand L = Lattice which uses brand S synthesis tools
Brand S = Synplify which can target many different vendors
KJ
Nico Coesel
Guest
Thu Aug 05, 2010 8:28 pm
Rob Gaddi <rgaddi_at_technologyhighland.com> wrote:
Quote:
On 8/4/2010 6:43 AM, Gabor wrote:
On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote:
A project I am considering undertaking would require that an FPGA's
implementation flow (synthesis through bitgen) be routinely run in a
scripted form at customer locations by the end customer, likely a non-
engineer. The RTL input can be assumed to be good. All aspects of
the vendor tools would be hidden from the end user via scripts or GUI.
The stability of the vendor tools are the biggest concern in this
project. I am not tied to any vendor. The performance specs are such
that almost any current or last generation FPGA could handle the
load.
I would appreciate hearing your thoughts on which vendor to consider
for this application. Unpredictable errors and crashes are something
that must be avoided.
Thank you in advance.
Angie
Having worked with Xilinx tools and devices for many years, I would
say that it is possible to have very stable results as long as you
know what to avoid. Generally speaking, a design with one system
clock and no special feature usage almost never has any issues
through the tool chain. Start adding too many clock resources
or other special features and you can run into issues where the
tools need to be guided to complete the design. I don't know
enough about your application to say whether Xilinx tools are
stable enough for your purposes. Whichever chip vendor you
pick, you will have some things you need to avoid. Only the
synthesis portion of the tool chain can be de-coupled from the
chip vendor. It would really help if you had extensive experience
working with your vendor of choice before going into your own
tool implementation. Most of the annoying bugs from Xilinx
are not in the actual synthesis / place / route / build, but in the
GUI wrapper.
I agree. The command line tools seem to work just fine.
Quote:
Regards,
Gabor
I've had nothing but problems with stability of Xilinx designs,
actually. Routinely in going from one version of the toolchain to the
next, command line options are changed or deprecated, forcing me to
tweak the settings in my Makefile. Right now I'm in the process of
opening a Webcase because a design which, under 12.1, was willing to
respect IOB=FORCE to push some input flip-flops into the ILOGIC cells
for timing reasons, it no longer will under 12.2.
IIRC it is possible to install and use several different versions of
the Xilinx tools if you use make or batch files.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico_at_nctdevpuntnl (punt=.)
--------------------------------------------------------------
Rob Gaddi
Guest
Fri Aug 06, 2010 12:43 am
On 8/5/2010 12:28 PM, Nico Coesel wrote:
Quote:
Rob Gaddi<rgaddi_at_technologyhighland.com> wrote:
On 8/4/2010 6:43 AM, Gabor wrote:
On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote:
A project I am considering undertaking would require that an FPGA's
implementation flow (synthesis through bitgen) be routinely run in a
scripted form at customer locations by the end customer, likely a non-
engineer. The RTL input can be assumed to be good. All aspects of
the vendor tools would be hidden from the end user via scripts or GUI.
The stability of the vendor tools are the biggest concern in this
project. I am not tied to any vendor. The performance specs are such
that almost any current or last generation FPGA could handle the
load.
I would appreciate hearing your thoughts on which vendor to consider
for this application. Unpredictable errors and crashes are something
that must be avoided.
Thank you in advance.
Angie
Having worked with Xilinx tools and devices for many years, I would
say that it is possible to have very stable results as long as you
know what to avoid. Generally speaking, a design with one system
clock and no special feature usage almost never has any issues
through the tool chain. Start adding too many clock resources
or other special features and you can run into issues where the
tools need to be guided to complete the design. I don't know
enough about your application to say whether Xilinx tools are
stable enough for your purposes. Whichever chip vendor you
pick, you will have some things you need to avoid. Only the
synthesis portion of the tool chain can be de-coupled from the
chip vendor. It would really help if you had extensive experience
working with your vendor of choice before going into your own
tool implementation. Most of the annoying bugs from Xilinx
are not in the actual synthesis / place / route / build, but in the
GUI wrapper.
I agree. The command line tools seem to work just fine.
Regards,
Gabor
I've had nothing but problems with stability of Xilinx designs,
actually. Routinely in going from one version of the toolchain to the
next, command line options are changed or deprecated, forcing me to
tweak the settings in my Makefile. Right now I'm in the process of
opening a Webcase because a design which, under 12.1, was willing to
respect IOB=FORCE to push some input flip-flops into the ILOGIC cells
for timing reasons, it no longer will under 12.2.
IIRC it is possible to install and use several different versions of
the Xilinx tools if you use make or batch files.
That's actually what I'm doing now on my Linux build machine; the
different versions of the Xilinx tools seems to all play fairly nicely
there. On my Windows box, versions 11 and higher (FlexLM) get seriously
snippy with one another.
--
Rob Gaddi, Highland Technology
Email address is currently out of order
Tim Wescott
Guest
Fri Aug 06, 2010 6:03 am
On 08/05/2010 04:43 PM, Rob Gaddi wrote:
Quote:
On 8/5/2010 12:28 PM, Nico Coesel wrote:
Rob Gaddi<rgaddi_at_technologyhighland.com> wrote:
On 8/4/2010 6:43 AM, Gabor wrote:
On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote:
A project I am considering undertaking would require that an FPGA's
implementation flow (synthesis through bitgen) be routinely run in a
scripted form at customer locations by the end customer, likely a non-
engineer. The RTL input can be assumed to be good. All aspects of
the vendor tools would be hidden from the end user via scripts or GUI.
The stability of the vendor tools are the biggest concern in this
project. I am not tied to any vendor. The performance specs are such
that almost any current or last generation FPGA could handle the
load.
I would appreciate hearing your thoughts on which vendor to consider
for this application. Unpredictable errors and crashes are something
that must be avoided.
Thank you in advance.
Angie
Having worked with Xilinx tools and devices for many years, I would
say that it is possible to have very stable results as long as you
know what to avoid. Generally speaking, a design with one system
clock and no special feature usage almost never has any issues
through the tool chain. Start adding too many clock resources
or other special features and you can run into issues where the
tools need to be guided to complete the design. I don't know
enough about your application to say whether Xilinx tools are
stable enough for your purposes. Whichever chip vendor you
pick, you will have some things you need to avoid. Only the
synthesis portion of the tool chain can be de-coupled from the
chip vendor. It would really help if you had extensive experience
working with your vendor of choice before going into your own
tool implementation. Most of the annoying bugs from Xilinx
are not in the actual synthesis / place / route / build, but in the
GUI wrapper.
I agree. The command line tools seem to work just fine.
Regards,
Gabor
I've had nothing but problems with stability of Xilinx designs,
actually. Routinely in going from one version of the toolchain to the
next, command line options are changed or deprecated, forcing me to
tweak the settings in my Makefile. Right now I'm in the process of
opening a Webcase because a design which, under 12.1, was willing to
respect IOB=FORCE to push some input flip-flops into the ILOGIC cells
for timing reasons, it no longer will under 12.2.
IIRC it is possible to install and use several different versions of
the Xilinx tools if you use make or batch files.
That's actually what I'm doing now on my Linux build machine; the
different versions of the Xilinx tools seems to all play fairly nicely
there. On my Windows box, versions 11 and higher (FlexLM) get seriously
snippy with one another.
Give Xilinx time, they'll get the deficiencies in the Linux versions
sorted out soon enough -- then your dissimilar versions will have
trouble playing together on the Linux box, too!
(Kudos to Xilinx, by the way -- the Linux version of their tool set is
perking along quite nicely under Ubuntu. Other than having to roll my
own driver for the parallel cable, all has worked straight out of the box).
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at
http://www.wescottdesign.com/actfes/actfes.html
David Brown
Guest
Fri Aug 06, 2010 8:35 am
On 06/08/2010 07:03, Tim Wescott wrote:
Quote:
On 08/05/2010 04:43 PM, Rob Gaddi wrote:
On 8/5/2010 12:28 PM, Nico Coesel wrote:
Rob Gaddi<rgaddi_at_technologyhighland.com> wrote:
On 8/4/2010 6:43 AM, Gabor wrote:
On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote:
A project I am considering undertaking would require that an FPGA's
implementation flow (synthesis through bitgen) be routinely run in a
scripted form at customer locations by the end customer, likely a
non-
engineer. The RTL input can be assumed to be good. All aspects of
the vendor tools would be hidden from the end user via scripts or
GUI.
The stability of the vendor tools are the biggest concern in this
project. I am not tied to any vendor. The performance specs are such
that almost any current or last generation FPGA could handle the
load.
I would appreciate hearing your thoughts on which vendor to consider
for this application. Unpredictable errors and crashes are something
that must be avoided.
Thank you in advance.
Angie
Having worked with Xilinx tools and devices for many years, I would
say that it is possible to have very stable results as long as you
know what to avoid. Generally speaking, a design with one system
clock and no special feature usage almost never has any issues
through the tool chain. Start adding too many clock resources
or other special features and you can run into issues where the
tools need to be guided to complete the design. I don't know
enough about your application to say whether Xilinx tools are
stable enough for your purposes. Whichever chip vendor you
pick, you will have some things you need to avoid. Only the
synthesis portion of the tool chain can be de-coupled from the
chip vendor. It would really help if you had extensive experience
working with your vendor of choice before going into your own
tool implementation. Most of the annoying bugs from Xilinx
are not in the actual synthesis / place / route / build, but in the
GUI wrapper.
I agree. The command line tools seem to work just fine.
Regards,
Gabor
I've had nothing but problems with stability of Xilinx designs,
actually. Routinely in going from one version of the toolchain to the
next, command line options are changed or deprecated, forcing me to
tweak the settings in my Makefile. Right now I'm in the process of
opening a Webcase because a design which, under 12.1, was willing to
respect IOB=FORCE to push some input flip-flops into the ILOGIC cells
for timing reasons, it no longer will under 12.2.
IIRC it is possible to install and use several different versions of
the Xilinx tools if you use make or batch files.
That's actually what I'm doing now on my Linux build machine; the
different versions of the Xilinx tools seems to all play fairly nicely
there. On my Windows box, versions 11 and higher (FlexLM) get seriously
snippy with one another.
Give Xilinx time, they'll get the deficiencies in the Linux versions
sorted out soon enough -- then your dissimilar versions will have
trouble playing together on the Linux box, too!
(Kudos to Xilinx, by the way -- the Linux version of their tool set is
perking along quite nicely under Ubuntu. Other than having to roll my
own driver for the parallel cable, all has worked straight out of the box).
If you are having trouble with several different versions of the tools
installed at the same time, consider running each one within its own
virtual machine (I like VirtualBox, but it's a matter of taste). I've
done that for other programs that conflict with each other.
Jason Thibodeau
Guest
Fri Aug 06, 2010 2:32 pm
On 08/06/2010 01:03 AM, Tim Wescott wrote:
Quote:
On 08/05/2010 04:43 PM, Rob Gaddi wrote:
On 8/5/2010 12:28 PM, Nico Coesel wrote:
Rob Gaddi<rgaddi_at_technologyhighland.com> wrote:
On 8/4/2010 6:43 AM, Gabor wrote:
On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote:
A project I am considering undertaking would require that an FPGA's
implementation flow (synthesis through bitgen) be routinely run in a
scripted form at customer locations by the end customer, likely a
non-
engineer. The RTL input can be assumed to be good. All aspects of
the vendor tools would be hidden from the end user via scripts or
GUI.
The stability of the vendor tools are the biggest concern in this
project. I am not tied to any vendor. The performance specs are such
that almost any current or last generation FPGA could handle the
load.
I would appreciate hearing your thoughts on which vendor to consider
for this application. Unpredictable errors and crashes are something
that must be avoided.
Thank you in advance.
Angie
Having worked with Xilinx tools and devices for many years, I would
say that it is possible to have very stable results as long as you
know what to avoid. Generally speaking, a design with one system
clock and no special feature usage almost never has any issues
through the tool chain. Start adding too many clock resources
or other special features and you can run into issues where the
tools need to be guided to complete the design. I don't know
enough about your application to say whether Xilinx tools are
stable enough for your purposes. Whichever chip vendor you
pick, you will have some things you need to avoid. Only the
synthesis portion of the tool chain can be de-coupled from the
chip vendor. It would really help if you had extensive experience
working with your vendor of choice before going into your own
tool implementation. Most of the annoying bugs from Xilinx
are not in the actual synthesis / place / route / build, but in the
GUI wrapper.
I agree. The command line tools seem to work just fine.
Regards,
Gabor
I've had nothing but problems with stability of Xilinx designs,
actually. Routinely in going from one version of the toolchain to the
next, command line options are changed or deprecated, forcing me to
tweak the settings in my Makefile. Right now I'm in the process of
opening a Webcase because a design which, under 12.1, was willing to
respect IOB=FORCE to push some input flip-flops into the ILOGIC cells
for timing reasons, it no longer will under 12.2.
IIRC it is possible to install and use several different versions of
the Xilinx tools if you use make or batch files.
That's actually what I'm doing now on my Linux build machine; the
different versions of the Xilinx tools seems to all play fairly nicely
there. On my Windows box, versions 11 and higher (FlexLM) get seriously
snippy with one another.
Give Xilinx time, they'll get the deficiencies in the Linux versions
sorted out soon enough -- then your dissimilar versions will have
trouble playing together on the Linux box, too!
(Kudos to Xilinx, by the way -- the Linux version of their tool set is
perking along quite nicely under Ubuntu. Other than having to roll my
own driver for the parallel cable, all has worked straight out of the box).
Agreed. I have a few versions running great on two separate Fedora
machines. One is F13 and one is F12.
--
Jason Thibodeau
John McCaskill
Guest
Fri Aug 06, 2010 6:48 pm
On Aug 5, 6:43 pm, Rob Gaddi <rga...@technologyhighland.com> wrote:
Quote:
On 8/5/2010 12:28 PM, Nico Coesel wrote:
Rob Gaddi<rga...@technologyhighland.com> wrote:
On 8/4/2010 6:43 AM, Gabor wrote:
On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote:
A project I am considering undertaking would require that an FPGA's
implementation flow (synthesis through bitgen) be routinely run in a
scripted form at customer locations by the end customer, likely a non-
engineer. The RTL input can be assumed to be good. All aspects of
the vendor tools would be hidden from the end user via scripts or GUI.
The stability of the vendor tools are the biggest concern in this
project. I am not tied to any vendor. The performance specs are such
that almost any current or last generation FPGA could handle the
load.
I would appreciate hearing your thoughts on which vendor to consider
for this application. Unpredictable errors and crashes are something
that must be avoided.
Thank you in advance.
Angie
Having worked with Xilinx tools and devices for many years, I would
say that it is possible to have very stable results as long as you
know what to avoid. Generally speaking, a design with one system
clock and no special feature usage almost never has any issues
through the tool chain. Start adding too many clock resources
or other special features and you can run into issues where the
tools need to be guided to complete the design. I don't know
enough about your application to say whether Xilinx tools are
stable enough for your purposes. Whichever chip vendor you
pick, you will have some things you need to avoid. Only the
synthesis portion of the tool chain can be de-coupled from the
chip vendor. It would really help if you had extensive experience
working with your vendor of choice before going into your own
tool implementation. Most of the annoying bugs from Xilinx
are not in the actual synthesis / place / route / build, but in the
GUI wrapper.
I agree. The command line tools seem to work just fine.
Regards,
Gabor
I've had nothing but problems with stability of Xilinx designs,
actually. Routinely in going from one version of the toolchain to the
next, command line options are changed or deprecated, forcing me to
tweak the settings in my Makefile. Right now I'm in the process of
opening a Webcase because a design which, under 12.1, was willing to
respect IOB=FORCE to push some input flip-flops into the ILOGIC cells
for timing reasons, it no longer will under 12.2.
IIRC it is possible to install and use several different versions of
the Xilinx tools if you use make or batch files.
That's actually what I'm doing now on my Linux build machine; the
different versions of the Xilinx tools seems to all play fairly nicely
there. On my Windows box, versions 11 and higher (FlexLM) get seriously
snippy with one another.
--
Rob Gaddi, Highland Technology
Email address is currently out of order
Xilinx has been changing how they install their software to make it
easier to have multiple versions on Windows machines. Starting with
11.1 (I think) they put each installed version into its own sub-
directory under /Xilinx by default. You still need to deal with
environment variables. I did this on my machines by replacing the hard
coded version in the environment variables with a XIL_VERSION
variable. Then I would just change that one when I switched between
versions, in this case only running one version at a time.
Starting with 12.1, the install no longer sets environment variables.
Instead, the entries in the start menu point to a batch file that sets
the environment variables for the shell the tools are launched in for
that run.
I currently have 12.1 and 11.4 running at the same time with out
interfering with each other.
I have not had any problems related to FlexLM, and in addition to ISE
System Edition, I also have ModelSim SE, two versions of HyperLynx and
Impulse C all which use FlexLM installed on twenty similar Windows
Vista machines using node locked licenses (locked to MAC IDs). I
also have a subset of that software running without problems on a few
more Windows XP machines that are not similar to the others. I have
not tried the floating licenses yet.
Your post strongly implies that you are seeing FlexLM problems, is
that what you mean when you say the tools get snippy with each other,
or did you mean something else?
Regards,
John McCaskill
www.FasterTechnology.com
Xilinx Alliance Partner and exclusive Xilinx Authorized Training
Provider for eight US states.
