RASSP Methodology Application Note

3.1 What are Workflows

The workflows are hierarchical in nature - representing the various disciplines associated with electronic design. The options available to a user organization are either to make use of the workflows in their current form or to develop plans based on a combination of reuse of workflow segments, individual process steps or augmentation of workflow segments with custom user process steps.

Synchronization refers to the relative timing of the process paths that either converge into or diverge out of a junction. A synchronous fan-in junction indicates that all processes connected to the input of the junction must complete simultaneously before the UOB connected to the output of the junction will be activated. If the fan-in is asynchronous, there is no timing constraint imposed on the completion of the input processes.

• Start - Start: The dependent process can begin a soon as the parent process begins, but not before. No completion order is implied.

• Start - Finish: The dependent process cannot complete successfully until the parent process starts. No starting order is implied.

• Finish - Start: The dependent process cannot begin until the parent process completes with the chosen exit status (exit statuses are defined by the implementation)

• Finish - Finish: The dependent process cannot complete successfully until the parent process completes with the chosen exit status. Either process may begin first.

• Concurrent: This is a combination of Start-Start and Finish-Finish. The dependent process cannot begin until the parent process begins, and cannot be completed until the parent process completes with the chosen exit status.

• Cascade: The dependent process cannot begin until the parent process completes with the chosen exit status, and is immediately and automatically invoked when the parent process completes with that status. Cascade connections are used to automatically trigger processes when the design passes a certain point.

• Fail (Reset): The dependent process and any downstream processes are marked as invalidated when the parent process completes with a status that activates a fail connection. It is useful to think of the fail connection as "Reset" -- it resets the workflow to a previous state based on a particular exit status that may or may not be a true "failure" condition.

• Fail Cascade: When a process completes with a status that activates a fail-cascade connection, the dependent process and all downstream processes are marked as never having started. The dependent process connected to the fail-cascade link is immediately launched.

P:SS for Start - Start
P:SF for Start - Finish
P:FS for Finish - Start
P:FF for Finish - Finish
P:CO for Concurrent
P:CA for Cascade
P:FR for Fail (Reset)
P:FC for Fail - Cascade

3.4 Modeling Example

• Process steps
• Precedence relationships between process steps
• Personnel roles authorized/required to perform workflow
• Information objects involved (created, used, modified, destroyed, etc.) in the process step
• Tools to be launched or controlled at each step

Although it is not the purpose of this Appendix to present IDEF3X concepts in depth, a quick review is in order. The text attached to the UOBs are called Business Items. These are place holders for actual file system items which contain the design data. There are four different types of Business Items or ICOMs. The inputs and outputs are self-explanatory. The controls are documents that can be referred such as libraries or specifications. The Mechanisms are the tools and personnel resources required to execute the process step.
The syntax of an input or output Business Item is:

[Grouped]*State*Business_Item_Name.

The [Grouped] term is optional. If it is present, (as in Grouped*Developed*SD Test Architecture and TSD 2.1.3 in Figure 3 - 1), it indicates that the Business Item actually consists of multiple file system items (files or directories). For example, Grouped*Developed*SD Test Architecture and TSD is made up of the file system entities:

Developed*SD Test Architecture
Developed*SD TSD
Developed*SD Test Plans
Developed*SD Test Procedures
Developed*SD Fault Model

The word "Developed" indicates the state of the Test Architecture and TSD. In this case, the data items have just been created during the process step 2.1.3.

Other states which are used are:

Developed: An item which has just been created during a process step Updated/Refined: A "Developed" item which has been updated/refined during a process step

Preliminary/Verified: An "Updated" item which has been refined and (possibly) simulated and is ready to be approved

Approved: A "Preliminary/Verified" item which has gone through some type of approval or Design Review cycle. The actual level of approval necessary to transition an item to an "Approved" state varies depending on the particular instantiation of the Design Reviews. It can vary from workflow to workflow and also from one implementation to another. There are several different states available:

Generated: An item which is automatically produced from a tool

Qualified: Refers to the skill designation which a person must have in order to be able to execute the process step

Responsible: Indicates which personnel resource will have the authority to transition the process step

Released: Refers to the status of a tool (Currently this is the only status used for tools)

Variable: Indicates that the data item is a pointer to a group of data items, one of which will be chosen based on decisions made during the execution of the program plan. For example, a particular processor may be chosen during a process step. Further on in the program plan, the generic code for that processor will be targeted using a library specific to that processor. The target library for the processor is one of the members of the "Variable*Target Libraries" (on the Architecture Definition:Architecture Verification Workflow).

In Figure 3 - 1, the workflow begins with the process step Architecture Sizing. In the Activity Definitions, it indicates that the purpose of this activity is to analyze the system requirements and processing flows for all required modes in terms of estimated operations per second, memory requirements, and I/O bandwidths. The resulting functional processing flows represent the detailed algorithms that must be performed for each required mode.

The inputs for this activity are the Business Items:
Grouped*Approved*Algorithm Flows
Grouped*Approved*Control Flows

The controls for this activity are:
Approved*RASSP Reuse Library
Grouped*Approved*System Specification
The outputs for this activity are:
Grouped*Developed*FD Sizing Estimates
Grouped*Developed*Non-DFG Software Requirements
Grouped*Developed*Functional Processing Designs
Grouped*Developed*Command Processing Designs

The tool mechanisms are:
Released*RDD뀬
Released*Aspect RRDM
Released*ALTA SPW
Released*Mathworks MATLAB
Released*EXCEL
Released*WORD

The personnel mechanisms are:
Qualified*Architecture Engineer
Qualified*Software Engineer

The other two activities can be analyzed similarly. It is important to distinguish between junction boxes which are used to distribute/collect data to/from multiple process blocks and junction boxes which are used to indicate precedence. Some Business Items which are outputs of 2.1.1 are directed to 2.1.2 and 2.1.3 via asynchronous "AND" junction boxes. In this case, no timing is implied. Note that similar boxes are used to direct the precedence links out of 2.1.1 to 2.1.2 and 2.1.3. These precedence links indicate that when 2.1.1 finishes, 2.1.2 and 2.1.3 become startable.

For readability purposes, the attached leaf-level Architecture workflows do not have the precedence links indicated on them.