Coolrunner in system programming - XAPP0058 - viable?

For lowest power/new designs, you would choose ATF1508BE

- not sure on the exact uA spec of that, I think ATF1508BE-7AU100 is now sampling.

See

-jg

Il 18/11/2007 0.12, Didi ha scritto:

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

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

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,

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.

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

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

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

That is a good question.

Comments Austin ? ( or Jesse? )

-jg

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

-jg

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.

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

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

------------------------------------------------------

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

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

------------------------------------------------------

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

------------------------------------------------------

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

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

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

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

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.

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

------------------------------------------------------

Thanks Peter / Jesse.

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

(XC2C256) by JTAG with a microcontroller. Xilinx provides all the info you need in their app notes.

production. Just a second to program a XC2C256, reasonably filled.

"easily" ported.

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

-jg

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.

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

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

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

Some use SVF files.

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

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

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

(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:

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

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,

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

------------------------------------------------------