ARK: Architecture for Security Resiliency in SoCDesigns with NetworK-on-Chip (NoC) Fabrics

Atul Prasad Deb Nath, Srivalli Boddupalli, Swarup Bhunia, Sandip RayDepartment of Electrical and Computer Engineering

University of FloridaGainesville, FL 32611. USA.

atulprasad@ufl.edu, bodsrivalli12@ufl.edu, swarup@ece.ufl.edu, sandip@ece.ufl.edu

Abstract—Modern SoC designs typically include hundreds ofpre-designed and pre-verified intellectual property (IP) coresthat communicate over a variety of Network-on-Chip (NoC)fabrics. Unfortunately, neither IPs nor the NoC fabrics can befully trusted. We address this problem through a novel SoCsecurity architecture for system resiliency even when developedby integration of untrusted components. We focus specifically onvulnerabilities and exploits that target system-level communica-tion among IPs through the NoC. We develop fine-grained policiesthat enable on-the-fly detection and mitigation of suspiciousrun-time activity that affect the system-level functionality. Ourexperiments show that the architecture incurs modest overheadin area, power, and congestion.

I. INTRODUCTION

System-on-Chip (SoC) designs enable realization of com-plete system functionality on a single Integrated Circuit (IC)through integration and coordination of pre-designed and pre-verified hardware design blocks in the form of intellectualproperty (IP) cores. They pervade a diversity of applica-tions, including automotive systems, wearables, implants, andInternet-of-Things. Modern SoC designs typically include hun-dreds of IPs, that communicate over a variety of Network-on-Chip (NoC) fabrics. Unfortunately, neither individual IPs northe NoC fabrics can be fully trusted. Errors and vulnerabilities,whether inadvertent or maliciously introduced, can escapevalidation to production and deployment; they can be exploitedin field to subvert the overall SoC communication and ul-timately compromise the entire system. On the other hand,the diversity of attack scenarios (e.g., rogue hardware andfirmware, malicious applications, even “innocent” optimiza-tions) and the aggressive time-to-market schedules make itinfeasible to substantially exercise these vulnerabilities duringsecurity validation. There is a critical need to develop novelSoC architecture that can ensure trusted SoC operation inpresence of untrusted IPs and NoC fabrics.

In this paper, we focus on a key component of the problem,e.g., how to ensure resiliency of the inter-IP communications,in the presence of potentially malicious or compromised IPs.We introduce a security architecture to ensure that a maliciousIP cannot subvert the communication and coordination of theentire system. We develop an adversary taxonomy covering

DISTRIBUTION STATEMENT A. Approved for public release: distribu-tion is unlimited.

common subversion models for NoC, and show how the ar-chitecture provides protection and resilience under reasonabletrust models. To our knowledge, our work provides the firstsystematic approach to an architecture for ensuring resilienceagainst communication attacks in SoC designs.

Our approach is inspired by previous research [1], [2], [3] onimplementing SoC security policies. That work introduced aan architectural framework called E-IIPS, which included (1)a centralized IP block named SPE (Security Policy Engine)to implement the security constraints to be enforced by thepolicies, and (2) smart wrappers for SPE to communicatewith the individual IPs and monitor any violation of thepolicy constraints. It was demonstrated to be effective inthe implementation of diverse security policies. However, thisarchitecture relied on the fidelity of communication betweenthe wrappers and SPE, and cannot be used to protect thesystem against attacks that tamper message communicationsamong IPs. The major contribution of this paper is to show(1) how to ensure resilience against communication attacksthrough a collection of fine-grained system-level securitypolicies, and (2) how to implement such fine-grained policiesthrough a centralized security policy engine even in the contextof untrusted communication.

II. BACKGROUND

A. SoC Security Policies

Security policies specify protection requirements of assets,i.e., sensitive data or information in SoC designs. Such as-sets include cryptographic keys, defeature bits, manufacturerfirmware, sensitive end-user information, etc. These assets areusually sprinkled across the entire SoC over various IP blocks.Following are two representative policy examples.

• Example 1 : At system boot phase, the data transmittedby the crypto blocks cannot be snooped by any other SoCcomponent other than the target IP.

• Example 2 : Secure key containers in the SoC platformare allowed to be updated during silicon validation phase;no updates are allowed after production.

