PC I/O More Questions

[Malfunction]

Hello again.

My questions about PC I/O hasn't come to end. Seems like they will never

Question: What's going on device side?

I have an x86 Pc. Suppose I want to design a device for it which connects via PCI. Normally when I connect a PCI device I bought, it communicates with PC through PCI. To do this registers of the device are mapped to memory or i/o address space. Then I write and read these with appropriate instructions. Things seem OK on PC side. But what's happening on the device side? How does it talk to via PCI. What hardware or protocol do they use? If that device too for example has an x86 cpu inside, when it connects to my main PC what happens. How I/O and PCI stuff are done on device side?

I also wanna know what would happen if we change bus from pci to i2c in previous question.

[Octocontrabass]

But what's happening on the device side? How does it talk to via PCI. What hardware or protocol do they use?

PCI.

If that device too for example has an x86 cpu inside, when it connects to my main PC what happens. How I/O and PCI stuff are done on device side?

However the hardware designer wants. For example, the device might include some RAM that's accessible to both the host CPU and the internal CPU, so that the two can communicate that way. PCI also supports things like DMA and IRQs, so the internal CPU may be able to control those as well.

I also wanna know what would happen if we change bus from pci to i2c in previous question.

There's no DMA and IRQs in I²C. Other than that, same answer.

[Malfunction]

Haha. I knew it is PCI but is it implemented differently in client side than host side (not sure if we can call them like that)?

Btw do we talk to PCI in our PC with in/out instructions just like peripherals on local bus? I am having hard time finding example code on PCI stuff.

[Octocontrabass]

Haha. I knew it is PCI but is it implemented differently in client side than host side (not sure if we can call them like that)?

It might be, it might not be. It's up to whoever designed the hardware.

Btw do we talk to PCI in our PC with in/out instructions just like peripherals on local bus? I am having hard time finding example code on PCI stuff.

Yes, if the device is expecting port I/O. For devices that use memory-mapped I/O you'll probably use MOV instructions instead. The PCI controller (connected to the local bus) will translate those into PCI bus accesses.

[StudlyCaps]

The super high level (as I understand it) is this:

Each device is connected to a shared bus. The bus has control lines, a shared clock and address/data line.

A device wanting to initiate a transfer (this includes the PCI host bridge which works on behalf of the CPU) will wait until the bus is free (signified by control lines) then claim it (also control lines, chip on mobo called the arbitrator grants access). This device is now the bus master, it first sets the address/data lines to an address. Each device knows which addresses it owns and when it sees an address in it's range it confirms it (control lines). Now the bus master can send one or more bytes of data by setting the address/data lines. After the transfer, the master gives up the bus and another can take over.

The system software is responsible for telling the devices which addresses are theirs. Devices which are not configured only respond when a special line called IDSEL is pulled high, each PCI port has one hardwired line that is not shared on the bus, this is the IDSEL line. Iterating through all these IDSEL lines is what is called PCI enumeration.

This is the PCI protocol, there are some standard data structures for configuration and some complexity around how much data can be sent and when, but that's the key stuff. Everything else the system software and devices do is the responsibility of the hardware designers, Some devices use IO ports, some don't, some use mapped memory, some don't. The data being sent and the protocol used to do it is not part of the PCI standard and neither is how the device responds to it. The hardware designer will decide and the writer of the device driver must simply know all these things and write a driver that gives it the right memory in the right places and uses it to send and receive the necessary data. From the perspective of the device designer PCI's purpose is only to let devices talk to each other and the CPU is a reliable and extensible way.

It's worth noting that PCIe doesn't work this way at all, though it appears similar in software it is a totally different system.

(Note: I'm not a hardware designer, I learned this from the Wikipedia page about PCI and a course I took 8 years ago, corrections welcome)

[bzt]

Normally when I connect a PCI device I bought, it communicates with PC through PCI.

Yes.

To do this registers of the device are mapped to memory or i/o address space. Then I write and read these with appropriate instructions. Things seem OK on PC side.

Correct.

But what's happening on the device side? How does it talk to via PCI. What hardware or protocol do they use?

Short answer they don't talk to the PC. They talk to the PCI Controller using the PCI bus. They provide an info sheet which describes which ports and MMIO addresses the device use. The PC side (or should we call it the CPU side) talks to the same PCI Controller, specifying the PCI address in IO registers (0xCF8). Then the PCI Controller provides the device's PCI info in it's data registers (0xCFC). The CPU can't directly access the PCI bus, only through the PCI controller. For PCIe, you don't use IO ports, rather MMIO. But this is irrelevant from the device's point of view, as it's connected to the PCI bus regardless.

Very simply put, devices are "talking" to the CPU with the PCI Controller translating between them.

If that device too for example has an x86 cpu inside, when it connects to my main PC what happens. How I/O and PCI stuff are done on device side?

I'm not sure anyone ever tried to use an x86 CPU on a PCI card. But I've used an X25 amateur radio card once which had a Z80 CPU on it. It worked like a totally separated machine, it couldn't access the default PCI Controller (or any other IO) ports as the main CPU did, it's access was strictly limited to the PCI bus' interface.

I also wanna know what would happen if we change bus from pci to i2c in previous question.

They are not replaceable. PCI is a complex bus system with wide addresses and high speed. It also has an address space standard with a hierarchical structure (see the aforementioned wiki page) and a main controller.

I2c on the other hand uses as few bits for the communication as possible, therefore it is a serial protocol with 2 bits only where speed was never a goal. It does not have any address space standards or hierarchy or designated controller like the PCI, rather uses packets between the equal nodes, where each device has it's "node address" and can be either a sender (master) or receiver (slave). Note this is a very-very simplified description for both PCI and i2c, but hope it helps you.

Cheers,
bzt

[Malfunction]

thanks for answers guys. one more

Are all of the i/o address space and parts of memory address space allocated to pci on x86? since there is no other way to i/o communication (without pci)?

[nullplan]

Are all of the i/o address space and parts of memory address space allocated to pci on x86?

No, only those written into the BARs. Otherwise PCI would have been incompatible with ISA, which would have hampered its early success.

[Octocontrabass]

Are all of the i/o address space and parts of memory address space allocated to pci on x86?

No, usually the portion of memory address space used for RAM is outside the PCI bus. The address space used for RAM is still configured as a PCI device, though, and the entire I/O address space goes through PCI.

This is true even on old computers with a mix of PCI and ISA slots; if no PCI device is configured to claim a particular address, the read/write is forwarded through the PCI-to-ISA bridge.