Vendor Tool Stability
in [FPGA]
|
From: Rob Gaddi on 5 Aug 2010 19:43 On 8/5/2010 12:28 PM, Nico Coesel wrote: > Rob Gaddi<rgaddi(a)technologyhighland.com> wrote: > >> On 8/4/2010 6:43 AM, Gabor wrote: >>> On Aug 3, 11:23 pm, Angela O<angieoak...(a)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
From: Tim Wescott on 6 Aug 2010 01:03 On 08/05/2010 04:43 PM, Rob Gaddi wrote: > On 8/5/2010 12:28 PM, Nico Coesel wrote: >> Rob Gaddi<rgaddi(a)technologyhighland.com> wrote: >> >>> On 8/4/2010 6:43 AM, Gabor wrote: >>>> On Aug 3, 11:23 pm, Angela O<angieoak...(a)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
From: David Brown on 6 Aug 2010 03:35 On 06/08/2010 07:03, Tim Wescott wrote: > On 08/05/2010 04:43 PM, Rob Gaddi wrote: >> On 8/5/2010 12:28 PM, Nico Coesel wrote: >>> Rob Gaddi<rgaddi(a)technologyhighland.com> wrote: >>> >>>> On 8/4/2010 6:43 AM, Gabor wrote: >>>>> On Aug 3, 11:23 pm, Angela O<angieoak...(a)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.
From: Jason Thibodeau on 6 Aug 2010 09:32 On 08/06/2010 01:03 AM, Tim Wescott wrote: > On 08/05/2010 04:43 PM, Rob Gaddi wrote: >> On 8/5/2010 12:28 PM, Nico Coesel wrote: >>> Rob Gaddi<rgaddi(a)technologyhighland.com> wrote: >>> >>>> On 8/4/2010 6:43 AM, Gabor wrote: >>>>> On Aug 3, 11:23 pm, Angela O<angieoak...(a)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
From: John McCaskill on 6 Aug 2010 11:48 On Aug 5, 6:43 pm, Rob Gaddi <rga...(a)technologyhighland.com> wrote: > On 8/5/2010 12:28 PM, Nico Coesel wrote: > > > > > Rob Gaddi<rga...(a)technologyhighland.com> wrote: > > >> On 8/4/2010 6:43 AM, Gabor wrote: > >>> On Aug 3, 11:23 pm, Angela O<angieoak...(a)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.
First
|
Prev
|
Pages: 1 2 Prev: Xilinx ISE Webpack and Pipeline Optimization Next: Logic implementation probelm |