The Symbolic Program approach, which we introduced in this thesis, is positioned between the Symbolic Instruction Trace (SIT) approach, as in theSpade[7] and theSesame[36] exploration driven approaches and the Control Data-Flow Graph (CDFG) approach, as in
the MTG-DF* [25, 38] design-driven approach. The SP approach and its positioning has
been shown in Figure 5.1. On the left-hand side, the typical sequence of activities using SIT is depicted. Similarly, on the right-hand side, the typical flow of activities using CDFG is shown. Finally, in the middle, the SP flow is shown; SPs allow designers (1) to perform design-steps as in the case of detailed design (indicated with dashed lines), (2) to run fast simulations of architectures being explored, and (3) to have more accurate numbers than in the case of TD simulations.
Control Trace Symbolic Program Symbolic Program’ Trace’ CDFG’ CDFG CDFG Generator CDFG Transformations Trace’ Trace Trace Generator Simulator Architecture Simulator Architecture High ACCURACY Low ACCURACY
High SIMULATION SPEED Low SIMULATION SPEED
B
A C
Application model (Kahn PN)
Compile
SP Approach
(annotated) YAPI code YAPI (source) code (annotated) YAPI code
CDFG Approach
T R A N S F O R M A T I O N S T E P S
YAPI (source) code
Instruction Stream Stream Data Ctrl. Trace TD Approach Architecture Simulator Data Data Generator Generator Symb. Prog. Control Trace’ Transformations Transformations Symb. Prog. Ctrl. Trace Trace Generator Trace Transformations OBJ. code Data Instruction Stream Instructions Architecture Specification Architecture Specification Architecture Architecture Specification Specification
Figure 5.1: The Symbolic Program approach vs. SIT & CDFG approaches (repeated Fig- ure 2.1).
Applications are modeled using Kahn’s MoC. Process behaviors are captured in Symbolic In- struction Traces (left), Symbolic Programs plus separated Control Traces (center), or Control Data-Flow Graphs (right). The SP approach allows for a performance analysis with accepted as well as simulation speed, whereas the other two approaches either have low accuracy or low simulation speed, respectively. The SP approach is, thus, a hybrid approach. Applications processes are abstracted by means of (1) generic non-executable CDFG-like representations of a process and (2) a symbolic instruction trace that captures conditional construct outcomes that are the result of the execution of a single data-set. The behavioral models of archi-
tecture components are derived from SI traces which in turn are determined by interpreting transformed application SPs in the light of control outcomes which are derived from control traces. It is worth noting here that the SP representations are repeating separation of concerns between control-traces and symbolic program data-structures. In Figure 5.1 these are marked as Data Stream (data-dependent part) and Instruction Stream (data-independent part). This is exactly the reason whyArchercan reuse application representations in mappings without changing underlying architecture specifications and why e.g.Sesamecannot guarantee the same. Moreover, this also ends-up in many other flexibilities for architecture, architecture and mapping modelings we presented in the preceding chapters.
The architecture models in the three approaches are very simple (left), very flexible (center), and very detailed (right). See also Chapter 3.
5.2.1
Symbolic Program Flow Details
Figure 5.2 shows the flow of the SP approach in more details. After a parallel application (process network) specification is obtained, each process is parsed and SP abstractions are derived. The SP abstractions assume that some basic blocks of the original application pro- cess are going to be substituted by symbolic instructions, and that some control points of the original application process are going to be annotated. A designer is the one who selects whether a basic block or a control point is going to be annotated or not. This is indicated with the label “Abstraction of details”.
Once the application sources and abstraction assumptions are ready, a tool based on the gen- eral purpose C/C++ parser [87] can translate them into the data-set independent SPs and control annotated application sources. The workstation symbol in Figure 5.2, with the label “Parser” above it, represents this tool. The control annotated application sources are then compiled and run on a single data set in order to check functional correctness. The resulting simulation is an untimed simulation, since no architecture restrictions are applied yet. The workstation symbol in Figure 5.2, with the label “Untimed Simulation” above it, represents the above. At this point the annotated control points generate control trace outcomes. These control traces represent the data-set dependent part of the SP representation.
In parallel with the previous steps, an architecture specification is obtained. The specification is given in terms of platform parameters, i.e., a number of units, types of units, properties of units such as delays, policies and the platform topology.
The key Y-chart part, the mapping, connects the SP application representation (both SPs and control traces) with the architecture specification, i.e., maps application processes onto architecture units. The product of this binding is a source code file which can be compiled and run on an architecture simulator. When it comes to symbolic programs, they are translated to the corresponding data structure. This data structure is often known as a parse tree. At the same time, control traces which correspond to symbolic programs are connected with these parse trees. These two inputs are forwarded to each architecture component on top of which a process from the process network is mapped.
Each architecture component is instantiated according to an architecture specification. Also, architecture components are generic Transaction Level Modeling (TLM) [3] building blocks.
They describe only a timing behavior, and not a functional behavior. A set of parameters that is given in the architecture specification is directly related to the timing behavior of a particular component. SPs (abstracted CDFGs) Specification of Architecture Instance Control Annotated PN Source Control Traces’ Outcomes Selected
Control Points & Basic Blocks
Process Network Source
Performance Numbers for the
Data Set Data Input (Single Data Set) Untimed Simulation Timed Simulation Parser
YAPI or other C/C++ code
Abstraction of details
Units (type, #, delays) Topology, Policies
Still image, motion image, etc.
Mapping (Binding)
Figure 5.2: The flow of the Symbolic Program approach. The inputs are: (1) an application process network, (2) intra-process-level abstractions, (3) a data set, and (4) an architecture specification. The data-set independent parts of the application model are captured in (5) SPs, and the data-set dependent part of the application model are captured in (6) control trace outcomes.
After mapping is done, application and architecture are co-simulated, with functional behav- ior being captured by the non-timed application model, and non-functional behavior being captured by the timed architecture model. See also Chapter 1. The mapping step is not fully automated because DSE feedback loops are not taken into account here. Therefore, in Figure 5.2 the mapping step is shown as a puzzle - it requires a designer input.
After the simulation has completed one can choose to perform transformations and changes on SPs and control traces, architecture specifications, or data-sets (which again affects control traces) in order to see how different application-architecture combinations will behave when evaluated in subsequent simulations.
5.2.2
Directions for Improvements
The Symbolic Program approach has its pros compared with the approaches in the same field. We have emphasised them many times in this thesis. However, the approach has many points of improvement as well. The most critical one is the absence of both the front-end and back-end tools that interface to the designer. By the front-end tool we mean a tool that automates the following designer actions: (1) derivations of SP texts, and (2) annotations of control-points of interest. By the back-end tool we mean a tool that collects the performance numbers ofN simulations of interests and then performs (semi-)automatic analysis of these numbers.