10

I don't come from an Electronics background, so please bear with me. Assume an Intel processor wants to talk to a temperature sensor over the I2C bus. How does the underlying communication look like? So far I understand, Intel processors use specialized CPU instructions (IN/OUT) to communicate with peripherals. Also, I believe an Intel doesn't have an on-chip I2C controller. So, we need an I2C controller, isn't it? If so, does the processor treat the controller as a peripheral and use IN/OUT CPU instructions to talk to it? Is the controller mounted on the motherboard? What bus connects the CPU and controller?

sherlock
  • 219
  • 2
  • 6

5 Answers5

17

So far I understand, Intel processors use specialized CPU instructions (IN/OUT) to communicate with peripherals.

Uh, this might have been true in the 1970s and 1980s, but really wouldn't even be very useful for an I²C peripheral, and incredibly intrusive for the programming of the CPU.

So, instead, there's some peripherals attached to a much, much faster bus (e.g. PCIe) that does the I²C talking, upon receiving commands to do so from the CPU; that communication usually happens trough writing data to a specific memory location, instead of using special IO instructions.

Also, I believe an Intel doesn't have an on-chip I2C controller.

Oh, I don't think that's true; there should be multiple controllers, but they are purpose-specific, for example, for reading the EEPROMs on RAM modules.

So, we need an I2C controller, isn't it?

yep.

If so, does the processor treat the controller as a peripheral

yes

and use IN/OUT CPU instructions to talk to it?

No, these instructions, as said, are used for a very small set of device types that have been around for a few decades (think: PS/2 keyboards, PCI address space configuration, real-time clock, floppy, parallel printer port, …) only that a CPU needs to directly talk to, mostly for boot and legacy reasons.

Basically, as soon as you've set up your PCI address space, most peripheral communications are just normal memory accesses.

Often, even, your program would prepare the commands for the I²C controller in a memory region, then tell some DMA controller to transfer that memory to the controller. So, your CPU doesn't even necessarily directly talk to the controller – it tells a DMA controller to tell a say, PCIe controller, to transfer bytes from some memory to a device.

Is the controller mounted on the motherboard? What bus connects the CPU and controller?

Depends; it can be integrated in the same IC package, or be on the motherboard.

If directly integrated in the Southbridge (which in Intel CPU chipsets is called the ICH), then the interface would be the Direct Media Interface; it might also sit in a PCIe device attached to the Southbridge, or in a USB device attached to a USB controller, which again can be part of the southbridge, or part of a PCIe-attached USB controller.

