Addressing the System-on-a-Chip Interconnect Woes Through Communication-Based Design

1. Addressing the System-on-a-Chip Interconnect Woes Through Communication-Based Design N. Vinay Krishnan EE249 Class Presentation

2. System-on-Chips • Not as easy as Fish’n’Chips • Formal approach-Platform based Design • Orthogonalization of concerns • Keep the computation of the IP cores distinct from the communication between them • Helpful for re-use of the core designs

3. Communication Design Woes • Predictability • Reduce design iterations • Wiring Delay • Signals taking multiple clock cycles to reach • Increasing Power Dissipation of Interconnect • Diverse Interconnect Architectures • More blocks to connect. More worries

4. Addressing the Woes • Design has to begin at a higher layer of abstraction than the RTL level • Paper introduces the idea – Adopt the OSI Standard! • Called Network-On-Chip methodology

5. OSI Model – An overview • Physical • Signal voltages, bus widths, pulse shape • Data Link • Arbitration, MAC • Network • Packet routing • Transport • Segmentation, flow control

6. OSI Model-An Overview-2 • Session • End-to-End connections • Presentation • Data format conversion • Application • Application

7. NOC E.g.-Pleiades Platform

8. Pleiades Platform-Maia Processor • Heterogeneous collection of logic units, like ALU’s, memories, processors, called satellites • Connected to each other and main controller using a reconfigurable interconnect • Asynchronous communication • Reduced swing signaling (LVDS)

9. Metropolis Approach • Communication design as the declaration of a set of constraints • Communication and computation independently formulated constraints • Adapters introduced to overcome constraints mismatches

10. Metropolis Adapters • Behavioural Adapters for Segmenting and Bit Rate matching • Channel Adapters for matching delay, throughput, reliability, etc…

11. Metropolis e.g.-Intercom • Embedded Microprocessor and custom logic connected through a chip-wide silicon backplane • Cadence VCC Design environment used • Models system components as a network of asynchronously communicating finite state machines

12. Intercom-2 • Behavioral adapters used :- • Packet segmenting to break voice stream • MAC TDMA-Round Robin token passing • Channel Adapters used :- • Memory mapped addressing scheme. • Buffer to queue data sending

13. MESCAL • Seeks to provide tools to formally specify protocol stacks for on-chip communication architectures • Ptolemy modeling environment used to provide high level description language of the Stack model

14. Family of Architectures • A MESCAL communication architecture can be described with a graph • Vertices are Communicators (PEs, memories, I/Os) • Edges are Communication Channels PE PE PE PE External I/O External Memory PE PE On-Chip Memory

15. Communicators • A Communicator is a system component paired with a Communication Assist (CA) Co-Processor • The CA can range in complexity from a simple FSM to a fully programmable processor Cache Communication Assist Local Memory Comm Channels PE

16. Communication Assists • A Communicator may also be a CA by itself • This is useful for building: • Bridges between communications channels • Programmable switch nodes Multiple Channel Implementations Data Table Communication Assist

17. Session Transport Network Data Link Physical Communication Assists • The CA provides an interface between the system component and one or more communication channels • OSI stack model: • Programmer’s model interface • Network protocols SW • Queues, buffers, arbitration • Channel electrical interfaces HW • The CA provides the minimum set of features necessary to utilize the communication channels

18. Communication Assists • Lower levels designed in hardware to suit architecture of application • Programmable higher levels can be changed to suit later modifications to application (programmable platforms, here we come…)