Configuration Blues

Sure.

(Although you don't say, I am assuming you are using Serial Slave configuration mode)

The clue is that loading the CCLK fixes things.

As I was reading your description I was thinking mechanical, so great that you did a test with an insulator.

Unfortunately you can't trust the scope picture, because as you have said, probing the CCLK pin fixes it. Often people are using passive probes (7 to 15 pf load) and scopes with bandwidth of 200 MHz or lower. You don't say what you are using. When I look for this stuff, I use at least 500 MHz bandwidth scope+probe system, with an active FET probe with 1 pf load. This has shown stuff that passive probes miss.

My best guess is that you have a signal integrity problem (termination, stubs, reflections, ...) and the problem is on the falling edge of CCLK, which you are probably not looking at. What I have seen is that during the falling edge, a SI problem leads to a little U turn in the clock during either the rising OR falling edge. Murphy often causes the U turn to occur at about the mid point of the falling edge, at about the trip point of the receiver. This looks to the receiver (CCLK in, in your case) as if there is a rising edge at the falling edge. The result is sub-optimal.

I last wrote about this in 12/13/2001

The reason that even INIT is not going low is that even the header is not being received correctly, and so it is not even starting the configuration process.

One of the best ways to diagnose the start of configuration problems is to look at the DOUT pin. You should see a complete copy of the initial header come out the DOUT pin a cycle or 2 after it goes in on DIN . If you don't see this, then neither did the FPGA.

Please let us know how things go on this.

All the best,

Philip

Philip Freidin Fliptronics

Right.

Hi, Philip,

Well, we've probed it with a 1 pF, 1 GHz fet probe into a TDS3052 (500 MHz) scope, and CCLK still looks beautiful. Maybe I should try the 3 GHz sampling probe next! The 68332 port edge is pokey enough that we wouldn't expect much ringing on a short trace, and we've done much longer and nastier multiple-FPGA configs without problems.

The fix is to kluge a 33 pF cap at the CCLK pin to ground. When we turn the PCB layout, we'll do something more elegant maybe, like source terminating *and* hanging the cap, but it remains a mystery.

Heck, we're engineers: we don't have to understand it, we only have to make it work.

Thanks

Oh: I have a Windows command-line app that builds ROM images out of Motorola S28 files and multiple .RBTs. Any interest?

John

I really should have emphasized this. Since you are using serial slave, the DOUT pin can give you a clear view of what the chip thinks it is getting, and you can look at this pin without loading the CCLK pin, so the issue of probing CCLK goes away. Until the header is recognized and completed, the DOUT pin echos th DIN pin. So if there are clock integrity problems you will see weirdness on the DOUT pin. Since you are using XC2S15, the DOUT changes as a result of a CCLK rising edge.

If you saw a DOUT change that followed a falling edge, this would be a significant indicator. Other interesting things you might see are bits being dropped, indicating a rising edge is being missed, or failing to meet setup and hold with regard to CCLK.

Maybe your micro is putting CCLK out upside down?

Maybe your micro (i.e. your download program) is changing the DIN bit at the same time as it changes the CCLK bit from '0' to '1' . This is a race condition. These need to be separate I/O writes to the output register, to make sure that DIN is stable at the new value, before you switch the CCLK from low to high.

Don't succumb to the dark side. There is a solution that does not involve 33 pf caps. :-)

( you left off the smiley )

Unsurprisingly I disagree. If you don't understand it, it will come back to bite you over and over again. You have done far too many FPGA designs to believe that serial config does not work, so the tough question is to figure out what is wrong with this design.

Little tools like this are always useful. If you want to donate it, I can make it available at

Please dont go the 33 pf route. I want to know what the real problem is.

Good luck, Philip

Philip Freidin Fliptronics

A trivial point - are you sending enough CCLK pulses ? I had something vaguely similar to your problem, which turned out to be stopping generating CCLK pulses as soon as I had seen DONE, wheras you actually need a few more to startup everything ... Dave

What about setup time between Din and CCLK? Loading down CCLK also will delay it a nS or so, and that may be enough. Maybe previous version of this had some other loads on CCLK that slowed it down, so you never saw this problem before.

Jon