Presentation is loading. Please wait.

Presentation is loading. Please wait.

Politecnico di Milano, Italy

Similar presentations

Presentation on theme: "Politecnico di Milano, Italy"— Presentation transcript:

1 Politecnico di Milano, Italy
SMASH: A Heuristic Methodology for Designing Partially Reconfigurable MPSoCs Riccardo Cattaneo, Christian Pilato, Gianluca C. Durelli, Marco D. Santambrogio and Donatella Sciuto Politecnico di Milano, Italy IEEE International Symposium on Rapid System Prototyping – Montreal, Canada – October 4, 2013

2 What is an FPGA? Hardware device that can be customized after the fabrication to execute a specific functionality Distinct hardware blocks are “intrinsically” running in parallel on the device Heterogeneous grid of interconnected components look-up tables (LUTs), block rams (BRAMs), digital signal processors (DSPs), switch matrices, input/output blocks (IOBs) etc… Possibility to reuse resources by reconfiguring part of the logic at run time (partial reconfiguration)

3 Heterogeneous SoCs with FPGAs
Highly coupled heterogeneous systems Zynq Platform: ARM Dual-Cortex A9 cores tightly coupled with a Xilinx Artix-7 FPGA High speed, low latency reconfigurable interconnect AVNet ZedBoard (Zynq7000-based dev board) Coarse Grain overview of Zynq7000 All-Programmable SoC

4 Design Challenges and Motivation
Hardware engineer needs to: partition the application in blocks (partitioning) determine which parts are better to be executed in hardware (mapping and scheduling) generate the systems (architecture refinement) Partial reconfiguration allows reusing the same logic across different tasks More tasks can be ported in hardware Significant overhead to be taken into account INPUT SMASH The steps are strictly interdependent!

5 SMASH: Proposed Methodology
Design Space Exploration determines the proper mapping and scheduling Architecture Refinement customizes the architectural template to derive the corresponding platform

6 Mapping and Scheduling
Input: Task graph (DAG) Architectural Template Identifies resources constraints Implementations List of different trade-offs in terms of performance and resources Output: Implementation and component for each task Order of execution

7 Implementation vs. Component
Each task can have multiple alternative implementations on the same component Faster tasks usually require more resources Some tasks can share implementations to execute the same functionality multiple times Hardware reuse: no reconfiguration is required Implementation is more related to functionality and resources Component is more related to where the task is actually executed Processor or hardware module

8 SMASH: Execution Overview
Simultaneous MApping and Scheduling Heuristic SMASH iteration Generate trace Schedule trace Evaluate metrics Store solution Termination? No Yes Return best solution

9 Exploring Mapping and Scheduling
Exploration based on the Serial Generation Scheme (SGS) Constructive approach to better handle design constraints Decision is not taken if it would lead to a constraint violation Different combinations of mapping and scheduling Each decision represents a mapping of a task with respect to an implementation and a processing element The order of selection represents the priority values for resolving scheduling conflicts on the resources

10 Ant Colony Optimization
Our proposed approach is based on Ant Colony Optimization (ACO) to limit unfeasible solutions Cooperative behavior of the ants while searching The ant has different possibilities at each step and takes stochastic decisions, composing a trace Stochastic principles guarantee exploration (a probability is generated for each admissible decision at each step) Feed-backs guarantee the exploitation of good parts of the solutions

11 Algorithm Overview Pseudo-code of the proposed ACO-based exploration:
Exploration: generating trace Mapping decision Exploitation: updating global information

12 Stochastic Selection Process
At each decision point d, the probability to assign a candidate j (task/communication) to a proper implementation point i (implementation+processing element) is: Global information G: feedback information Probability that the decision leads to a good solution Local heuristic L: problem-specific hint “Adjusted” by the global heuristic if wrong Roulette wheel and extraction of a combination i, j Probability is generated iff the resources required by the resulting PEs can be satisfied by the architecture global heuristic local heuristic There is always the possibility of adding a new PE or reusing an existing one (platform customization)

13 More about SMASH Simultaneous MApping and Scheduling Heuristic No Yes
SMASH iteration Generate trace Schedule trace Evaluate metrics Store solution Termination? No Yes Return best solution 13

14 Trace Generation and Evaluation
Evaluation is performed only on the complete trace Updated version of the original TG augmented with communications and reconfigurations Reconfiguration is taken into account from the early stages of the design process Possibility to include different evaluation methods Analytical estimations vs. TLM simulations Decisions composing the best solution are reinforced As the time goes, the best trace is identified [generazione della traccia] Analisi statica, simulazione TLM (vedi SoC), possibilità di modificare il TG per integrare informazioni più dettagliate (diverse comunicazioni, riconfigurabilità) Possibility to evaluate and compare alternative approaches

15 Scheduling Definition
Input Task graph (DAG) Trace: ordered list of mapping decisions (task-component-implementation) Output Start/end time estimations for each task Goal Reduce total execution time Task Component Implementation A p1 impl_0 B p2 impl_1 C impl_2 D p3 impl_3

16 Scheduling: Methodology Overview
SMASH scheduler Task graph and trace Extended task graph Metrics Create extended task graph Actual scheduling (assign times) Evaluate Metrics

17 Extended TG: Communications
Adding explicit tasks based on the communication topology

18 Extended TG: Reconfigurations
A reconfiguration task is introduced iff: Two processing tasks are mapped on the same component and Their implementations are different, i.e., module cannot be reused Insertion of a reconfiguration task: New edges are introduced from all WRITEs exiting the source processing task to the reconfiguration New edges are introduced from the reconfiguration to all the READs entering the target processing task

19 Extended TG: Reconfigurations
Task Component Implementation A p1 impl_0 B p2 impl_1 C impl_2 D p3 impl_3

20 Trace Evaluation Possibility to integrate different policies to generate the corresponding scheduling

21 Architecture Refinement
Actual platform instance is derived based on the resulting decisions Hardware modules with only one task assigned are converted into static IP blocks Hardware modules with more tasks assigned are represented as reconfigurable regions Integration with the generation of the run time manager to manage reconfigurations Still work in progress and manually performed

22 Experimental Evaluation
Synthetic benchmarks (TGFF) Focus on scalability of the approach Possibility to evaluate different task graph patterns Resulting systems (platform instance and extended task graph with mapping/scheduling decisions) converted into virtual platforms Validation of the different solutions assuming correctness of the execution Simulations performed with Synopsys Platform Architect VPU performance annotations extracted from tasks’ implementations

23 Experimental Setup Three different class of experiments:
Static: FPGA area is divided into a set of up to KS static IP cores (no partial reconfiguration) Mixed: both IP cores and reconfigurable regions can be used, with an upper bound of KM IPs and RM reconfigurable regions. Reconfigurable: architectures with no more than KR regions Reconfigurable regions can be also deployed as static cores in the final architecture if only one task is assigned to them

24 Experimental Results Small task graphs cannot benefit of reconfiguration Large task graphs are affected by communication overhead static mixed reconfigurable #Task IPs RRs HW tasks #Reconf 12 7 6 20 18 1 17 19 31 30 4 16 41 8 40 14 52 9 51 25 26 60 15 10 53 28 27 70 55 58 33 83 11 80 54 81 56 90 23 3 5 39 100 46

25 Conclusions and Future Work
SMASH is an automated methodology to design reconfigurable systems It determines the mapping and scheduling of the different tasks It allows customizing the architectural template Future work Integration of floorplanning procedures to compuate and validate physical constraints of the blocks Automatic generation of the platform specification

26 End…

Download ppt "Politecnico di Milano, Italy"

Similar presentations

Ads by Google