PCI bus signal analyzer/monitor?

[[email protected]]

Hi all,

I have a PLX 9030 PCI bridge device on a new design that is not
working. Although I can access the device itself and load my drivers,
and the PLX device is configuring itself correctly from the onboard
eeprom, I am unable to access anything on the local bus side of the
device.

Going round and round with support and having exhausted most options,
and have recently been advised that perhaps the 9030 is rejecting
accesses and returning fault codes, or any one of a number of other
things that can go wrong on the PCI side.

The board is not going to allow me to affix any kind of bus analysis
tool, or even a four channel Digital Scope to get any useful
information, as it is tight, and I have no access to the tools that can
attach or probe such an IC package, plus there is not a lot of money
for high end, multichannel logic analyzers and other related tools.

Since I want to view the data across the PCI bus, and the card is the
only one in any of the slots, I am curious about maybe finding some
kind of bus "low end" analyzer/monitor that might be able to capture
windows of data across the PCI bus that may be helpful in getting my
product up and running.

I know there are such things for debugging a PC that will not POST, or
has other power up issues, and wonder if such tools might apply to my
needs?

I cannot spend a ton of $$$ on this, so its either something in the
broad neighborhood of hundreds of dollars, or a rental.

Anyone have an ideas if such a beast exists, where to look, and if such
a thing might help me analyze this failure?

Thanks for any suggestions or ideas.

John

 

[John Larkin]

Here is one example your basic POST card and breakout adapter:
http://www.pcengines.ch/test.htm

Even if these don't solve your current problem, they are cheap
and you should own one hanging on your PCI buss as you work.

There are many such POST cards on eBay, cheap. For example:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=5219195729

Here is a more capable/expensive one:
http://www.uxd.com/phdpci2.shtml
(I really like this unit!)

If the above solutions don't work, here are the big guns:
http://www.silicon-control.com/pci650.htm
http://www.silicon-control.com/pci850.htm

I note here that GM has cross-posted his reply to his private
GM-moderated group, thus hijacking a thread that was posted only to
s.e.d. and placing himself in control of followup posts to the s.e.d
thread. He did all sorts of weird stuff to the header, too.

Whenever I think maybe we've ragged him enough, he does something
obnoxious like this.


John

 

[Pooh Bear]

I note here that GM has cross-posted his reply to his private
GM-moderated group, thus hijacking a thread that was posted only to
s.e.d. and placing himself in control of followup posts to the s.e.d
thread. He did all sorts of weird stuff to the header, too.

Whenever I think maybe we've ragged him enough, he does something
obnoxious like this.

Maybe fathead is too kind a description ?

Graham

 

[Guy Macon]

Hi all,

I have a PLX 9030 PCI bridge device on a new design that is not
working. Although I can access the device itself and load my drivers,
and the PLX device is configuring itself correctly from the onboard
eeprom, I am unable to access anything on the local bus side of the
device.

Going round and round with support and having exhausted most options,
and have recently been advised that perhaps the 9030 is rejecting
accesses and returning fault codes, or any one of a number of other
things that can go wrong on the PCI side.

The board is not going to allow me to affix any kind of bus analysis
tool, or even a four channel Digital Scope to get any useful
information, as it is tight, and I have no access to the tools that can
attach or probe such an IC package, plus there is not a lot of money
for high end, multichannel logic analyzers and other related tools.

Since I want to view the data across the PCI bus, and the card is the
only one in any of the slots, I am curious about maybe finding some
kind of bus "low end" analyzer/monitor that might be able to capture
windows of data across the PCI bus that may be helpful in getting my
product up and running.

I know there are such things for debugging a PC that will not POST, or
has other power up issues, and wonder if such tools might apply to my
needs?

I cannot spend a ton of $$$ on this, so its either something in the
broad neighborhood of hundreds of dollars, or a rental.

Anyone have an ideas if such a beast exists, where to look, and if such
a thing might help me analyze this failure?

Here is one example your basic POST card and breakout adapter:
http://www.pcengines.ch/test.htm

Even if these don't solve your current problem, they are cheap
and you should own one hanging on your PCI buss as you work.

There are many such POST cards on eBay, cheap. For example:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=5219195729

