Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 126325

Article: 126325
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 20 Nov 2007 12:06:15 +1300
Links: << >>  << T >>  << A >>
Antonio Pasini wrote:

> Il 18/11/2007 0.12, Didi ha scritto:
> 
>> A few hours of digging later I found out that the JTAG
>> sequences needed to write to a XPLA3 and Coolrunner-II
>> are publically available.
>>  However, the JEDEC -> JTAGgable fuse address translation
>> map is not (I do have that for the Philips Coolrunner,
>> the bit locations in the JTAG sequence descriptions have
>> nothing to do with the bit locations in the JEDEC file).
> 
> 
> Dimitri, I'm not sure I understood what your problem is; do you need to 
> write your own JTAG programmer routines ?
> 
> In last project I did I had to program (or re-program) a CoolrunnerII 
> (XC2C256) by JTAG with a microcontroller. Xilinx provides all the info 
> you need in their app notes.
> 
> It was not so difficult; in fact, it works so well I'm using that also 
> on production. Just a second to program a XC2C256, reasonably filled.
> 
> 1) Tweak the XAPP058 code for your platform; easy, that code is meant to 
> be "easily" ported.
> 
> 2) suppose I have my foo.jed file to program (made for XC2C256)
> 
> 3) use Impact (free download) to translate the jedec in a XSVF binary 
> file. You can do on GUI by hand, or by makefile as I prefer; syntax is:
> 
> impact -batch impact_make_xsvf.cmd
> 
>   where "impact_make_xsvf.cmd" contains:
> 
> setMode -bs
> setCable -port xsvf -file "foo.xsvf"
> addDevice -p 1 -file "foo.jed"
> Program -p 1 -e -v -defaultVersion 0
> quit
> 
> 4) write (or google..) a little utility (BIN2C) to convert your binary 
> XSVF image file in a C const array in source form, or include it 
> directly with assembly directives, if any, or whatever you think.
> 
> 5) the "player" in XAPP058 will erase, blank check, program and verify 
> your device.
> 
> 
> In fact, they did all the hard work for you, and provide also the source 
>  of the jtag "player".
> 
> You don't need to pay anyone to do the translation, just use the free 
> Impact tool. And yes, it works even without network connection (no 
> spyware, I think!).

That is also a good suggestion.
What code/data size was the microcontroller 'SVF/Jatg  player' ?

-jg


Article: 126326
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Didi <diditgi@gmail.com>
Date: Mon, 19 Nov 2007 15:06:53 -0800 (PST)
Links: << >>  << T >>  << A >>
> It was not so difficult; in fact, it works so well I'm using that also
> on production. Just a second to program a XC2C256, reasonably filled.

I know it is not difficult at all, like I said, I have made it - and
a lot more than that - for the original coolrunner 5-6 years ago.

> 1) Tweak the XAPP058 code for your platform; easy, that code is meant to
> be "easily" ported.
>
> 2) suppose I have my foo.jed file to program (made for XC2C256)

So far I am accepting that (using xilinx software to create the jedec
file, I'd accept this precedent here).

>
> 3) use Impact (free download) to translate the jedec in a XSVF binary
> file. You can do on GUI by hand, or by makefile as I prefer; syntax is:
>

Now this is a hoop I can do without. XAPP058 actually states you have
to do jedec -> svf -> xsvf, and I see only the svf->xsvf tool freely
available. Is the tool for doing jedec->svf also freely available?
Can you point me to it please?

Thanks,

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

On Nov 20, 12:11 am, Antonio Pasini
<removethis_antonio.pas...@alice.it> wrote:
> Il 18/11/2007 0.12, Didi ha scritto:
>
> > A few hours of digging later I found out that the JTAG
> > sequences needed to write to a XPLA3 and Coolrunner-II
> > are publically available.
> >  However, the JEDEC -> JTAGgable fuse address translation
> > map is not (I do have that for the Philips Coolrunner,
> > the bit locations in the JTAG sequence descriptions have
> > nothing to do with the bit locations in the JEDEC file).
>
> Dimitri, I'm not sure I understood what your problem is; do you need to
> write your own JTAG programmer routines ?
>
> In last project I did I had to program (or re-program) a CoolrunnerII
> (XC2C256) by JTAG with a microcontroller. Xilinx provides all the info
> you need in their app notes.
>
> It was not so difficult; in fact, it works so well I'm using that also
> on production. Just a second to program a XC2C256, reasonably filled.
>
> 1) Tweak the XAPP058 code for your platform; easy, that code is meant to
> be "easily" ported.
>
> 2) suppose I have my foo.jed file to program (made for XC2C256)
>
> 3) use Impact (free download) to translate the jedec in a XSVF binary
> file. You can do on GUI by hand, or by makefile as I prefer; syntax is:
>
> impact -batch impact_make_xsvf.cmd
>
>    where "impact_make_xsvf.cmd" contains:
>
> setMode -bs
> setCable -port xsvf -file "foo.xsvf"
> addDevice -p 1 -file "foo.jed"
> Program -p 1 -e -v -defaultVersion 0
> quit
>
> 4) write (or google..) a little utility (BIN2C) to convert your binary
> XSVF image file in a C const array in source form, or include it
> directly with assembly directives, if any, or whatever you think.
>
> 5) the "player" in XAPP058 will erase, blank check, program and verify
> your device.
>
> In fact, they did all the hard work for you, and provide also the source
>   of the jtag "player".
>
> You don't need to pay anyone to do the translation, just use the free
> Impact tool. And yes, it works even without network connection (no
> spyware, I think!).


Article: 126327
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Didi <diditgi@gmail.com>
Date: Mon, 19 Nov 2007 15:19:36 -0800 (PST)
Links: << >>  << T >>  << A >>
> > Well the fact of the matter is that there is no CPLD on the market
> > to compete with all the coolrunner parameters at the same time - and
> > I do use them.
>
> Across the size range, you may be right.
> But at the highest volume end Atmel and Lattice have good low power
> offerings. Actel may start to impact > 128MC CPLDs