Marcus Müller
  • 88,280
  • 5
  • 131
  • 237
  • "So, instead, there's some peripherals attached to a much, much faster bus (e.g. PCIe) that does the I²C talking, upon receiving commands to do so from the CPU". Is it like `CPU <=> PCIe controller <=> DMA controller <=> I2C controller`? – sherlock Jan 16 '20 at 07:46
  • 4
    no, more like CPU: write to memory regions belonging to the DMA controller; DMA controller, independently: take memory region and move it to the specified address. Oh, specified address belongs to PCIe bus? make the PCIe transfer the data. I²C controller: oh, there's someone sending me data. – Marcus Müller Jan 16 '20 at 08:27
  • 1
    @Holmes.Sherlock: This is called [MMIO (memory-mapped I/O)](https://en.wikipedia.org/wiki/Memory-mapped_I/O). Modern devices still have "registers" that you read or write to configure them or make stuff happen, but they're in physical (memory) address space instead of I/O space, because that's more efficient to access. in/out instructions are slow because of the required serializing semantics. Related: [X86 Address Space Controller?](//superuser.com/q/1226197) – Peter Cordes Jan 16 '20 at 22:35
  • 1
    Which hardware/software component decides the address space a device occupies in the case of MMIO? – sherlock Jan 16 '20 at 23:27
  • 1
    @Holmes.Sherlock surprisingly complex question: Depends on the type of device of device, actually. But for "high level" devices: that's up for configuration after enumeration on the bus they connect to. There's varying degrees of freedom here, and the addresses "seen by the device" might not be the same as "seen by the device driver" – Marcus Müller Jan 16 '20 at 23:30
  • @MarcusMüller could you recommend books or any other resources to learn about this topic? It's very hard to find good content about the communication between the CPU and the I/O devices. Topics such as motherboard chipsets, northbridge, southbridge, MMIO, DMA, bus mastering, busses protocols (PCI, ISA, ...) are never really explored in depth in any PC-architecture book — they usually focus a lot more on the CPU than the rest of the system. I would appreciate a lot if you could give some insight about how one could study about these topics. – felipeek Aug 15 '20 at 04:55
  • @felipeek sorry, no, don't have anything. It was all learn by using the internet long enough and talking to smarter friends while trying to understand what this driver / operating system does. – Marcus Müller Aug 15 '20 at 09:58
  • @MarcusMüller fair enough, thanks! – felipeek Aug 15 '20 at 15:55
14

An Intel Core processor is attached with Direct Media Interface DMI to the Platform Controller Hub PCH.
The PCH contains all peripherals, like PCI, USB, AHCI, Display outputs all the stuff.

But also the SMBus (I2C) interface, which connects all the little sensors together.

The PCH makes these peripherals available in the address space via the DMI. This is a proprietary interface and the PCH is mandatory. So for the concept of an Intel Platform you can consider this an on-chip SMBus controller.

enter image description here (intel 7 gen PCH)

Jeroen3
  • 21,976
  • 36
  • 73
4

i just looked randomly at one datasheet of Intel Processor

[EDIT:] its a on-package Platform Controller Hub (PCH) datasheet

in the introduction: enter image description here

  • and you also might see it sometimes under different name: (SMBus) enter image description here

your question, how it looks like this is really good tutorial that explains it: https://learn.sparkfun.com/tutorials/i2c/all

its just like this: 1 pin for syncing clock between the chips (sent by master of bus) .. 1 pin for data.. (the device who want to send bits on the line will pull it low) the master usually sends address of the chip he wants to talk to, that chip will ack and then the communication happens... other chips are silent :D

the i2c is too slow it will be to talk to chip and get information or configurations.. no data exchange stuff.

Hasan alattar
  • 487
  • 5
  • 16
  • 6
    You've really missed the point: that datasheet is **not** a CPU datasheet! that's an external hub controller. – Marcus Müller Jan 16 '20 at 07:19
  • @MarcusMüller it _is_ the point. The OP asks "What bus connects the CPU and [I2C] controller?" and this is it _"The Platform Controller Hub (PCH) is a family of Intel chipsets, introduced circa 2008. **It is the successor to the Intel Hub Architecture, which used a northbridge and southbridge**"_ - https://en.wikipedia.org/wiki/Platform_Controller_Hub – Bruce Abbott Jan 16 '20 at 08:07
  • 1
    @BruceAbbott first sentence: "looked at a CPU datasheet". Picture: screenshots of an Intel Hub. That this is integrated in the same package as the CPU core doesn't make a difference to interfacing with it from a software side. – Marcus Müller Jan 16 '20 at 08:28
  • in my context i ment the whole package not the core .. so if there are 100 datasheets i just said (i opened random ibe) .. i dont consider my self expert in this field but i thought that my limited knowledge with few searches will help the OP. i still dont think i missed the point though @MarcusMüller – Hasan alattar Jan 16 '20 at 08:49
  • @MarcusMüller: I'm pretty sure the "package" in question is the southbridge, not the CPU. The "northbridge" was integrated into the CPU itself, but I/O like USB and ethernet isn't, at least not in mainstream Sandybridge-family; the CPU itself only has video output from the integrated GPU, memory controller, and DMI / PCIe to talk to the southbridge and PCI / PCIe slots. Low-power stuff like Atom / Silvermont-family might be more aggressively SoC (System On Chip) but I think "400 series" are the chipsets for IceLake, like Z490. So yes, you're totally right; this isn't physically in the CPU. – Peter Cordes Jan 16 '20 at 22:31
  • 1
    @Hasan alattar The PCH is the chipset (usually on your motherboard), not part of the CPU, and usually not even on the same package. If you look at the current Intel PCH datasheet: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7-series-chipset-pch-datasheet.pdf The I2C controller is part of the smbus controller, located at PCI Bus 0:Device 31:Function 3. Software would therefore talk to the i2c controller through a PCI bus. – user1850479 Jan 16 '20 at 23:25
  • aah ok thanks.. @user1850479 – Hasan alattar Jan 17 '20 at 08:21
2

PCs have several I²C controllers. Most prominently those for the DDC and those for the RAM modules' SPD. Sometimes temperature sensors and fan control is also put on I²C buses.

It depends on the board's chipset how to control those I²C buses. Most host adapters are very simple and consist of not much more than a clock generator, a shift register and some logic to create the I²C start and stop conditions. The whole transfer is under software control. Fiddling with control bits inside the board's south bridge chip.

The south bridge chips are incredibly complex and feature a lot of legacy stuff inside. The I²C controller inside may be even connected through an LPC bus inside the chip.

Janka
  • 13,636
  • 1
  • 19
  • 33
  • 1
    SMBus is a superset of I2C. RAM typically uses SMBus not I2C. – Passerby Jan 16 '20 at 06:26
  • Is it like the motherboard's southbridge hosts one or more I2C controllers as well? How does the CPU communicate with those off-chip controllers? Does this communication take place through some standard interface? – sherlock Jan 16 '20 at 06:39
  • @Passerby: SMBus is both a superset and a subset of I²C. It defines some standard transactions on top of I²C, which could then be executed autonomously by a state machine built into hardware. You cannot do all the stunts possible with I²C with it — e.g. address knocking —, and often those SMBus controllers are broken in subtle ways and may lockup if a client chip does not comply in corner cases. – Janka Jan 17 '20 at 00:28
0

I2C is a communication protocol that operates over two wires. Voltage sequencing over those wires communicates between the I2C master (controlled by software) and an I2C slave (perhaps a temperature sensor).

Software does not usually directly manipulate the voltage sequencing of the wires of I2C (that would be called "bit banging"), but instead convinces some intermediate hardware to do the sequencing for it. Software controls the intermediate hardware by performing memory reads and writes to well-known memory addresses that correspond to the hardware's registers. (Some memory addresses point to memory; other memory addresses can point to hardware registers.)

The intermediate hardware ("I2C controller") is directly connected to the I2C bus wires. Its registers could be part of the CPU chip, or could be on another chip that can be controlled by the CPU (perhaps via CPU memory accesses). This depends on how the system was wired together.

The I2C controller registers are written and read to cause I2C communication: One hardware register would be written to configure settings (e.g., data rate); another would be written to send data; another would be read to receive data; another would be read to determine whether communication is complete. Every chip vendor can implement their hardware registers (the meaning of each bit of each addressable register) however they want; this is explained in its data sheet.

The I2C device has its own data sheet on what to say over the I2C bus. It defines the various measurements and controls implemented by the I2C device, and how to communicate them in a bus transaction of bytes over I2C. It also specifies its I2C slave address number (so you can connect multiple slaves to a single bus, yet communicate to a specific one).

Note that many types of I2C devices can be configured (by pulling one or more pins to a high or low voltage) to one of several I2C slave addresses, so you might need to experiment (or get a schematic) to determine the I2C slave address that corresponds to the specific I2C device of interest.

Dirk Helgemo
  • 41
  • 3