Putting the P.H.D. to the Test
The P.H.D. card is a complicated tool and takes some getting used to. I found it necessary to use it on a number of systems before I got the gist of what it’s capable of. The main thing to understand is that the card not only tests out whether specific hardware subsystems work or not, but it can also fail something that is not implemented to spec. This means that even though a system appears to be functioning perfectly, you may still get some failures from the P.H.D. Interpreting the results, and knowing when a failure is a problem or something that can be ignored, takes experience and a certain degree of intuition. I used the P.H.D. card for over a month in approximately 10 systems and still needed numerous conversations with Ultra-X technical support to help interpret what I was seeing. This is not a card that you plug in and your job is done.
My assessment is that I have not seen another card capable of testing the functionality or compatibility at such an exhaustive low level as the P.H.D. card. This provides a view way beyond go/no go type products. For example, if a device on the PCI bus is not PCI 2.1 compliant, it may just fail some overall timing spec and still function fine. It’s important to notice while a board is being tested what the error messages are telling you. Often I saw failures that were really related to "Not within spec" type failures. The 4 different test speeds make it easier to slow down the test execution so that the test messages that flash by are more readable.
Testing Newer Designs
To baseline the P.H.D. PCI card I used it on a number of systems that were brand new and functioning properly. A few boards I tested, like the recently released AOpen AX3S (i815E chipset), passed all of the tests flawlessly in the PHD diagnostic mode. This mode is the one where you just boot up the system with the P.H.D. card plugged in and the diagnostic mode will start immediately after the mainboard’s BIOS is booted. I ran this excellent new mainboard for three straight days looping on all the PHD diagnostics tests and did not log a single failure. Some of the better mainboards are certainly capable of passing all the functional and compatibility tests without a problem.
Another view of the P.H.D. can be taken from my testing with the newest FIC FA11 motherboard. The FA11 is a Socket370 design based on the VIA Apollo Pro 133A. To read our review of this board, go to /page.cfm?articleid=RWT081500000000. Considering this is a brand new design, you’d expect results similar to what was seen with the AOpen AX3S. Unfortunately I found some repeatable errors in the Interrupt Controller test, and with the Hummer IP on the ISA bus (specifically the Port B test of system byte high enable). Now, the FA11 had functioned just fine during my initial evaluation, so it’s difficult to weigh the significance of having it fail on these more obscure tests. This brings about one of the main difficulties with the P.H.D. PCI card, which is interpreting the results. This is the best time to contact Ultra-X’s quite proficient technical support team. Once you’ve seen a particular error and discussed it with them, it becomes easier to put each error in perspective. I feel a better description of each test in the manual would make this process easier.
Testing With Different Video Cards
During my testing with the P.H.D., I used a number of PCI and AGP video cards in the different systems and motherboards. Most of the newer cards would work fine for the most part, but sometimes I’d have get strange results, such as with the Diamond Stealth 4MB PCI card (based on the S3 968 Vision chipset). When the P.H.D. card initiated the standard diagnostics and scanned the PCI bus, the inquiry to the Diamond card would loop forever and never recover. After discussing the issue with Ultra-X, it was explained that if a card did not properly implement the PCI spec, it was unpredictable how it might respond. What was suppose to happen is that the P.H.D. card would poll the Diamond card and ask about its resources. The Diamond should respond and then communicate to the P.H.D. card that it was done. But in this instance the Diamond card didn’t communicate that it was done, so the P.H.D. continued its query forever. This is another example of how tricky it can be to understand why a test is hanging or getting lost.
Testing On Older, Non-Standard Systems
The company I work for utilizes a large number of PCI/EISA ALR server systems in our products. I figured this would be an excellent application for the P.H.D. card considering we have to repair and support this server platform for a number of years. We have been looking at buying a P.H.D. card several years to help the service depot and new production integration issues. It has been hard to justify the expense, so it was my mission to see what help the P.H.D. card could provide in improving our product quality and reliability.
The first ALR computer is what is known as an ALR MP1, and has a Pentium 100 processor, 3 PCI slots and 6 EISA slots. The first time I plugged in the P.H.D. card, I was surprised to find the standard diagnostic mode did not initiate. After a number of emails and phone conversations with Ultra-X, we had exhausted all of their standard tricks and work arounds. Apparently the P.H.D.’s BIOS was not being found when the main motherboard’s BIOS was suppose to be scanning the system for any optional BIOS. The P.H.D. card was not seen and would not initiate. After some negotiations with Ultra-X, it was decided we should ship the ALR server to Ultra-X so that they could analyze it in their labs and possibly come up with a fix.
After Ultra-X had the server for a week, and had begun testing it in their lab, I began requesting feedback on what they were finding. The problem turned out to be the implementation of the PCI bus has not even followed the basic 1.1 revision of the PCI spec. This meant that the normal scan for any option BIOS was not taking place and therefore the P.H.D. card was not being seen. Ultra-X is now working on the painstaking job of reverse engineering the server’s BIOS on a line by line basis. Theoritically, when they are done they can tweak the code in the P.H.D.’s BIOS so that the card can be located and the testing properly initiated. In the meantime I was offered an older (out of production) ISA based PC Inspector card that should allow me some degree of functional testing from the EISA bus. This was an impressive effort by Ultra-X to supply a customer with outstanding support.
Ordinarily, I find most products ship to me in good working order. Since this is a review of the entire package from Ultra-X, I find it my duty to comment on a problem I found with the Hummer IP card that was received directly from Ultra-X. The Hummer card was not found by the P.H.D. card during the initial boot up sequence. I played around with the card’s seating on the ISA bus slot but could not get it going. After visually inspecting the card, I found one of the only two chips on the card improperly inserted in a dip socket. A 20 pin DIP IC latch had pin 1 and 20 bent and not inserted in the socket. After pulling the chip out and fixing the leads, the card came up properly. It was disappointing that the diagnostic card needed debugging out of the box. See the picture below.
Be the first to discuss this article!