PCI bus signals seem to be switcing on the wrong clock edge... Why?

[davec]

The signals on my PCI bus seem to be switching on the rising edge,
which doesn't make sense, since that is when the signals are being
sampled. Why would this be happening? I checked the silly stuff, like
making sure my scope wasn't inverting, etc...

I have a TI Firewire OHCI chip (TSB43AB22A) tied to a Blackfin 21535.
My system locks up occasionally when writing data out through Firewire,
and I'm wondering if this isn't part of the problem. I feed the clock
into both chips, but can't understand why the chips would switch their
signals near the rising edge. Any thoughts?

Thanks.
Dave

 

[Nico Coesel]

The signals on my PCI bus seem to be switching on the rising edge,
which doesn't make sense, since that is when the signals are being
sampled. Why would this be happening? I checked the silly stuff, like
making sure my scope wasn't inverting, etc...

I have a TI Firewire OHCI chip (TSB43AB22A) tied to a Blackfin 21535.
My system locks up occasionally when writing data out through Firewire,
and I'm wondering if this isn't part of the problem. I feed the clock
into both chips, but can't understand why the chips would switch their
signals near the rising edge. Any thoughts?

Did you set the probe to 1:10? Otherwise you may load the bus too much
by the oscilloscope's & probe input capacitance.

Why are you sure it is a PCI problem? If the driver for the firewire
chip is written correctly, it should note a bus problem and retry.

If the firewire chip has a buffer you can read and write, it is a good
idea to write a piece of software that reads and writes that buffer
with different amounts of data for a few days. Just see what happens.

 

[Ben Jackson]

The signals on my PCI bus seem to be switching on the rising edge,

Where are you getting the clock and signals? What signals are you
looking at besides CLK?

 

[davec]

I do have my probe set to 1:10. I've attached flying leads to the PCI
bus signals - I've looked at CLK, IRDY, TRDY, FRAME, GRANT, REQ. The
PCI clock is running at 19MHz.

The device I am working is a portable product called the 744T (you can
see it on www.sounddevices.com, my company). It has been shipping for
a couple years with the system working well where audio is recorded to
the internal harddisk and transferred to a PC later. Now we are trying
to get it to record to an external drive, and that is where the
problems are coming in.

Because we've been able to copy from internal through Firewire to a PC
reliably, and because recording to the internal drive by itself seems
to be working, I suspected some kind of bus conflict going on, so I
started flying wires in on the bus to look at the signalling, and that
is when I noticed the clock signalling looked backwards.

 

[[email protected]]

The signals on my PCI bus seem to be switching on the rising edge,
which doesn't make sense, since that is when the signals are being
sampled. Why would this be happening? I checked the silly stuff, like
making sure my scope wasn't inverting, etc...

I have a TI Firewire OHCI chip (TSB43AB22A) tied to a Blackfin 21535.
My system locks up occasionally when writing data out through Firewire,
and I'm wondering if this isn't part of the problem. I feed the clock
into both chips, but can't understand why the chips would switch their
signals near the rising edge. Any thoughts?

Thanks.
Dave

that normal synchronous design, everything happens on the rising edge,
so what
gets sampled is what was right before the edge and data changes after
the
edge.

It does require that the clock skew and delay is under control, since
if the logic
delay between flipflops are less that the skew/delay it won't work.

if data changed on the falling edge and was sampled on the rising you
would only have half as much setup time. So you could probably only run
half as fast

-Lasse

 

[davec]

Well, that would correlate with what I'm seeing, since it looks like
the signal is switching **slightly** after the rising edge. That puts
a tight tolerance on the clock edge rate - perhaps I should take a look
at that next...

 

[[email protected]]

Because we've been able to copy from internal through Firewire to a PC
reliably, and because recording to the internal drive by itself seems
to be working, I suspected some kind of bus conflict going on, so I
started flying wires in on the bus to look at the signalling, and that
is when I noticed the clock signalling looked backwards.

That sounds so much more like a firewire driver problem than a PCI
hardware problem.

 

[davec]

okay, so now I need to prove which it is. I'm going to hook a logic
analyzer up to the PCI bus tomorrow to verify all the PCI signalling
and bus arbitration is correct - perhaps I can see where in the PCI
cycle it is locking up. I am also going to try different speed PCI
clocks to see how that affects the lockups. Power supplies are clean.

It is a weird problem - sometimes I can get it to record externally for
10-15 minutes without an error, and sometimes only 20 or 30 seconds.

Thanks.
Dave