Coolrunner in system programming - XAPP0058 - viable?

I looked at XAPP0058 which describes some algorithms for in system
programming of some Xilinx CPLDs.
 It appears that there are enough data to program a XPLA3 device once
I have the binary data I want to program without needing any more
tools/software/hoops_to_jump_through_I_havent_thought_of.
 However, given the long history of programming data secrecy (of
not just Xilinx, they only pioneered that, I believe) I would like to
get
a confirmation by someone who has done it that this is actually
possible for the XPLA3.
 Can I produce a binary using ABEL or whatever I can find in their
free software (the way this used to be possible using PHDL before
Xilinx bought and made the Coolrunner programming secret) and
program it into their xpla3 parts _without_ using any JTAG
tools/software other than those I make? Would I be able to utilize all
CPLD resources with their free software (as far as producing the
binary
is concerned, that is)?
 I am using my own JTAG hardware/software, it runs under DPS,
under which my logic compiler for the Philips coolrunner used to run
(still does, just no parts available). Adapting it to do anything is
not a problem, as long as "anything" is not kept secret.
 This may sound overly paranoid, but I do expect all sorts of catches
nowadays not only from Xilinx, hence my question.
 IIRC Xilinx had something in the agreement with Philips to support
all
previous customers, but I am not in the mood for legal battles, I just
need a usable CPLD (not one which comes with a PC/MS or whatever
attached to it in order to be written to) without having to do a lot
of
reverse engineering.

Dimiter

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

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

Didi wrote:
> I looked at XAPP0058 which describes some algorithms for in system
> programming of some Xilinx CPLDs.
>  It appears that there are enough data to program a XPLA3 device once
> I have the binary data I want to program without needing any more
> tools/software/hoops_to_jump_through_I_havent_thought_of.
>  However, given the long history of programming data secrecy (of
> not just Xilinx, they only pioneered that, I believe) I would like to
> get
> a confirmation by someone who has done it that this is actually
> possible for the XPLA3.
>  Can I produce a binary using ABEL or whatever I can find in their
> free software (the way this used to be possible using PHDL before
> Xilinx bought and made the Coolrunner programming secret) and
> program it into their xpla3 parts _without_ using any JTAG
> tools/software other than those I make? Would I be able to utilize all
> CPLD resources with their free software (as far as producing the
> binary
> is concerned, that is)?
>  I am using my own JTAG hardware/software, it runs under DPS,
> under which my logic compiler for the Philips coolrunner used to run
> (still does, just no parts available). Adapting it to do anything is
> not a problem, as long as "anything" is not kept secret.
>  This may sound overly paranoid, but I do expect all sorts of catches
> nowadays not only from Xilinx, hence my question.
>  IIRC Xilinx had something in the agreement with Philips to support
> all
> previous customers, but I am not in the mood for legal battles, I just
> need a usable CPLD (not one which comes with a PC/MS or whatever
> attached to it in order to be written to) without having to do a lot
> of
> reverse engineering.
> 
> Dimiter

If you consider yourself the same as a programmer manufacturer :

My device programmer lists

PZ5032
PZ3032
XC3032XL
XC2C32A

so, that means the algorithms for all of those are published.

-jg

A few hours of digging later I found out that the JTAG
sequences needed to write to a XPLA3 and Coolrunner-II
are publically available.
 However, the JEDEC -> JTAGgable fuse address translation
map is not (I do have that for the Philips Coolrunner,
the bit locations in the JTAG sequence descriptions have
nothing to do with the bit locations in the JEDEC file).
 The suggested way is to go through a variety of hoops,
obviously for no other reason than to obscure the fact
that one has to pay them up to translate the bit locations
for me.
 Notice this fact is _very_ obscure, I am not sure
many - if any - people realise it, apparently done so
the user would discover that fact when it is too late
(after having designed the part in).

Do people know that? If I am more lucky, has anyone
found the solution to that? (paying up for being allowed
to program a part I have bought is not something I would
consider, this is racket rather than business in my book).

Thanks,

Dimiter

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

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