I would be really happy to see an alternative to the coolrunner,
especially if its documentation is less secretive. Until then,
we are all stuck with xilinx for CPLDs above a certain complexity
and below some power, which is why I am still trying to get some
way to use them (notice I even accept to use their software to
produce the jedec file, something unprecedented here).

> My understanding there is the parts were not externally foundry fab'd
> and when the plug was pulled on the fab line, that then killed the
> product line. ...

Well I do not find it very plausible - making a new coolrunner line
from scratch cannot have been easier than repeating an existing
product, mask sets and all being available.
 But whatever, their agreement with Philips was to support all
existing customers the way Philips had supported them.
 This has not been the case with us - we do have the jedec -> jtag
maps from Philips and we do not have these from Xilinx.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

On Nov 20, 1:03 am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Didi wrote:
> >>The Atmel devices top out at 128 macrocells, but you can pack
> >>a little more into a Atmel macrocell.
> >>The new BE family, are uA static devices, in 32/64 MC (released)
> >>and 128MC (soon)
>
> > Well the fact of the matter is that there is no CPLD on the market
> > to compete with all the coolrunner parameters at the same time - and
> > I do use them.
>
> Across the size range, you may be right.
> But at the highest volume end Atmel and Lattice have good low power
> offerings. Actel may start to impact > 128MC CPLDs
>
> >  Philips could have taken over the sector with that device easily,
> > we'll never know what happened behind the scenes so they sold it to
> > xilinx - who immediately killed the original Philips line which was
> > great but had leaked out programming information (no other plausible
> > reason for killing such a good device I can think of).
>
> My understanding there is the parts were not externally foundry fab'd
> and when the plug was pulled on the fab line, that then killed the
> product line. (similar problem happened with some Lattice.AMD parts)
>
> Not good for the end customers. - but certainly not a conspiracy,
> instead a by-product of some decoupled bean-counter's decisons, and
> we have all seen that before ! :)
>
> >  And now we stand with xilinx having monopoly over the only up-to-date
> > CPLD on the market, and they will not let you write to it without
> > revealing your written code to them (oh yeah, they'll swear to god
> > their software only translates one map to another and I am just
> > paranoid because I think it is the spyware it actually is - but
> > ask them _why_ do they keep that jedec -> jtag mapping data secret
> > and feel free to wait for another century for a plausible answer).
>
> That is a good question.
>
> Comments Austin ? ( or Jesse? )
>
> -jg


Article: 126328
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Didi <diditgi@gmail.com>
Date: Mon, 19 Nov 2007 15:25:58 -0800 (PST)
Links: << >>  << T >>  << A >>
> > Well the fact of the matter is that there is no CPLD on the market
> > to compete with all the coolrunner parameters at the same time - and
> > I do use them.
>
> I feel your pain.  It is often that I need devices with 5 volt
> tolerance.  But that makes it difficult to migrate to the finer
> processes which lower the cost of devices.
> ...

I do need less and less of the 5V tolerance (but still not easy
to replace in some instances - say an ATA interface which is
5V for 2.5" and 3.5" devices). Actually the coolrunner-II is
more appealing for the future because it has a variety of I/O
voltage options, most of these are already in demand...

I am glad I am not the only one feeling the pain of having to
deal with the defacto monopoly of Xilinx on the high end/low power
CPLD market.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

