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.
Finished reading?
Mark it complete to track your progress through the path.
Go further
AXI, APB, SPI and I2C questions are standard in RTL and DV interviews. Practise them with real scenarios.
Get new lessons by email
New lessons, interview prep and real EDA tool workflows. No spam.