On Nov 17, 6:00 pm, Didi <didi...@gmail.com> wrote:
> I looked at XAPP0058 which describes some algorithms for in system
> programming of some Xilinx CPLDs.
>  It appears that there are enough data to program a XPLA3 device once
> I have the binary data I want to program without needing any more
> tools/software/hoops_to_jump_through_I_havent_thought_of.
>  However, given the long history of programming data secrecy (of
> not just Xilinx, they only pioneered that, I believe) I would like to
> get
> a confirmation by someone who has done it that this is actually
> possible for the XPLA3.
>  Can I produce a binary using ABEL or whatever I can find in their
> free software (the way this used to be possible using PHDL before
> Xilinx bought and made the Coolrunner programming secret) and
> program it into their xpla3 parts _without_ using any JTAG
> tools/software other than those I make? Would I be able to utilize all
> CPLD resources with their free software (as far as producing the
> binary
> is concerned, that is)?
>  I am using my own JTAG hardware/software, it runs under DPS,
> under which my logic compiler for the Philips coolrunner used to run
> (still does, just no parts available). Adapting it to do anything is
> not a problem, as long as "anything" is not kept secret.
>  This may sound overly paranoid, but I do expect all sorts of catches
> nowadays not only from Xilinx, hence my question.
>  IIRC Xilinx had something in the agreement with Philips to support
> all
> previous customers, but I am not in the mood for legal battles, I just
> need a usable CPLD (not one which comes with a PC/MS or whatever
> attached to it in order to be written to) without having to do a lot
> of
> reverse engineering.
>
> Dimiter
>
> ------------------------------------------------------
> Dimiter Popoff               Transgalactic Instruments
>
> http://www.tgi-sci.com
> ------------------------------------------------------

Hi Jim,

> My device programmer lists
>
> PZ5032
> PZ3032
> XC3032XL
> XC2C32A
>
> so, that means the algorithms for all of those are published.

do you mean there should be all data out there so one can write
what it takes to program a device from a JEDEC file? So far I
fail to find out how (all day), please send some more hint
(also please take my other posting about JEDEC <-> JTAG mapping into
account).

Dimiter

On Nov 18, 12:43 am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Didi wrote:
> > I looked at XAPP0058 which describes some algorithms for in system
> > programming of some Xilinx CPLDs.
> >  It appears that there are enough data to program a XPLA3 device once
> > I have the binary data I want to program without needing any more
> > tools/software/hoops_to_jump_through_I_havent_thought_of.
> >  However, given the long history of programming data secrecy (of
> > not just Xilinx, they only pioneered that, I believe) I would like to
> > get
> > a confirmation by someone who has done it that this is actually
> > possible for the XPLA3.
> >  Can I produce a binary using ABEL or whatever I can find in their
> > free software (the way this used to be possible using PHDL before
> > Xilinx bought and made the Coolrunner programming secret) and
> > program it into their xpla3 parts _without_ using any JTAG
> > tools/software other than those I make? Would I be able to utilize all
> > CPLD resources with their free software (as far as producing the
> > binary
> > is concerned, that is)?
> >  I am using my own JTAG hardware/software, it runs under DPS,
> > under which my logic compiler for the Philips coolrunner used to run
> > (still does, just no parts available). Adapting it to do anything is
> > not a problem, as long as "anything" is not kept secret.
> >  This may sound overly paranoid, but I do expect all sorts of catches
> > nowadays not only from Xilinx, hence my question.
> >  IIRC Xilinx had something in the agreement with Philips to support
> > all
> > previous customers, but I am not in the mood for legal battles, I just
> > need a usable CPLD (not one which comes with a PC/MS or whatever
> > attached to it in order to be written to) without having to do a lot
> > of
> > reverse engineering.
>
> > Dimiter
>
> If you consider yourself the same as a programmer manufacturer :
>
> My device programmer lists
>
> PZ5032
> PZ3032
> XC3032XL
> XC2C32A
>
> so, that means the algorithms for all of those are published.
>
> -jg

Didi wrote:

