Get your ASICs and SOCs off the Bus!

Get your ASICs and SOCs off the Bus!

High-Speed I/O Alternatives for Inter-Processor Communications on SOCs

The choice of hardware-interconnection mechanisms among processor blocks in an SOC affects communication performance and silicon cost. The default on-chip communications choice for most ASIC and SOC design teams is the global bus or a bus hierarchy, however this choice automatically incurs many performance and design problems. There are other choices that may be more appropriate for today's nanometer ASIC and SOC designs. These choices match well with communications concepts frequently used by software developers.

For example, message-passing software communications have a natural correspondence to data queues. Message passing can be implemented using other types of hardware such as bus-based hardware with global memory. Similarly, the shared-memory software-communications mode has a natural correspondence to bus-based hardware, but shared-memory protocols can be physically implemented even when no globally accessible physical memory exists.

Flexibility when implementing on-chip communications allows chip designers to implement a spectrum of different task-to-task connections in ways that optimize performance, power, and cost.

This white paper provides short descriptions of the most common hardware mechanisms-buses, direct connections, and data queues-used to interconnect processor cores on ASICs and SOCs. Except where explicitly noted, this paper assumes a one-to-one correspondence between tasks and processors. In fact, multiple tasks can be mapped onto one time-sliced processor and some tasks can be implemented by other non-programmable hardware accelerator blocks.

Processor Buses

A bus is a shared-access hardware mechanism allowing one or more processors to communicate with slave memories and I/O blocks. In the simplest system designs, each slave is accessible only from one bus. The processor that owns that bus also owns the slaves. In bus-based, multiprocessor systems, different processors must arbitrate for the bus, but this is the sole arbitration mechanism. Processors and slaves can have a range of bus-transfer requirements or traffic patterns, based on hardware limitations. For example:

• An 8-bit UART slave device may not allow any 16- or 32-bit transfers (a bus-transfer limitation)
• The processor may maximize performance with cache-line-sized block transfers-16 bytes or more (a traffic-pattern limitation)

Moreover, some transfers may be quite sensitive to latency-the task may not need much data but when it needs data, it needs that data immediately-and others may be more sensitive to bandwidth-the task requires an average sustained bandwidth, but the latency of any one transfer is inconsequential.

Bus design tradeoffs

Bus-centric system designs use a range of strategies to satisfy conflicting goals among the processors, memories, and other devices. Three classes of design decision stand out: