UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor hopsa
Visitor
1,510 Views
Registered: ‎11-14-2014

Spartan 6 Slave programming Clock issues

Jump to solution

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. 

 

oddclockstarts.PNG
0 Kudos
1 Solution

Accepted Solutions
Visitor hopsa
Visitor
1,822 Views
Registered: ‎11-14-2014

Re: Spartan 6 Slave programming Clock issues

Jump to 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!

0 Kudos
8 Replies
Observer efly_zhao
Observer
1,470 Views
Registered: ‎04-04-2018

Re: Spartan 6 Slave programming Clock issues

Jump to solution

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.

0 Kudos
Highlighted
Scholar drjohnsmith
Scholar
1,458 Views
Registered: ‎07-09-2009

Re: Spartan 6 Slave programming Clock issues

Jump to solution

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,

 

 

0 Kudos
Visitor hopsa
Visitor
1,441 Views
Registered: ‎11-14-2014

Re: Spartan 6 Slave programming Clock issues

Jump to solution

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.

0 Kudos
Scholar drjohnsmith
Scholar
1,429 Views
Registered: ‎07-09-2009

Re: Spartan 6 Slave programming Clock issues

Jump to solution

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 )

 

Visitor hopsa
Visitor
1,403 Views
Registered: ‎11-14-2014

Re: Spartan 6 Slave programming Clock issues

Jump to solution

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.

0 Kudos
Visitor hopsa
Visitor
1,393 Views
Registered: ‎11-14-2014

Re: Spartan 6 Slave programming Clock issues

Jump to solution

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?

0 Kudos
Scholar drjohnsmith
Scholar
1,390 Views
Registered: ‎07-09-2009

Re: Spartan 6 Slave programming Clock issues

Jump to solution

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 ? 

 

0 Kudos
Visitor hopsa
Visitor
1,823 Views
Registered: ‎11-14-2014

Re: Spartan 6 Slave programming Clock issues

Jump to 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!

0 Kudos