FPGA Central

OK, a simple system: a Motorola MC68332 uP is trying to configure a
Spartan2 chip, an XC2S15-VQ100. We've done this sort of thing tons of
times without incident. There are two short traces from the a uP
parallel port to the CCLK and DIN pins on the FPGA; PROGRAM- is wired
to the uP RESET- line, so we can config the chip after powerup. We're
using code that has always worked; the bits from the RBT file are
built into the uP rom image, and the processor just bangs the bits
out. Timing is legal and conservative; setup/hold times exceed a
microsecond. CCLK and DIN are 5 volt, fairly slow HCMOS levels, but
that should be OK here. Powerup sequence is legal.

But this one won't configure. INIT just stays high after reset, even
if I load deliberately bad data frames. This for three days! CCLK and
DIN look OK, in fact very clean, on their test points, but finally I
decide to look at CCLK and DIN *at the fpga pins*. So, when I touch a
scope probe on the CCLK pin and run the code, the green LED (on DONE)
lights! It works! It also works if the CCLK pin is touched with a
small insulated screwdriver, 330 ohms to ground, or an x-acto knife,
but not a toothpick (so it's not mechanical). The scope waveform looks
fine, no serious ringing or whatever, but the probe capacitance is
doing something.

Anybody seen anything like this?

John

On Thu, 16 Oct 2003 10:03:02 -0700, John Larkin <[email protected]> wrote:
>OK, a simple system: a Motorola MC68332 uP is trying to configure a
>Spartan2 chip, an XC2S15-VQ100. We've done this sort of thing tons of
>times without incident. There are two short traces from the a uP
>parallel port to the CCLK and DIN pins on the FPGA; PROGRAM- is wired
>to the uP RESET- line, so we can config the chip after powerup. We're
>using code that has always worked; the bits from the RBT file are
>built into the uP rom image, and the processor just bangs the bits
>out. Timing is legal and conservative; setup/hold times exceed a
>microsecond. CCLK and DIN are 5 volt, fairly slow HCMOS levels, but
>that should be OK here. Powerup sequence is legal.
>
>But this one won't configure. INIT just stays high after reset, even
>if I load deliberately bad data frames. This for three days! CCLK and
>DIN look OK, in fact very clean, on their test points, but finally I
>decide to look at CCLK and DIN *at the fpga pins*. So, when I touch a
>scope probe on the CCLK pin and run the code, the green LED (on DONE)
>lights! It works! It also works if the CCLK pin is touched with a
>small insulated screwdriver, 330 ohms to ground, or an x-acto knife,
>but not a toothpick (so it's not mechanical). The scope waveform looks
>fine, no serious ringing or whatever, but the probe capacitance is
>doing something.
>
>Anybody seen anything like this?
>
>John

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

http://www.fpga-faq.com/archives/37500.html#37520

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

On Sat, 18 Oct 2003 01:20:57 GMT, Philip Freidin
<[email protected]> wrote:

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

Right.

>
>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
>
> http://www.fpga-faq.com/archives/37500.html#37520
>
>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


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

Hi John,

On Sat, 18 Oct 2003 16:39:38 -0700, John Larkin <[email protected]> wrote:
>On Sat, 18 Oct 2003 01:20:57 GMT, Philip Freidin
><[email protected]> wrote:
>>
>>(Although you don't say, I am assuming you are using Serial Slave
>>configuration mode)
>
>Right.
>
>> .....
>>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.

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.

>>
>>Please let us know how things go on this.
>>
>>All the best,
>>
>>Philip

> ....
>
>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.

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

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

( 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.

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

Little tools like this are always useful. If you want to donate it, I
can make it available at www.fpga-faq.com . Just email it to me.

>John

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

"Philip Freidin" <[email protected]> wrote in message
news:[email protected]...
> Hi John,
>
> On Sat, 18 Oct 2003 16:39:38 -0700, John Larkin
<[email protected]> wrote:
> >On Sat, 18 Oct 2003 01:20:57 GMT, Philip Freidin
> ><[email protected]> wrote:
> >>
> >>(Although you don't say, I am assuming you are using Serial Slave
> >>configuration mode)
> >
> >Right.
> >
> >> .....
> >>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.
>
> 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.
>
> >>
> >>Please let us know how things go on this.
> >>
> >>All the best,
> >>
> >>Philip
>
> > ....
> >
> >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.
>
> Don't succumb to the dark side. There is a solution that does not
> involve 33 pf caps. :-)
>
> >Heck, we're engineers: we don't have to understand it, we only have to
> >make it work.
>
> ( 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.
>
> >Thanks
> >
> >Oh: I have a Windows command-line app that builds ROM images out of
> >Motorola S28 files and multiple .RBTs. Any interest?
>
> Little tools like this are always useful. If you want to donate it, I
> can make it available at www.fpga-faq.com . Just email it to me.
>
> >John
>
> Please dont go the 33 pf route. I want to know what the real problem is.
>
> Good luck,
> Philip
>
>
>
>
>
> Philip Freidin
> Fliptronics

John Larkin wrote:

>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.
>
>
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