> Hi Jim,
> 
> 
>>My device programmer lists
>>
>>PZ5032
>>PZ3032
>>XC3032XL
>>XC2C32A
>>
>>so, that means the algorithms for all of those are published.
> 
> 
> do you mean there should be all data out there so one can write
> what it takes to program a device from a JEDEC file? So far I
> fail to find out how (all day), please send some more hint
> (also please take my other posting about JEDEC <-> JTAG mapping into
> account).

  Basically, yes. Clearly our programemr supplier (ee tools) has done this.

  Mostly they use the JTAG pins and pathway, tho some PLDs also have 
extra means to jtag-unlock, which needs more pins.

  It means that progamming documents must exist, and be sent to the
programmer manufacturers.

  They may not be fully public, but they are not 'closed' either.

  So ask Xilinx for the info, explain you are manufacturing device 
programmers.

  If they prove too hard to work with, you could try Atmel etc
They have appx equivalent devices to the smaller XPLA3

  A working device programmer is also not a bad way to reality-check your
work.
  eg You can pgm a part, and then confirm you can read it in your system,
and then pgm in your system, and read/save the result, to analyse if
some bits are in the wrong place.

-jg



> 
> Dimiter
> 
> On Nov 18, 12:43 am, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
> 
>>Didi wrote:
>>
>>>I looked at XAPP0058 which describes some algorithms for in system
>>>programming of some Xilinx CPLDs.
>>> It appears that there are enough data to program a XPLA3 device once
>>>I have the binary data I want to program without needing any more
>>>tools/software/hoops_to_jump_through_I_havent_thought_of.
>>> However, given the long history of programming data secrecy (of
>>>not just Xilinx, they only pioneered that, I believe) I would like to
>>>get
>>>a confirmation by someone who has done it that this is actually
>>>possible for the XPLA3.
>>> Can I produce a binary using ABEL or whatever I can find in their
>>>free software (the way this used to be possible using PHDL before
>>>Xilinx bought and made the Coolrunner programming secret) and
>>>program it into their xpla3 parts _without_ using any JTAG
>>>tools/software other than those I make? Would I be able to utilize all
>>>CPLD resources with their free software (as far as producing the
>>>binary
>>>is concerned, that is)?
>>> I am using my own JTAG hardware/software, it runs under DPS,
>>>under which my logic compiler for the Philips coolrunner used to run
>>>(still does, just no parts available). Adapting it to do anything is
>>>not a problem, as long as "anything" is not kept secret.
>>> This may sound overly paranoid, but I do expect all sorts of catches
>>>nowadays not only from Xilinx, hence my question.
>>> IIRC Xilinx had something in the agreement with Philips to support
>>>all
>>>previous customers, but I am not in the mood for legal battles, I just
>>>need a usable CPLD (not one which comes with a PC/MS or whatever
>>>attached to it in order to be written to) without having to do a lot
>>>of
>>>reverse engineering.
>>
>>>Dimiter
>>
>>If you consider yourself the same as a programmer manufacturer :
>>
>>My device programmer lists
>>
>>PZ5032
>>PZ3032
>>XC3032XL
>>XC2C32A
>>
>>so, that means the algorithms for all of those are published.
>>
>>-jg
> 
> 

>   So ask Xilinx for the info, explain you are manufacturing device
> programmers.
>
>   If they prove too hard to work with, you could try Atmel etc
> They have appx equivalent devices to the smaller XPLA3

Well thanks, Jim, sounds encouraging. Have not wasted any time talking
programming data to their support for years, time to try again may be.
I strongly suspect I know what the result will be, though.

>   It means that progamming documents must exist, and be sent to the
> programmer manufacturers.

Are you saying you can program a Coolrunner using a non-Xilinx
programmer and a _JEDEC_ file? Without the programmer using
(or asking you to use) some paid Xilinx software to do some
fuse address mapping?
 Generally this is the question Xilinx' documents do not
answer (and seem to deliberately obscure).

>   A working device programmer is also not a bad way to reality-check your
> work.
>   eg You can pgm a part, and then confirm you can read it in your system,
> and then pgm in your system, and read/save the result, to analyse if
> some bits are in the wrong place.