On Nov 20, 12:35 am, rickman <gnu...@gmail.com> wrote:
> On Nov 19, 4:27 pm, Didi <didi...@gmail.com> wrote:
>
> > > The Atmel devices top out at 128 macrocells, but you can pack
> > > a little more into a Atmel macrocell.
> > > The new BE family, are uA static devices, in 32/64 MC (released)
> > > and 128MC (soon)
>
> > Well the fact of the matter is that there is no CPLD on the market
> > to compete with all the coolrunner parameters at the same time - and
> > I do use them.
>
> I feel your pain.  It is often that I need devices with 5 volt
> tolerance.  But that makes it difficult to migrate to the finer
> processes which lower the cost of devices.  Adding extra processing to
> retain 5 volt tolerance drives the price back up.  I can't say which
> of the two is more significant, but it is interesting that many MCU
> vendors seem able to produce 5 volt tolerant devices in the newer
> processes at *VERY low* prices.
>
> I looked at exactly this issue a bit over a year ago and came up with
> the XPLA family and the Lattice parts.  Xilinx won't compete on price
> with the XPLA line because it is not one of the new lines they are
> pushing.  I think they literally don't care a hoot about design wins
> with older logic.  At least the sales people are always pushing the
> new stuff even after I have told them why it is not suited (or they
> have not been able to tell me how I will be able to get these new
> parts in preproduction).  Clearly there is a lot of incentive to
> salesmen for design wins with the new parts over the old.
>
> >  Philips could have taken over the sector with that device easily,
> > we'll never know what happened behind the scenes so they sold it to
> > xilinx - who immediately killed the original Philips line which was
> > great but had leaked out programming information (no other plausible
> > reason for killing such a good device I can think of).
>
> Philips and Xilinx have different processes.  Xilinx adjusted the
> design to suit their manufacturing and to improve it in some ways.
> They may not be willing to share detailed info, but I don't think they
> would go to the expense of redesigning a chip line just to prevent
> users from having "programming information".
>
> >  And now we stand with xilinx having monopoly over the only up-to-date
> > CPLD on the market, and they will not let you write to it without
> > revealing your written code to them (oh yeah, they'll swear to god
> > their software only translates one map to another and I am just
> > paranoid because I think it is the spyware it actually is - but
> > ask them _why_ do they keep that jedec -> jtag mapping data secret
> > and feel free to wait for another century for a plausible answer).
>
> You're only paranoid because everyone is out to get you!  You don't
> have to literally give them your design.  You just have to process it
> with their software, right?  If all else fails, you can do that on a
> machine that is not connected anywhere and wipe the disk once you have
> taken your data with you.  That should make even the CIA happy... well
> maybe not the CIA.  They would want to reverse engineer the code and
> destroy the hard drive along with any non-volatile memory.
>
> Jim,
>
> > > The Atmel devices top out at 128 macrocells, but you can pack
> > > a little more into a Atmel macrocell.
> > > The new BE family, are uA static devices, in 32/64 MC (released)
> > > and 128MC (soon)
>
> I guess these are new devices that weren't out when I looked.  Are
> they planning anything larger than 128 macrocells?  Personally I like
> the Lattice parts.  They also have some interesting flash FPGA like
> devices, but of course they are not zero power.
>
> > > The Lattice ispMACH4000 family go to 256MC in Zero power, and
> > > 512 in non-zero power. (IIRC)
>
> > > In the larger 128/512 macrocell area, CPLDs struggle a little,
> > > and the FPGA Fabric CPLDs are taking over (Altere MAX II,
> > > lattice MachXO, and the Actel Igloo devices are examples.
> > > Igloo are relatively new, but I saw a press release claiming
> > > $1.50[volume] for ~192 macrocell equiv device.
>
> I'm not sure why you say CPLDs are "taking over".  512 macrocell
> devices have been around for quite some time.  Actually, I think the
> Lattice XO flash based FPGA parts are doing a good job of pushing
> down, along with the MAX II parts which are FPGA like.  Just because
> they have flash, does not make them CPLDs in my opinion.  These lines
> are LUT based and route like FPGAs.  I think that makes them much more
> usable for the high end of CPLDs, not to mention cheaper!
>
> > > Lattice do have a 'sort-of' 5V spec: they say 5.5V max, but
> > > add this strange qualifier :
> > > "5. Maximum of 64 I/Os per device with VIN > 3.6V is allowed."
> > > [How does one IO, know, or care, what the voltage is on another IO ?]
>
> I asked about this once and they told me it has to do with the leakage
> current.  You can drive the I/Os above Vdd, but it will draw more
> current.  Too many at one time and the device can blow.  Not totally
> unlike multiple I/Os driving LEDs and such.  But you can ask your
> FAE.


Article: 126329
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 19 Nov 2007 16:09:53 -0800 (PST)
Links: << >>  << T >>  << A >>
Here is the comment by Jesse Jenkins, who was and is responsible for
CPLD applications support:

...regarding the JEDEC issue.  We do NOT want people making their own
programming solutions. When we engage with third party programmer
manufacturers, we have them go through extensive qualification of
their circuitry, sign NDAs, etc. to assure they are doing a great job
of programming our parts.  It's more complicated than just delivering
a bitstream into the parts.  Internal charge pump voltage levels,
various pulse widths, etc must be correctly delivered to assure
correctly programmed parts.  If these parameters are violated, parts
can be incorrectly programmed, and create huge customer
support issues.  We wish to avoid these.  It increases the cost of
supporting the parts for our main stream customers that are willing to
use our recommended methods, and CPLDs are a very competitive market.

Will you please kindly convey this to the Comp Arch folks?
 Thanks,
 JJ
Submitted by Peter Alfke, Xilinx Applications


On Nov 19, 3:03 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Didi wrote:
> >>The Atmel devices top out at 128 macrocells, but you can pack
> >>a little more into a Atmel macrocell.
> >>The new BE family, are uA static devices, in 32/64 MC (released)
> >>and 128MC (soon)
>
> > Well the fact of the matter is that there is no CPLD on the market
> > to compete with all the coolrunner parameters at the same time - and
> > I do use them.
>
> Across the size range, you may be right.
> But at the highest volume end Atmel and Lattice have good low power
> offerings. Actel may start to impact > 128MC CPLDs
>
> >  Philips could have taken over the sector with that device easily,
> > we'll never know what happened behind the scenes so they sold it to
> > xilinx - who immediately killed the original Philips line which was
> > great but had leaked out programming information (no other plausible
> > reason for killing such a good device I can think of).
>
> My understanding there is the parts were not externally foundry fab'd
> and when the plug was pulled on the fab line, that then killed the
> product line. (similar problem happened with some Lattice.AMD parts)
>
> Not good for the end customers. - but certainly not a conspiracy,
> instead a by-product of some decoupled bean-counter's decisons, and
> we have all seen that before ! :)
>
> >  And now we stand with xilinx having monopoly over the only up-to-date
> > CPLD on the market, and they will not let you write to it without
> > revealing your written code to them (oh yeah, they'll swear to god
> > their software only translates one map to another and I am just
> > paranoid because I think it is the spyware it actually is - but
> > ask them _why_ do they keep that jedec -> jtag mapping data secret
> > and feel free to wait for another century for a plausible answer).
>
> That is a good question.
>
> Comments Austin ? ( or Jesse? )
>
> -jg


Article: 126330
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 20 Nov 2007 13:43:44 +1300
Links: << >>  << T >>  << A >>
rickman wrote:
<snip>
>>Well the fact of the matter is that there is no CPLD on the market
>>to compete with all the coolrunner parameters at the same time - and
>>I do use them.
> 
> 
> I feel your pain.  It is often that I need devices with 5 volt
> tolerance.  But that makes it difficult to migrate to the finer
> processes which lower the cost of devices.  Adding extra processing to
> retain 5 volt tolerance drives the price back up.  I can't say which
> of the two is more significant, but it is interesting that many MCU
> vendors seem able to produce 5 volt tolerant devices in the newer
> processes at *VERY low* prices.

  I do mention this to the CPLD vendors, but part of the constraint,