There are three crucial components in a security policy: (1)how to protect an asset; (2) from whom to protect; and (3)when to protect. Policy requirements vary significantly based

88

on the state-of-execution (e.g., normal operation, boot mode,crypto mode, etc.) and stage of development in SoC life-cycle.

B. E-IIPS Architecture

The E-IIPS architecture [1], [2], [3] is an architecturalframework developed for implementing SoC security policies.It includes a central “security policy engine” (SPE) and smartsecurity wrappers implemented around each IP. The securitywrappers detect security critical events at individual IPs andare responsible for communication with SPE. SPE monitorsthe security state of the SoC at system execution time andenforces the policy restrictions upon notification of securitycritical events by the wrappers.

The E-IIPS architecture was used to implement diverse SoCsecurity policies. However, a key limitation of the architecturewas the reliance on the fidelity of communication betweenthe wrappers and SPE: the architecture operated correctly onlyunder the condition that the events transmitted by the wrappersat any time were delivered to SPE without tamper and within ashort communication latency. To enforce this requirement, E-IIPS was targeted for SoC designs with crossbar or bus-basedinter-IP communication: on-chip networks were not consid-ered. On the other hand, communication is a critical target ofattack in modern SoC designs; furthermore, they are difficult todetect during security validation as they might involve subtleand complex interleaving of inter-IP messages that are difficultto exercise. Our work shows how to achieve system-levelresiliency in the presence of untrusted communication.

III. TAXONOMY OF ATTACKS ON NOC

In order to systematically study resilience questions againsta category of security attacks, it is critical to first comprehendthe scope and diversity of these attacks. Unfortunately, nosuch classification exists for communication attacks on NoCfabrics. Consequently, we developed a taxonomy of attacks onsystem-level communication that covers threats arising frommultifarious sources. Fig. 1 shows our taxonomy. While notcomprehensive, it covers the broad range of communicationvulnerabilities considered in today’s industrial practice. At-tacks are classified broadly into two categories based on (i)attack surfaces and (ii) action characteristics. These categoriesare further expanded in accordance to attack locations, attackmediums, attack payloads, etc. Note that a given attack canlead to more than one kind of system-level impact.

IV. SECURITY REQUIREMENTS FOR NOC-BASED SOCDESIGNS

Based on the system-level impact, security properties ofsystem level communication in NoC-based SoC designs canbe broadly categorized as follows:

1) Misdirection prevention: An unauthorized IP should notbe able to act as a diverter, i.e., misdirect the messagesfrom their original destinations in the NoC fabric.

2) Masquerade prevention: An unauthorized IP should notbe able to act as a masquerader, i.e., disguise itself asa different (trusted) IP.

Fig. 1. Taxonomy of Attacks on NoC

3) Message immutability: An unauthorized IP should not beable to act as a modifier, i.e., alter the messages passingthrough on-chip network.

4) Non-observability: An unauthorized IP should notbe able to act as a active/passive reader andsnoop/read/collect messages illegally through the on-chip network.

Note that the above categorization of NoC security re-quirements is based on the the impact on the NoC of po-tentially malicious activity. Furthermore, collusion among un-trusted/compromised IPs can lead to attack instances causingsecurity violations in multiple categories.

V. RESILIENT ARCHITECTURE FOR UNTRUSTED IPS

A. Trust model

For this paper, the trust model assumes a trusted SoCintegration house that procures 3PIPs from multiple vendorswith a varying level of trust. Table I shows our assumptionsregarding the presence of untrusted IPs and their interactionwith other on-chip components. For instance, a 3PIP mighthave a hardware Trojan located at strategic locations likecontrol logic, data-path, the storage section, etc. or executemalicious firmware/software. However, we consider the IPtest and debug wrappers to be trustworthy. To realize thisassumption, we have developed a standardized security wrap-per architecture by augmenting the IEEE P1500 test wrappersand the ARM R©CoresightTMdebug wrappers which have a

89

TABLE ITRUST MODEL OF THE PROPOSED FRAMEWORK

IP core and NoC Fabric Test and Debug Wrapper Satellite Units at IPs/Routers Satellite Unit to SPE Comm. SPE Interacting IP

Trust assumptions Untrusted Trusted Trusted Trusted Trusted Trusted

Fig. 2. A high-level overview of proposed security architecture in a tiled manycore SoC design with on-chip network (a mesh topology network is shownin the figure to illustrate the compatibility and scalability of our architecturewith complex SoC designs).

