[Next] [Previous] [Up] [Top]

2.0 Code Generation with Ptolemy

2.1 General Framework


To use Ptolemy to implement an algorithm, the problem is represented as a hierarchical dataflow graph. Two interfaces are provided: a graphical interface based on VEM, the graphic editor that is part of U.C. Berkeley's Octtools CAD system [20], and a text interface based on Ousterhout's extensible interpreter language Tcl [21]. The user builds graphs hierarchically out of existing blocks, and may also link in user-written blocks by using Ptolemy's incremental linking facility. A special preprocessor makes user-written atomic blocks (stars) easier to produce.

While this paper focuses on code generation facilities, a key feature of Ptolemy is its ability to interface different models of computation. For example, code on a DSP board can interact with a discrete-event or logic simulation running on a workstation. Similarly, a register-transfer-level simulation of hardware (complete with programmable DSPs modeled functionally) can execute generated code and process signals synthesized in another Ptolemy domain. This gives Ptolemy most of its power when applied to hardware-software codesign. The interfacing mechanism that permits one model of computation, or domain, to interface cleanly with another is called a wormhole, after the theoretical cosmological phenomenon widely used in science fiction writing that may connect widely separated regions of space, or even different universes. This mechanism is described in [6, 19], and is explained in the context of code generation with a simple example given in section 2.5.

All code generation domains are derived from the CG domain. Only the derivative domains are of practical use for generating code. The stars in the CG domain itself can be thought of as "comment generators"; they are useful for testing and debugging schedulers and for little else. The CG domain is intended as a model and a collection of base classes for derivative domains. The code generation class hierarchy is designed to save work and to make the system more maintainable. Most of the work required to allocate memory for buffers, constants, tables, and to generate symbols that are required in code is completely processor-independent; thus these facilities are provided in generic classes.

In the following sections, I will introduce Targets and Stars and detail the methods and data structures needed to write new ones. I will first define a Ptolemy target, introducing the concepts of code streams, code generation methods, and wormhole methods. Next, I will detail what is required to write single-processor target. Afterwards I will define code generation stars and their respective methods. Following that I will describe the various methods which will generally use the addCode() method to piece together the codeblocks into the code streams. Finally I will document the various schedulers available in the code generation domains.


Software Synthesis for Single-Processor DSP Systems Using Ptolemy - 04 SEP 94

[Next] [Previous] [Up] [Top]