Coolrunner in system programming - XAPP0058 - viable?

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

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

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

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.

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

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.

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

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

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

Jim,

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

I am quite sure I can reproduce the entire chain of hoops
in xapp058. It would allow me to eventually reverse engineer
their jedec -> jtag mapping in a matter of days or may be
weeks if I want to include more devices.
 The "impact" tool Antonio is using is not available on the
xilinx website, but I am sure I could find it as well, it
must be out there.
 Yet the question remains - _why_ do they keep the mapping
data secret? I predicted we may wait for a century or so
for a plausible answer - the first one we got from their
CPLD support is more arrogant than it is ridiculous. Who
does this person think is talking to, housewifes? Their
JTAG interface is too complex for us to handle, yeah,
in fact some of us have handled the coolrunner jtag interface
before xilinx had a clue what the coolrunner was.
 I wonder if this reply is more arrogant and rude than
the one I got from their "support" department 5-6 years
ago, then they wanted me to make the $20M/quarter revenue
before they would consider talking to me. I'll dig that
message and post it here as well, this is the least their
arrogance deserves.

Dimiter

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

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


On Nov 20, 11:54 am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> 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