Jtag CPLD configuration. (2025 Update)

I think you'll find it all in the appnote

There's a link to a download for the C source of the files required.

The 3064 is the oldest - from the Philips time - Coolrunner. I have the data it takes to be programmed - in fact, I have it supported by my logic compiler under DPS (which probably is of no interest to you since you have no DPS machine). Some of the data took some reverse-engineering from me - I discovered Philips had given me not all fusemap data when it was too late - part designed in, Xilinx having taken over (and talking to Xilinx about fusemap data is a waste of time, unless you need a good laughter - at some point some "support" person told me I had to make a $20M quarterly revenue for them then they would consider my case and perhaps hand me the data...)

You can contact me privately at snipped-for-privacy@tgi-sci.com if you want me to do some digging and send you the files I have, I can do that and will be happy to do it. If you want to use newer - purely Xilinx - coolrunners, I can be of little if any help, though.

Dimiter

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

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

required.

Thanks, Paul, I've seen that: it's quite complicated. I had hoped there would be an easier way, after all, I did it years ago with a much bigger FPGA using a serial mode. This is just a

There's a little over 3KB of configuration bits as far as I can tell from the .jed file - do Xilinx/Philips deliberately obscure matters for these parts?

Cheers

Thanks, Dimiter. email follows.

Cheers

FPGAs are SRAM, and designed for Serial-Bootload, whilst CPLDs are FLASH, so add an Erase/Verify pass, and also the FLASH pgm is blocked in nature, then you typically have variable size chunks, in the Product term areas, and in the macrocell config, and finally the security.

Some CPLDs have a RAM mode, that may be simpler to put into a uC (but is, of course, volatile)

Why do you need to store this in a uC - does the uC change it, or is it for some possible later upgrade.

You could get a handle on the config, if you dropped a device into a universal programmer, and put a storage scope / counter on the JTAG pins.

-jg

Hi Jim, thanks, that's clearer. It would be nice if all this were published.

We're stuck withthe XCR3064XL - I'm not sure if this has a RAM mode, it's hinted at in one of the datasheets. Do the EEPROM cells control the configuration directly, or do they load RAM cells on bootup?

can

obscure

It's mainly for future upgrades. I'd like to keep everything in one place (the uC flash) so it's just one file to update - the equipment is field-upgradeable. A side benefit is gaining the programming port real estate.

into

the

This is a 'back burner' project at the moment, so I may well find time to do that.

Cheers

Most of the micro-power ones, have a boot-time, so they load from EE to RAM, and usually finite 'many us to some ms' region. Varies with vendor. Players in this market are Atmel, Lattice, Xilinx.

Most vendors will create a SVF file, and that could be token-compressed, or reverse engineered. I see Atmel also mention a SVF to PCF (HP Tester format) utility, so you could see if Xilinx have something similar, and if the PCF is easier to work with, or not.

A quick look here, at some Atmel files, shows a 109KB/5270 line SVF file, and the PCF file is 191K lines, 3.7MB, and those for a 2.2KByte binary fuse size. So there is 'fat' :)

-jg