ASSET A methodology for heterogeneous design of real time embedded systems '

1
ASSET A methodology for heterogeneous design of
real time embedded systems .

• Prof.M.Balakrishnan
• Presenting the work done by Embedded Systems
  Group, IIT Delhi, India.

2
Motivation

• Embedded systems becoming a part of everyday
  life.
• System on silicon becoming a reality.
• Traditional ad-hoc techniques no longer viable.
• Drive towards automated system design.
• In this project we target computation dominated
  embedded systems.

3
Previous approaches - Polis

• FSM based methodology.
• Suitable for small control dominated systems.
• Supports formal verification.
• Simulation through Ptolemy.
• Restricted architecture support.

4
- COSYMA

• Software oriented approach
• Automated partitioning and co-processor
  synthesis.
• Single thread of execution.
• Limited architectures supported.
• No formal verification.

5
- Chinook

• Intended for control dominated designs.
• Specification in Verilog.
• Automated interface and device driver synthesis.
• Single simulation environment for complete
  design.
• Supports wide range of architectures.

6
- Ptolemy

• Modeling of heterogeneous systems.
• Supports various models of computation (domains).
• New domains can be defined.

7
- TSS

• Simulation of complex hardware designs.
• Modules written in C.
• Can mix levels of abstraction.
• Interfaces to Leapfrog and Verilog XL simulators.
• Cycle level accurate.

8
Methodology
9
ESIR Embedded Systems Internal Representation

• Storehouse of information.
• Uses SUIF for providing the data structures.
• SUIF annotations used to add information to the
  application syntax tree.

10
- Different views

• Internal Representation for ASSET
• Input/Output for all tools.
• Abstract syntax tree
• With annotations.
• A database
• With query functions.

11
- Example
12
Specification

• Application specified in C.
• Strengths
• Good for specification of large systems.
• Available software.
• Weaknesses
• Parallelism.
• Real time constraints.

13
- MPI Message Passing Interface

• Concurrent processes.
• Point to point communication.
• Blocking and non blocking calls.
• No shared memory.
• A subset selected.

14
- Pthreads POSIX threads

• Multiple threads.
• Create and join calls.
• Shared memory.
• A subset selected.
• Each MPI process allowed to have multiple threads.

15
- Constraints

• Specified as comments in C code.
• Have a defined grammar.
• Rate, timeout, latency constraints.
• Inter and intra process constraints.

16
- Architecture Template

• Quick evaluation of alternate architectures.
• Structural VHDL file.
• Resource libraries.
• Processor selector evaluation used as guideline.
• Attached as an annotation to the AST.

17
Processor Selector

• Matching application
• with the processors.
• Identification of application
• characteristics.
• Capturing processor features.
• Also for software estimation.

18
- Architecture

• Types of functional units and their properties.
• Number of each type available.
• Number of registers.
• Slots for each operation.
• Load/Store in parallel.

19
- Application Parameters

• Average block size.
• Number of mac operations.
• Address ALU utilization.
• Memory bandwidth requirement.
• ASAP schedule and average arc length.

20
- Constraint Scheduler

• Scheduling application on processor.
• Profiler results used.
• Assumptions -
• Infinite register file.
• All operations on registers.
• All blocks executed sequentially.
• First fit heuristic for mapping functions to FUs.
  

21
- Results (MPEG Case Study)
22
- Design Flow
23
Partitioning

• Process/function level partitioning.
• Single processor, multiple FPGAs.
• Algorithms developed using
• Dynamic programming.
• Integer linear programming

24
Cosimulation

• Functional simulation.
• Software in C, hardware in VHDL.
• Trimedia and Leapforg simulators used.
• Currently, channels implemented using files.
• Ptolemy studied but presently not used.

25
- Tool
26
Case Study

• Tracking application
• Vision based.
• Computation intensive.

27
- Testing

• Application coded using MPI and Pthreads.
• Translated to ESIR.

28
Conclusion

• Methodology in place.
• ESIR developed and some annotations defined.
• Processor selector, partitioner and cosimulator
  developed.
• More tools to be developed and the existing ones
  refined.

29
References

• Project technical reports
• TR 99/1 - 99/9
• Website
• http//www.cse.iitd.ernet.in/esproject