Multiple PCI devices on the same bus

One or more devices on the bus must be a bus master=20 controller with core logic. Transfers can only be initiated=20 by bus masters. When a bus master on the PCI bus initiates a=20 PCI transaction, the core decodes the address and the=20 command and claims the transaction if the address is decoded=20 to be within the address space defined in the base address=20 register. The PCI target controller also responds to=20 configuration read and write operations. The PCI=20 configuration registers for the host bridge=E2=80=99s own master and=20 target functions are provided by the core and they can be=20 accessed in the same way the host bridge accesses the=20 configuration registers of other PCI devices. When a=20 configuration request targets the host bridge's own=20 configuration register, the host bridge functions as both=20 the master and target for the configuration cycle on the PCI=20 bus. The core logic of the bus master initiating the=20 transfer ("data share") will seize the bus and signal the=20 appropriate controller to start the data transfer. Whether=20 individual bytes, words, bursts or blocks are transferred=20 depends on the transfer mode. During the transfer, the bus=20 is disabled for other controllers - leading to high levels=20 of contention where considerable data traffic is required.=20 The bus must always have at least one bus master controller=20

- if none of the cards have one, the function is provided by=20 the bridge. If several bus controllers initiate a request=20 simultaneously, the bridge master controller takes precedence.

-- HTH Sue

Thanks for the quick answer!

What you wrote is quite all clear, even though I still don't see the answer to some of my doubts...

Suppose that all the devices could be masters and there is also an arbiter for granting the bus ownership to one of them when requested, so the bus ownership is no longer an issue. My main doubt is related to how the master can discriminate between the two targets (suppose they are just copies of each other, eg two memories) and communicate (eg start a read I/O access cycle) with the selected one. Is this done by the master by the FRAME signal to the proper target (driving it low at the start of the transaction only for the selected target)? If it's correct I would need one FRAME pin on the master for each target, that seems a waste of pins.. Thus I suppose is the target selected by other means, but I fail to pick them out.. the only other thing I can guess it's that the correct target is selected at the beginning of the transaction during the address phase.. please could you explain this issue?

Thanks!

You are, I would suggest, going too far down the communications protocol stack. This is an intelligent bus where different hardware line transitions are interpreted in different ways depending on the mode of the target controller, which has been pre-determined by the core logic. Each target will have its own identity and whilst it will listen to all command streams, it will only act on control signals that are set enabled. The sequence of a data transfer will require the target controller being configured to expect a DMA request. Such a DMA request may take many bus cycles, indeed many slices, before it is placed - and could even be placed when the bus is in contention. One problem is that a target master cannot issue commands when in target mode, so has to have a timeout clock, in case the request has been lost. So your answer is that the correct target has been selected because it has been preselected. DMA transfer, particularly in burst or block mode, monopolises the bus for long enough enyway, without having to include the negotiation cycles.

-- Sue

The point is that I'd like to understand the comm. protocol of the bus... Let's suppose this scenario: As in my previous "scheme" there is a board with 3 PCI devices (lets call them A, B, C) directly connected to the bus (I mean their electric lines just connect to the bus, not 3 single PCI boards connected on a mainboard) that are the same kind of device (eg. 3 FPGAs with a PCI core) with the same decoding speed, and assume for configuration purposes that IDSEL(A) == AD[31], IDSEL(B) == AD[30] and IDSEL(C) == AD[29]. My first and main issue is understand how to discriminate between the 3 devices during memory access and I/O cycles: do they recive some kind of ID? and in the case who sets it? if they don't recive an ID, when one of them becomes master how could it discriminate between the targets during memory and I/O accesses (for what I've understood, IDSEL counts only during configuration accesses).

Consider this example: while the bus is idle, A wants to read the memory of B, so requests the bus and then becomes master; at this point A asserts the FRAME# signal and writes something on the AD signal lines (and also on the C/BE signal lines, but that's not my concern at this moment)... this is what confuses me: as B and C appear to be the same (as to Vendor, Revision and Subsystem IDs and maybe also Device ID, as they are predefined), why should B to answer and assert the DEVSEL# signal and not C?

I haven't come across any system with multiple PCI devices, directly addressable, on a single card in a single slot. It is an interesting thought. You are quite correct that IDSEL works on a card by card, slot by slot basis. I don't know of any inbuilt lower-level PCI protocol that can define shared slots. Obviously, at higher levels of ths stack it matters not where the devices are.

Of course it would be possible by having an arbiter on the card which would have the equivalent of a single IDSEL, etc in and several, local only, ones out. Elffectively yoy would be creating a local PCI bus within the card itself.

Is that the sort of thing you have in mind? If so, the question is really of "multiple PCI devices on the same card" rather than the same bus.

Palindr=E2=98=BBme ha scritto:

More or less yes, it's what I have in mind... The fact is that it would be a stand alone card, not a Pc card (it would communicate with the outside world by other means than PCI, maybe ethernet, it's not my concern at the moment); it would be something closer to a multiprocessor core bus (but using the PCI comm. protocol and 3 FPGAs instead of processors) than a Pc card; my fault was to think that speaking generically of a bus would include my case and that would be a not so unusual thing as I'm realizing now.

I though about using PCI because I need the 3 devices communicate with each other (so I needed a robust and quite fast communication protocol) and they would be provided with a PCI interface, so the though of creating a local (on board) PCI bus was straightforward.

So, as far as you know it would be possible to realize this and discriminate between this almost identical devices (except for the IDSEL signal line)? As I said I'm quite a newbie to PCI (I'm reading "PCI Hardware and Software Architecture and Design" by Solari and Willse, but I find it's almost for someone who already knows how PCI works, rather than for someone who tries to learn PCI) and I'd like to understand exactly how the bus works, in order to be sure that PCI is the solution I'm looking for to have these 3 device communicate with each other.

Thanks!

After reading the PCI 2.2 Spec. (I wrongly supposed a book about PCI would be easier to understand than the Spec) another question aroused: there is a common addresses map for all the PCI devices and at each device corresponds a subset of that addresses map? If this is correct, who assigns to each device its subset of addresses?