Jtag CPLD configuration.

<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