Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 CP in Electronic Design Automation (EDA) (Java Constraint Programming) JaCoP solver Radoslaw (Radek) Szymanek.

Similar presentations


Presentation on theme: "1 CP in Electronic Design Automation (EDA) (Java Constraint Programming) JaCoP solver Radoslaw (Radek) Szymanek."— Presentation transcript:

1 1 CP in Electronic Design Automation (EDA) (Java Constraint Programming) JaCoP solver Radoslaw (Radek) Szymanek

2 2 Outline Introduction Embedded Systems (CP applications) JaCoP “free” cake

3 3

4 4

5 5

6 6 CP in EDA Constraint-Driven Design Space Exploration for Memory-Dominated Embedded Systems Radoslaw Szymanek

7 7 Embedded Systems Processor based system Integral part of larger system Specific functionality Heterogeneous architecture Heterogeneous requirements

8 8 Application Data dominated application Application model at high abstraction level Annotated task graph Heterogeneous constraints

9 9 Processing Architecture P1 ROMRAM P2 ROMRAM P3 ROM RAM A1 RAM B1 L1 L2 Heterogeneous units Resource view Trade-offs Architecture Selection

10 10 Execution Scenario ErrCor D4D4 ASIC Cancel D2D2 DSP UI D1D1 PP D3D3 D3D3 DSP D4D4 D5D5 D6D6 Scrabling Encoding Decoding C3C3 Descrabling C4C4

11 11 Design Flow Specification Design Execution Application (C/C++, SystemC) Architecture Selection Task Assignment Task Scheduling Application Task Graph Model Pareto Diagram Composition Data Assignment Data Access Scheduling Application Execution Scenario(s)

12 12 Motivation Memory contributes most to cost, power consumption, and application execution time Exploration of different resource trade-offs (finds efficient execution scenarios) Constraints during the system synthesis are abundant (Specify, Explore, Refinement) Synthesis problem often changes so we need an easy method to extend, understand, and employ optimization suite

13 13 Constraint Programming Introduction “Constraint programming represents one of the closest approaches computer science has yet made to the Holy Grail of programming: the user states the problem, the computer solves it.” Eugene C. Freuder CONSTRAINTS, April 1997

14 14 Schedule length versus cost (I) Architecture selection determines the schedule makespan We choose an architecture and optimize schedule makespan for it Heterogeneous application, architecture, and constraints Task 2 Task 1 Task 3 Task 2 Task 1 Task 3 PU 1 PU 2 PU 1 time

15 15 Schedule length versus cost (I) Uses meta search heuristics to search only part of the design space search – partial search Explore Architecture selection Explore Assignment Explore Scheduling 1st best solution

16 16 Schedule length versus cost (I) Divide and Conquer based on consecutive refinement 2nd best solution Explore Architecture selection Explore Assignment Explore Scheduling

17 17 Schedule length versus cost (I) Each exploration step uses results from previous steps 3rd best solution Explore Architecture selection Explore Assignment Explore Scheduling

18 18 Schedule length versus cost (I) Scheduling refinement (first interval then time point) T1T2T3T4T5T7T8T6 T1 I1 I2 T1 T7 T8

19 19 Memory versus Execution Time (II) Faster execution usually requires more data memory Data T2 Data T3 Memory Address Data T1 Data T2 Data T3 Data T1 Memory Address time Parallel Execution Sequential Execution

20 20 Data 3 Memory versus Execution Time (II) Scheduling with data memory placement so memory fragmentation problem is taken into account Data 2 Data 1 Memory Address time

21 21 Memory versus Execution Time (II) Scheduling with data memory placement so memory fragmentation problem is taken into account Data 3 Data 2 Data 1 Memory Address time

22 22 Memory versus Execution Time (II) Adaptive and estimate guided heuristic (criteria memory consumption or execution time) Look-ahead and backtracking capabilities Memory bottleneck? Reduce Execution Time Reduce Memory Usage (backtrack, consume data) No Yes

23 23 Memory versus Execution Time (II) Algorithmic pipelining to improve throughput Memory Sequential Data 2 Data 1 Data 3 Data 2 Data 1 Data 3 Data 2 Data 1 Data 3 Memory Pipelining time Data 2 Data 1 Data 3

24 24 Partial Assignment Technique (III) Reduce the problem size to simplify task assignment and task scheduling Clustering – simplifies the model T1T2T3T4T5T7T8T6T1T2&T4T3&T5T7T6&T8

25 25 Partial Assignment Technique (III) Clustering can cause deadlock, not all groups of tasks are allowed Linear groups of tasks are not optimal any longer if resources such as memories are present T1T2T3T1&T3T2

26 26 Partial Assignment Technique (III) Problem simplification through adding constraints; not model simplification No deadlock problem, more refine simplifications Better than clustering with linear-clusters T1T2T3T1T2T3 P T1 = P T3

27 27 Memory Bandwidth A major bottleneck in many data-dominated applications Processor often waits for data – latency or bandwidth Actual bandwidth depends on access patterns and data assignment Higher bandwidth? –more memories –better utilization

28 28 Memory Architecture (IV-V) Most significant resource Bandwidth bottleneck Energy and timing considerations Complex memories such as SDRAM Multiple memories : : row n row 1 page 1page 2 SDRAM port Bank 1 Bank 2

