Spartan 6 Slave programming Clock issues

[hopsa]

I'm trying to program a spartan 6 in slave mode from a microcontroller. I know there are many threads about this topic already, but as far as I can see no one has had my problem before.

I am certain I'm doing the prog/init dance correctly: pull prog down, wait until init comes down, pull prog up, wait until init comes up, start blasting out the bitstream.

When I send out the bitstream (it only happens when I send my proper bitstream, not with bogus data), I see weird things happen on the CCLK pin, it seems that after a while a second, much faster, clock gets superimposed ( see attachment).

This faster clock keeps toggling when I'm not sending any data, and eventually 'ready' goes low which makes sense since the fpga did not receive good data.

The bitstream was generated in ISE with startupClk=CCLK, so that's not the issue. 

[efly_zhao]

It seems the clock signal is ringing.

You can try to put a serial resistor, e.g. 22R - 55R at the drive side, or maybe also a decoupling capacitor, e.g. >=10nF  to ground on receive side. See whether it helps. 

You can also try the on-chip termination in FPGA (see UG381), if it is difficult to change hardware.

[drjohnsmith]

could do with some info on that plot

like what each colour is, whats the volts per div  time scale and most importantly, when is ground.

Assuming the blue is going from low to high, it does not seem to go to ground,

The red, as you say. looks like it gets a clock on it

but interestingly its not going full voltage, but mid scale up or down

As this is not happening with bogus data,

    could it be the chip is 'answering'

          have you gotten the connections to the chip correct,  is the chip in the right mode , or is it trying to drive the clock out ?

   whats the frequency of the 'extra clock' , if its similar to the clock frequency the fpga puts out in config mode , that could be an answer.

Do you have the correct pull ups on the configuration lines ?

    Are you driving done and init , or are they open collector in your code ?

How about a circuit diagram of the configuration circuit,

[hopsa]

Red is supposed to be CCLK, or from the perspecitve of my microcontroller SPI clock.

Blue is the MOSI line, green is the init pin. Scales and offsets on the plot are all over the place, I'll have to take a better capture tomorrow.

The microcontroller is driving the SPI at 100 khz, the fast clock that overlays it is therefore 1 mhz. As far as I remember UG380 the default value for the config clock generated internally in the fpga is 2 mhz though, and the fpga should not drive that line when it's in slave mode in the first place.

Mode pins are definitely correct, I can read them out though Impact, they're both 1.

[drjohnsmith]

configuration schematic would be of great use,

I'm guessing you have the fpga in SPI mode really.

Look at 

https://www.xilinx.com/support/documentation/user_guides/ug380.pdf

fig 2.3, check you have that

( btw, I  did not know that impact read the mode pins , interesting )

[hopsa]

We experimented with the termination of the clock line a bit, but it does not seem to make much of a difference.

However the behavior does not seem to happen when I break the SPI into smaller packets, so I now suspect the microcontroller's SPI peripheral.

[hopsa]

I have some more info:

• SPI clock phase and polarity were wrong, it was running mode 3 (clock high by default, data sampled on rising edge) instead of mode 0(clock low by default, data sampled on rising edge). Did not make a difference, probably since the fpga will just sample the data line on the rising edge of the config clock and does not care about the extra falling clock edge at the beginning.
• It still happens when I break the data into smaller bursts, just later.
• It still happens if I reduce SPI frequency to a pedestrian 10khz.
• It does NOT happen when I keep the FPGA in reset (pull prog_B low and keep it there), therefore it's really the fpga that's counterdriving the clock line.
• MODE pins on the board were free floating due to an omitted resistor, but since they have an internal pullup in the fpga they were sampled as high anyway. They're pulled up properly now, made no difference though.
• When INIT eventually goes low, it does not stay low, it is just pulsed. However when I read the status register from Impact I still see it as low.

I'll see if I can post some schematics.

Could it be some hidden setting somewhere in the bitstream that tries to bring the fpga into another config mode as soon as the configuration sequence has progressed a bit?

[drjohnsmith]

its not a signal integrity type problem, 

  those levels are way to strong for that,

Looks to me like to pins driving, 

    have you checked for shorts ? 

[hopsa · Accepted solution]

I think we have it figured out, the fpga was indeed counterdriving the clock pin.

We started decoding the bitstream to see what config registers it was setting, and it turns out the CCLK_FREQ register (see ug380 page 110) had bit 14 not set and something nonstandard on the lower 10 bits as well.

The reason for that turned out to be that in ISE under Bitstream generation options/ configuration options  "Enable External Master Clock" was not set.

I have a Done pin now. Thanks for the support!