Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Addressing the System-on-a-Chip Interconnect Woes Through Communication-Based Design N. Vinay Krishnan EE249 Class Presentation 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 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 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 OSI Model – An overview Physical Signal voltages, bus widths, pulse shape Data Link Arbitration, MAC Network Packet routing Transport Segmentation, flow control OSI Model-An Overview-2 Session End-to-End connections Presentation Data format conversion Application Application NOC E.g.-Pleiades Platform 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) Metropolis Approach Communication design as the declaration of a set of constraints Communication and computation independently formulated constraints Adapters introduced to overcome constraints mismatches Metropolis Adapters Behavioural Adapters for Segmenting and Bit Rate matching Channel Adapters for matching delay, throughput, reliability, etc… 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 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 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 Family of Architectures A MESCAL communication architecture can be described with a graph Vertices are Communicators (PEs, memories, I/Os) Edges are Communication Channels External I/O External Memory PE PE PE PE PE PE On-Chip Memory 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 Local Memory Cache Communication Assist PE Comm Channels Communication Assists A Communicator may also be a CA by itself This is useful for building: Bridges between communications channels Programmable switch nodes Data Table Communication Assist Multiple Channel Implementations Communication Assists The CA provides an interface between the system component and one or more communication channels Session OSI stack model: Programmer’s model interface Transport SW Network protocols Network Data Link Physical HW Queues, buffers, arbitration Channel electrical interfaces The CA provides the minimum set of features necessary to utilize the communication channels 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…)