1. NoC Modeling Networks-on-Chips seminar May, 2008 Anton Lavro

2. Simulation Purposes  Hardware designers use models for “ design space exploration ” Performance/power estimation in early design stages Algorithm validation  Two main approaches: Analytic modeling  Makes simplistic assumptions, sometimes just too complicated Simulation

3. Simulator Classification  Level of detail RTL Abstract models Cycle approximate UntimedCycle accurate Transaction LevelBit accurate  Tradeoff between accuracy, flexibility, complexity and run-time

4. NoC Simulator Level of Detail  Interface level Provides packet delivery Approximates latency based on distance  Capacity level Adds simple constraints on resource capacities and contention  Flit level Resource usage is tracked on a flit-by-flit basis  Hardware level Adds implementation details of hardware

5. NoC Simulator Workload  Application driven – real applications and/or benchmarks Execution driven Trace driven  Advantages: “ Real world ” workloads  Drawbacks: Requires full system simulator Can be slow Low workload space coverage

6. NoC Simulator Workload  Synthetic workload - traffic generator Statistical Transaction dependent  Advantages: Flexible – can be used by different NoC models Faster than application driven Better workload space coverage  Drawbacks: Has to be carefully designed to reflect a real NoC traffic pattern

7. NoC Simulator Servey  Most use the straight-forward approach of bit and cycle accurate modeling  SystemC is widely used – both for transaction level and RTL modeling  Some simulator exist that are not NoC specific: Orion, Noxim, OCCN  Several CMP NoC simulators exist that are linked to a functional ISA simulator (e.g. Simics)

8. NoC Simulator Servey  Some designers incorporate the simulation in their design flow ( Æ thereal, Xpipe, Nostrum)  The NoC is parameterised in several specification files Topology Latency/throughput requirements between components Area constraints  SystmeC or HDL code is generated by an automatic tool  Some use FPGA emulation  Sometimes the same code is used for simulation and synthesis

9. NoC Simulator Servey  Generic NoC design flow NoC specification files Simulator code generation RTL code generation NoC configuration and generation Hardware synthesis Performance and power estimation

10. NoC Simulator Survey Simulator workloads/benchmarks  According to Erno Salminen of the Tampere University, Finland survey of 44 existing NoCs: Analytical model – 20% Statistical tg – 41% TX dependent tg – 27 % Application – 30%  There are no standard benchmarks that are dedicated to communication- centric modeling

11. NoC Simulator Survey Simulator workloads/benchmarks  OCP-IP (Open Core Protocol) initiative towards an open NoC benchmark Provides better comparison results between different NoCs Enables result reproducibility  Mimics a real application  Based on Communication Task Graphs: Task ATask B Task C Traffic Input data

12. High Level Power Analysis for On Chip Networks (Noel Eisley and Li-Shiuan Peh, Princeton University)

13. High Level Power Analysis for On Chip Networks  The goals is to estimate the energy consumed in N cycles  Simulator input: message injection functions: Injection rate Time

14. High Level Power Analysis for On Chip Networks

15.  Link utilizations are calculated according to the message injection functions  The energy consumed by all the messages is summed into the total energy

16. High Level Power Analysis for On Chip Networks  The simulator was validated against Orion (cycle accurate simulator)  Run-time speedup compared to Orion:

17. Future Work  Most NoC simulators use a high level of detail Slow Not flexible  The NoCs are relatively simple (at least for now)  A more abstract quasi-analytic model can be built

18. Future Work High level Simulator NoC Model Packet (src, dst, size) Packet latency Client Model Routing Algorithm Src, DstRoute State: Buffer occupancy, link load etc Parameter instantiation: buffer sizes, link capacities etc.

19. Future Work High level Simulator  Implementation details of hardware elements are abstracted out  Optionally supports several levels of abstraction  Can be parameterized to reflect behavior of different NoCs  Can be hooked to a functional simulator