Trouble programming V4FX40

Have you tried recompiling for a FX40? The bit file will be very different!

Have you recompiled the FX20 design for the FX40 package? Hex digits

4-5 (94 vs 8c) are supposed to be the part size. Since the chain report shows the correct size, I've got to assume you have the wrong programming file.

If you run the scan on a board with the xc4vfx20, do you get this "other" IDCODE?

- John_H

Yes, the file was built for FX40... unless it is a path problem... but I don't think so...

/Mikhail

Hmm... As I've already said in another post the file has been compiled for FX40... I've checked that several times... But I will check again....

No, in that case it works fine...

/Mikhail

"it works fine"

The question was whether the other board returns

Validating chain... Boundary-scan chain validated successfully. '2': IDCODE is '00000001111010010100000010010011' '2': IDCODE is '01e94093' (in hex). '2': : Manufacturer's ID =Xilinx xc4vfx20, Version : 0

OR if the IDCODE is something completely different.

If you're programming the OLD board with the NEW programming file and "it works fine" then YES you have the old programming file for the new board.

In some versions of the software the xc4vfx40 idcode was incorrectly coded into the BSDL files which will effect the programming.

See this Answer Record for more information.

Ed McGettigan

--
Xilinx Inc.

Will have to check...

No, I am programming the old board with the old file and the new board with the new file...

/Mikhail

It seemed for a moment that it had to be it, but I've checked the BSDL files and they are correct in both ISE8.2 and 10.1. I have 9.2 installed as well and indeed the file in 9.2 is wrong, however there is no way it gets used as this installation is completely dormant (no paths or environment variables pointing to it)... Very confusing...

Here is the beginning of the bitgen report proving that the file is for FX40:

Release 8.2.03i - Bitgen I.34 Copyright (c) 1995-2006 Xilinx, Inc. All rights reserved. Loading device for application Rf_Device from file '4vfx40.nph' in environment C:\Xilinx\ISE82. "curc_top" is an NCD, version 3.1, device xc4vfx40, package ff672, speed -10 The STEPPING level for this design is 0. Opened constraints file curc_top.pcf.

Tue Jun 10 17:59:41 2008

C:\Xilinx\ISE82\bin\nt\bitgen.exe -intstyle ise -w -g DebugBitstream:No -g Binary:no -g CRC:Enable -g ConfigRate:4 -g CclkPin:PullUp -g M0Pin:PullUp -g M1Pin:PullUp -g M2Pin:PullUp -g ProgPin:PullUp -g DonePin:PullUp -g InitPin:Pullup -g CsPin:Pullup -g DinPin:Pullup -g BusyPin:Pullup -g RdWrPin:Pullup -g TckPin:PullUp -g TdiPin:PullUp -g TdoPin:PullUp -g TmsPin:PullUp -g UnusedPin:PullDown -g UserID:0xFFFFFFFF -g DCIUpdateMode:AsRequired -g StartUpClk:JtagClk -g DONE_cycle:4 -g GTS_cycle:5 -g GWE_cycle:6 -g LCK_cycle:NoWait -g Match_cycle:Auto -g Security:None -g DonePipe:No -g DriveDone:No -g Encrypt:No curc_top.ncd

/Mikhail

I'm hoping that a read from the FX20 board (or a look at the BSDL file) would show 01e64093 per the lone table I found at the bottom of page 19 in

My worry is with the note attached to your FX40 JTAG IDCODE of 01e8c093(1):

1. Does not reflect the actual device array size.

This note suggests someone may have taken on the responsibility of changing the IDCODE to reflect the proper "device array size."

You HAVE actually talked to a CAE at the Xilinx Support Hotline (or opened a webcase) haven't you?

This sounds like a very specific issue that might just not be in the external answers database yet.

The date code on the chips may also be helpful information for the CAE handling your case.

- John_H

John,

It reads 21e64093, which I believe is fine, as 2 at the start is just a version code.

Not yet, but probably will very soon... :)

/Mikhail

I believe that the problem is that the 8.2 software that you are using has a hardcoded (not in the BSDL) IDCODE value of 0x01e94093 and this has been written into your BIT file. The correct value should

0x01e8c093. Try rerunning bitgen to create a newBIT file using 10.1 software (the 9.2 might also work, it was just the BSDL file that was wrong in this version).