Oh I do not need that, last time I did it for the original Coolrunner
it took me weeks rather than months to do the whole thing having
just the data and a few chips. It totally took me about 3 months
to write a suitable logic compiler (similar - not directly
compatible - to PHDL, but more flexible/powerful, with all the DPS
scripting. macros etc.) and some reverse engineering I had to do
because I did not have all the data (Philips were easier to deal
with than Xilinx - I guess everyone is that - but sent me only
_most_ of the data, omitted a significant part of them...).
 Programming a device via JTAG is a lot easier than they make
it sound (and cash in for), one just needs the device documentation.

Dimiter

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

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


On Nov 18, 2:41 am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Didi wrote:
> > Hi Jim,
>
> >>My device programmer lists
>
> >>PZ5032
> >>PZ3032
> >>XC3032XL
> >>XC2C32A
>
> >>so, that means the algorithms for all of those are published.
>
> > do you mean there should be all data out there so one can write
> > what it takes to program a device from a JEDEC file? So far I
> > fail to find out how (all day), please send some more hint
> > (also please take my other posting about JEDEC <-> JTAG mapping into
> > account).
>
>   Basically, yes. Clearly our programemr supplier (ee tools) has done this.
>
>   Mostly they use the JTAG pins and pathway, tho some PLDs also have
> extra means to jtag-unlock, which needs more pins.
>
>   It means that progamming documents must exist, and be sent to the
> programmer manufacturers.
>
>   They may not be fully public, but they are not 'closed' either.
>
>   So ask Xilinx for the info, explain you are manufacturing device
> programmers.
>
>   If they prove too hard to work with, you could try Atmel etc
> They have appx equivalent devices to the smaller XPLA3
>
>   A working device programmer is also not a bad way to reality-check your
> work.
>   eg You can pgm a part, and then confirm you can read it in your system,
> and then pgm in your system, and read/save the result, to analyse if
> some bits are in the wrong place.
>
> -jg
>
>
>
> > Dimiter
>
> > On Nov 18, 12:43 am, Jim Granville <no.s...@designtools.maps.co.nz>
> > wrote:
>
> >>Didi wrote:
>
> >>>I looked at XAPP0058 which describes some algorithms for in system
> >>>programming of some Xilinx CPLDs.
> >>> It appears that there are enough data to program a XPLA3 device once
> >>>I have the binary data I want to program without needing any more
> >>>tools/software/hoops_to_jump_through_I_havent_thought_of.
> >>> However, given the long history of programming data secrecy (of
> >>>not just Xilinx, they only pioneered that, I believe) I would like to
> >>>get
> >>>a confirmation by someone who has done it that this is actually
> >>>possible for the XPLA3.
> >>> Can I produce a binary using ABEL or whatever I can find in their
> >>>free software (the way this used to be possible using PHDL before
> >>>Xilinx bought and made the Coolrunner programming secret) and
> >>>program it into their xpla3 parts _without_ using any JTAG
> >>>tools/software other than those I make? Would I be able to utilize all
> >>>CPLD resources with their free software (as far as producing the
> >>>binary
> >>>is concerned, that is)?
> >>> I am using my own JTAG hardware/software, it runs under DPS,
> >>>under which my logic compiler for the Philips coolrunner used to run
> >>>(still does, just no parts available). Adapting it to do anything is
> >>>not a problem, as long as "anything" is not kept secret.
> >>> This may sound overly paranoid, but I do expect all sorts of catches
> >>>nowadays not only from Xilinx, hence my question.
> >>> IIRC Xilinx had something in the agreement with Philips to support
> >>>all
> >>>previous customers, but I am not in the mood for legal battles, I just
> >>>need a usable CPLD (not one which comes with a PC/MS or whatever
> >>>attached to it in order to be written to) without having to do a lot
> >>>of
> >>>reverse engineering.
>
> >>>Dimiter
>
> >>If you consider yourself the same as a programmer manufacturer :
>
> >>My device programmer lists
>
> >>PZ5032
> >>PZ3032
> >>XC3032XL
> >>XC2C32A
>
> >>so, that means the algorithms for all of those are published.
>
> >>-jg

