Managing Complexity in Heterogeneous System Specification, Simulation, and Synthesis
Figure 5 illustrates a particular design flow example within DesignMaker. It represents the design flow for the automated synthesis of the hardware (netlist) and the software (programs running on the processors) components of a multiprocessor system that implements a given application. A dataflow graph G (GraphName) describing the application (ex: music synthesis) and a specific interprocessor communication mechanism (Architecture) are specified by the user. The goal is to synthesize this multiprocessor system with the minimum number of processors such that required latency is met. We now run through a typical flow execution sequence to demonstrate the effects of the various constructs and dependencies.
Suppose that the flow is run the very first time using Run All. Tools are examined for active dependencies by traversing the flow according to precedence ordering between tools. Source (T1) outputs the dataflow graph G specified by GraphName. NumProcEstimator (T2) and Code Generator (T6) are dependent on T1. Note that T2 is enabled, while T6 is not (second input N, has not yet been generated). T2 is a hierarchical description of the estimation process, which iteratively determines the minimum number of processors required to implement G at the desired latency.
ProcEstimator (T3) estimates the number of processors (N) required to implement G. Estimators of different accuracy can be selected by changing parameters of this block. Suppose that the desired latency is 320 cycles and the sum of execution times of all the nodes in G is 900. A possible estimator would assume maximum parallelism to estimate a lower bound of 3 processors. T3 has an optional input that receives an indication as to whether or not the current N satisfies the latency requirements. When this input is available, T3 uses it to improve the estimate for N. Note that the loop (T3-T4-T5) does not deadlock because this input is optional. The Scheduler (T4) schedules G onto N (=3) processors and determines the actual time required (makespan M) to implement G. T4 detects convergence of the estimation loop if the value of N generated by T3 in consecutive iterations is the same. T4 generates outputs conditionally -- it generates output N if the iteration has converged, else it generates output M and the it The Code Generator (T6) is now invoked. T6 uses the N-processor schedule to synthesize software for the N processors. A parameter for T6 is used to select the type of code generator. T7 generates the netlist for the system. The generated architectural model, where the processors run the synthesized software is then simulated by the Simulator (T8). As no more dependencies are alive, the flow execution stops. Subsequent changes to the flow or data could render parts of the flow invalid. For instance, suppose that the input to T8 is modified externally and the Run All command is re-issued. The timestamp on the input to T8 is different from that in its most recent invocation, causing the timestamp data dependency to be activated. As no other dependencies are active, only T8 is invoked. If the system is run again and no data files or arguments have changed, then no tool is invoked.
Conditionals prevent unnecessary tool invocations. For instance, although T6 and T7 are data-dependent on T4, they are invoked only when there is new data on their inputs and not unconditionally whenever T4 runs. Control dependencies track parameter changes. For instance, if GraphName is changed, T1 is first invoked due to a control dependency. This activates a filename data dependency for T2 as the input data (GraphName) changes, causing it to be invoked. Other tools on the downstream flow that are data-dependent on T2 (complete flow) are similarly invoked. Suppose that the type of code generator is changed by changing a parameter for T6, only T6 and its downstream tools (T7, T8) are invoked. The Run Upto option implements the demand-driven flow scheduler, while Run Tool allows a specific tool to be invoked by the user (it is run only if enabled).
Note than the DesignMaker is much more powerful than a graphical make [13] utility. Specification of iteration, hierarchy, and conditionals in the design flow, allowing optional inputs and outputs for tools, ensuring tool compatibility, and detecting argument changes are some of the additional features. The DesignMaker environment also makes it possible to track designs and design flows, store a library of flows, and maintain a history of the design.