Here is a more capable/expensive one:
http://www.uxd.com/phdpci2.shtml
(I really like this unit!)

If the above solutions don't work, here are the big guns:
http://www.silicon-control.com/pci650.htm
http://www.silicon-control.com/pci850.htm

 

[Al Borowski]

I note here that GM has cross-posted his reply to his private
GM-moderated group, thus hijacking a thread that was posted only to
s.e.d. and placing himself in control of followup posts to the s.e.d
thread. He did all sorts of weird stuff to the header, too.

I thought it was supposed to be focused on product development. However
recent threads include "recovering old disks" and "shortage of poor
people". I thought moderation was supposed to prevent this type of OT stuff.

Al

 

[John Larkin]

I thought it was supposed to be focused on product development. However
recent threads include "recovering old disks" and "shortage of poor
people". I thought moderation was supposed to prevent this type of OT stuff.

Al

Well, he needs traffic. And about 95% of the threads over there are
started by... you'll never guess... Guy Macon! So he hijacks threads
from other groups for his own private usenet empire.

But maybe he really has problems, and it's actually unkind to pound on
him. That happens; you think a guy is merely obnoxious, so you rag
him, but things go so far that you sometimes feel he's actually a sad
case, and we're just being mean to someone who's out of control.
"Normal" people might get into snits now and then, but they mostly get
over it and drift back into the group; GM seems to be flailing worse
and worse, and fighting with and plonking most everybody.

But I wish he'd quit doing the stupid header tricks.

Dunno.

John

 

[Jim Thompson]

On Fri, 15 Jul 2005 15:45:25 -0700, John Larkin

[snip]

GM seems to be flailing worse
and worse, and fighting with and plonking most everybody.

But I wish he'd quit doing the stupid header tricks.

Dunno.

John

Who cares? GM is nonexistent.

...Jim Thompson

 

[Andy Peters]

I have a PLX 9030 PCI bridge device on a new design that is not
working. Although I can access the device itself and load my drivers,
and the PLX device is configuring itself correctly from the onboard
eeprom, I am unable to access anything on the local bus side of the
device.

Going round and round with support and having exhausted most options,
and have recently been advised that perhaps the 9030 is rejecting
accesses and returning fault codes, or any one of a number of other
things that can go wrong on the PCI side.

The board is not going to allow me to affix any kind of bus analysis
tool, or even a four channel Digital Scope to get any useful
information, as it is tight, and I have no access to the tools that can
attach or probe such an IC package, plus there is not a lot of money
for high end, multichannel logic analyzers and other related tools.

Since I want to view the data across the PCI bus, and the card is the
only one in any of the slots, I am curious about maybe finding some
kind of bus "low end" analyzer/monitor that might be able to capture
windows of data across the PCI bus that may be helpful in getting my
product up and running.

I know there are such things for debugging a PC that will not POST, or
has other power up issues, and wonder if such tools might apply to my
needs?

I cannot spend a ton of $$$ on this, so its either something in the
broad neighborhood of hundreds of dollars, or a rental.

Anyone have an ideas if such a beast exists, where to look, and if such
a thing might help me analyze this failure?

You may be able to rent a PCI bus analyzer. While they're not cheap,
you should consider springing for one if you're doing PCI bus designs.
If you can see what's happening on the PCI bus, you'll save yourself a
LOT of time. And since time = money, how much money will your
organization burn if you're dicking around without the proper tools?

Another thing to consider is that maybe your EEPROM load isn't correct.
Wrong BARs, wrong local-bus spaces, wrong chip select outputs, all
sorts of things can bite you. Is it possible to attach test wires to
vias and such, maybe just for the important signals, and then monitor
them on a logic analyzer? The 9030's local bus can't run all that
fast, and an HP1660 is a reasonable choice here.

-a

 

[[email protected]]

You may be able to rent a PCI bus analyzer.

Thanks. I may well have to go there. I am not familiar with them at
all, so is this something that plugs into an empty PCI slot, or would
it have to be connected to the board being debugged? Somehow, that
seems rather impossible to do without creating another layout just for
testing purposes.

While they're not cheap,
you should consider springing for one if you're doing PCI bus designs.

After this disaster, I am getting out of the business altogether!

