0

Some CPU like x86 processor has two address spaces. One for memory and one for IO. And different instructions to access them.

And the PCI 3.0 spec also mentions some important IO addresses:

Two DWORD I/O locations are used to generate configuration transactions for PC-AT compatible systems. The first DWORD location (CF8h) references a read/write register that is named CONFIG_ADDRESS. The second DWORD address (CFCh) references a read/write register named CONFIG_DATA.

So it seems PCI 3.0 spec is tightly coupled to processors that does implement IO address space. And that's the a priori knowledge that SW/FW writers should know.

So what about the other processor archs that don't have IO address space? Like ARM. How can they interact with the PCI configuration space?

ADD 1 --- 9:19 2023/4/19

A related thread:

https://electronics.stackexchange.com/questions/661331/is-pcie-io-address-space-meaningless-for-arm-based-system

smwikipedia
  • 61,609
  • 92
  • 309
  • 482

2 Answers2

0

The paragraph immediately preceding the one quoted in the question directly addresses the question. It says:

Systems must provide a mechanism that allows software to generate PCI configuration transactions. ... For PC-AT compatible systems, the mechanism for generating configuration transactions is defined and specified in this section. ... For other system architectures, the method of generating configuration transactions is not defined in this specification.

In other words, systems that are not PC-AT compatible must provide a mechanism, but it is specified elsewhere. The PCI spec isn't tightly coupled to PC-AT systems, but it doesn't define the mechanism for other types of systems.

The paragraph in the question only applies to PC-AT compatible systems.

prl
  • 11,716
  • 2
  • 13
  • 31
  • Thanks. I did notice that paragraph. But I am not sure what "PC-AT compatible" means exactly. There are ARM-based PCs as well nowadays. Are they PC-compatible? The x86 processor has separate address spaces for memory and I/O. I'm not sure if that shaped the meaning of "PC-AT compatible". I'm not sure if there's any spec about what is "PC-AT compatible". – smwikipedia Jan 28 '23 at 12:55
0

Below quote from here clears things up:

The method for generating configuration cycles is host dependent. In IA machines, special I/O ports are used. On other platforms, the PCI configuration space can be memory-mapped to certain address locations corresponding to the PCI host bridge in the host address domain.

And

I/O space can be accessed differently on different platforms. Processors with special I/O instructions, like the Intel processor family, access the I/O space with in and out instructions. Machines without special I/O instructions will map to the address locations corresponding to the PCI host bridge in the host address domain. When the processor accesses the memory-mapped addresses, an I/O request will be sent to the PCI host bridge, which then translates the addresses into I/O cycles and puts them on the PCI bus.

So for non-IA platform, MMIO can just be used instead. And the platform specs should document that memory-mapped address for the PCI host bridge as the a priori knowledge for SW/FW writers.

ADD 1 - 14:36 2023/2/5

From the digital design's perspective, the host CPU and the PCIe subsystem are just two separate IP blocks. And the communication between them is achieved by a bunch of digital signals in the form of address/data/control lines. As long as the signals can be conveyed, the communication can be made.

For x86 CPUs, the memory address space and IO address space are just different usage of address lines down to the earth. I don't think there's any strong reason that memory addresses cannot be used to communicate with PCIe subsystem. I think it's a more logical choice back then to use I/O addresses for PCIe because PCIe is deemed as I/O.

So the real critical thing I think, is to convey the digital signals in proper format between IPs. PCIe is independent of CPU architectures and cares nothing about what lines to be used. For ARM, there's nothing unnatural to use memory addresses, i.e., MMIO. After all it's digital signals and are capable of passing necessary information properly.

smwikipedia
  • 61,609
  • 92
  • 309
  • 482
  • This doesn't clarify (I'm not a downvoter, btw) how ECAM is involved to all this and if it's involved at all. – 0andriy Feb 03 '23 at 18:45
  • And in the Q your conclusion is wrong, so this answer doesn't explicitly says that, that PCI specification is not tighten to the CPU architecture. – 0andriy Feb 03 '23 at 18:46
  • @0andriy I added *ADD 1* to my answer. – smwikipedia Feb 05 '23 at 06:47
  • x86 architecture has specific signal (wire) and ISA (don't be confused with legacy bus name) subset to IO vs. MMIO. That's why it's different on x86 and ARM, but the latter can also utilize those signals somehow and as you said just allocate 64k of MMIO to actually assert different signal (or send a different message) to distinguish PCI IO and MMIO accesses. – 0andriy Feb 06 '23 at 21:19
  • @0andriy Thanks. I am not a native English speaker so I don't quite get the meaning of "... and ISA subset to IO vs. MMIO ..." – smwikipedia Feb 07 '23 at 01:12
  • Me neither, but ISA in this context is https://en.wikipedia.org/wiki/Instruction_set_architecture. And in x86 (if you curious it comes actually from 8080 design, that's why 64k space avaialble and never was expanded) has `outX()`/`inX()` instructions and IO/#MEM pin (or negative to that, I don't remember and lazy to look into) on the chip to decode address space (https://en.wikipedia.org/wiki/Memory-mapped_I/O_and_port-mapped_I/O). – 0andriy Feb 07 '23 at 12:11