Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Hardware/Software Codesign."— Presentation transcript:

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

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

3 - 3 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund © Lauro Rizzatti Marketing Vice President Emulation & Verification Engineering (EVE)

4 - 4 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 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

5 - 5 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 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].

6 - 6 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Iterative approach (1) Guided by performance evaluation

7 - 7 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Essentially the same with our flow … Mapping

8 - 8 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Iterative approach: SpecC model

9 - 9 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 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.

10  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 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

11  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 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.

12  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 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.

13  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 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.

14  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Automated rewriting of the task system - Example -

15  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Attributes of a system that needs rewriting Tasks blocking after they have already started running

16  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Work by Costadella 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

17  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Result, as published by Cortadella Reads only at the beginning Initialization task Always true Never true

18  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 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

19  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 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

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

21  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 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 s x x>>1 y s s result + © Ki-Il Kum, et al

22  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 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

23  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 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

24  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 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 check runtime overflows mulh –to access the upper half of the multiplied result –target dependent implementation sll –to check runtime overflows © Ki-Il Kum, et al

25  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Performance Comparison - Machine Cycles - © Ki-Il Kum, et al

26  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Performance Comparison - Machine Cycles - © Ki-Il Kum, et al

27  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Performance Comparison - SNR - © Ki-Il Kum, et al

28  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Fundamental considerations of tradeoffs by Brodersen (Berkeley)

29  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Fridge RWTH Aachen, commercialized by Synopsys as part of the CoCentric tool suite. Used type definition features of C++ to define types Fixed and fixed. Using types in declarations: fixed a, *b, c[8] Defining types in assignments: a= fixed(5,4,wt,*b) RWTH Aachen, commercialized by Synopsys as part of the CoCentric tool suite. Used type definition features of C++ to define types Fixed and fixed. Using types in declarations: fixed a, *b, c[8] Defining types in assignments: a= fixed(5,4,wt,*b) Word-length Wrap-around truncation Fractional wordlength

30  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Other work on the topic Fridge (RWTH Aachen), commercialized by Synopsys Some support in Simulink (MATLAB toolbox).. hundreds of papers on the topic. Fridge (RWTH Aachen), commercialized by Synopsys Some support in Simulink (MATLAB toolbox).. hundreds of papers on the topic.


Download ppt "- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Hardware/Software Codesign."

Similar presentations


Ads by Google