From: Angela O on 3 Aug 2010 23:23 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
From: Gabor on 4 Aug 2010 09:43 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. Regards, Gabor
From: Rob Gaddi on 4 Aug 2010 13:49 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. > > 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
From: KJ on 4 Aug 2010 20:50 On Aug 3, 11:23 pm, Angela O <angieoak...(a)gmail.com> wrote: > 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. > > 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
From: Nico Coesel on 5 Aug 2010 15:28 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. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico(a)nctdevpuntnl (punt=.) --------------------------------------------------------------
|
Next
|
Last
Pages: 1 2 Prev: Xilinx ISE Webpack and Pipeline Optimization Next: Logic implementation probelm |