is the CPLD market is relatively small, and the design teams tend to
be digital in nature, so they let the process dictate Vcc, and not
be proactive about the other way around.
Some of it is related to Test flow, and guarantees.

eg  I have tested the ATF1502BE, for example, and it has a nice 
open-drain (no VccIO clamp diode) ESD structure that avalanches at 5.6V
This has a 2KV ESD rating, so it is quite a rugged avalanch.

So, from a simple test bench aspect there seems to be no reason to not 
spec this as a 5V tolerant device. But if the process and oxide are
not qualified to do that, Atmel are reluctant to spec it.

  As an example from the processor sector, I'm impressed by the Freescle 
RS08. 30c+ region prices, and 'hidden' on-chip regulator, for stable uA 
level operation, and Vcc from 1.8 to 5.5V
  A CPLD in that process, would be a nice device :)


> Jim,
> 
> 
>>>The Atmel devices top out at 128 macrocells, but you can pack
>>>a little more into a Atmel macrocell.
>>>The new BE family, are uA static devices, in 32/64 MC (released)
>>>and 128MC (soon)
> 
> 
> I guess these are new devices that weren't out when I looked.  Are
> they planning anything larger than 128 macrocells? 

The road map is hazy there. A part number exists, but I'm not
sure a schedule does :)
In these bigger CPLDs it gets harder to compete with the fpga-fabric 
alternatives, like the Igloo.

There is a single supply 128 MC device coming (ATF1508RE-7AU100), with a 
better regulator than Lattice. (but not as good as the RS08 :)


> Personally I like
> the Lattice parts.  They also have some interesting flash FPGA like
> devices, but of course they are not zero power.
> 
> 
> 
>>>The Lattice ispMACH4000 family go to 256MC in Zero power, and
>>>512 in non-zero power. (IIRC)
>>
>>>In the larger 128/512 macrocell area, CPLDs struggle a little,
>>>and the FPGA Fabric CPLDs are taking over (Altere MAX II,
>>>lattice MachXO, and the Actel Igloo devices are examples.
>>>Igloo are relatively new, but I saw a press release claiming
>>>$1.50[volume] for ~192 macrocell equiv device.
> 
> 
> I'm not sure why you say CPLDs are "taking over".  512 macrocell
> devices have been around for quite some time.  Actually, I think the
> Lattice XO flash based FPGA parts are doing a good job of pushing
> down, along with the MAX II parts which are FPGA like.  Just because
> they have flash, does not make them CPLDs in my opinion.  These lines
> are LUT based and route like FPGAs.  I think that makes them much more
> usable for the high end of CPLDs, not to mention cheaper!

I think you misread what I wrote. I said at the larger CPLD spectrum
the 'FPGA Fabric' CPLDs are taking over. You may not call them CPLDs
but they are marketed as CPLDs.
They are cheaper, because in the large sizes, CPLDs do not scale well.



>>>Lattice do have a 'sort-of' 5V spec: they say 5.5V max, but
>>>add this strange qualifier :
>>>"5. Maximum of 64 I/Os per device with VIN > 3.6V is allowed."
>>>[How does one IO, know, or care, what the voltage is on another IO ?]
> 
> 
> I asked about this once and they told me it has to do with the leakage
> current.  You can drive the I/Os above Vdd, but it will draw more
> current.  Too many at one time and the device can blow.  Not totally
> unlike multiple I/Os driving LEDs and such.  But you can ask your
> FAE.

Yes, but the data quotes 20uA MAX at 105'C, for a pin at 5.5V
Does not look like a big thermal issue to me :)

-jg



Article: 126331
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Didi <diditgi@gmail.com>
Date: Mon, 19 Nov 2007 16:45:58 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Peter,

thanks for forwarding the message to the group.

> ...regarding the JEDEC issue.  We do NOT want people making their own
> programming solutions. When we engage with third party programmer
> manufacturers, we have them go through extensive qualification of
> their circuitry, sign NDAs, etc. to assure they are doing a great job
> of programming our parts.  It's more complicated than just delivering
> a bitstream into the parts.  Internal charge pump voltage levels,
> various pulse widths, etc must be correctly delivered to assure
> correctly programmed parts.  If these parameters are violated, parts
> can be incorrectly programmed,

So XAPP058 is not viable after all.
 The above quote states that reprogramming of a xilinx coolrunner
CPLD is not possible in a stand-alone system to which no cable is
attached and is done by some local MCU - say, remotely.

 Now perhaps Xilinx CPLD support would consider commenting on
which we are supposed to believe - xapp058 or the above statement.

> and create huge customer
> support issues.  We wish to avoid these.  It increases the cost of
> supporting the parts for our main stream customers that are willing to
> use our recommended methods, and CPLDs are a very competitive market.

This is simply not true. Like anyone else, Xilinx can provide
support only to those using their tools and let the rest of us
use ours without support, just hand us the jedec -> jtag data.
 BTW, the sequences and timings are all publically available
anyway from xilinx; it is only the Excel mapping files which are
kept secret.
 I would sign what it takes to gain access to them, including a