Ed McGettigan

-- Xilinx Inc.

Hi Ed,

That's indeed the case. I rebuilt the file with 10.1 bitgen and the IDCODE problem is gone now. However the Done still doesn't go high... Although I do see now that something gets loaded in the device, so maybe it's just the Done signal itself... I am investigating...

Thanks, /Mikhail

Still no luck... Now when programming finishes, the status register reads all zeros and I can't read the IDCODE from the device at all unless I power cycle the board... I tried changing all kinds of bitgen options I could think of, all to no avail..... Perhaps I should mention that another device in the chain is a Platform Flash, but it is of a wrong size (forgot to upgrade it). I can't replace it now as I am waiting for the new parts to arrive, but I can't see how it can cause any harm while it's blank...

// *** BATCH CMD : Program -p 2 Maximum TCK operating frequency for this device chain: 15000000. Validating chain... Boundary-scan chain validated successfully. PROGRESS_START - Starting Operation. '2': Programming device... Match_cycle = NoWait. Match cycle: NoWait done. '2': Reading status register contents... CRC error : 0 Decryptor security set : 0 DCM locked : 0 DCI matched : 0 End of startup signal from Startup block : 0 status of GTS_CFG_B : 0 status of GWE : 0 status of GHIGH : 0 value of MODE pin M0 : 0 value of MODE pin M1 : 0 Value of MODE pin M2 : 0 Internal signal indicates when housecleaning is completed: 0 Value driver in from INIT pad : 0 Internal signal indicates that chip is configured : 0 Value of DONE pin : 0 Indicates when ID value written does not match chip ID: 0 Decryptor error Signal : 0 System Monitor Over-Temperature Alarm : 0 WARNING:iMPACT:2218 - Error shows in the status register, release done bit is NOT 1. INFO:iMPACT:2219 - Status register values: INFO:iMPACT - 0000 0000 0000 0000 0000 0000 0000 0000 INFO:iMPACT:579 - '2': Completed downloading bit file to device. Match_cycle = NoWait. Match cycle: NoWait INFO:iMPACT - '2': Checking done pin....done. '2': Programming terminated. DONE did not go high. PROGRESS_END - End Operation. Elapsed time = 30 sec.

/Mikhail

"MM" wrote in message news: snipped-for-privacy@mid.individual.net...

Tried already. I can program/erase the flash with no problems.

This is not easy. Both chips are BGAs and the board is 14 layers...

Yeah, I guess that's the next step... Sigh...

/Mikhail

JTAG sometimes is voodoo. Check your JTAG cables, try to program the flash and read it back to see if your chain works. Try to bypass the flash perhaps disconnect TDO and solder a wire TDI -> TDO). You can also try to make a super simple bitstream like a LED blinker with all pins tristated except the LED.

Readback too ?

Oops. I'm really grateful I put that via on the JTAG signals... because before I bypassed the flash it failed... this is entirely the fault of my crummy cable I think, but I'm too cheap to get a real JTAG cable ;)

Rant : Why is it that the very complicated things like FPGAs, work the first time, but the simple things, like JTAG, don't ?

Well, I think I have found the problem. It looks as the EDK portion of my design hasn't got updated properly. FX40 has 2 PPC cores vs. 1 in FX20. I forgot to include the second PPC in the chain and it never complained. Fixing it now...

/Mikhail

It's perhaps because some designers think that because JTAG is a 'slow' bus compared to the hundreds of MHz on the other I/O pins, they don't do proper SI design on the JTAG signals. They think it's a 'simple thing' to just wire it up. If they do the simulation, it works first time, every time. HTH., Syms.

I looked into that, but the SI simulation software is "slightly" pricey for a hobbyist ;) (not to mention where to find the models for the cable and the JTAG adapter) so I used a trace impedance calculator and tried to match with the stated impedance in the ribbon cable's datasheet, minimize stubs, insert source termination on TDO, etc, yet I still have problems sometimes though. Configuration works about 95% of the times so I let it be... I suspect double clocking on TCK yet the waveforms look good on the scope (but it's only a 100 MHz analog scope so perhaps I don't see what happens). As I said I think the culprit is my crummy Xilinx parallel III clone from Trenz... but it was cheap... too cheap perhaps !