Didi wrote:
>>  So ask Xilinx for the info, explain you are manufacturing device
>>programmers.
>>
>>  If they prove too hard to work with, you could try Atmel etc
>>They have appx equivalent devices to the smaller XPLA3
> 
> 
> Well thanks, Jim, sounds encouraging. Have not wasted any time talking
> programming data to their support for years, time to try again may be.
> I strongly suspect I know what the result will be, though.
> 
> 
>>  It means that progamming documents must exist, and be sent to the
>>programmer manufacturers.
> 
> 
> Are you saying you can program a Coolrunner using a non-Xilinx
> programmer and a _JEDEC_ file? Without the programmer using
> (or asking you to use) some paid Xilinx software to do some
> fuse address mapping?
>  Generally this is the question Xilinx' documents do not
> answer (and seem to deliberately obscure).

Yes. On my EE Tools ChipMAx and TopMAX, I can load a std JED file
(which typically does need Xilinx/Vendor tools to generate :)
and then I can Pgm Xc2C XCR, XCS Coolrunner devices
( as well as CPLD from Altera, Atmel, Lattice, etc,so they have the
Programming specs from all those suppliers )

The fuse address mapping, is included in the Programming Document,
so the Device programmer handles that
(and does the reverse process, when it reads the CPLD and saves to a JED 
file)
It will also vector test, which just needs a simple pin-mapping.

On the documents I've seen, it aligns reasonably well with
the JED - often they vary Pgm block sizes, and round to boundaries,
and security can differ.

> 
>>  A working device programmer is also not a bad way to reality-check your
>>work.
>>  eg You can pgm a part, and then confirm you can read it in your system,
>>and then pgm in your system, and read/save the result, to analyse if
>>some bits are in the wrong place.
> 
> 
> Oh I do not need that, last time I did it for the original Coolrunner
> it took me weeks rather than months to do the whole thing having
> just the data and a few chips. It totally took me about 3 months
> to write a suitable logic compiler (similar - not directly
> compatible - to PHDL, but more flexible/powerful, with all the DPS
> scripting. macros etc.) and some reverse engineering I had to do
> because I did not have all the data (Philips were easier to deal
> with than Xilinx - I guess everyone is that - but sent me only
> _most_ of the data, omitted a significant part of them...).
>  Programming a device via JTAG is a lot easier than they make
> it sound (and cash in for), one just needs the device documentation.

I didn't think you _needed_ it, just that it can be useful to save 
time... :)

-jg

Jim,

> The fuse address mapping, is included in the Programming Document,
> so the Device programmer handles that
> (and does the reverse process, when it reads the CPLD and saves to a JED
> file)
> It will also vector test, which just needs a simple pin-mapping.
>
> On the documents I've seen, it aligns reasonably well with
> the JED - often they vary Pgm block sizes, and round to boundaries,
> and security can differ.

they are cheating somehow.
Their document on Coolrunner-II programming states:

"The Excel fuse map file indicates the bit position of each bit
of fuse data in the ISC Register.  Each column in the fuse map
represents a device address.  Each row represents a bit in the
ISC Register.  The leftmost column is ordinal address 0.  The
uppermost row is ISC Register data bit location 0. "

This is pretty much what I have on the original coolruner, the
.xls file which allowed me to do jedec file -> jtag stream.
 Not available anywhere from xilinx - I looked pretty hard.

So either the programmer manufacturers have been "party members"
and have been given these data or there is some other cheating
going on.
 Can you please verify that you can program a jedec file to
a coolrunner on a PC which does not have the Xilinx software
on it? While being disconected from the net, that is...
 If it works, I may apply for party membership at 52 for
the first time, who knows.... :-).

 Thanks a lot,

Dimiter

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

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



