The Notation Environment for Jazz was devised to provide an intuitive, structured application-development system in Java. In this comprehensive system-development environment, ease of use is achieved through a structured object-oriented approach to building virtual IP components. Such components are building blocks for algorithms, communication channels and data manipulation. System designers will define a system as a collection of objects. Notation controls the system-level design process and leads the designer through it, ensuring that a controlled description is used for the input to Solo, the compilation system.
The user environment team was faced with a number of significant design challenges in providing such an intuitive development environment while also enabling efficient mapping onto the Jazz architecture. The three most critical requirements were defining the right computation model, supporting verification throughout the design flow and creating a cost-effective design environment.
The Notation Environment is built around the notion of supporting system-level modeling coupled with advanced analysis and compilation tools. A system-level model is an executable description of the system. In this context, the model of the system is developed with the intent to map the system to silicon.
The computational model is centered on the definition of system behavior as a collection of tasks. The functions implemented by a task can be described using a behavioral, operational language. The tasks interact by means of a system-control description that defines a partial-order timing relationship between the tasks.
Tasks in the system consume and create data and the system inevitably has to interact with the outside world, and this interaction is defined by the system interfaces. Finally, to be useful in a real-world environment a system has to conform to certain constraints with respect to time, speed, power and size.
A model of a system is a combination of all those elements. A fifth element that is useful in system-level modeling is a testbench environment. The testbench is not part of the model but is a critical part of the model's success.
Throughout the industry, there is increasing discussion of the need for a "system-level" modeling capability that is both intuitive for modeling complex applications and can be mapped into a highly efficient implementation. Existing system-level modeling methodologies, such as data flow, state charts and synchronous languages have specialized on specific aspects of modeling but have not been able to scale up to the full requirements of system modeling. This has led to the drive for heterogeneous modeling, where different computational models are used for various aspects of an application.
For instance, data-flow models might be developed for specific algorithms and transforms within an application, synchronous language used for the interactive and control aspects of a design, with both of these types of models tied together with hierarchical descriptions. While this approach might work, in the sense that the application can be correctly modeled, it creates an extremely complicated environment to develop compilation, analysis and synthesis tools.
Rather than a heterogeneous, ad-hoc approach, Improv has focused on defining a single computational model that can handle the seemingly conflicting requirements of data flow and control. As a starting point, we looked at the strengths of a variety of modeling methodologies in different domains.
Our conclusion was that hardware-description languages (HDLs) provided strong support for modeling structure and connectivity between concurrent components; behavioral modeling of algorithms and functions is best supported by sequential languages like C; and object-oriented languages worked best for integrating development support directly into the modeling environment.
However, support for managing concurrent execution in these approaches was lacking. In particular, there was no clean separation of data dependencies between tasks and an explicit mechanism for managing the flow of control among multiple tasks. Therefore, Improv developed a modeling paradigm that pulled from the strengths of HDLs, C programming and object-oriented approaches to forge a model of concurrency.
We call this modeling paradigm directed control dataflow networks (DCDNs). Basically, a DCDN consists of a number of nodes representing either tasks or data channels. A task is an executable sequence of behavioral statements. A data channel is a communication channel through which data is passed from one task to another. Tasks can be connected by two types of directional arcs: data arcs and control arcs. Data arcs represent a data-dependency relationship from one task to a data channel. Control arcs connect one task to another and identify that one task fires another task. A task is defined by encapsulating it into a VirtualIP component that has data ports and control ports representing placeholders to the various arcs.
Data channels are defined by encapsulating them into data managers, which can be attached to the data ports of the VirtualIP component. Control connections are created by attaching the output control port of one component to the input control port of another.
A DCDN is constructed by creating a hierarchical structure of VirtualIP components. Components are connected together by attaching data managers through data ports and attaching component control ports to each other. Components can also contain instantiations of other components to create a hierarchical component.
Application developers can associate properties with these components that can be used to provide constraints into the mapping process. It is the job of the mapping tool to address those constraints during the mapping process or at least let the developer know why specific constraints cannot be met.
The DCDN model is implemented as a Java class system called the Notation Framework. The class system is used to describe applications in Java.
Verification is a critical issue in the development of any type of system. System-level verification contains many aspects operating at many levels. For instance, consider a videoconferencing codec chip. The application might have a display and interface showing a picture, picture-in-picture and menu system that needs to be verified by examining the display. The codec must support a specific bit rate, based on the connection channel, and display at standardized frame rates, requiring broad performance analysis of the application over large frame sets.
The Notation Debug tool takes advantage of Java's capabilities to provide functional simulation support directly in the Java class system implementing our DCDN framework. The Notation Framework has a built-in run-time system that interacts directly with the application developer's test bench.
Once the compiler has been run on the app code, the assembly-level code can be read into an instruction-set simulator (ISS) to allow verification at the cycle-accurate level. The ISS simulates all the processing engines running in parallel.
The final form of verification is to run the chip loaded with the application in the system in which it is intended to operate. This can take two forms.
Before mapping the application onto a physical chip, the ISS can be embedded inside an HDL (VHDL or Verilog) wrapper and run within an HDL simulation of the system. After mapping, the chip can be run in-system on an evaluation board, with a debug driver interacting with a host to provide debug or timing information.