If you can see what's happening on the PCI bus, you'll save yourself a
LOT of time. And since time = money, how much money will your
organization burn if you're dicking around without the proper tools?

I am with you on the "time is money" issue. The design that this
company uses already works in a popular 5V version using the PLX 9050,
which they sell a ton of. Needing a 3V version, for a handful of
customers, PLX assured me that it was a piece of cake to roll it over
onto a 3V 9030 device, and that the existing software would all work on
the 9030, as is (minor eeprom register address issues in a new eeprom.)
Given the concept of not having to redevelop the product it was decided
to go ahead and do it, even if the market is not that big at the
moment. Big mistake....

Another thing to consider is that maybe your EEPROM load isn't correct.
Wrong BARs, wrong local-bus spaces, wrong chip select outputs, all
sorts of things can bite you.

I have pestered the PXL support folks to verify the design from the
schematic, and I have used their tools, and abused one of their
software engineers to confirm that the eeprom and its software is
correct. As I mentioned, I can eve load our device driver software into
the device so that windows can access it. The more depressing point is
that PLX says my hardware and my software is correct. It just doesn't
work....

The 9030's local bus can't run all that
fast, and an HP1660 is a reasonable choice here.

Monitoring the local bus side is easier as the devices are more easily
attached to, but the problem is, the local bus side never, ever has any
signaling or activity on any of its data/address, or control lines.
This has been verified using a storage scope looking for any kinds of
triggers or activity. It behaves as if the 9030 device is completely
shut off on the local bus side, so there is nothing to monitor or check
for. I am of the impression that the local bus side is such a very
simple interface, that once I can "convince" the 9030 to actually
access it, I will be on my way. All anyone can think of is that the
9030 is returning fault and errors to the PCI bus, and taking itself
off line, refusing access to the local bus. I just need a reasonable
way to show that to be true or false. A monitor is certainly looking
like the only way to get past this, so I will be out looking for one.

If anyone has any other recommendations for a bus monitor that won't
take me three months to learn <g> or break the bank, I am surely
interested to hear about it. I will be looking at what Guy pointed out,
and hope to find something soon.

Much obliged for your time and ideas,

John

 

[Carter Buck]

John,

I had communicated with you some months back and noted errors in your
board layout (that a 2-layer board with 1.2 inch clock trace won't
work). Did you re-spin your board?

We do not have record of reviewing your schematic, and the software
engineer that you communicated with no longer has your EEPROM file,
although he was able to load your driver with our reference board, and
he provided to you our PlxCm utility with which you were apparently
able to successfully access PLX 9030 registers as well as the EEPROM.
If your board is working to this point, and there is no Parity Error
flagged in the PCI Status register, then the hardware is probably
working correctly. The fact that you are not seeing Local bus activity
is likely due to an incorrect address, EEPROM value or software. I do
see that you recently downloaded the PLXMon demo version from our
website; the demo version will not access the Local bus.

You had mentioned that your previous design uses I/O-mapping. The PlxCm
and PLXMon-DOS commands that the software engineer mentioned to you
(dl/el) provide memory command access, not I/O command access. So the
problem could simply be that of using the wrong commands. You should
use our utilities to test access to the Local bus, and once that works,
you can try your existing software.

Please do not email directly; use our support website at
http://www.plxtech.com/support/
In your case especially, you did submit your request to our Helpdesk,
but then further communication was through email to various engineers,
who should not have moved support to direct email; files and
correspondence for each support case should be stored in one location
(so that another engineer such as myself can access the complete record
if necessary to help resolve issues). In order to support you, I will
need to see your schematic, and both EEPROM files (PLX 9030 and PLX
9050).

Carter Buck
Applications Engineer
PLX Technology, Inc.

 

[Paul Burke]

PLX assured me that it was a piece of cake to roll it over
onto a 3V 9030 device, and that the existing software would all work on
the 9030, as is (minor eeprom register address issues in a new eeprom.)
Given the concept of not having to redevelop the product it was decided
to go ahead and do it, even if the market is not that big at the
moment. Big mistake....

I transferred a design from the 9052 to the 9030 a short while ago, with
no problems whatsoever. It even 'looks' exactly like the old product to
the system (if I want it to) so that the drivers don't need to be
changed. It's not the 9030...

Paul Burke