Spartan 6 pull ups during SPI indirect programming using xc6slx45_spi.cor

j1s1e1 · ‎03-05-2010

I'm bringing up some boards with an XC6SLX45-2CSG324I and a Windbond W25Q32BVZPIG flash for configuration. When using the xc6slx45_spi.cor for programming the flash, the device does not appear to follow the HSWAPEN pin. I have the pin pulled up to 3.3V so that pull-ups will be disabled during configuration. This works fine when the FPGA configures itself from the flash. However, when the flash is being configured, the xc6slx45_spi.cor, the pin is ignored and all unused pull-ups (from the core) are enabled. This enables a power supply which causes a voltage drop that causes the flash programming to fail.

The source for the flash programming core is unavailable. Is there any other way to control the pull ups while the flash programming core is running?

Thanks,

James

eteam00 · ‎07-21-2009

I don't have an answer for you, but it would be a good idea to specify which version of ISE (and iMPACT) tools you are using.

If you don't get a response from the forums -- or even if you do get a response -- you should consider opening a webcase for direct response from Xilinx support team. If this is a bug (and your description suggests that it might be considered a bug), then a webcase is the proper mechanism for reporting the bug and initiating a software CR (correction request).

Also, you might consider using the non-Xilinx Digilent tools (hardware and software) for indirect programming. There's a chance that the Digilent ADEPT software works differently than Xilinx' iMPACT.

Good job on troubleshooting this problem, by the way.

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.

j1s1e1 · ‎03-05-2010

Bob --

Thanks for the tip regarding the alternate programmer. That's a great low cost alternative if we set up a bunch of programinng stations. I'm currenlty using ISE 13.2 and Impact 0.61xd. I'll have to submit a webcase and request the ability to control unused pins when programming flash. I started to do that yesterday, but I haven't signed up with my corporate email yet, so I figured I would check in here first.

James

gszakacs · ‎08-14-2007

Actually the behavior of I/O pins during SPI programming is exactly what one might expect,

since the SPI programming core is just another bitstream, and therefore the bitstream itself

controls the behavior of "unused IOB's" after it is loaded. Xilinx could make a different version

of the core without pullup on unused IOB's. They could also use the JTAG connection to

determine the state of HSWAPEN (or PUDC_B) before deciding which core to use.

Lattice had another approach, which is to offer the indirect SPI programming core for

implentation into your own project. With that approach you could also use the core

to connect to SPI Flash that isn't on the dedicated config pins, as well as to determine

the state of the other device pins during SPI programming.

The bottom line is that the solution you want must be provided by Xilinx. Other

workarounds, including direct SPI programming or tolerance to pullups during

SPI programnming would require modification of your hardware.

-- Gabor

j1s1e1 · ‎03-05-2010

Gabor --

As you've said, it's not really a bug, just the way the core operates. Unfortunately, this provides a second "configuration" that needs to be considered. Also, since the behavior of the core is not specified, it could change at a later date. Your suggestion about detecting the HSWAPEN (or PUDC_B) before selecting a core would be ideal. I was able to get a core with the pins floated from Xilinx, and have requested the ideal behavior as a possible enhancement for IMPACT in the next update.

Thanks for your help.

James

eteam00 · ‎07-21-2009

James,

Well done pursuing this to its practical near-term conclusion, and well-done to Xilinx for providing the workaround you needed.

This thread raises a real unanticipated problem which could affect a number of customer designs, and concludes with a practical workaround solution. You should mark this thread as 'solved'.

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.

j1s1e1 · ‎03-05-2010

Another user requested the file with the pins floated. I have attached the file. Instructions for use are:

The bit file needs to be extracted and renamed to match the file referenced in the original post. This can then be used to replace the other core that does not float the pins. Be aware that this is of course specific to this part. Also, if you use the standard core with other projects, you will want to be sure to manage which one is in the appropriate directory when using the cores.