XCF02S programming failed

[anshumantech]

Hello,

We have 2 different PROM XCF02S ICs, One is XCF02S V and another is XCF02S VG. I have checked datasheet of IC. In that it is mentioned that VG version IC are Lead (Pb Free) Free.

XCF02S V version PROM IC is failed to program under ISE Impact 14.2/14.7 using Digilent’s HS1/HS3 cable. Error is IDCODE does not match issue (tried on different TCK frequencies but same problem occurs). But same PROM is programmed successfully under ISE Impact 10.1 with parallel port cable and transfer program to FPGA.

While XCF02S VG version PROM IC is programmed successfully under ISE Impact 14.2/14.7 using Digilent’s HS1/HS3 cable and transfers data to FPGA. Also it is programmed successfully under ISE Impact 10.1 with parallel port cable and transfer program to FPGA.

What’s the difference between V and VG versions?

[bpatil]

Hello @anshumantech 

It seems their is change in version of flash XCF02S due to change in package

[kkn]

there shouldnt be any difference in the way leaded and lead free XCF02S programming is concerned.

could you try with Xilinx platform usb programming cable in 14.7/14.2 both the proms and share the results

https://www.xilinx.com/products/boards-and-kits/hw-usb-ii-g.html

This will help in identifying if the issue is in impact tool/xilinx device or with the programming cable

[anshumantech]

This reply is simply parroting of what is given in datasheet! Both V and VG version PROMS program & transfer data to FPGA if programmed using parallel port cable under ISE Impact 10.1, there too IDCODE exists & ISE 10.1 can tackles it successfully.
Then what happens if you are using ISE 14.7 through HS1/HS3 module?
I am curious to know specifics!

[drjohnsmith]

If I understand you, the diligent does not work, the Parallel port one does.

I would suggest that the answer is that the parallel cable , and software was designed 30 plus years ago, and is very different to the code written now for the digilent programmers. The 386 PC we used to run these things on is very different to the Xenon things we now use as PC's. Back in those days the parallel port was not even "protected" you could just bit bang to it direct from code into memory space !


The parallel pods have not been supported for decades

Its good sense IMHO that as the programmer knows what the destination should be from the prom file, that it checks and fails if they are not the same.

I'd imagine a long time ago, that coding was a lot less strict,

I can imagine a customer complaining a while back that they had programmed the wrong code into a batch of proms and why did the code not check. I know I'd be less than happy if some one writing code for us did not put that feature in now days,

[anshumantech]

I requested for specifics i.e to avoid verboseness but I received a verbose reply.
Ignoring the specific issue !
Please help if you can !

[drjohnsmith]

What help are you asking for ?

You asked what was the difference between V and VG, the answer was given its the Pb
,
What you have is a bit file with the wrong ID for the device you want to program,

So you have some options,

a) generate the correct file for your part
b) find the right part for you file
c) try to find some other software
d) use the ISE you know works
e) get Xilinx to write some software,

[anshumantech]

Hello,
1) I didn't ask for explain difference between V and VG.
2) I stated following,
a) XCF02S VG version PROM IC is programmed successfully under ISE Impact 14.2/14.7 using Digilent’s HS1/HS3 cable and transfers data to FPGA. Also it is programmed successfully under ISE Impact 10.1 with parallel port cable and transfer program to FPGA.
b) However XCF02S V version PROM IC fails in the above place.
3) Please explain the difference in ICs as well as cause stated in a & b above.

[drjohnsmith]

why do you think a) and b) is answered by the points about different versions of the software , and the two parts having different ID codes ?

The very old software seems to ignore the ID codes, I did not know that, where as the newer versions , correctly IMHO, identifies the ID code and checks it against the file ID for correctness.

3) is confusing, the difference in the ICs you ask us to explain, but in 1) you say you don't want to know the difference !!

The difference is one is Pb free and one is not, ( Pb being Lead ) , and as they are different, they have different ID codes, to stop the wrong part being put on a board.

Does that not answer all your questions ?

[anshumantech]

Again you are getting it wrongly! A case of dyslexia like me!
VG version programs & executes whether parallel port cable used under ISE 10.1 or HS1/HS3 USB modules under ISE 14.2/14.7 without getting into IDcode issue. Then why V version programs and executes only when parallel port cable used under ISE 10.1 but fails under ISE 14.2/14.7 when HS1/HS3 used. Please do not look for answer in "IDCODE", look for another answer!

[drjohnsmith]

@anshumantech 

IDcode fits as an answer,

From what you said, It can be concluded that older tools dont sheck the IDCODE ?

 whilst newer tools do check the ID code.

So older tools can program either part,  as they dont care about IDcode.

   where as newer tools need correct ID code in part to match the file, 

My guess is your  file is for the VG part, so will program VG parts for all tools.

   whilst only the older tools, that dont care about ID code can be used to program a V part whos ID does not match the file.

have a great Christmas

[anshumantech]

@drjohnsmith 

Sorry to bother you. However answer following: -
Who is supplying IDCODE? The newer software has to read it correctly from VG version but cannot read from V version. In both cases we only select XCF02S part yet newer software fails to detect part with V version but detects VG version.
Conclusion: Xilinx must release patch file for correct the anomaly, we have no role to play here. So please learn to draw correct conclusion. Merry Christmas!

[drjohnsmith]

the id code is in the chip and in the file your programming,
Looks like newer software reads the id code from the chip, and compares it to check its correct,
whilst older code it looks like it did not care what the id code in the device was
As to should Xilinx revert to the old way or not is a question for you and your FAE,
May be over a Christmas lunch ..
Personally, I'd say it was a negative step to revert the software to ignoring the ID code from the chip,

[anshumantech]

@drjohnsmith

Again wrong reading & therefore wrong conclusion:
1) Forget older and newer S/W (ISE).
2) The newer S/W reads & tallies IDCODE from VG version while can't do the same from V version, rest of H/W environment remains same.
Hence it's Xilinx issue & not ours! correct conclusion please! I will enjoy Christmas lunch with someone more useful!