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

On Aug 3, 11:23=A0pm, 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. =A0The RTL input can be assumed to be good. =A0All 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. =A0I am not tied to any vendor. =A0The performance specs are suc=
h
> 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. =A0Unpredictable 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

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.
>
> 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

On Aug 3, 11:23=A0pm, Angela O
<angieoak...@gmail.com> wrote:

> The stability of the vendor tools are the biggest concern in this
> project. =A0I am not tied to any vendor. =A0

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. =A0

Brand A =3D Altera
Brand X =3D Xilinx
Brand L =3D Lattice which uses brand S synthesis tools
Brand S =3D Synplify which can target many different vendors

KJ

Rob Gaddi <r...@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.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

On 8/5/2010 12:28 PM, Nico Coesel wrote:
> Rob Gaddi<r...@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

On 08/05/2010 04:43 PM, Rob Gaddi wrote:
> On 8/5/2010 12:28 PM, Nico Coesel wrote:
>> Rob Gaddi<r...@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

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<r...@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.

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<r...@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

On Aug 5, 6:43=A0pm, Rob Gaddi
<rga...@technologyhighland.com> wrote:
> On 8/5/2010 12:28 PM, Nico Coesel wrote:
>
>
>
> > Rob Gaddi<rga...@technologyhighland.com> =A0wrote:
>
> >> On 8/4/2010 6:43 AM, Gabor wrote:
> >>> On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> =A0 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
no=
n-
> >>>> engineer. =A0The RTL input can be assumed to be good. =A0All
aspects=
 of
> >>>> the vendor tools would be hidden from the end user via scripts or
GU=
I.
>
> >>>> The stability of the vendor tools are the biggest concern in this
> >>>> project. =A0I am not tied to any vendor. =A0The performance specs
ar=
e 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. =A0Unpredictable errors and crashes are
someth=
ing
> >>>> 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. =A0Generally speaking, a design with one system
> >>> clock and no special feature usage almost never has any issues
> >>> through the tool chain. =A0Start 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. =A0I don't know
> >>> enough about your application to say whether Xilinx tools are
> >>> stable enough for your purposes. =A0Whichever chip vendor you
> >>> pick, you will have some things you need to avoid. =A0Only the
> >>> synthesis portion of the tool chain can be de-coupled from the
> >>> chip vendor. =A0It would really help if you had extensive experience
> >>> working with your vendor of choice before going into your own
> >>> tool implementation. =A0Most 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. =A0Routinely in going from one version of the toolchain to t=
he
> >> next, command line options are changed or deprecated, forcing me to
> >> tweak the settings in my Makefile. =A0Right now I'm in the process of
> >> opening a Webcase because a design which, under 12.1, was willing to
> >> respect IOB=3DFORCE to push some input flip-flops into the ILOGIC cell=
s
> >> 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. =A0On my Windows box, versions 11 and higher (FlexLM) get seriousl=
y
> 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.