guarantee
not to ask any support questions (i.e. if I have the true
data and things do not work for me, I'll accept that).

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

On Nov 20, 2:09 am, Peter Alfke <pe...@xilinx.com> wrote:
> Here is the comment by Jesse Jenkins, who was and is responsible for
> CPLD applications support:
>
> ...regarding the JEDEC issue.  We do NOT want people making their own
> programming solutions. When we engage with third party programmer
> manufacturers, we have them go through extensive qualification of
> their circuitry, sign NDAs, etc. to assure they are doing a great job
> of programming our parts.  It's more complicated than just delivering
> a bitstream into the parts.  Internal charge pump voltage levels,
> various pulse widths, etc must be correctly delivered to assure
> correctly programmed parts.  If these parameters are violated, parts
> can be incorrectly programmed, and create huge customer
> support issues.  We wish to avoid these.  It increases the cost of
> supporting the parts for our main stream customers that are willing to
> use our recommended methods, and CPLDs are a very competitive market.
>
> Will you please kindly convey this to the Comp Arch folks?
>  Thanks,
>  JJ
> Submitted by Peter Alfke, Xilinx Applications
>
> On Nov 19, 3:03 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>
> > Didi wrote:
> > >>The Atmel devices top out at 128 macrocells, but you can pack
> > >>a little more into a Atmel macrocell.
> > >>The new BE family, are uA static devices, in 32/64 MC (released)
> > >>and 128MC (soon)
>
> > > Well the fact of the matter is that there is no CPLD on the market
> > > to compete with all the coolrunner parameters at the same time - and
> > > I do use them.
>
> > Across the size range, you may be right.
> > But at the highest volume end Atmel and Lattice have good low power
> > offerings. Actel may start to impact > 128MC CPLDs
>
> > >  Philips could have taken over the sector with that device easily,
> > > we'll never know what happened behind the scenes so they sold it to
> > > xilinx - who immediately killed the original Philips line which was
> > > great but had leaked out programming information (no other plausible
> > > reason for killing such a good device I can think of).
>
> > My understanding there is the parts were not externally foundry fab'd
> > and when the plug was pulled on the fab line, that then killed the
> > product line. (similar problem happened with some Lattice.AMD parts)
>
> > Not good for the end customers. - but certainly not a conspiracy,
> > instead a by-product of some decoupled bean-counter's decisons, and
> > we have all seen that before ! :)
>
> > >  And now we stand with xilinx having monopoly over the only up-to-date
> > > CPLD on the market, and they will not let you write to it without
> > > revealing your written code to them (oh yeah, they'll swear to god
> > > their software only translates one map to another and I am just
> > > paranoid because I think it is the spyware it actually is - but
> > > ask them _why_ do they keep that jedec -> jtag mapping data secret
> > > and feel free to wait for another century for a plausible answer).
>
> > That is a good question.
>
> > Comments Austin ? ( or Jesse? )
>
> > -jg


Article: 126332
Subject: Re: simulating xilinx block ram with modelsim
From: Duane Clark <junkmail@junkmail.com>
Date: Mon, 19 Nov 2007 16:51:15 -0800
Links: << >>  << T >>  << A >>
u_stadler@yahoo.de wrote:
> ...
> entity spi_memory is
>    PORT ( CLK : in  	STD_LOGIC;
> 	Data_in : inout  STD_LOGIC_VECTOR (31 downto 0);
> 	...

I just noticed that. Could you explain why Data_in is inout? If you are 
going to do that, then a driver is expected somewhere within this code. 
And if you don't supply a driver, perhaps a 'U' is inferred. Normally an 
inout port would be driven with a piece of code that looks something like:
   Data_in <= Data_inout when DEN = '1' else "ZZZZ...";

Article: 126333
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 20 Nov 2007 13:59:24 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Here is the comment by Jesse Jenkins, who was and is responsible for
> CPLD applications support:
> 
> ...regarding the JEDEC issue.  We do NOT want people making their own
> programming solutions. When we engage with third party programmer
> manufacturers, we have them go through extensive qualification of
> their circuitry, sign NDAs, etc. to assure they are doing a great job
> of programming our parts.  It's more complicated than just delivering
> a bitstream into the parts.  Internal charge pump voltage levels,
> various pulse widths, etc must be correctly delivered to assure
> correctly programmed parts.  If these parameters are violated, parts
> can be incorrectly programmed, and create huge customer
> support issues.  We wish to avoid these.  It increases the cost of
> supporting the parts for our main stream customers that are willing to
> use our recommended methods, and CPLDs are a very competitive market.
> 
> Will you please kindly convey this to the Comp Arch folks?
>  Thanks,
>  JJ
> Submitted by Peter Alfke, Xilinx Applications

Thanks Peter / Jesse.

I can sort of understand the reasoning, but how does this
reconcile with Antonio's post :

> In last project I did I had to program (or re-program) a CoolrunnerII (XC2C256) by JTAG with a microcontroller. Xilinx provides all the info you need in their app notes.
> 
> It was not so difficult; in fact, it works so well I'm using that also on production. Just a second to program a XC2C256, reasonably filled.
> 
> 1) Tweak the XAPP058 code for your platform; easy, that code is meant to be "easily" ported.

Seems Antonio DID 'make his own programming solution', in a 
microcontroller ? JTAG is a purely digital interface.

-jg



Article: 126334
Subject: Re: Microblaze books
From: Jeff Cunningham <jcc@sover.net>
Date: Mon, 19 Nov 2007 20:15:57 -0500
Links: << >>  << T >>  << A >>
ghelbig@lycos.com wrote:
> 
> Except for crt0.s, there really isn't a need for assembly programming
> a RISC processor...

In general I agree, but in addition to crt0.s, I find assy language is 
often very useful for memcpy/blitting/bulk IO operations in embedded 
systems.

-Jeff

Article: 126335
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Mon, 19 Nov 2007 19:34:05 -0600
Links: << >>  << T >>  << A >>
In article <19c9df45-da86-46c4-abb4-ee94a4aedc8a@e25g2000prg.googlegroups.com>, Peter Alfke <peter@xilinx.com> writes:
>Here is the comment by Jesse Jenkins, who was and is responsible for
>CPLD applications support:
>
>...regarding the JEDEC issue.  We do NOT want people making their own
>programming solutions. When we engage with third party programmer
>manufacturers, we have them go through extensive qualification of
>their circuitry, sign NDAs, etc. to assure they are doing a great job
>of programming our parts.  It's more complicated than just delivering
>a bitstream into the parts.  Internal charge pump voltage levels,
>various pulse widths, etc must be correctly delivered to assure
>correctly programmed parts.  If these parameters are violated, parts
>can be incorrectly programmed, and create huge customer
>support issues.  We wish to avoid these.  It increases the cost of
>supporting the parts for our main stream customers that are willing to
>use our recommended methods, and CPLDs are a very competitive market.