standardized and highly validated infrastructure. On the otherhand, we account for collusion among the untrusted IPs. Forinstance, we consider scenarios where a malicious IP launchesattacks with cooperation of a compromised NoC component.

B. Architectural Components

Fig. 2 provides a high-level overview of our framework. Ourarchitecture involves two major components: (1) a SatelliteUnit at each IP and router of the SoC platform to monitorsecurity critical events, establish a standardized communi-cation among the IPs, routers and security policy engine,and assert appropriate security controls; and (2) a centralizedSecurity Policy Engine (SPE) connected to the NoC fabric asan infrastructure IP for system-level security monitoring.

Satellite Units. We implement satellite units at each IP androuter block. They are designed with smart security wrappers,interface action detection logic, and frame-based interfacefor communication with centralized SPE. These units mon-itor security critical events of interest, send triggered eventinformation to the central SPE, and enforce security policyrestrictions in co-ordination with SPE.

Detection of Critical Interface Actions. Our goal is toprevent the propagation of malicious activity through the NoCthat could result in system-level impact. The interface actiondetection logic monitors for critical communication events.On detection of a triggered event, the current transaction isstalled and the event information is sent to the SPE. To avoidpotential bottleneck due to traffic congestion, the logics areconfigured to detect and verify a specific set of security criticalevents based on the IP type and attempted transactions. Weclassify IP interface signals into four basic types (e.g., control,

data, global, and test signals), and design the trigger logics tomonitor the control and data signals of the output interface.

Communication with SPE. The micro-architectural events aremonitored, analyzed, and stored by the smart security wrap-pers. The communication interface of satellite units generatesframe-based packets with security-critical event meta-data forIP-specific temporal events and critical actions detected by theactivity detection circuitry. The frame-based interface facili-tates a standardized communication for sending data packetsover the NoC. To enable portability of event detection logicfor multiple IPs, satellite units include configuration registerswhich are configured at boot-time by the SPE.

SPE Architecture and Policy Implementation. A primarybuilding block of our resilience architecture is a centralized“security brain”, i.e., a single IP called security policy engine(SPE) which enforces all system-level security policies. We de-velop fine-grained policies that enable on-the-fly detection andmitigation of suspicious run-time NoC communications thatmay affect the system-level functionality. SPE is developedfrom the ground up to implement, adapt, modify, and upgradediverse system-level security policies. SPE is connected to theNoC fabric as an infrastructure IP and interfaced with the NoCcomponents (routers and links) to adhere to on-chip-networkprotocol. The key functionality of SPE is to analyze thepackets sent by the satellite units, enforce security policies bysending control signals as standardized frame-based packets,and update the security state of the overall system. In ourframework, the policy engine is designed as a micro-controlledsoft IP that asserts appropriate security controls through a well-defined state machine. The policy engine module incorporatesprogrammable configuration registers to allow SoC designerstailor specific set of policies in accordance to security require-ments.

C. Implementing NoC Security Resilience through Policies

Given the architecture above, we can implement resilienceagainst malicious NoC communication through a collection offine-grained security policies implemented in SPE. Below wego through an illustrative implementation.

Non-observability and Misdirection prevention. Followingare two typical requirements of non-observability and misdi-rection prevention.

• Representative Policy 1: Untrusted IPs are prohibitedfrom exploiting Direct Memory Access (DMA) to securememory range.

• Representative Policy 2: The routing units of untrustedNoC routers are subject to update only at secure boot orat run-time by a trusted IP.

90

Fig. 3. Message flow diagram of proposed solution for resilient and trust-worthy SoC operation in use case scenarios of non-observability and messagemisdirection.

1) Attack Model: Recall from non-observability require-ments that untrusted IPs should not be able to observe in-formation intended for other SoC components. We considera malicious IP attempting to violate non-observability in twoways. It can attempt to read from the protected memory regionof on-chip memory or it can misdirect data packets to itselfor to an illegal destination through a compromised router. Inthis scenario, we assume the presence of a malicious processorIP that can initiate an illegal DMA read request to the securememory region or alter the router configuration to misdirectdata packets to illegal destinations including itself.

2) Flow of operation: Fig. 3 shows the flow of events fora security policy to protect against the attack.