On Nov 18, 9:03 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Didi wrote:
> >>  So ask Xilinx for the info, explain you are manufacturing device
> >>programmers.
>
> >>  If they prove too hard to work with, you could try Atmel etc
> >>They have appx equivalent devices to the smaller XPLA3
>
> > Well thanks, Jim, sounds encouraging. Have not wasted any time talking
> > programming data to their support for years, time to try again may be.
> > I strongly suspect I know what the result will be, though.
>
> >>  It means that progamming documents must exist, and be sent to the
> >>programmer manufacturers.
>
> > Are you saying you can program a Coolrunner using a non-Xilinx
> > programmer and a _JEDEC_ file? Without the programmer using
> > (or asking you to use) some paid Xilinx software to do some
> > fuse address mapping?
> >  Generally this is the question Xilinx' documents do not
> > answer (and seem to deliberately obscure).
>
> Yes. On my EE Tools ChipMAx and TopMAX, I can load a std JED file
> (which typically does need Xilinx/Vendor tools to generate :)
> and then I can Pgm Xc2C XCR, XCS Coolrunner devices
> ( as well as CPLD from Altera, Atmel, Lattice, etc,so they have the
> Programming specs from all those suppliers )
>
> The fuse address mapping, is included in the Programming Document,
> so the Device programmer handles that
> (and does the reverse process, when it reads the CPLD and saves to a JED
> file)
> It will also vector test, which just needs a simple pin-mapping.
>
> On the documents I've seen, it aligns reasonably well with
> the JED - often they vary Pgm block sizes, and round to boundaries,
> and security can differ.
>
>
>
>
>
> >>  A working device programmer is also not a bad way to reality-check your
> >>work.
> >>  eg You can pgm a part, and then confirm you can read it in your system,
> >>and then pgm in your system, and read/save the result, to analyse if
> >>some bits are in the wrong place.
>
> > Oh I do not need that, last time I did it for the original Coolrunner
> > it took me weeks rather than months to do the whole thing having
> > just the data and a few chips. It totally took me about 3 months
> > to write a suitable logic compiler (similar - not directly
> > compatible - to PHDL, but more flexible/powerful, with all the DPS
> > scripting. macros etc.) and some reverse engineering I had to do
> > because I did not have all the data (Philips were easier to deal
> > with than Xilinx - I guess everyone is that - but sent me only
> > _most_ of the data, omitted a significant part of them...).
> >  Programming a device via JTAG is a lot easier than they make
> > it sound (and cash in for), one just needs the device documentation.
>
> I didn't think you _needed_ it, just that it can be useful to save
> time... :)
>
> -jg

Didi wrote:
> Jim,
> 
> 
>>The fuse address mapping, is included in the Programming Document,
>>so the Device programmer handles that
>>(and does the reverse process, when it reads the CPLD and saves to a JED
>>file)
>>It will also vector test, which just needs a simple pin-mapping.
>>
>>On the documents I've seen, it aligns reasonably well with
>>the JED - often they vary Pgm block sizes, and round to boundaries,
>>and security can differ.
> 
> 
> they are cheating somehow.
> Their document on Coolrunner-II programming states:
> 
> "The Excel fuse map file indicates the bit position of each bit
> of fuse data in the ISC Register.  Each column in the fuse map
> represents a device address.  Each row represents a bit in the
> ISC Register.  The leftmost column is ordinal address 0.  The
> uppermost row is ISC Register data bit location 0. "
> 
> This is pretty much what I have on the original coolruner, the
> .xls file which allowed me to do jedec file -> jtag stream.
>  Not available anywhere from xilinx - I looked pretty hard.
> 
> So either the programmer manufacturers have been "party members"
> and have been given these data 

Yes. They don't have the time, or inclination, to reverse engineer !

If Xilinx wants device programmer support, they must provide the info.
(as do all the chip vendors)

> or there is some other cheating  going on.
>  Can you please verify that you can program a jedec file to
> a coolrunner on a PC which does not have the Xilinx software
> on it? While being disconected from the net, that is...
>  If it works, I may apply for party membership at 52 for
> the first time, who knows.... :-).
> 
>  Thanks a lot,

  I'm not sure what you are expecting, the flow IS pretty simple :
[I suspect you are being too paranoid :) ? ]