30 years ago, back in the dark ages when programming algorithims
were mostly analog black magic, that sort of story would have made sense.

Is that still valid today?  I thought programming via JTAG was
now common.  I think of JTAG as a digital process.  Are there
weird timing restrictions that a typical programmer gets wrong?

I assume most of your CPLDs are programmed by some ATE gear
connected to the JTAG pins.  Who writes the "program" that does
that?  Is there a certified subroutine that the end user calls
to program a CPLD?

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 126336
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 20 Nov 2007 15:43:35 +1300
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> In article <19c9df45-da86-46c4-abb4-ee94a4aedc8a@e25g2000prg.googlegroups.com>, Peter Alfke <peter@xilinx.com> writes:
> 
>>Here is the comment by Jesse Jenkins, who was and is responsible for
>>CPLD applications support:
>>
>>...regarding the JEDEC issue.  We do NOT want people making their own
>>programming solutions. When we engage with third party programmer
>>manufacturers, we have them go through extensive qualification of
>>their circuitry, sign NDAs, etc. to assure they are doing a great job
>>of programming our parts.  It's more complicated than just delivering
>>a bitstream into the parts.  Internal charge pump voltage levels,
>>various pulse widths, etc must be correctly delivered to assure
>>correctly programmed parts.  If these parameters are violated, parts
>>can be incorrectly programmed, and create huge customer
>>support issues.  We wish to avoid these.  It increases the cost of
>>supporting the parts for our main stream customers that are willing to
>>use our recommended methods, and CPLDs are a very competitive market.
> 
> 
> 30 years ago, back in the dark ages when programming algorithims
> were mostly analog black magic, that sort of story would have made sense.

Yes, I recall seeing dV/dT specs on some fuse devices

> Is that still valid today?  I thought programming via JTAG was
> now common.  

it is more than common, on many device that is the ONLY means of
programming.

> I think of JTAG as a digital process.  Are there
> weird timing restrictions that a typical programmer gets wrong?

No. JTAG does not even cycle Vcc.
The most complex timing, is the JTAG link itself.

> 
> I assume most of your CPLDs are programmed by some ATE gear
> connected to the JTAG pins.  Who writes the "program" that does
> that?  Is there a certified subroutine that the end user calls
> to program a CPLD?

Some use SVF files.

Most EE/FLASH chips self-time, and you'll see things like :
PowerUp time    [1ms]
Bulk Erase time [<950ms ]
Write time      [<5ms]

So about the only rocket science, is a simple timer.
These things can be programmed from parallel port cables,
and the times above are not even bounded,
just simple 'wait longer than'

A few devices have dual-purpose JTAG pins, and they have
some means to unlock the JTAG access. - but that's only needed
if you want dual mode pins.

-jg



Article: 126337
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: rickman <gnuarm@gmail.com>
Date: Mon, 19 Nov 2007 19:19:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 19, 7:43 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> rickman wrote:
>
> I think you misread what I wrote. I said at the larger CPLD spectrum
> the 'FPGA Fabric' CPLDs are taking over. You may not call them CPLDs
> but they are marketed as CPLDs.
> They are cheaper, because in the large sizes, CPLDs do not scale well.

Yes, I see now that we are saying the same thing.  I agree that the
FPGA fabric is likely cheaper as well as more versatile.  If you need
a simple and gate to drive an output, it uses a full macro cell in a
CPLD.  Using a LUT is a lot less expensive for smaller logic
functions.

> > I asked about this once and they told me it has to do with the leakage
> > current.  You can drive the I/Os above Vdd, but it will draw more
> > current.  Too many at one time and the device can blow.  Not totally
> > unlike multiple I/Os driving LEDs and such.  But you can ask your
> > FAE.
>
> Yes, but the data quotes 20uA MAX at 105'C, for a pin at 5.5V
> Does not look like a big thermal issue to me :)

I don't think it is a thermal issue.  I did not get a full
explanation, but I believe then since they would have no reason to
spec that limit if it wasn't real.  Like I said, you might try asking
your FAE what the basis of that limitation is.



Article: 126338
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Antonio Pasini <removethis_antonio.pasini@alice.it>
Date: Tue, 20 Nov 2007 06:01:26 +0100
Links: << >>  << T >>  << A >>
Il 20/11/2007 0.06, Didi ha scritto:
> 
>> 3) use Impact (free download) to translate the jedec in a XSVF binary
>> file. You can do on GUI by hand, or by makefile as I prefer; syntax is:
>>
> 
> Now this is a hoop I can do without. XAPP058 actually states you have
> to do jedec -> svf -> xsvf, and I see only the svf->xsvf tool freely
> available. Is the tool for doing jedec->svf also freely available?
> Can you point me to it please?
> 

Impact makes the jedec -> svf OR jedec ->XSVF translation, with the 
commands of my previous posts.
At the time of XAPP058, it wasn't able to.
Now you can just go stright from jedec to XSVF with Impact alone.

