RE: PCI Signal Loading

["B. P. Lame'" <blame@prolog.com>]

The wording in PCI Spec 2.1, section 4.4.3.4 certainly seems ambiguous since "shared PCI signals" does not appear to be specificly defined in the signals definition section and the bullet statements in section 4.4.3.4 refer to "PCI signal" and "any PCI signal" rather than "shared PCI signal."  I would interpret that to mean snooping the REQ# signal on your add-in card is a technical violation.  However, because PCI output drivers in general are supposed to be able to support 10 loads and the REQ# signal typically only has two (the connector and the host chipset, though I've seen implementations where the host board has two or three loads in adition to the connector), you could probably get away with it from a signal integrity standpoint.  Just verify that the PCI REQ# output driver of your device has the same characteristics as the other PCI output drivers.  And be careful about calling your card PCI compliant; rather, it's PCI compatible.
--
Brooks Lame'

On Friday, 30 January, 1998 14:31, Scott Eichman[SMTP:seichman@simpact.com] wrote:
> PCI spec 2.1 Signal Loading section 4.4.3.4   says:
> 
> "Shared PCI signals must be limited to one load on the expansion card.
> Violation of expansion board trace . . . . ." 
> 
> The section goes on to list some specific violations that must be avoided.
> 
> My question is:  Do the specifics within this section apply only to the
> "shared" signals identified in the first sentence? Or, do these rules also
> apply to point-to-point signals? 
> 
> Specificaly, can I "snoop" my own  REQ# output? Am I prohibited from
> connecting my own REQ#, which only goes to the system arbiter, to a CPLD
> input on my own card?
> 
> If you are wondering "why the *#?@ does this idiot need to to this"? Well,
> I'm using an AMCC 5933 in add-in bus mastering mode and am seeing an
> extremely intermittent condition related to a known errata for the device.
> The desgin error has "No Factory alteration planned" according to AMCC's
> errata sheet. I think that I have a work-around that could be accomplished
> by qualifying the bus master enable de-assertion, which I drive from the
> board side, with the REQ# output. I would be glad to talk about it with
> anyone who is really interested in the details.
> 
> Thanks in advance for any insight into section 4.4.3.4.