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?
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?
If so, does the processor treat the controller as a peripheral
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.
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.
i just looked randomly at one datasheet of Intel Processor
[EDIT:] its a on-package Platform Controller Hub (PCH) datasheet
- and you also might see it sometimes under different name: (SMBus)
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.
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.
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.