• During boot phase, the wrappers and interface action de-tectors at satellite units of IPs and routers are programmedby the SPE for event detection. Events include triggers formicro-architectural flows, e.g., value of program counterwithin secure memory address range, read access tosecure data memory, incoming flit to valid channel queue,flit register content update, allocation to proper virtualchannel, etc.

• When a DMA transfer request is detected by the interfaceaction detectors at the DMA table corresponding to theuntrusted IP, the request address and access type isevaluated by the wrapper logic. If there is no violation, thetransfer request is not stalled. Upon detection of a DMArequest to illegal memory addresses, a security-criticalevent notification is triggered, the violation is loggedat the security wrappers of satellite unit, and the entryrequest for DMA is discarded. The IP security wrappers

Fig. 4. Our SoC model with proposed security architecture: SPE acts as acentralized flexible security policy engine to enforce policies in collaborationwith distributed satellite units.

form frames with event logs and meta-data, and sendthe corresponding packets through the communicationinterface to SPE.

• It is possible for a malicious IP to violate non-observability without memory access. The maliciousprocessor attempts to clone and/or divert data packetsthrough a compromised router IP. Misconfiguration ofrouter involves micro-architectural events, e.g., assigningincoming flit to invalid channel queue, illegal updateof flit register content, allocation to improper virtualchannel, etc. Any deviation from the standardized eventsin the routers is detected by the security wrapper throughinterface action logic. Thus, the suspicious event will bestalled by the router wrappers and corresponding eventframes are sent to SPE as packets.

• Upon reception of the packets from the IP securitywrapper or router wrapper, SPE extracts the event frames,updates the security status of the system, sends messagepackets to satellite units at the IP and the router toblock subsequent DMA requests of the IP, and discardsthe data packets from compromised router until furtherverification in debug mode.

The non-observability enforcement above employs a policy-based solution for packet misdirection as part of data snoopingprevention. As the attack models are not mutually exclusive,the non-observability policy also prevents packet misdirectionin this case.

91

VI. EXPERIMENTAL RESULTS

A. Experimental testbed

Given the dearth of standard open-source SoCs for architec-tural study, we have been developing our own SoC model. Fig.4 illustrates the current version of our model. Albeit academic,it is architected with many substantial SoC components andreflects the relevant features of NoC-based industrial SoCdesigns, including tree-based topology for routers inspiredby a recent commercial SoC, a mix of high-speed and low-speed IPs, different cryptographic modules, etc. The IPs aresegregated into two clusters. The North cluster includes thehigh-speed IPs (e.g., CPU and DSP accelerators) and theSouth cluster incorporates crypto engines, PMU module, andexternal communication IPs like UART and SPI. The IPs arewishbone-bus compatible. The network adapter facilitates theircompatibility to NoC protocol. All the IPs are obtained fromvarious open source repositories in Verilog and SystemVerilogRTL models. The SoC model is functionally validated inModelSim for specific use cases. We augment the abovemodel with an SPE unit, implemented through a 32-bit 5-stage DLX micro-controller with dedicated instruction anddata memory. Furthermore, each IP and router is augmentedwith a representative satellite unit.

B. Area and Power Overhead Analysis

To obtain representative overhead values for area and power,we synthesized the SoC model in Synopsis Design Compilerusing a LEDA standard cell library at TSMC 250nm tech-nology node. The estimated area and power overhead resultsincurred by the proposed satellite units at each IP module androuter is presented in Table II. The percentile increase in areaand power overhead is relatively small and varies over a rangeof 1.67 to 13.25. Table III shows the area and power overheadresults incurred by the SoC security policies implemented forthe use cases studied in this work. Note that the overhead isestimated with respect to the baseline processor and routerIP with no satellite units integrated to them. The overheadresults in the router is comparatively high due to the relativelysmall design of the IP. The overhead incurred in baseline SPEdue to use case implementation is negligible compared to itsoriginal die area and total power. We studied the estimatedarea and power overhead of the SPE with respect to our SoCmodel and different commercial SoCs i.e., Intel Atom Z2520,Apple A6 (APL0598), and QualComm Snapdragon 800. Theresults are shown in Table IV. In comparison to the industrialSoCs, the die area overhead incurred by the proposed securitypolicy engine is significantly low. For generic commercial SoCdesigns, it can be concluded that the overhead of proposedsecurity architecture would be minimal with respect to fullSoC dies.

