Why Chips Need Protocols
How blocks and chips agree on how to talk
a chip is not one block, it is many: a CPU, memories, and peripherals that all have to exchange data. They can only do that if they agree on a set of rules for who drives what and when. Those rules are protocols, and naming them in an interview (AXI, APB, SPI, I2C, UART) is expected of any RTL or SoC engineer.
A common language
If every block invented its own wiring and timing, nothing would connect. A protocol is a shared agreement: which wires carry address, which carry data, and exactly when each side may drive or sample them. Standard protocols let blocks from different teams, or different companies, plug together.
Two families
| Family | Where it lives | Examples |
|---|---|---|
| On-chip buses | Between blocks inside one chip | AXI, AHB, APB (the AMBA family from ARM) |
| Serial interfaces | Between chips on a board | SPI, I2C, UART |
Master and slave
Almost every protocol has an initiator and a target. The master (or initiator) starts a transaction, a read or a write. The slave (or target) responds. A CPU reading from memory is the master; the memory is the slave. Keep that role split in mind and every protocol gets easier to follow.
What this path covers
You will start with the VALID/READY handshake that underpins modern on-chip buses, then learn APB, AHB, and AXI in order of complexity, and finish with the three serial protocols every embedded and SoC engineer must know: SPI, I2C, and UART.