RASSP Methodology Application Note

There are three library population software development activities which must be supported:

1. building a signal processing primitive library element,
2. building an operating system primitive library element, and
3. developing hardware models.

These three functions are shown in Figure 10 - 1 and discussed in the following paragraphs.

To build a new primitive, the primitive generation tool(s) should interact with the user (i.e., application programmer) to construct the prototype for experimentation in the architecture design process. Templates for prototype primitives are stored in the library to support the developer. These templates provide the encapsulation wrappers to interface with the various tools in the system. Approximate timing information for the primitive (for the processor type(s) of interest) must also be generated or estimated to support the architecture trade-off process. This timing information may be updated as the primitive validation proceeds.

After developing the prototype element, the architecture definition process can proceed. We can use the prototype element in the synthesis, evaluation, and trade-off of candidate architectures during hardware/software codesign.

We continue library population by validating the prototype element for permanent inclusion in the library. There is more to the library validation process than simply validating the prototype code. To be a permanent library element, the code must be generated as a domain-primitive suitable for constructing domain-primitive graphs that are architecture-independent. We must validate it over a broad range of test stimulus, document it as a permanent part of the library, and model it in terms of performance on all processor types in the library. This process is aided by templates maintained in the library.

As we validate the prototype code and add support for the code generation process and validate it, the new library element can be used in the autocode generation. It should be noted that library elements may be optimized, which could result in multiple implementations of the primitive being maintained in the library. For some processors, it may be appropriate to optimize the primitive in assembly language or microcode to maximize performance. Translations of the domain-level primitive to the target processors of interest will be maintained in the library in the form of target processor mappings.

In addition to validating that the code produced is functionally correct, the validation process must produce the necessary documentation elements that are also maintained in the library. This documentation should include the test suites used and the resulting test report.

Adding a non-computational architectural element, such as a communication element (e.g., cross bar switch), processor interface, or I/O interface, may require modifications or additions to the application support software maintained in the reuse library. In many cases, the new element requires additions or modifications of operating system kernel support functions, such as drivers or mapping tables, which provide the operating system services to the applications.

The addition of a new operating system requires that all operating system services that are assumed to be available for any processor of interest must be generated for each processor type for which the new operating system is intended for use. We assume that the operating system vendor has provided the operating system for one or more specific processors, and that only the operating system services required to support the application program interface to the run-time system are required.

When we insert a computational element as a new architectural element, we assume that the required HOL compiler(s) is available for the processor. In the RASSP methodology, the atomic computational element may be any general-purpose processor or DSP that is supported by a HOL compiler and/or assembler.

Adding a new computational element requires that we modify other existing library information, or add new library functions. First, the functional performance of all application-primitive elements intended for the new computational element must be verified; that is, they must compile and execute the test suite to produce the correct results. To provide the information required for the hardware/software codesign process, we must update the application primitives and the operating system services elements to incorporate timing estimates for the new computational element. This process must be performed for all primitives in the library available for the new computational element. In addition, to support automated generation of software for the target hardware, an operating system that provides the standard set of services required to support the methodology must be validated for the new computational element. Specialized microcoded functions (such as math libraries) for the new element must also be incorporated into the library so that primitives use the optimum code when translated and compiled for the new computational element.