C. Performance Overhead Analysis

Since our SoC model does not include sufficient instrumen-tation to provide adequate controllability of internal events, itis difficult to deterministically exercise specific traffic patterns

Fig. 5. Overhead Estimation of the latency and link utilization for variouspositions of SPE in the network during benign & malicious operatingconditions.

to enable study of latency and congestion. To study perfor-mance overhead, we instead use a state-of-the-art configurableNoC simulator that provides flexibility in studying the networkbehavior in the context of varying traffic patterns and SoCoperating conditions. The traffic flow is simulated with open-source Garnet 2.0 interconnection network model inside Gem5simulator [4], [5]. The NoC model is generated by runningGarnet 2.0 in standalone mode. The traffic pattern to be exer-cised is computed by analyzing the policy implementation andinterspersing traffic due to policies with randomized messagecommunication to simulate other concurrent communications.

We ran the different traffic patterns for 10K cycles for thefollowing cases: a) Baseline activity with no communicationbetween SPE and the satellite units. b) Benign activity withcommunication of security critical messages from satelliteunits to the SPE. c) Malicious activity involving detectionand mitigation of attacks by satellite units and SPE throughthe security policies presented in the use cases. Note that theplacement of SPE affects the traffic pattern; in fact, one criticalreason for studying traffic patterns is to identify the locationfor SPE that incurs minimal latency.

Our experimental results are shown in Fig. 5. SPE isconnected to each router of our topology and the simu-lation is run each time to analyze the resultant effect onthe network performance as interpreted from the observedoverhead with respect to the baseline. The communicationbetween the satellite units and the SPE incurs a communi-cation overhead of approximately 5% in benign operationalconditions where no attack is launched. During maliciousactivity, the implementation of the illustrated security policiesincur an additional 0.5% communication overhead for thedetection and mitigation of the attack. The results indicatethat for our specific tree topology, connecting SPE to Router2 results in optimal performance and incurs the least overhead,while connecting the SPE to Router 1 results in the highestperformance overhead.

VII. RELATED WORK

The state of the art on trust verification of 3PIPs involvesanalysis, detection, and deterrence of hardware Trojans inuntrusted IP cores [6], [7], [8]. These approaches rely onthe categorization of hardware Trojans based on inherentproperties like design and activation mechanism. Most of thesetechniques, however, are limited to static trust verification of

92

TABLE IIAREA AND POWER OVERHEAD OF SATELLITE UNITS IN REPRESENTATIVE IP CORES

Representative IP cores CPU FFT FIR IDFT SRAM AES DES3 SHA PMU UART SPI Router

Area Overhead (%) 1.67 5.81 3.25 3.17 11.25 6.93 7.2 5.25 10.58 10.45 12.79 13.25

Power (Active+Leage) Overhead (%) 2.35 6.23 4.15 4.29 10.58 6.55 8.25 4.19 13.49 9.83 13.23 12.17

TABLE IIIAREA AND POWER OVERHEAD OF IMPLEMENTED POLICIES FOR DIFFERENT USE CASE SCENARIOS

Use Case ScenariosProcessor NoC Router

Die Area Overhead(%)

Power (Active+Leakage)Overhead (%)

Die Area Overhead(%)

Power (Active+Leakage)Overhead (%)

Case I Non-observability and/ornon-misdirection

2.65 3.78 14.98 13.46

Case II Masquerade prevention and/ormessage immutability

3.34 2.94 15.23 13.79

TABLE IVDIE AREA OVERHEAD OF CENTRALIZED SPE (AREA: 3.3× 106 µm2 ;

POWER: 13.85 MW ) IN COMPARISON TO REALISTIC SOCS

SoC Die Area (µm2) Overhead of SPE (%)

Our SoC model 27.6 × 106 12.07Intel Atom Z2520 40.6 × 106 8.2

A6 (APL0598) 96.71 × 106 3.44Qualcomm Snapdragon 800 118.3 × 106 2.81

standalone IPs and their efficacy is limited by design size andcomplexity. Existing works on run-time detection of hardwareTrojans also suffer from limited application scope and cannotbe extended to heterogeneous SoCs with varying interconnectprotocols [9], [10].