Impact is free with the Webpack 
(http://www.xilinx.com/ise/logic_design_prod/webpack.htm).

(I remember that there's also a "production" package with just the 
Impact tool, but I don't find the link).







Article: 126339
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Antonio Pasini <removethis_antonio.pasini@alice.it>
Date: Tue, 20 Nov 2007 06:13:03 +0100
Links: << >>  << T >>  << A >>
Il 20/11/2007 0.06, Jim Granville ha scritto:

> 
> That is also a good suggestion.
> What code/data size was the microcontroller 'SVF/Jatg  player' ?
> 

In one case, a Renesas r8c/tiny (16k flash, 1 kram), programming a 
X2C64. The CPLD binary content was "pulled" from the jtag player by an 
RS485 connection.

In another, a Blackfin BF561 with lots of memory, programming a X2C256, 
directly.

In the R8C/Tiny case, the player needs roughly 3-4Kb of code and 600-700 
bytes of ram (most of them are temporary buffers, you can "recycle" for 
other purposes out of the programming routines).



Article: 126340
Subject: Re: Microblaze books
From: svenand <svenand@comhem.se>
Date: Mon, 19 Nov 2007 21:41:39 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 19, 4:46 pm, xenix <last...@gmail.com> wrote:
> hello all,
>  I am looking for some books for microblaze  and some examples with
> assembly for microblaze. since now i havent found anything  helpful.
> thank you
>
> regards

You can find some useful information in my blog: http://www.fpgafromscratch.com

Sven

Article: 126341
Subject: 33+ Regs in PLB IPIF
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Tue, 20 Nov 2007 06:18:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
I have created a custom peripheral in EDK 9.1/ISE 9.1 that needs to have 
100 registers and communicates with the PowerPC CPU via the PLB bus.  The 
board I'm using is the XUP Virtex-IIPro dev. board.  I used the wizard in 
EDK to create a template for my peripheral, but the wizard only offers up 
to 32 registers.  Therefore, I selected 32 registers and tried to change 
the USER_NUM_CE constant in the top-level module in the created template 
to 128, as opposed to 32.  I have read the PLB IPIF datasheet from Xilinx, 
which only says that USER_NUM_CE needs to be a power of two, which is why 
I used 128 versus 100.  After implementation, access to any register above 
32 leads to a returned value of zero, when it should be non-zero.  Any suggestions 
of what else I need to change in the generated IPIF code to get this working? 
 I really would like to avoid rolling my own.


---Matthew Hicks



Article: 126342
Subject: Re: Low cost FPGA w/serdes
From: lb.edc@telenet.be
Date: Tue, 20 Nov 2007 08:11:50 GMT
Links: << >>  << T >>  << A >>
Wow, how a discussion can evolve from a single reply from Austin to
contact my disti to a discussion about the distribution landscape in
Europe.

At Austin I would like to say: Austin, I've contacted my disti, but
they don't carry Xilinx. I'm sorry, I'm a Lattice user, so if I would
concider Xilinx (or Altera) the disti should contact me, shouldn't
they?

At all they other posters in this discussion: yes, you are right,
distribution has changed, but I wouldn't generalize this statement.
There are still good FAE's in this world. But the supplier should
train them well, and let them do their job, get experienced, find the
best solution (even if this is not in line with the directives from
the supplier to sell the newest part), ...

Concider this statement: distribution FAE's are the sausage between
the hot dog. They are sitting between the supplier and the customer
and are also trying to do what they are payed for.

At the end, I haven't found out the latest and greatest from Xilinx -
and as long as the parts aren't available in production, I will not
concider them for a new design. The ECP2M that I'm using is in
production, I get my parts at a decent price (better than the "one
off" price at Digikey), and I get from time to time annoying questions
from the disti FAE. But that's life I guess. (refering to Austin)

At least, I'm happy that my design is working. Now I can look for
someone who can build it in smaller quantities. But that's another
discussion, isn't it?

Luc

On Mon, 19 Nov 2007 18:24:03 +0000, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

>On Mon, 19 Nov 2007 10:00:22 -0800, austin <austin@xilinx.com> wrote:
>
>>If one argues that FPGA technology needs to become more user friendly,
>>and easier to use, in order to make inroads into all possible
>>applications, your experience is merely one example of an opportunity
>>(for Xilinx).
>
>Please don't forget that the experiences I was reporting 
>(ranting about) are a decade old.  To a large extent I think
>it's an opportunity you've already grasped - webshop, 
>excellent online documentation, free software downloads 
>for smaller customers, good appnotes.... and, dare I say,
>informal access to top-notch factory expertise via public
>media such as this group.
>
>>Sure, we could say "well, that is life" but who would we be serving?
>
>Nah.  You wouldn't do that.  You need to eat too :-)
>
>Like I said: it seems to me that major FPGA vendors have somewhat
>taken that opportunity already.  Almost without exception, they
>(or at least their FPGA business) started small, with reasonably
>close relations between factory and even the smaller customers.
>As they've grown they seem to have remembered that heritage,
>and the quality of technical information available through 
>FPGA vendors' websites and other resources is pretty good.
>(Yes, I know people complain all the time.  And you put a 
>brave face on it, because you know that there's at least a
>grain of truth in most complaints, and you want happy customers
>and happy potential customers.  We appreciate it.  Really.)
>
>I see the result of all this being a sidelining of the traditional
>distributor role as intermediary between factory and customer.
>Instead, the successful distributors either act as supermarkets
>(in which case let us treat them as such, and punish with our
>lack of custom those who can't keep their shelves full of 
>attractive products at attractive prices) or act as agencies
>helping large customers collaborate effectively with the
>factory to ensure a good deal for both parties.  The 
>traditional component disti, who tries to erect walls between
>customer and factory to protect his own revenue monopoly
>at the customer's expense, is surely a dinosaur whose 
>meteorite is already bright in the sky.  Their passing 
>will be mourned by but few.

Article: 126343
Subject: problem with adding custom logic to an IP core (xilinx edk)
From: techG <giuliopulina@gmail.com>
Date: Tue, 20 Nov 2007 00:23:02 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi all, I'm experiencing problems with adding custom logic to an IP
core that I have generate in EDK. I changed the vhdl file of an auto-
generated IP core that is connected via FSL to the FPGA, but the
behaviour of the program remains still the same. I've tried also to re-
import the modified core to the project, but I still get errors due to
the fact that the file xparameters.h doesn't contains the appropriated
names.
How can I do to let EDK notice changes in vhdl files?
Thank you in advance!

Giulio

Article: 126344
Subject: Re: problem with adding custom logic to an IP core (xilinx edk)
From: Andrew Greensted <ajg112@ohm.york.ac.uk>
Date: Tue, 20 Nov 2007 08:39:28 +0000
Links: << >>  << T >>  << A >>
techG wrote:
> Hi all, I'm experiencing problems with adding custom logic to an IP
> core that I have generate in EDK. I changed the vhdl file of an auto-
> generated IP core that is connected via FSL to the FPGA, but the
> behaviour of the program remains still the same. I've tried also to re-
> import the modified core to the project, but I still get errors due to
> the fact that the file xparameters.h doesn't contains the appropriated
> names.
> How can I do to let EDK notice changes in vhdl files?
> Thank you in advance!
> 
> Giulio

Hi Giulio,

You can regenerate the xparameters.h file using this menu option:
Software -> Generate Libraries and BSPs

Andy

Article: 126345
Subject: EDK 9.2 and virtex 2 devices
From: Andreas Wassatsch <wassatsch@hll.mpg.de>
Date: Tue, 20 Nov 2007 09:46:38 +0100
Links: << >>  << T >>  << A >>
Hi all,

i'm currently trying to make an virtex2 project with edk 9.2i.
Unfortunately all virtex2 based boards are removed from the bsb dialog
(also boards with older spartan devices).
Also the migration of an existing edk 91.i virtex2 project doesn't work.
The reason for these should be the new plb_v4.6. But the old plb version
is still there, so it should work.

Any ideas to solve these problem ?

Thanks in advance !

Andreas

Article: 126346
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 20 Nov 2007 22:54:13 +1300
Links: << >>  << T >>  << A >>
Antonio Pasini wrote:
> Il 20/11/2007 0.06, Didi ha scritto:
> 
>>
>>> 3) use Impact (free download) to translate the jedec in a XSVF binary
>>> file. You can do on GUI by hand, or by makefile as I prefer; syntax is:
>>>
>>
>> Now this is a hoop I can do without. XAPP058 actually states you have
>> to do jedec -> svf -> xsvf, and I see only the svf->xsvf tool freely
>> available. Is the tool for doing jedec->svf also freely available?
>> Can you point me to it please?
>>
> 
> Impact makes the jedec -> svf OR jedec ->XSVF translation, with the 
> commands of my previous posts.
> At the time of XAPP058, it wasn't able to.
> Now you can just go stright from jedec to XSVF with Impact alone.
> 
> Impact is free with the Webpack 
> (http://www.xilinx.com/ise/logic_design_prod/webpack.htm).
> 
> (I remember that there's also a "production" package with just the 
> Impact tool, but I don't find the link).

Do you have the xsvf file size handy, for your XC2C64 design ?
That would give Didi some info on the svf pathway.
(to go with the player info you've given)

(the XC2C64 has 3226.5 Bytes of fuse info.)
Usually svf have quite an overhead :
(eg an Atmel device with 2101.75 bytes of fuse info,
spawns a 110925 byte SVF file ~ 50:1 )

I have not tried to compress the SVF, but I'd guess 5-10
simple compression should be easy, esp for a known brand.
So that brings it down to 10-20K bytes, for a 2K binary image.

I also notice the Atmel tools can create a PCF via SVF2PCF,
for an even larger file, but one that is a logic analyser
storage - 191K lines, to JED pgm the 2KB fuses.

-jg




Article: 126347
Subject: Re: Update to Xilinx ISE 9.2
From: Andreas Hofmann <ahnews@gmx.net>
Date: Tue, 20 Nov 2007 10:57:08 +0100
Links: << >>  << T >>  << A >>
Harald schrieb:
> Sounds good, I just have here a full version of 7.1 available.
> So everyone would recommend me to download the 9.2 webpackage version
> and install that instead of 7.1?

That depends if your device is supported by WebPack. Take a look at
http://www.xilinx.com/ise/products/webpack_config.htm

Regards,
Andreas

Article: 126348
Subject: Re: EDK 9.2 and virtex 2 devices
From: Harald <Harald@yahoo.co.uk>
Date: Tue, 20 Nov 2007 11:28:01 +0000
Links: << >>  << T >>  << A >>
> i'm currently trying to make an virtex2 project with edk 9.2i.
> Unfortunately all virtex2 based boards are removed from the bsb dialog
> (also boards with older spartan devices).

I have the same problem. I have a Virtex2-XC2V6000 board that I wanna 
use for sythesis. In the device properties of ISE 9.2 I just have the 
option to chose between the following devices:

- XC2V40
- XC2V80
- XC2V250
- XC2V500

Is there a way to run synthesis for my board? I assume the other boards
wont be compatible with the one I am using?

Cheers,
Harald

Article: 126349
Subject: Re: EDK 9.2 and virtex 2 devices
From: Andreas Wassatsch <wassatsch@hll.mpg.de>
Date: Tue, 20 Nov 2007 12:46:42 +0100
Links: << >>  << T >>  << A >>
Dear Harald,

i have in the ISE9.2_03i(lin64) the xc2v6000 in the device option tab

my problem is the edk and not the ise

Regards,

Andreas

Harald wrote:
>> i'm currently trying to make an virtex2 project with edk 9.2i.
>> Unfortunately all virtex2 based boards are removed from the bsb dialog
>> (also boards with older spartan devices).
> 
> I have the same problem. I have a Virtex2-XC2V6000 board that I wanna
> use for sythesis. In the device properties of ISE 9.2 I just have the
> option to chose between the following devices:
> 
> - XC2V40
> - XC2V80
> - XC2V250
> - XC2V500
> 
> Is there a way to run synthesis for my board? I assume the other boards
> wont be compatible with the one I am using?
> 
> Cheers,
> Harald



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search