PCI bus signal analyzer/monitor?

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

Here is one example your basic POST card and breakout adapter:

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:

Here is a more capable/expensive one:

(I really like this unit!)

If the above solutions don't work, here are the big guns:

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

[snip]

Who cares? GM is nonexistent.

...Jim Thompson

-- | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona Voice:(480)460-2350 | | | E-mail Address at Website Fax:(480)460-2142 | Brass Rat | |

| 1962 | I love to cook with wine. Sometimes I even put it in the food.

Maybe fathead is too kind a description ?

Graham

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

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

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.

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

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

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

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

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

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 Applicati> Andy Peters wrote:

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