Connect with us

PCI bus signal analyzer/monitor?

Discussion in 'Electronic Design' started by [email protected], Jul 15, 2005.

Scroll to continue with content
  1. Guest

    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

    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

    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.

  2. John  Larkin

    John Larkin Guest

    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.

  3. Pooh Bear

    Pooh Bear Guest

    Maybe fathead is too kind a description ?

  4. Guy Macon

    Guy Macon Guest

    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:
  5. Al Borowski

    Al Borowski Guest

    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.

  6. John  Larkin

    John Larkin Guest

    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.


  7. Jim Thompson

    Jim Thompson Guest

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

    Who cares? GM is nonexistent.

    ...Jim Thompson
  8. Andy Peters

    Andy Peters Guest

    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.

  9. Guest

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

  10. Carter Buck

    Carter Buck Guest


    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

    Carter Buck
    Applications Engineer
    PLX Technology, Inc.
  11. Paul Burke

    Paul Burke Guest

    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
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day