06-07-2018 06:10 AM
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.
06-11-2018 01:32 AM
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!
06-07-2018 08:14 AM
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.
06-07-2018 09:06 AM
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,
06-07-2018 10:15 AM
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.
06-07-2018 10:54 AM - edited 06-07-2018 10:58 AM
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 )
06-08-2018 03:36 AM
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.
06-08-2018 06:28 AM
I have some more info:
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?
06-08-2018 06:31 AM
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 ?
06-11-2018 01:32 AM
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!