eg : I trawl my PC for a Xilinx JED file,
and find this

D:\Xilinx\DesignPaths\Design.JED:

Programmer Jedec Bit Map
Date Extracted: Wed Apr 30 21:16:51 2007
QF25808*
QP56*
QV0*
F0*
X0*
J0 0*
N DEVICE XC2C64-4-CP56*

Note Block 0 *
Note Block 0 ZIA *
L000000 1110110011111111*
L000016 1110101011111111*
<snip>
Note Block 3 I/O Macrocell Configuration 27 bits *
N Aclk ClkOp Clk:2 ClkFreq R:2 P:2 RegMod:2 INz:2 FB:2 InReg St XorIn:2 
RegCom Oe:4 Tm Slw Pu*
L025360 000001111001111100010000001*
L025387 000001111001111100010000001*
L025414 000001111001111100010000001*
L025441 000001111001111110011111100*
L025468 000001111001111101110000001*
L025495 000001111001111110011111100*
L025522 000001111000011100011111100*
L025549 000001111001111110011111100*
L025576 000001111001111110011111100*
L025603 000001111000011100011111100*
L025630 000001111001111110011111100*
L025657 000001111001111110011111100*
L025684 000001111001111110011111100*
L025711 000001111001111110011111100*
L025738 000001111001111110011111100*
L025765 000001111001111110011111100*

Note Globals *
Note Global Clock Mux *
L025792 100*

Note Global Set/Reset Mux *
L025795 00*

Note Global OE Mux *
L025797 11111111*

Note Global Termination *
L025805 0*

Note Input Voltage Standard for IOB *
L025806 1*

Note Output Voltage Standard for IOB *
L025807 1*


  Then, on ChipMAX I just Select XC2C64A & File-Open gives this :

-XILINX XC2C64A selected.
-File loading...
-File load success.
-Buffer checksum : 9832h
-File checksum : 9832h
-Blow Count : 24180

and I can see and edit the fuses, by JED number.

So, it is a simple Load process, and no, there is no translation
process needed. The Programming data used by the Pgmr Vendor, handles
all that (and also the converse on read-save-to-JED, as I mentioned )

What I cannot do with Xilinx tools (that I can with Atmel)
is Vector Test the programmed device, but that's a side issue.

-jg

>   I'm not sure what you are expecting, the flow IS pretty simple :
> [I suspect you are being too paranoid :) ? ]

Of course I am paranoid - and I do not think I can be nearly
enough that when it comes to xilinx programming data...

> > eg : I trawl my PC for a Xilinx JED file,
> and find this
>
> D:\Xilinx\DesignPaths\Design.JED:
> ...

Are you sure you don't have the xilinx paid software installed
somewhere on that PC? If this is the case we cannot tell whether
there is no fuse address mapping going on behind the scenes
(transparent at user level). They would be less likely to
do that over the net as this would be way easier to catch,
but it would take an unplugged RJ-45 to make sure :-).
 Please keep the issue in background and keep me posted if
you stumble across some related news (I seldomly read com.arch.fpga
but a do read pretty often comp.arch.embedded).
 I would have tried to talk to some other vendor if anyone
else had a coolrunner-like part (practically 0 static power),
sadly xilinx bought the philips line only to shut it down - and
now I cannot do what I could do while there were Philips devices.
 I'll try to ask xilinx support for the .xls document which
translates jedec address <-> jtag_stream_bit_offset; I wonder
how many millions/quarter revenue they'll ask me to make for them
this time before they consider my chance of getting the data (last
time I asked it was $20M/quarter).

Thanks again,

Dimiter

P.S. I keep on wondering how come CPLD/FPGA manufacturers can get
away with selling non-documented devices, if a CPU vendor would try
to sell a processor and supply only a C compiler for it and
no instruction set he would stand no chance (at least in todays
world, not so sure about tomorrows...)

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

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

