Transcript NOC
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…)