conquering mpsoc design and architecture complexity with
play

Conquering MPSoC Design and Architecture Complexity with - PDF document

Technische Universitt Mnchen MPSoC Forum 2014 Margeaux, France, July 10, 2014 Conquering MPSoC Design and Architecture Complexity with Bio-Inspired Self-Organization Andreas Herkersdorf Institute for Integrated Systems, TU Mnchen


  1. Technische Universität München MPSoC Forum 2014 Margeaux, France, July 10, 2014 Conquering MPSoC Design and Architecture Complexity with Bio-Inspired Self-Organization Andreas Herkersdorf Institute for Integrated Systems, TU München http:/www.lis.tum.de Technische Universität München The System Design Complexity Challenge Source: H.-J. Bullinger, Fraunhofer Gesellschaft How will the future look like? What topics do matter to society? Energy Mobility Environment Key enabling technologies: ICT Technology Health Communication Security MPSoC Forum 2014 - 2 A. Herkersdorf 1

  2. Technische Universität München The System Design Complexity Challenge Source: H.-J. Bullinger,  Moore’s law is the technological enabler for Billion MOSFET designs, but … Fraunhofer Gesellschaft How will the future look like?  … how to deal with the design complexity of Billion MOSFET (MP)SoCs What topics do matter to society?  considering implications of various forms of variability Energy Mobility Environment  and get the design and fabrication right at first time? Key enabling technologies:  When the MPSoC design & manufacturing challenge is solved, how to … ICT Technology  program massively parallel processor components,  guarantee real-time, security, mixed-criticality and power constraints?  Progress of IC design and integration gets more and more constraint by direct or indirect complexity issues Health Communication Security  What alternative to established, best practice engineering approaches do we have to tackle complexity? MPSoC Forum 2014 - 3 A. Herkersdorf Technische Universität München MPSoC Resilience [Zeppenfeld08]  Video frames distributed among 1 – 3 operational RISC cores  RISC cores may arbitrarily fail … (mimicked by purposely switch-off every few 100 ms)  … which is compensated by CPU1 CPU2 CPU3 workload redistribution and f, V DD scaling (DVFS) of remaining cores Bus  Heuristic by which f, V DD are altered Interrupt Video MEM Control Interface will be revealed later MPSoC Forum 2014 - 4 A. Herkersdorf 2

  3. Technische Universität München MPSoC Resilience The more often we switch cores off/on, the lower the frame drop rate Frame Drop Rate Frequency[GHz] / Utilization[x100%] MPSoC Forum 2014 - 5 A. Herkersdorf Technische Universität München MPSoC Task Mapping / Workload Balancing [Zeppenfeld11]  IP packet processing is split into 5 tasks, which are executed sequentially and initially all mapped to Core 1  IP flow received at MAC, sent to T1 and received from T5 for retransmit T3 T2 T5  Cores may issue task relocation when in high-load condition and perform T1 T4 DVFS Core1 Core2 Core3  Same heuristic and method applied Bus as in previous example of resilient video applications UART MEM MAC MPSoC Forum 2014 - 6 3

  4. Technische Universität München MPSoC Task Mapping / Workload Balancing 1 0.9 0.8 Utilization 0.7 0.6 0.5 0.4 0.3 With increasing number of packets 0.2 received / processed, the core utilization 0.1 0 saturates at high, frequency at low level 0 s 100 200 300 400 500 600 700 800 900 1 ms 1100 1200 1300 1400 1500 1600 1700 1800 1900 2 ms 0.3 us us us us us us us us us us us us us us us us us us … Frequency (GHz) CPU1 CPU2 0.2 0.1 CPU3 0 0 s 100 200 300 400 500 600 700 800 900 1 ms 1100 1200 1300 1400 1500 1600 1700 1800 1900 2 ms us us us us us us us us us us us us us us us us us us MPSoC Forum 2014 - 7 Technische Universität München MPSoC Task Mapping / Workload Balancing 50 Average Latency ( μ s) 40 … and variation of IP packet forwarding latency settles at 30 low level. 20 10 0 0 s 100 200 300 400 500 600 700 800 900 1 ms 1100 1200 1300 1400 1500 1600 1700 1800 1900 2 ms us us us us us us us us us us us us us us us us us us MPSoC Forum 2014 - 8 4

  5. Technische Universität München „Manycore“ System in Nature …  Fish school does not seam to have a complexity or reliability problem  Entire system behaves orderly and defends itself reliably against predators  How is orchestration of “fish school” facilitated among its components? A. Herkersdorf MPSoC Forum 2014 - 9 Technische Universität München Nature designs and optimizes differently … [Inada02, Pathel04] Every system constituent (fish) follows a local rule set on how to behave under stress  Rule set is simple, easily manageable for each constituent  Every constituent follows same rule set  Global system behavior not necessarily reflected in local rule set If (d < R r ) then Repulsion: Avoid clashes Else if (d < R p ) then Orientation: Parallel to neighbor Else if (d < R a ) Attraction: Approach companion Endif A. Herkersdorf MPSoC Forum 2014 - 10 5

  6. Technische Universität München Self-Organization / Emergence [Fromm04] Local behavior of the constituents of a self-organizing system may lead to observable, emergent global behavior which is not reflected in local behavior / rules  Population of interacting system constituents  System is hierarchically structured (multi-layer organization) System  Emergent behavior observable at levels above constituent level (system level or system environment) as a result of hidden causal relationships across levels A. Herkersdorf MPSoC Forum 2014 - 11 Technische Universität München Conway’s Game of Life [Gardner70] Constituent pattern determines system level behavior:  Rotary, translatory movements, oscillation, persistence, …  … in combination and with varying parameters Conway (rule 3/3) hexagonal (rule 34/2) If (cell alive AND N = 3 ) then live unchanged to next generation Else if (cell alive AND N < 2 OR N > 3 ) then death by loneliness or overcrowding Else if (cell dead AND N = 3) then birth of new cell in next generation End MPSoC Forum 2014 - 12 A. Herkersdorf 6

  7. Technische Universität München ASoC: Autonomic System on Chip [Herkersdorf/Rosenstiel04] Evolutionary, platform-centric approach AUTONOMIC Layer Autonomic with compatibility to SoC design method: Monitor Element Evaluator  Functional layer containing conventional IPs Actuator  Autonomic layer extends IPs with self-x Communication I/F properties  Improved Reliability  Performance / Power optimization at CPU CPU runtime Dedicate part of chip capacity to self-x RAM PU abilities at autonomic layer Network I / F Functional Future SoC shall have the ability to learn to Element FUNCTIONAL Layer live with environmentally imposed variations or work around defects Joint project with University of autonomously Tübingen and FZI Karlsruhe MPSoC Forum 2014 - 13 Technische Universität München ASoC: Self-Optimization through Runtime Learning [Zeppenfeld11, Holland78, Wilson95, Butz06]  Monitors  Error rate, (Temperature) Learning Classifier Table Learning Classifier Table Learning Classifier Table  Condition Condition Condition Action Action Action Fitness Fitness Frequency 1 1 1 X X X X X X 0 0 0 : 1001 : 1001 : 1001 52 52  Fitness Utilization X X X 0 0 0 1 1 1 X X X : 1010 : 1010 : 1010 3 3 Update . . . . . . . . . . . . . . . . . . . . . . . .  Workload X X X 1 1 1 0 0 0 X X X : 1100 : 1100 : 1100 15 15  Actuators  Frequency (and voltage) CPU1 CPU2 CPU3  Task migration  Evaluator Bus  Learning classifier system adapted for efficient HW implementation Interrupt Video MEM Control Interface  Reinforcement learning through fitness update of individual rules  Communicator  Sharing of global information MPSoC Forum 2014 - 14 A. Herkersdorf 7

Recommend


More recommend