[Next] [Previous] [Top]
Managing Complexity in Heterogeneous System Specification, Simulation, and Synthesis
A design methodology specifies a sequence (flow) of tools that operate on data. Design methodology management (DMM) is formally defined as "definition, execution, and control of design methodologies in a flexible and configurable way" [9]. The problems encountered in DMM are: data, tool, and flow management.
DMM as such is not new; traditional DMM systems (often referred to as "frameworks") are used quite extensively in the physical VLSI design process. These systems [10][11] focus on data and tool management, i.e., maintaining consistent versions of data, and invoking a user-specified tool after ensuring that the preconditions for enabling it are satisfied, respectively. The key to system-level design, however, is design space exploration. At the system level, design flows are less well-defined than at the physical design level, and the range of tools involved is much larger. Powerful constructs for flow definition, dependency analysis, and automated flow execution dominate the system-level design process. Our focus is to manage the complexity of the "system-level" design problem, with emphasis on flow management.
Figure 2 illustrates the details of the components of our DMM mechanism. A design flow is specified as a directed graph, where nodes represent tools, and arcs specify the ordering between tools. Tools communicate via filenames and encapsulate actual programs. Tool parameters specify the arguments for these programs. A tool's inputs and outputs are associated with its ports. Ports can be of two types: required and optional. Optional ports make it possible to represent conditionals and iterations in flows (illustrated in Section 4.2).
The information model is represented as a distributed data structure. Associated with each tool is a Param_Changed_Flag that gets set when parameters of a tool are changed. Associated with each port of a tool are three attributes: File_Name, Time_Stamp, and Optional_Flag. File_Name and Time_Stamp represent the filename and the timestamp of the data on the port (associated with the most recent invocation of the tool). Optional_Flag indicates whether the port is required or optional.
3.2 Dependencies
Figure 3
shows the three types of dependencies that are supported. Temporal dependencies track the timestamps on input-output ports of the tools -- a tool needs to be run if any of its output is out-of-date, i.e., any of its input timestamps are newer than its output timestamps. Data dependency ensures that a tool is run whenever the file received on any of its input ports has either a filename or a timestamp that is different from the previous tool invocation. Control dependency tracks parameter changes; a tool needs to be run if any of its parameters has changed.
3.3 Flow Management
Automatic flow invocation is based on analyzing the tool dependencies and executing tools as required. A tool is said to be enabled when all of its required input ports have data. Absence of data on the optional input ports does not affect enabling. Once enabled, a tool is checked for dependencies. A tool is invoked (run) when at least one of its dependencies is live. On execution, a tool generates data on its required output ports, and conditionally on the optional output ports. Two types of flow invocation mechanisms are desired: data-driven, and demand-driven (Figure 4). In the data-driven approach, the flow scheduler traverses the flow according to precedences. The process halts when all tools with live dependencies have been exhausted. In the demand-driven mode, the user selects a tool for execution. The scheduler traverses the predecessors and executes all tools with live dependencies on the path.
Managing Complexity in Heterogeneous System Specification, Simulation, and Synthesis
[Next] [Previous] [Top]