On Nov 19, 12:24 am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Didi wrote:
> > Jim,
>
> >>The fuse address mapping, is included in the Programming Document,
> >>so the Device programmer handles that
> >>(and does the reverse process, when it reads the CPLD and saves to a JED
> >>file)
> >>It will also vector test, which just needs a simple pin-mapping.
>
> >>On the documents I've seen, it aligns reasonably well with
> >>the JED - often they vary Pgm block sizes, and round to boundaries,
> >>and security can differ.
>
> > they are cheating somehow.
> > Their document on Coolrunner-II programming states:
>
> > "The Excel fuse map file indicates the bit position of each bit
> > of fuse data in the ISC Register.  Each column in the fuse map
> > represents a device address.  Each row represents a bit in the
> > ISC Register.  The leftmost column is ordinal address 0.  The
> > uppermost row is ISC Register data bit location 0. "
>
> > This is pretty much what I have on the original coolruner, the
> > .xls file which allowed me to do jedec file -> jtag stream.
> >  Not available anywhere from xilinx - I looked pretty hard.
>
> > So either the programmer manufacturers have been "party members"
> > and have been given these data
>
> Yes. They don't have the time, or inclination, to reverse engineer !
>
> If Xilinx wants device programmer support, they must provide the info.
> (as do all the chip vendors)
>
> > or there is some other cheating  going on.
> >  Can you please verify that you can program a jedec file to
> > a coolrunner on a PC which does not have the Xilinx software
> > on it? While being disconected from the net, that is...
> >  If it works, I may apply for party membership at 52 for
> > the first time, who knows.... :-).
>
> >  Thanks a lot,
>
>   I'm not sure what you are expecting, the flow IS pretty simple :
> [I suspect you are being too paranoid :) ? ]
>
> eg : I trawl my PC for a Xilinx JED file,
> and find this
>
> D:\Xilinx\DesignPaths\Design.JED:
>
> Programmer Jedec Bit Map
> Date Extracted: Wed Apr 30 21:16:51 2007
> QF25808*
> QP56*
> QV0*
> F0*
> X0*
> J0 0*
> N DEVICE XC2C64-4-CP56*
>
> Note Block 0 *
> Note Block 0 ZIA *
> L000000 1110110011111111*
> L000016 1110101011111111*
> <snip>
> Note Block 3 I/O Macrocell Configuration 27 bits *
> N Aclk ClkOp Clk:2 ClkFreq R:2 P:2 RegMod:2 INz:2 FB:2 InReg St XorIn:2
> RegCom Oe:4 Tm Slw Pu*
> L025360 000001111001111100010000001*
> L025387 000001111001111100010000001*
> L025414 000001111001111100010000001*
> L025441 000001111001111110011111100*
> L025468 000001111001111101110000001*
> L025495 000001111001111110011111100*
> L025522 000001111000011100011111100*
> L025549 000001111001111110011111100*
> L025576 000001111001111110011111100*
> L025603 000001111000011100011111100*
> L025630 000001111001111110011111100*
> L025657 000001111001111110011111100*
> L025684 000001111001111110011111100*
> L025711 000001111001111110011111100*
> L025738 000001111001111110011111100*
> L025765 000001111001111110011111100*
>
> Note Globals *
> Note Global Clock Mux *
> L025792 100*
>
> Note Global Set/Reset Mux *
> L025795 00*
>
> Note Global OE Mux *
> L025797 11111111*
>
> Note Global Termination *
> L025805 0*
>
> Note Input Voltage Standard for IOB *
> L025806 1*
>
> Note Output Voltage Standard for IOB *
> L025807 1*
>
>   Then, on ChipMAX I just Select XC2C64A & File-Open gives this :
>
> -XILINX XC2C64A selected.
> -File loading...
> -File load success.
> -Buffer checksum : 9832h
> -File checksum : 9832h
> -Blow Count : 24180
>
> and I can see and edit the fuses, by JED number.
>
> So, it is a simple Load process, and no, there is no translation
> process needed. The Programming data used by the Pgmr Vendor, handles
> all that (and also the converse on read-save-to-JED, as I mentioned )
>
> What I cannot do with Xilinx tools (that I can with Atmel)
> is Vector Test the programmed device, but that's a side issue.
>
> -jg