MPSoCs run-time monitoring through Networks-on-Chip

Abstract

Abstract-Networks-on-Chip (NoCs) have appeared as design strategy to overcome the limitations, in terms of scalability, efficiency, and power consumption of current buses. In this paper, we discuss the idea of using NoCs to monitor system behaviour at run-time by tracing activities at initiators and targets. Main goal of the monitoring system is to retrieve information useful for run-time optimization and resources allocation in adaptive systems. Information detected by probes embedded within NIs is sent to a central unit, in charge of collecting and elaborating the data. We detail the design of the basic blocks and analyse the overhead associated with the ASIC implementation of the monitoring system, as well as discussing implications in terms of the additional traffic generated in the NoC 1 .

Exploiting error control approaches for Hardware Trojans on Network-on-Chip links

“…The approaches of encryption authorization [19], internal probing [20], and exchanging secret information through virtual channels [21] have been recently studied. Dividing the network into secure and non-secure IP core zones can allow only secure information to be sent to and from secure zone, which protects the network from malicious inclusions [22].…”

Monitoring and timing prediction in early analyzing and checking performance of interconnection networks at ESL

“…For statistical performance metrics like link utilization and throughput, we also assume that they can be collected and checked by existing techniques [20,22]. In the paper, we focus on early checking the end-to-end performance metric (i.e., latency).…”

“…Moreover, identifying root causes of violations becomes extremely difficult because a large amount of concurrent traffic which exists before the deadline has to be filtered and analyzed. In order to also capture data at multiple routing stages, the 3 rd technique (MT3) enables that monitors are within interface units, switches, or routers [21][22][23]. However, it has similar limitations as the 2 nd one.…”

A monitoring system for NoCs

“…When the elements identifying the transaction (i.e., initiator, target, type of operation) are equivalent to those specified in the configuration registers, the accumulator is enabled and the information about the amount of data transferred in the transaction (carried by the OCP/IP signal MBurstLength) is added to the accumulator. The OCP/IP signals involved in the detection are MCmd, which specifies the type of operation (load/store, i.e., incoming/outgoing traffic), MConnID (connection identifier) and MthreadID (thread identifier), which identifies the initiator, and signals coming from the look up table (LUT) of the NI Kernel (LUT PathAddr ) [6]. LUT PathAddr drives the RAM of the LUT looking up the target memory address present as input of the OCP/IP MAddr signal to retrieve the routing information to be inserted in the header of the packet [9].…”