Prev: Xilinx ISE Webpack and Pipeline Optimization
Next: Logic implementation probelm
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