Networks on Chips A Synthesis Perspective

Networks on Chips:A Synthesis Perspective F.Angiolini,P.Meloni,D.Bertozzi,L.Benini,S.Carta,L.Raffopublished inParallel Computing:Current&Future Issues of High-End Computing,Proceedings of the International Conference ParCo2005,G.R.Joubert,W.E.Nagel,F.J.Peters,O.Plata,P.Tirado,E.Zapata (Editors),John von Neumann Institute for Computing,J¨ulich,NIC Series,Vol.33,ISBN3-00-017352-8,pp.745-752,2006.c 2006by John von Neumann Institute for ComputingPermission to make digital or hard copies of portions of this work for personal or classroom use is granted provided that the copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on thefirst page.To copy otherwise requires prior specific permission by the publisher mentioned above.http://www.fz-juelich.de/nic-series/volume33745Networks on Chips:A Synthesis PerspectiveFederico Angiolini a,Paolo Meloni b,Davide Bertozzi c,Luca Benini a,Salvatore Carta d,LuigiRaffo ba Dipartimento di Elettronica,Informatica e Sistemistica,University of Bologna,40136Bologna, Italyb Dipartimento di Ingegneria Elettrica ed Elettronica,University of Cagliari,09123Cagliari,Italyc Dipartimento di Ingegneria,University of Ferrara,44100Ferrara,Italyd Dipartimento di Matematicae Informatica,University of Cagliari,09123Cagliari,ItalyTo face increasing requirements for computational density in embedded chips,MultiProcessor Systems-on-Chip(MPSoCs)are being widely deployed.This evolution increases communication re-quirements,therefore new,more scalable,on-chip interconnect fabrics are being called works-on-Chip(NoCs)appear to solve the upcoming scalability issue.However,it is presently unclear how exactly NoCs can position themselves in terms of performance/area tradeoff.Since NoCs are supposed to span across the whole chip area,difficult questions associated to chip layout arise.Specifically,the delay impact of long-range wiring resources is unknown,and the delay estimation provided by synthesis tools must be verified against post-placementfigures.This paper will address such question marks,by showing a complete NoC synthesisflow going down to the layout level.The experimental results include assessment of a complete placed NoC instance and analysis of single switches when synthesized in varying configurations.1.IntroductionThe ever increasing System-on-Chip(SoC)integration is calling for a huge increase in intra-chip communication resources.The traditional SoC interconnect fabric leverages upon a single shared bus;this approach is quickly becoming insufficient to cope with current and future requirements. More complex and better performing architectures,namely crossbars,are being studied and de-ployed,but they are inherently non-scalable due to wiring congestion.This fact dictates the need for a more radical departure from the common notion of a monolithic communication fabric featuring afixed topology.Instead,packet-switched networks,such as the Internet,spring to mind for their efficiency and inherent scalability.The transfer of the packet-switching concept to the on-die realm takes the name of Network-on-Chip(NoC).NoCs provide aflexible path toward complex fabric topologies with abundant amounts of available bandwidth.SoC architectures exhibit a highly heterogeneous nature,and industry trends point at the integra-tion of an increasing number of different functional blocks on the same die.Therefore,homogeneous or preconfigured NoCs look like an inefficient solution to the interconnect scalability problem.This observation calls for the creation of a library of highly parameterizable NoC components,enabling the designer to instantiate a NoC architecture custom-tailored to specific applications and usage needs.The configurability of such“soft macros”however must be provided without incurring in any noticeable performance overhead.While undertaking the effort of developing such building blocks,it is of course crucial to assess the performance,area and power targets of the whole NoC instance.This task is not trivial,also746due to the unknown wiring overhead after performing thefinal chip placement and routing.Such overhead is clearly critical in a distributed component spanning the whole chip area.Thus,a key design principle must be a strict control of wiring resources,so that they do not span across long distances on the die.This can be achieved e.g.by link pipelining through clocked repeaters.In any case,it is essential to be able to carry the design through all stages of physical synthesis before being able to properly estimate critical factors such as maximum achievable clock frequency.The presently available industrial and academic literature is lacking thorough examples of this analysis.This work will discuss the above key topic by presenting synthesis results for×pipes,a library of fully synthesizable,highly customizable,high frequency and low latency NoC modules.By leverag-ing upon aflexible custom-built CAD toolchain,we enabled a completeflow where the×pipes com-ponents were deployed in a NoC topology interconnecting functional IP cores.This topology,which is fully simulatable to assess architectural efficiency,was then synthesized in a0.13µm technology, andfinally placed and routed.The last step allowed us to get reliablefigures about critical parame-ters such as frequency and area of the NoC.In this work,we will mostly focus on the description of a complete topology instantiation and on the area/delay issues of wiring resources.A thorough power consumption analysis,while possible in the framework that we will describe,requires additional research to identify appropriate traffic patterns for the modeling of an entire topology and of single building blocks,and is therefore left for future work.This paper is organized as follows.Section2will discuss the state of the art in NoC implemen-tations.Section3will describe the component blocks of the NoC we developed and synthesized. Section4will describe the synthesis steps and related issues,while Section5will show experimental results.Finally,Section6will draw conclusions.2.Related WorkTo face the interconnect scalability bottleneck,NoCs have been suggested as an effective long-term solution[8],[3].In recent years,an increasingly large body of research has bloomed around this subject,focusing for example on complete architectures[11],flow control protocols[13],Quality of Service(QoS)provisions[6],[16],support CAD tools[4],asynchronous implementations[5]. While these issues are critical,they are often discussed without a complete analysis of the area and delay implications when carrying such designs onto a real chip.Work focused on the synthesis stage of the NoCflow exists.For example,a test chip,mostly focused on electrical properties and power consumption,is mentioned in[12],while fully placed designs are presented in[14],[2]. However,neither of them proposes a completely configurable library of parameterizable building blocks,neither presents wide spectrum architectural exploration results,and all rely on some full custom blocks to achieve higher performance.For some NoCs[17],FPGA mappings are described in the literature.However,these attempts help shedding light only up to a certain extent,due to the huge unpredictability of the FPGA synthesis results across different device families and vendors. Moreover,physical delay issues get masked by the architecture of the specific FPGA chip at hand.We build on our previous work[7],[15]to further illustrate a fully parametric NoC library,car-rying its implementation to the layout level.While still being able to explore architectural design tradeoffs thanks to the completely synthetic nature of theflow,this step makes it possible to evaluate important design assumptions,such as wire predictability and scalability.747 3.×pipes Architectural Blocks×pipes is a highly configurable,high performance NoC.One of its most prominent features is the ability to be deployed in different topologies and with different design parameters,thus matching the requirements of any specific target application.To achieve this objective,×pipes is based upon a library of components;it is the system designer’s responsibility to pick up,configure and connect the proper blocks to create the complete interconnect fabric,of course assisted by CAD tools.The ×pipes library contains three main components:switches,Network Interfaces(NIs)and links. Switches constitute the backbone of the NoC,as they route packets from sources to destinations. They can be connected in aflexible manner,according to the designer’s preference,thus resulting in arbitrary fabric topologies.Switches provide buffering resources to improve performance;in×pipes, output buffering was chosen,i.e.FIFOs are present on each output port.Moreover,switches handle flow control issues,and resolve conflicts among packets when they overlap in requesting access to the same physical links.NIs take care of the task of converting processor transaction requests into packets,and of the dual process of transaction unpacketing.Therefore,an NI is needed to connect each IP core to the NoC.Further,each packet is split by the NIs into a sequence of“flits”(FLow control unITS) before transmission,to decrease the physical wire parallelism requirements.In×pipes,two separate NIs are defined,an initiator and a target one,respectively associated to system masters and system slaves.In case of a device requiring both interfaces,an NI of each type must be attached to it.The interface among IP cores and NIs is defined by the OCP2.0[1]specification,for maximum reuse capability.NIs also take care of specifying the path that packets will follow in the network to reach their destination(source routing),by means of path Look-Up Tables(LUTs).NIs provide dual clock capability,in that two different clock signals can be attached to it:one is driving the NI front-end(the OCP interface),the other is driving the NI back-end(the×pipes interface).These clocks have to be in an integer multiple relationship with one another,the OCP clock being slower.This arrangement allows the NoC fabric to run at a fast clock even though some or all of the attached IP cores are slower,which is crucial to keep transaction latency low.Also,each IP core can run at a different divider of the×pipes frequency,therefore making mixed-clock platforms possible.Inter-block links are a critical component of NoCs,especially when taking into account technol-ogy trends.Since links can span across the whole die or significant portions thereof,the problem of signal propagation delay is critical.For this reason,×pipes supports link pipelining,i.e.the interleaving of logical buffers along links.Properflow control protocols are implemented in link transmitters and receivers,i.e.within NIs and switches,to make the link latency transparent to the surrounding logic.By means of this design choice,the overall platform can run at a fast clock fre-quency,without the longest wires being a global speed limiter.Instead,only the links which are too long for single-cycle propagation will pay a latency penalty.A custom CAD tool,called×pipesCompiler,allows the designer to instantiate and configure ×pipes library components tofit his or her application needs.By means of a simple specification textfile(which may be generated as the output of an additional external tool),components can be attached to each other in arbitrary topologies,and routing tables can be freely set.The NoCflow control policy can be chosen among a simple single-token credit-based one(called STALL/GO),and a retransmission-enabled one(called ACK/NACK),which provides some of the facilities required for more thorough fault tolerance.Theflit width can be set to arbitrary values.Additionally,switches can be customized in terms of I/O ports,buffering resources and arbitration policies,while network interfaces in terms of buffering resources and clock dividers.7484.Toward Chip LayoutOne of the aims of the×pipes NoC infrastructure is devising a complete designflow,letting the designer configure,simulate,synthesize and verify an MPSoC instance.For this paper,we willstages.especially focus on the portions of thisflow which pertain to the synthesis and place&route Array Figure1.The×pipes designflowFigure1is showing a high-level view of the complete process of instantiating a NoC platform. The main inputs of theflow are the×pipes component library,written in SystemC,and a text for-mat topology specification.The×pipesCompiler tool processes these sources to generate a SystemC instance,which is suitable both for architectural simulation and for synthesis.When the synthesis path is taken,a SystemC-to-HDL automatic translation is performed.Three major outputs are the result:the HDL code for traffic generators,for the NoC building blocks,and for the top level in-stantiation code.The latter two are synthesized with Synopsys Design Compiler[10].During this stage,a technology library is required;for this paper,we used a0.13µm library.No full custom blocks are employed in the process,even though they would lead to better performance,to illustrate the results achievable with a completely synthetic,and therefore maximallyflexible,approach.The resulting netlists now need to be placed and routed,which is done in two steps by Cadence SoC Encounter[9].First,each building block is processed;subsequently,blocks are connected together according to the top level module specifications,and thefinal optimizations are made.Thefinal output is a placed&routed topology,which is suitable for further area and delay analysis and for ver-ification.By back annotation of parasitic capacitances,powerfigures could be extracted,but such analysis is beyond the scope of this paper.5.Experimental ResultsFigure2(b)depicts a sample NoCfloorplan resulting from the previously describedflow.For this paper,we chose a5x3regular mesh(Figure2(a)),which interconnects30IP cores(15masters and749(a)(b)Figure2.Topology(a)andfloorplan(b)of a5x3×pipes mesh15slaves).Each of these cores is supposed to be square and obstructing an area of1mm2,which is reasonable for embedded cores and/or32kB SRAM banks at the0.13µm node.Synthesis was car-ried on by leveraging a UMC0.13µm technology library,which does not have extreme performance as its focus,but for which obstruction information was available to us in the place&route phase.Our test topology comprises30NIs,equally split among initiators and targets,and15switches,of which three having6input and6output ports(those in the center of the mesh),eight5x5(at the sides),and four4x4(in the corners).Each switch is connected to one initiator and one target NI.The mesh is configured with38-bitflits,3-flit buffering FIFOs,fixed priority arbitration,the ACK/NACKflow control protocol,and non-pipelined links.Experimental results for this topology are reported in Fig-ure3at varying frequency targets.As can be seen,even when pushed to the performance limits,the NoC cells do not require more than7%of the overall die area.At a lower frequency target of500 MHz,NoC cells take5.7%of the chip real estate.However,wiring resources and the need to reserve some slack space for the global nets(e.g.the clock tree)cause the baseline area of30mm2(30IP cores of1mm2each)to stretch to a global area of42to44mm2.We would like to mention that wework.did not perform any specific area optimization in this ArrayFigure3.Area of a5x3×pipes mesh synthesized with different frequency targetsAn importantfigure to notice here is the degree of divergence among delay estimations based upon the netlist and upon the placed topology.When aiming for maximum frequency,the netlist was estimated to be capable of running at910MHz;after the place&route stage,the real achievable frequency was845MHz,which translates into a decrease of just8%.Moreover,the critical path was within the NoC logic(namely,the6x6switches),and not on the global wires,which even allowed us to deploy non-pipelined links among the NoC blocks.Thesefindings confirm the effectiveness of NoCs in downplaying global wires as performance limiters.Figure4analyzes the behaviour of switch components when synthesized with varying configura-750tion parameters.We will explore the configuration space independently for each parameter,keeping as a baseline a6x6,38-bit switch having a3-flit buffer depth and usingfixed priority arbitration and ACK/NACKflow control.All instances have been synthesized,placed and eventually routed to providefigures as accurate as possible.Figures4(a)and4(b)show trends when varying the amount of I/O ports;since the bulk of the switch logic and buffering in×pipes is associated with output ports,which is compounded by a mild dependence on inputs,the area scales up a bit more than linearly with the amount of output ports. Increasing numbers of input ports make arbitration and multiplexing more complex,which results in a10%worse frequency when moving from four to six inputs.Figures4(c)and4(d)depict performance when varying theflit width of packets.When moving from16to38bits(which is an optimalflit size for performance once the decomposition of packets intoflits is taken into account),a huge area penalty of64%can be observed.Such penalty is however weakly proportional toflit width,which increased by138%.This result is logical,since the area for the datapath(including buffers)has to scale linearly withflit width,but arbitration and control logic are unaffected.The maximum operating frequency is also almost unaffected byflit width,which suggests the worsening of wiring congestion to be not critical.The impact of buffering is investigated in Figures4(e)and4(f).Since buffering resources repre-sent a significant percentage of the component area,doubling the buffer depth results in a noticeable 54%area penalty.Also,due to the FIFO nature of the buffers,increased logic and wiring complexity impacts maximum frequency by as much as52MHz(around6%).Implementing a fair round-robin arbitration policy instead of the baselinefixed priority one incurs a noticeable cost.Additional logic to track the status of input ports results in15%worse area and maximum operating frequency(Figures4(g)and4(h)).The choice offlow control protocols impacts the performance of the NoC also with respect to performance of the single building blocks.We tested with two alternative protocols,namely ACK/NACK(which features retransmission capabilities,and is suitable for fault-tolerant environ-ments)and STALL/GO(which is a variant of credit-based schemes where only one credit is avail-able,thus allowing for a pipelined link implementation).The×pipes architecture natively exhibits output buffering,and is therefore more suitable to the ACK/NACK protocol.When deploying STALL/GO logic,additional input buffering had to be added;albeit minimal,this incurred a52% area overhead and a5%lower frequency(Figures4(i)and4(j)).6.Conclusions and Future WorkIn this paper,we showed a complete NoC synthesisflow leading to chip layout.Synthesis results highlight the relationship among design parameters andfinal performance,helping the designer to choose the best tradeoffs.As an example,for the×pipes architecture,to achieve maximum perfor-mance if area is not a concern,increasing theflit widthfirst is better than adding buffers,since it has a much lower frequency penalty.The place&route phase is essential to validate the proposedflow and to check design assumptions. Despite of the distributed nature of NoC fabrics,post-place&route synthesisfigures do not show a significant delay degradation with respect to netlist estimates,and critical paths are within the building blocks.When considering that traditional interconnects are limited by global wire delay already at the current lithographic nodes,these twofindings strengthen the positioning of NoCs as a highly scalable,highly predictable interconnect fabric for future technologies.Future work revolves around architectural optimizations,a thorough power consumption analysis and the investigation of the performance impact of the usage of full custom logic blocks.751 References[1]Open Core Protocol Specification,Release2.0,,2003.[2]Adrijean Andriahantenaina and Alain Greiner.Micro-network for SoC:Implementation of a32-portspin network.In The Proceedings of Design,Automation and Test in Europe Conference and Exhibition, pages1128–1129.IEEE,2003.[3]Luca Benini and Giovanni De works on chips:A new SoC paradigm.IEEE Computer,35(1):70–78,January2002.[4]Davide Bertozzi,Antoine Jalabert,Srinivasan Murali,Rutuparna R.Tamhankar,Stergios Stergiou,LucaBenini,and Giovanni De Micheli.NoC synthesisflow for customized domain specific multiprocessor systems-on-chip.IEEE Transactions on Parallel and Distributed Systems,16,Issue2:113–129,Febru-ary2005.[5]Tobias Bjerregaard and Jens Sparsø.Scheduling discipline for latency and bandwidth guarantees in asyn-chronous network-on-chip.In Proceedings of the11th IEEE International Symposium on Asynchronous Circuits and Systems(ASYNC),pages34–43,2005.[6]Evgeny Bolotin,Israel Cidon,Ran Ginosar,and Avinoam Kolodny.QNoC:QoS architecture and designprocess for network on chip.In Journal of Systems Architecture.Elsevier,2004.[7]Matteo Dall’Osso,Gianluca Biccari,Luca Giovannini,Davide Bertozzi,and Luca Benini.×pipes:Alatency insensitive parameterized Network-on-Chip architecture for multi-processor SoCs.In Proceed-ings of21st International Conference on Computer Design,pages536–539.IEEE Computer Society, 2003.[8]William J.Dally and Brian Towles.Route packets,not wires:On-chip interconnection networks.InProceedings of the38th Design Automation Conference,pages684–689,June2001.[9]Cadence Design Systems Inc.SoC Encounter,.[10]Synopsys Inc.Design Compiler,.[11]Faraydon Karim,Anh Nguyen,Sujit Dey,and Ramesh Rao.On-chip communication architecture forOC-768network processors.In Proceedings of the Design Automation Conference(DAC),pages678–683,2001.[12]Kangmin Lee,Se-Joong Lee,Sung-Eun Kim,Hye-Mi Choi,Donghyun Kim,Sunyoung Kim,Min-WukLee,and Hoi-Jun Yoo.A51mW1.6GHz on-chip network for low-power heterogeneous SoC platform.In Digest of Technical Papers of the2004IEEE International Solid-State Circuits Conference(ISSC), pages152–518.IEEE Computer Society,2004.[13]Antonio Pullini,Federico Angiolini,Davide Bertozzi,and Luca Benini.Fault tolerance overhead innetwork-on-chipflow control schemes.In Proceedings of the SBCCI Conference2005(to be published), 2005.[14]Andrei Radulescu,John Dielissen,Kees Goossens,Edwin Rijpkema,and Paul Wielage.An efficienton-chip network interface offering guaranteed services,shared-memory abstraction,andflexible net-work configuration.In Proceedings of the2004Design,Automation and Test in Europe Conference (DATE’04).IEEE,2004.[15]Stergios Stergiou,Federico Angiolini,Salvatore Carta,Luigi Raffo,Davide Bertozzi,and Giovanni DeMicheli.×pipes Lite:A synthesis oriented design library for networks on chips.In Proceedings of Design,Automation and Testing in Europe Conference2005(DATE05),pages1188–1193.IEEE,March 2005.[16]Daniel Wiklund and Dake Liu.SoCBUS:Switched network on chip for hard real time embedded sys-tems.In Proceedings of the International Parallel and Distributed Processing Symposium(IPDPS03).IEEE,2003.[17]Cesar Albenes Zeferino and Altamiro Amadeu Susin.SoCIN:A parametric and scalable network-on-chip.In Proceedings of the16th Symposium on Integrated Circuits and Systems Design(SBCCI03), pages34–43,2003.(a)(b)(c)(d)(e)(f)(g)(h)(i)(j)Figure4.Area and max frequency of×pipes switches configured with varying parameters:number of ports(a-b),flit width(c-d),buffering(e-f),arbitration policy(g-h),flow control protocol(i-j) 752。