Existing works on the security of on-chip networks focuson physical, software, and side-channel attacks. The proposedsolutions include encrypted transmission of on-chip data,isolating the secure data operated region from the untrustedregion, and deployment of data protection units for secureaccess control to the memory, etc. [11], [12], [13]. Theseworks provide solutions to specific vulnerabilities arisingfrom compromised NoCs like information leakage and datacorruption.

VIII. CONCLUSION

We have presented a resilient SoC security architecture tobuild a trusted system involving NoC communication amonguntrusted IPs. We have shown how to systematically imple-ment key security requirements of inter-IP communication andproposed an architecture-level solution for run-time detectionand mitigation of on-chip communication threats. Recent yearshave seen an increased reliance on untrusted 3PIPs and NoCsin SoC design. Unfortunately, existing works on design-timeIP-trust verification fail to guarantee trusted SoC operationwith the increasing modalities of communication attacks. Wepresent a fundamentally different approach, e.g., an architec-ture for run-time resilience. We have shown the efficacy of theapproach by implementing policy-based solutions for use casescenarios of secure system-level communication.

In future work, we will evaluate the framework on industrialSoC designs and investigate mechanisms for automating thesynthesis of the fine-grained security policies for differentcommunication attacks.

REFERENCES

[1] A. Basak, S. Bhunia, and S. Ray, “A Flexible Architecture for SystematicImplementation of SoC Security Policies,” in IEEE ICCAD, 2015.

[2] ——, “Exploiting Design-for-Debug for Flexible SoC Security Archi-tecture,” in DAC, 2016.

[3] A. P. D. Nath, S. Ray, A. Basak, and S. Bhunia, “System-on-chip securityarchitecture and cad framework for hardware patch,” in Proceedings ofthe 23rd Asia and South Pacific Design Automation Conference. IEEEPress, 2018, pp. 733–738.

[4] N. Agarwal, T. Krishna, L.-S. Peh, and N. K. Jha, “Garnet: A detailedon-chip network model inside a full-system simulator,” in PerformanceAnalysis of Systems and Software, 2009. ISPASS 2009. IEEE Interna-tional Symposium on. IEEE, 2009, pp. 33–42.

[5] N. Binkert, B. Beckmann, G. Black, S. K. Reinhardt, A. Saidi, A. Basu,J. Hestness, D. R. Hower, T. Krishna, S. Sardashti et al., “The gem5simulator,” ACM SIGARCH Computer Architecture News, vol. 39, no. 2,pp. 1–7, 2011.

[6] A. Waksman, M. Suozzo, and S. Sethumadhavan, “Fanci: identifica-tion of stealthy malicious logic using boolean functional analysis,” inProceedings of the 2013 ACM SIGSAC conference on Computer &communications security. ACM, 2013, pp. 697–708.

[7] J. Rajendran, V. Vedula, and R. Karri, “Detecting malicious modifica-tions of data in third-party intellectual property cores,” in Proceedingsof the 52nd Annual Design Automation Conference. ACM, 2015, p.112.

[8] R. S. Chakraborty, S. Narasimhan, and S. Bhunia, “Hardware trojan:Threats and emerging solutions,” in High Level Design Validation andTest Workshop, 2009. HLDVT 2009. IEEE International. IEEE, 2009,pp. 166–171.

[9] A. Waksman and S. Sethumadhavan, “Tamper evident microprocessors,”in 2010 IEEE Symposium on Security and Privacy (SP). IEEE, 2010,pp. 173–188.

[10] J. Dubeuf, D. Hely, and R. Karri, “Run-time detection of hardwaretrojans: The processor protection unit,” in Test Symposium (ETS), 201318th IEEE European. IEEE, 2013, pp. 1–6.

[11] L. Fiorin, G. Palermo, S. Lukovic, V. Catalano, and C. Silvano, “Securememory accesses on networks-on-chip,” IEEE Transactions on Comput-ers, vol. 57, no. 9, pp. 1216–1229, 2008.

[12] J.-P. Diguet, S. Evain, R. Vaslin, G. Gogniat, and E. Juin, “Noc-centricsecurity of reconfigurable soc,” in Networks-on-Chip, 2007. NOCS 2007.First International Symposium on. IEEE, 2007, pp. 223–232.

[13] Y. Wang and G. E. Suh, “Efficient timing channel protection for on-chip networks,” in Networks on Chip (NoCS), 2012 Sixth IEEE/ACMInternational Symposium on. IEEE, 2012, pp. 142–151.

93