[Xc3sprog-users] Antwort: Re: XCFP does not yet support bitfile subranges

[Mirko C. <mir...@ki...>]

Hello Joris,

>>I realized, that we are using a special patched xc3sprog version
>>0.5 with a new file progalgxcfxxp.cpp, based on
>>progalgxcf.cpp.  
>Are you saying that this special version of
>XC3SPROG programs your board successfully, while the main
>version of XC3SPROG does not?  
Yes, that's right. It is the progalgxcfxxp.cpp I sent to you separatly.
The onliest problem: Sometimes it can't erase PROM successfully, especially if the first try was interupted due to power lost.
That's the reason because I started dealing with current xc3sprog.

>Just out of curiosity, where did
>you get the special version?
An internal programmer wrote it, based on your progalgxcf.cpp V0.5 (appr. 2004,2005 ?)
But this internal programmer is not available anymore.

>>If you won't include mode pin
>>set-up in xc3sprog, could you give me a 
>>hint, how to add it.
>It is not so much a matter of pin set-up.  XCFP devices can be
>used in a number of modes, including either serial or parallel,
>and either master or slave. The PROM contains a CCB register
>which determines the mode for which it is configured.  
>This register is documented in Xilinx ug161:  
>CCB<0>    1 = external clock, 0 = internal PROM clock  
>CCB<2:1>  11 = serial output, 00= parallel output  
>CCB<3>    1 = PROM slave (FPGA master), 0 =PROM master  
>CCB<5:4>  11 = 40 MHz clock, 01 = 20 MHz clock
Thanks, I got it now from the document you mentioned above.

>Currently, XC3SPROG programs XCFP devices in FPGA Master Serial
>mode (CCB=0xffff). XCFS devices don't have a CCB register; they
>always operate in FPGA Master Serial mode.   It would be a good
>idea to add support for different modes. This could be done by
>adding an XCFP-specific command-line option which then gets
>translated into the proper value for the CCB register.
At this point I'm out of my skills. I'm only a linux guy, trying to get it work.

What I see:
Programming with your patched xc3sprog consumes 10 times longer than with patched V0.5-version (327 sec <-> 31 sec).
As you mentioned, maybe CCB=0xffff is not the fastest setting. But I cannot figure out the differences in progalgxcfxxp.cpp.
I find only CCB[2] ..., see below:

#include "progalgxcfxxp.h"

// Info for interpreting the commands that are shifted in IR:
// Size of Instruction Register is 16 bit (IR Length=16).
// The data buffer is shifted with LSB bit first.
// That is why shifting 16 bit:      0b0000000011101010 = 0x00e8
// is equivalent to shifting 22 bit: 0b0000000011101010111111 = 0x3a3f

const byte ProgAlgXCFxxP::XSC_DATA_DONE[2]    ={0x09,0x00};
const byte ProgAlgXCFxxP::XSC_DATA_CCB[2]     ={0x0c,0x00};
const byte ProgAlgXCFxxP::XSC_DATA_SUCR[2]    ={0x0e,0x00};
const byte ProgAlgXCFxxP::XSC_BLANK_CHECK[2]  ={0x0d,0x00};
const byte ProgAlgXCFxxP::ISPEN[2]            ={0xe8,0x00};
const byte ProgAlgXCFxxP::ISC_PROGRAM[2]      ={0xea,0x00};   // 1110'1010
const byte ProgAlgXCFxxP::ISC_ADDRESS_SHIFT[2]={0xeb,0x00};   // 1110'1011
const byte ProgAlgXCFxxP::ISC_ERASE[2]        ={0xec,0x00};
const byte ProgAlgXCFxxP::ISC_DATA_SHIFT[2]   ={0xed,0x00};   // 1110'1101
const byte ProgAlgXCFxxP::CONFIG[2]           ={0xee,0x00};
const byte ProgAlgXCFxxP::NORMRST[2]          ={0xf0,0x00};   // conld
const byte ProgAlgXCFxxP::XSC_DATA_BTC[2]     ={0xf2,0x00};
const byte ProgAlgXCFxxP::XSC_CLEAR_STATUS[2] ={0xf4,0x00};
const byte ProgAlgXCFxxP::IDCODE[2]           ={0xfe,0x00};
const byte ProgAlgXCFxxP::XSC_UNLOCK[2]       ={0x55,0xaa};
const byte ProgAlgXCFxxP::BYPASS[2]           ={0xff,0xff};

But I do not understand the correct order of bit settings (comment lines above) ... shifting 16 bit?
Again, I can not fix it.

Are you going to add XCFP-specific command-line option for the CCB register?

Thanks for answer!
Best regards,
Mirko