29 29 Memory model for SDRAM (IV-V) considered as a resource since –Fixed maximal size –Fixed number of page buffers –Fixed maximal bandwidth B1B2B3B4 ………. S1S2S3S4 P1P2 T1 T2 Time Window time

30 30 Energy vs. Execution Time (IV-V) D1 D2 D3 D4 D5 D6 D7

31 31 Energy vs. Execution Time (IV-V) SDRAM 1SDRAM 2 D1 D2 D3 D4 D5 D6 D7

32 32 Energy vs. Execution Time (IV-V) energy time exploration Application Pareto Diagram D1 D2 D3 D4 D5 D6 D7 SDRAM 1SDRAM 2

33 33 Task Pareto Diagram (IV-V) SDRAM 3 SDRAM 2 SDRAM 1 time energy

34 34 SDRAM 3 SDRAM 2 SDRAM 1 Task Pareto Diagram (IV-V) time energy

35 35 SDRAM 3 SDRAM 2 SDRAM 1 Task Pareto Diagram (IV-V) energy time

36 36 Conflict Graph (IV-V) Specifies assignment constraints for different tasks’ execution options Memory/Page conflict edge Memory/Bank compatibility edge SDRAM Y SDRAM X memory compatibility page conflict memory conflict

37 37 Composition (IV) energy time exploration Application Pareto Diagram SDRAM 1SDRAM 2 D1 D2 D3 D4 D5 D6 D7

38 38 Energy vs. Execution Time (IV) Heuristic for trading bandwidth and assignment constraints between tasks to achieve efficient application execution Scheduling estimates, data assignment feasibility check Memory oriented application model (e.g. SDRAM) A B C D ACAC + time energy ADAD BCBC BDBD

39 39 Energy vs. Execution Time (IV) Heuristic for trading bandwidth and assignment constraints between tasks to achieve efficient application execution Scheduling estimates, data assignment feasibility check Memory oriented application model (e.g. SDRAM) … time energy

40 40 Scheduling Optimization Iterative Optimization (V) Memory Structure Assignment Optimization Application Task Graph Pareto Composition weights adjustment Non valid CG Composition removal Suboptimal Points removal Parallelization constraints Application Pareto Diagram

41 41 Summary of CP applications in EDA We considered data-dominated applications and memory issues We showed that CP framework can be efficiently used as an optimization framework for modeling and solving embedded system synthesis problems We proposed and evaluated different techniques, heuristics, and models for system level synthesis (e.g., PAT) We addressed resource and optimization trade-offs

42 42 Radek Szymanek (Java Constraint Programming) JaCoP solver

43 43 Outline Basics Features Marketing stuff Typical misconceptions Applications Licensing

44 44 Basics written by only two people (Krzysztof Kuchcinski and Radoslaw Szymanek) entirely based on Java the process of developing JaCoP began in 2001 it is under continuous development it has slightly above 20 thousands lines of code there is no GUI (just core engine)

45 45 Basics it can be easily plug-in in any other Java based application it has reasonable performance scheduling application problems from electronic design automation industry influenced development it has global constraints (scheduling related) it was already used in several research facilities

46 46 Features global constraints - alldifferent, cumulative, diff2, element, and circuit - often available in different flavors (gcc in plans ;)) it is rather simple to extend Application Programming Interface (API) generated using JavaDoc is available small JaCoP guide is also available

47 47 Marketing stuff ;) it has simple and convenient API it was already tested in different situations (quite robust) small footprint (around 200k in jar file) it keeps getting better ;) great vehicle for research complex data structures/reuse of already computed information

48 48 Typical misconceptions it is Java based so it must be really slow (garbage collector is a sweet thing) it must be hard to extend it (extensions are easier than with other industrial solvers and extensions can be more efficiently implemented) it must be hard to learn (experience with any other solver suffice, it is used for teaching purposes in Sweden and Poland)

49 49 Applications JaCoP authors own research published at EDA conferences and journals (scheduling problems) Los Alamos National Laboratory (synthesis of FPGA based designs) Kunliga Tekniska Hogskola (KTH) research in the field of Network on Chip (NoC) First industrial application on the way ;)

50 50 Licensing It is free for research and it will always be ;) commercial applications require fee per contract basis (at least 25euro AND at least 1% contract value), paid when contract is realized any further distribution requires notification of JaCoP licensing terms any extension which does not required reverse engineering (code is obfuscated) and keeps JaCoP in its original form is allowed

51 51 Licensing (Special terms for 4C) the source code is available, right to modify and share source code within 4C No possibility to distribute your own version of JaCoP outside 4C (to keep from forking – like Java) authors are eager to incorporate any improvements you suggest/make so you can distribute your own application with standard JaCoP library on normal terms

52 52 Research Ideas (cooperation) Global constraints (how to efficiently compute consistency methods, iterative computation) Visualization and explanations within global constraints, extending constraint functionality SALSA type of search framework for developing search methods (coarse grain search methods) Any of this topic is of interest for me, few more ideas piled on the stack (playing with your own solver gives you plenty of ideas)

53 53 Thanks! Questions?


Download ppt "1 CP in Electronic Design Automation (EDA) (Java Constraint Programming) JaCoP solver Radoslaw (Radek) Szymanek."

Similar presentations


Ads by Google