Forums

Jtag CPLD configuration.

Started by Keith September 7, 2007
<Previously posted to comp.arch.fpga with no luck so far.
Thought I'd try here.>

Hello

I have a Xilinx XCR3064 CPLD with its JTAG pins hooked up to
some digital I/O pins on a uC.  I intend to configure the CPLD
from a binary file held in uC flash by bit-banging the uC pins.
So far I've implemented the TAP state machine and managed to
correctly read the 32 bit ID code, so a start has been made.

But what to do now?  The documentation seems sparse or
overwhelming but undetailed.

What I've found so far is:

<quote>
CoolRunner Programming Algorithm

Enter the device into ISP mode
Erase the entire device
Program all addresses
Verify all addresses
Exit the ISP mode and return to normal functional mode.
</quote>

Which all seems fair enough but insufficient.  Do I use the
commands isp-write, then clock in the bitstream followed by
isp-program? Is there some sort of flag which will tell me when
an erase or write has finished?

How do I make the bitstream from an ascii .jed file?  Do I just
ignore the various markers and bundle the 0's and 1's into a
binary file?

These svf and xsvfs files look a bit unnecessary.  Is the
bitstream loaded in one lump?  Is the erase just one command?  I
saw a reference to blocks, whassat then?

All these questions and more; I know many people must have done
this but can't find anything clear.  I've not used JTAG before,
so it's all a bit confusing.  I did it years ago with a
RAM-based FPGA but that was an easy non-JTAG port method, 'slave
serial mode' IIRC.

There are good technical reasons for not using an FPGA for this
which I can't go into.

Help?

TVM
-- 
Keith Wootten




-- 
Posted via a free Usenet account from http://www.teranews.com

Keith wrote:

> <quote> > CoolRunner Programming Algorithm > > Enter the device into ISP mode > Erase the entire device > Program all addresses > Verify all addresses > Exit the ISP mode and return to normal functional mode. > </quote>
I think you'll find it all in the appnote http://direct.xilinx.com/bvdocs/appnotes/xapp058.pdf There's a link to a download for the C source of the files required.
> I have a Xilinx XCR3064 CPLD with its JTAG pins hooked up to > some digital I/O pins on a uC. I intend to configure the CPLD > from a binary file held in uC flash by bit-banging the uC pins. > So far I've implemented the TAP state machine and managed to > correctly read the 32 bit ID code, so a start has been made. > > But what to do now? The documentation seems sparse or > overwhelming but undetailed.
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 dp@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 http://www.tgi-sci.com ------------------------------------------------------ On Sep 7, 6:38 pm, "Keith" <nonon...@no.no> wrote:
> <Previously posted to comp.arch.fpga with no luck so far. > Thought I'd try here.> > > Hello > > I have a Xilinx XCR3064 CPLD with its JTAG pins hooked up to > some digital I/O pins on a uC. I intend to configure the CPLD > from a binary file held in uC flash by bit-banging the uC pins. > So far I've implemented the TAP state machine and managed to > correctly read the 32 bit ID code, so a start has been made. > > But what to do now? The documentation seems sparse or > overwhelming but undetailed. > > What I've found so far is: > > <quote> > CoolRunner Programming Algorithm > > Enter the device into ISP mode > Erase the entire device > Program all addresses > Verify all addresses > Exit the ISP mode and return to normal functional mode. > </quote> > > Which all seems fair enough but insufficient. Do I use the > commands isp-write, then clock in the bitstream followed by > isp-program? Is there some sort of flag which will tell me when > an erase or write has finished? > > How do I make the bitstream from an ascii .jed file? Do I just > ignore the various markers and bundle the 0's and 1's into a > binary file? > > These svf and xsvfs files look a bit unnecessary. Is the > bitstream loaded in one lump? Is the erase just one command? I > saw a reference to blocks, whassat then? > > All these questions and more; I know many people must have done > this but can't find anything clear. I've not used JTAG before, > so it's all a bit confusing. I did it years ago with a > RAM-based FPGA but that was an easy non-JTAG port method, 'slave > serial mode' IIRC. > > There are good technical reasons for not using an FPGA for this > which I can't go into. > > Help? > > TVM > -- > Keith Wootten > > -- > Posted via a free Usenet account fromhttp://www.teranews.com
"Paul Burke" <paul@scazon.com> wrote in message
news:5kdao0F34s2eU1@mid.individual.net...

<snip>
> > I think you'll find it all in the appnote > http://direct.xilinx.com/bvdocs/appnotes/xapp058.pdf > > There's a link to a download for the C source of the files
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 64 macrocell CPLD - surely it must be simpler? 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 -- Keith Wootten -- Posted via a free Usenet account from http://www.teranews.com
"Didi" <dp@tgi-sci.com> wrote in message
news:1189181038.480505.298620@o80g2000hse.googlegroups.com...

<snipped>

> You can contact me privately at <snipped> 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
Thanks, Dimiter. email follows. Cheers -- Keith Wootten -- Posted via a free Usenet account from http://www.teranews.com
Keith wrote:
> "Paul Burke" <paul@scazon.com> wrote in message > news:5kdao0F34s2eU1@mid.individual.net... > > <snip> > >>I think you'll find it all in the appnote >>http://direct.xilinx.com/bvdocs/appnotes/xapp058.pdf >> >>There's a link to a download for the C source of the files > > 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 > 64 macrocell CPLD - surely it must be simpler?
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)
> > 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?
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
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in
message news:46e59be4$1@clear.net.nz...

<snip>

> 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.
Hi Jim, thanks, that's clearer. It would be nice if all this were published.
> Some CPLDs have a RAM mode, that may be simpler to put into > a uC (but is, of course, volatile)
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?
> > 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? > > Why do you need to store this in a uC - does the uC change it, > or is it for some possible later upgrade.
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.
> 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.
This is a 'back burner' project at the moment, so I may well find time to do that. Cheers -- Keith Wootten -- Posted via a free Usenet account from http://www.teranews.com
Keith wrote:
> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in > message news:46e59be4$1@clear.net.nz... > > <snip> > >>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. > > > Hi Jim, thanks, that's clearer. It would be nice if all this > were published. > > >>Some CPLDs have a RAM mode, that may be simpler to put into >>a uC (but is, of course, volatile) > > > 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?
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