1. - 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Hardware/Software Codesign

2. - 2 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Design productivity gap

3. - 3 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund © Lauro Rizzatti Marketing Vice President Emulation & Verification Engineering (EVE) lauro@eve-usa.com

4. - 4 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Today: people taking about crises! Previous ITRS editions have documented a design productivity gap: the number of available transistors grows faster than the ability to meaningfully design them. Yet, investment in process technology has by far dominated investment in design technology. Good news: Enabling progress in DT continues. :-) Bad news:  Test cost has grown exponentially relative to manufacturing cost.  Today, many design technology gaps are crises. Previous ITRS editions have documented a design productivity gap: the number of available transistors grows faster than the ability to meaningfully design them. Yet, investment in process technology has by far dominated investment in design technology. Good news: Enabling progress in DT continues. :-) Bad news:  Test cost has grown exponentially relative to manufacturing cost.  Today, many design technology gaps are crises. [ ITRS, Design Report 2003, http://public.itrs.net/ ]

5. - 5 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Current approach: Improving DT step-by-step [ ITRS, Design Report 2003, http://public.itrs.net/ ]

6. - 6 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Reuse as a way out Pre-designed standard components to be used. Standard software components Standard hardware components  Platform-based design Pre-designed standard components to be used. Standard software components Standard hardware components  Platform-based design

7. - 7 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Platform-based design A platform is a family of architectures satisfying a set of constraints imposed to allow the reuse of hardware and software components. However, a hardware platform is not enough. Quick, reliable, derivative design requires using a platform application programming interface (API) to extend the platform toward application software. In general, a platform is an abstraction layer that covers many possible refinements to a lower level. Platform-based design is a meet-in-the-middle approach: In the top-down design flow, designers map an instance of the upper platform to an instance of the lower, and propagate design constraints [Sangiovanni-Vincentelli, 2002].

8. - 8 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Platform-based design Platform instances Platform abstraction levels Top-Down: Map an instance of the upper platform onto an lower platform considering appropriate constrains. Bottom-Up: Find the appropriate platform levels. Define platform level parameters

9. - 9 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Platform-based design [Sangiovanni-Vincentelli, DAC 2004] Decouples the application development process from the architectural implementation process. System Platform Stack The main application area. The primary notion of PBD originates here. Network Platforms Equivalent to protocol stacks. Analog Platform Performance models, behavioral models and interconnection models. System Platform Stack The main application area. The primary notion of PBD originates here. Network Platforms Equivalent to protocol stacks. Analog Platform Performance models, behavioral models and interconnection models. Few design areas suitable for PBD:

10. - 10 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Iterative approach (1) Guided by performance evaluation

11. - 11 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Essentially the same with our flow … System architecture Performance simulation Refine System behavior Implementation Mapping

12. - 12 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Iterative approach: SpecC model

13. - 13 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Overview of design activities Task level concurrency management Which tasks in the final system? High level transformations Transformation that are outside the scope of traditional compilers Hardware/software partitioning Which operation mapped to hardware, which to software? Compilation Hardware-aware compilation Scheduling Performed several times, with varying precision Design space exploration Set of possible designs, not just one. Task level concurrency management Which tasks in the final system? High level transformations Transformation that are outside the scope of traditional compilers Hardware/software partitioning Which operation mapped to hardware, which to software? Compilation Hardware-aware compilation Scheduling Performed several times, with varying precision Design space exploration Set of possible designs, not just one.

14. - 14 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Task-level concurrency management Granularity: size of tasks (e.g. in instructions) Readable specifications and efficient implementations can possibly require different task structures.  Granularity changes Granularity: size of tasks (e.g. in instructions) Readable specifications and efficient implementations can possibly require different task structures.  Granularity changes

15. - 15 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Merging of tasks Reduced overhead of context switches, More global optimization of machine code, Reduced overhead for inter-process/task communication. Reduced overhead of context switches, More global optimization of machine code, Reduced overhead for inter-process/task communication.

16. - 16 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Splitting of tasks No blocking of resources while waiting for input, more flexibility for scheduling, possibly improved result. No blocking of resources while waiting for input, more flexibility for scheduling, possibly improved result.

17. - 17 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Merging and splitting of tasks The most appropriate task graph granularity depends upon the context  merging and splitting may be required. Merging and splitting of tasks should be done automatically, depending upon the context. The most appropriate task graph granularity depends upon the context  merging and splitting may be required. Merging and splitting of tasks should be done automatically, depending upon the context.

18. - 18 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Automated rewriting of the task system - Example -

19. - 19 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Attributes of a system that needs rewriting Tasks blocking after they have already started running

20. - 20 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Work by Cortadella et al. 1.Transform each of the tasks into a Petri net, 2.Generate one global Petri net from the nets of the tasks, 3.Partition global net into “sequences of transition” 4.Generate one task from each such sequence 1.Transform each of the tasks into a Petri net, 2.Generate one global Petri net from the nets of the tasks, 3.Partition global net into “sequences of transition” 4.Generate one task from each such sequence Mature, commercial approach not yet available

21. - 21 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Result, as published by Cortadella Reads only at the beginning Initialization task Always true Never true

22. - 22 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Optimized version of Tin Tin () { READ (IN, sample, 1); sum += sample; i++; DATA = sample; d = DATA; L0: if (i < N) return; DATA = sum/N; d = DATA; d = d*c; WRITE(OUT,d,1); sum = 0; i = 0; return; } Tin () { READ (IN, sample, 1); sum += sample; i++; DATA = sample; d = DATA; L0: if (i < N) return; DATA = sum/N; d = DATA; d = d*c; WRITE(OUT,d,1); sum = 0; i = 0; return; } Always true j==i-1 j  i Never true

23. - 23 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Task-level concurrency management (2)  The dynamic behavior of applications getting more attention.  Energy consumption reduction is the main target.  Some classes of applications (i.e. video processing) have a considerable variation in processing power requirements depending on input data.  Static design-time methods becoming insufficient.  Runtime-only methods not feasible for embedded systems.  How about mixed approaches?  The dynamic behavior of applications getting more attention.  Energy consumption reduction is the main target.  Some classes of applications (i.e. video processing) have a considerable variation in processing power requirements depending on input data.  Static design-time methods becoming insufficient.  Runtime-only methods not feasible for embedded systems.  How about mixed approaches?

24. - 24 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Example of a mixed TCM [IMEC, Belgium, http://www.imec.be/] …or they can define a probability for violating the deadline. t Deadline Task1 Task2 Task3 Static (compile-time) methods can ensure WCET feasible schedules, but waste energy in the average case. t E Deadline Runtime scheduler selects the most energy saving, deadline preserving combination. t Deadline Mixed methods use compile-time analysis to define a set of possible execution parameters for each task.

25. - 25 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Example of an mixed TCM [IMEC, Belgium, http://www.imec.be/] „Gray-box“: Extract only the information needed for scheduling. Transformations: Merge and/or split task. (Functionality comparable to Cortadella’s approach.) Find Pareto-curves for each task. Runtime scheduler: uses an heuristic to combine the Pareto-curves.

26. - 26 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Floating-point to fixed point conversion Pros: –Lower cost –Faster –Lower power consumption –Sufficient SQNR, if properly scaled –Suitable for portable applications Cons: –Decreased dynamic range –Finite word-length effect, unless properly scaled Overflow and excessive quantization noise –Extra programming effort Pros: –Lower cost –Faster –Lower power consumption –Sufficient SQNR, if properly scaled –Suitable for portable applications Cons: –Decreased dynamic range –Finite word-length effect, unless properly scaled Overflow and excessive quantization noise –Extra programming effort © Ki-Il Kum, et al. (Seoul National University): A Floating-point To Fixed-point C Converter For Fixed-point Digital Signal Processors, 2nd SUIF Workshop, 1996

27. - 27 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Fixed-Point Data Format S100...000010 hypothetical binary point IWL=3 S100...000010 (a) Integer (b) Fixed-Point FWL © Ki-Il Kum, et al Floating-Point vs. Fixed-Point Integer vs. Fixed-Point –exponent, mantissa –Floating-Point automatic computation and update of each exponent at run-time –Fixed-Point implicit exponent determined off-line –exponent, mantissa –Floating-Point automatic computation and update of each exponent at run-time –Fixed-Point implicit exponent determined off-line

28. - 28 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Assignment and Addition/Subtraction Assume y = x, with -x (IWL=2) and -y (IWL=3): Assume y = x, with -x (IWL=2) and -y (IWL=3): s s x x>>1 y s Let result = x + y: equalizing each IWL s y s result + © Ki-Il Kum, et al s x x>>1 s

29. - 29 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Multiplication Assume result = x * y, with -x (IWL=2) and -y (IWL=3) ->result (IWL=2+3) Assume result = x * y, with -x (IWL=2) and -y (IWL=3) ->result (IWL=2+3) s x * y s s result © Ki-Il Kum, et al s s

30. - 30 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Development Procedure Range Estimation C Program Execution Floating-Point C Program Fixed-Point C Program Floating- Point to Fixed-Point C Program Converter Range Estimator Manual specification IWL information © Ki-Il Kum, et al

31. - 31 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Range Estimator C pre-processor C front-end ID assignment Subroutine call insertion SUIF-to-C converter Floating-Point C Program Range Estimation C Program IWL Information Execution float iir1(float x) { static float s = 0; float y; y = 0.9 * s + x; range(y, 0); s = y; range(s, 1); return y; } float iir1(float x) { static float s = 0; float y; y = 0.9 * s + x; range(y, 0); s = y; range(s, 1); return y; } Range Estimation C Program © Ki-Il Kum, et al

32. - 32 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Floating-Point to Fixed-Point Program Converter int iir1(int x) { static int s = 0; int y; y=sll(mulh(29491,s)+ (x>> 5),1); s = y; return y; } Fixed-Point C Program mulh –to access the upper half of the multiplied result –target dependent implementation sll –to remove 2 nd sign bit –opt. overflow check mulh –to access the upper half of the multiplied result –target dependent implementation sll –to remove 2 nd sign bit –opt. overflow check © Ki-Il Kum, et al

33. - 33 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Floating-Point to Fixed-Point Program Converter int iir1(int x) { static int s = 0; int y; y=sll(mulh(29491,s)+ (x>> 5),1); s = y; return y; } Fixed-Point C Program © Ki-Il Kum, et al 0.9 @ IWL = 0  0 111000011 = 0x7333 = 29491 x IWL = 0 y IWL = 4 s IWL = 4 “mulh” IWL = 0+4+1s = 5  x>>5 for add

34. - 34 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Performance Comparison - Machine Cycles - © Ki-Il Kum, et al

35. - 35 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Performance Comparison - Machine Cycles - © Ki-Il Kum, et al

36. - 36 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Performance Comparison - SNR - © Ki-Il Kum, et al

37. - 37 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Fundamental considerations of tradeoffs by Brodersen (Berkeley)

38. - 38 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Fridge Fixed-Point Programming and Design Environment RWTH Aachen, commercialized by Synopsys as part of the CoCentric tool suite. Uses type definition features of C++ to define abstract data types (i.e. ‘fixed’) Incorporated into SystemC. (It’s used for bit-true simulation.) Needs architecture dependent back-end optimizations. RWTH Aachen, commercialized by Synopsys as part of the CoCentric tool suite. Uses type definition features of C++ to define abstract data types (i.e. ‘fixed’) Incorporated into SystemC. (It’s used for bit-true simulation.) Needs architecture dependent back-end optimizations. [ISS, Aachen, http://www.iss.rwth-aachen.de/]

39. - 39 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Fridge Fixed-Point Programming and Design Environment [ISS, Aachen, http://www.iss.rwth-aachen.de/] Workflow overview: Input: floating-point algorithm + designer supplied annotations. Conversion. Iterative, feedback through simulation. Back-end exploits architectural features. (i.e. mulh, sat, round) Output: Target optimized integer C code. Input: floating-point algorithm + designer supplied annotations. Conversion. Iterative, feedback through simulation. Back-end exploits architectural features. (i.e. mulh, sat, round) Output: Target optimized integer C code.

40. - 40 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Fridge Fixed-Point Programming and Design Environment [ISS, Aachen, http://www.iss.rwth-aachen.de/] DSP Back End Designer annotates some operands (with WL, IWL, …) Hybrid code: Partially converted to fixed-point. Interpolation: Automatic annotate of remaining operands, transfer each operand into fixed-point type. Code Gen.: Generates pure C code. Back End: Optimize for target. Bit-true simulation. Designer annotates some operands (with WL, IWL, …) Hybrid code: Partially converted to fixed-point. Interpolation: Automatic annotate of remaining operands, transfer each operand into fixed-point type. Code Gen.: Generates pure C code. Back End: Optimize for target. Bit-true simulation. Conversion steps:

41. - 41 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Today’s summary Design-Productivity-Gap: No final remedy available, but step-by-step improvements keep costs in a reasonable range. Platform based design: Reuse is the key. PBD is the systematic approach to it. Task-Concurrency-Management: Optimize the task set. Goals: Non-blocking job execution / Increased energy efficiency. Float-point to Fixed-point: Fixed-point arithmetic uses integer operations  Simpler and faster hardware than for float-point operations. Design-Productivity-Gap: No final remedy available, but step-by-step improvements keep costs in a reasonable range. Platform based design: Reuse is the key. PBD is the systematic approach to it. Task-Concurrency-Management: Optimize the task set. Goals: Non-blocking job execution / Increased energy efficiency. Float-point to Fixed-point: Fixed-point arithmetic uses integer operations  Simpler and faster hardware than for float-point operations.