cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
sean.durkin
Participant
Participant
9,573 Views
Registered: ‎05-15-2013

CCLK pin after configuration

Hi *,

 

I was wondering if there is a way to tristate the CCLK pin in an Artix-7 device after configuration?

 

I have the FPGA hooked up to an SPI flash device for configuration, which works fine. To that same SPI interface I have also connected a microcontroller for updating bitfiles via USB and such. This also works fine, as long as I pull the PROB_B-pin while the microcontroller wants to access the SPI flash. This is because the FPGA keeps driving the CCLK pin after configuration; and since CCLK can't be used as a user I/O, I can't force it to 'Z' in my design.

 

This is all known and documented behaviour, but I was wondering if there still is some way to influence CCLK from the design? It must be possible somehow, or indirect SPI programming via iMPACT wouldn't work. I suppose you can do some JTAG magic to toggle CCLK or something, but can't find any documentation on that.

 

The situation as it is is OK for my design, but it would be nice to be able to access the SPI flash from the microcontroller while the FPGA is loaded, without having to fuss about with external multiplexers on the board and such.

 

Greetings,

Sean

Tags (4)
0 Kudos
6 Replies
sean.durkin
Participant
Participant
9,568 Views
Registered: ‎05-15-2013

Hi *,

 

found something. The STARTUPE2 primitive should be able to help with what I want to do. Documentation is sparse, though, still fiddling around with it.

 

At least that enables you to drive the CCLK pin after configuration, so that looks good.

 

Greetings,

Sean

0 Kudos
ralfk
Xilinx Employee
Xilinx Employee
9,556 Views
Registered: ‎10-11-2007

You shouldn't have to do that. Unless you have turned on persist or the SEU detection option (RBCRC) the CCLK in master mode is tri-stated with a weak pullup.

0 Kudos
sean.durkin
Participant
Participant
9,543 Views
Registered: ‎05-15-2013

I didn't have persist enabled, it should be disabled per default. Disabling it explicitely in the XDC didn't help, though. The way I read the documentation, the persist option only applies to the multi-function pins, but not to the dedicated configuration pins in bank 0.

 

I would expect CCLK to be tri-stated after configuration (BTW, does it say that in the documentation somewhere?), but what I see is:

- FPGA not configured (i.e. PROG_B held low): flash access from the microcontroller works reliably and every time

- FPGA configured: flash access fails 80% of the time (meaning all I get is all 0s or 1s)

 

So to me that does not look like a software issue (wrong flash settings or something), but like bus contention or some other hardware issue that is in some way influenced by the FPGA.

 

I found this at the Spansion site. They state in 4.2 that you must pull PROG_B low or the FPGA will interfere with the SPI pins:

http://www.spansion.com/Support/Application%20Notes/SPI_Flash_Config_Xilinx_FPGA_AN.pdf

 

So that's where I got the general idea that CCLK could be the problem (all the other SPI pins I can manually tri-state in my design).

 

Then I thought maybe the FPGA sets a different flash access mode during configuration (32bit address mode, quad mode, ...), but then the microcontroller shouldn't be able to access at all, not only fail most of the time. Besides, there's a software reset command you can use that should always work, regardless of the mode the flash is in, but I can't even get that through (meaning the shifted data coming back from the device is always garbage).

 

Any other idea how this could happen?

0 Kudos
ralfk
Xilinx Employee
Xilinx Employee
9,531 Views
Registered: ‎10-11-2007

Correct. By default persist is turned off. Both the multi function pins as well as the CCLK are preserved if persist is turned on. I believe the user guide does mention this behaviour. Check the overview section.

 

You are basically saying your flash access works 20% of the time? The FPGA will behave the same all the time. Perhaps you are trying to access the flash too early? I think there are some extra cycles on the CCLK after configuration is done to ensure the startup sequence is properly excecuted. Perhaps 10 cycles or so.

 

The Spansion recommendation is probably there so that the user application does not interfere with the multi purpose pins connected to the SPI such as MOSI/FCS.

 

Check the signals with a scope.

0 Kudos
sean.durkin
Participant
Participant
9,514 Views
Registered: ‎05-15-2013

Since yesterday, the problem has disappeared. I'm at the moment retracing my steps, trying to figure out what I changed that "fixed" it, and I'm doing testing across a batch of boards now to see if there's a difference.

 

What I was seeing was that with some bitfiles SPI would work, with others (most of them) it would never work, even though bitfile settings were always identical. Timing should not have been a problem, since it wouldn't work after minutes/hours, either.

 

I'll do some more digging... even if it does work now, I don't like not knowing for certain what the problem was. Those things tend to re-appear and bite you when you least expect it...

0 Kudos
dufl
Visitor
Visitor
3,456 Views
Registered: ‎02-25-2015

Hi @sean.durkin.

There is direct way to solve your problem.

Input port "USRCCLKTS" of STARTUPE2 primitive is controlling state of the CCLK pin.

.USRCCLKTS(1'b0),
will set CCLK pin to output mode, when

.USRCCLKTS(1'b1),
will set CCLK pin to the tristate mode.

0 Kudos