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

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.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

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

--
Ben Jackson AD7GD

http://www.ben.com/

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

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.

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

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

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

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

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

cs snipped-for-privacy@hotmail.com wrote: