Configuration Blues

[John Larkin]

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

 

[Philip Freidin]

On Thu, 16 Oct 2003 10:03:02 -0700, John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> 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

 

[John Larkin]

On Sat, 18 Oct 2003 01:20:57 GMT, Philip Freidin
<philip@fliptronics.com> 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

 

[Philip Freidin]

Hi John,

On Sat, 18 Oct 2003 16:39:38 -0700, John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote:

On Sat, 18 Oct 2003 01:20:57 GMT, Philip Freidin
philip@fliptronics.com> 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

 

[Dave Garnett]

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" <philip@fliptronics.com> wrote in message
news:a964pvks3uor3v1dv7jse71jk8pq904gd0@4ax.com...

Hi John,

On Sat, 18 Oct 2003 16:39:38 -0700, John Larkin
jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote:
On Sat, 18 Oct 2003 01:20:57 GMT, Philip Freidin
philip@fliptronics.com> 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

 

[Jon Elson]

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