pigi. For example, if the value of the signal parameter is:
Another useful Utilities command is DFT ("^"), which reads a signal just as above and plots the magnitude and phase of the discrete-time Fourier transform of the signal. These are plotted as a function of frequency normalized to the sampling rate, from
vemcommand move-objects ("m") in the Selection menu to do this. You can move objects as follows:
vem"Selection" menu. To do this, first select the object or objects you wish to copy. Then place a point in the center of the object. Then place a second point in the location where you would like the new object, and type "x". The new object starts life selected, so you can immediately move it, or type "control-u" to unselect it. As of this writing,
vemunfortunately does not allow you to copy objects from one facet to another.
vemedit-label ("E") command in the "Edit" menu will do this. It takes two arguments: a point specifying the position of the label, and the name of a layer, which determines the color of the label. Place a point where you would like the label, and then type a layer name, such as "blackSolid" (with the quotation marks). Then type "E". An Athena widget dialog box like that on page 2-25 will appear, offering various options. Type the text for your label in the "Label" box. It can contain carriage returns to get more than one line of text. To select a text height (font size) you can move the slider to the right of the "Text Height" box. The middle button moves the slider by large amounts, and the left and right buttons are used for fine tuning. The initial default is 40, in releases earlier than Ptolemy 0.6, the default was 100, which was too big for all but the loudest titles. Sizes 60 and 40 work well with the overall scaling of Ptolemy facets. You can also change the justification by clicking the left button to the right of each justification box. A pop-up menu lists the options. The colors recommended for labels are:
2.12.5 Icon orientation
Most Ptolemy icons have inputs coming in from the left and outputs going out to the right. To get better looking diagrams, you may sometimes wish to reorient the icons. This can be done with the
vem command "transform" ("t"). Select the icon you wish to transform and type "t" as many times as necessary to get the desired orientation. Each time, you get a 90 degree rotation. Then execute the move-object "m" to commit the change. Notice that a 180 degree rotation results in an upside down icon. To avoid this, reflect the icon rather than rotating it. To reflect it in the vertical direction (exchanging what's on top for what's on the bottom), select the object, type "my" (include the quotation marks), type "t" to transform, and "m" to move. To reflect along the horizontal direction, use "mx" instead of "my". In summary:
2.12.6 Finding the names of terminals
Some stars have several terminals, each with a different function. The documentation may refer to these terminals only by name. Unfortunately, the name of a terminal is not normally visible when an icon is viewed with normal scaling. However, zooming in will eventually reveal the name. The easiest way to do this is to draw a box around the terminal and open a new window with the "o" command. Then you can zoom in if necessary. Future versions of Ptolemy will hopefully have a better mechanism.
2.12.7 Multiple inputs and outputs
Ptolemy supports star definitions that do not specify how many inputs or outputs there are. The
Fork stars are defined this way, for instance. Consider the following two icons, found in the "arithmetic" palette of the SDF domain:
Let's go through an example of how to create a star icon that has multiple input terminals based on an existing Ptolemy star that supports multiple inputs. Suppose you need an icon for an adder with eight inputs. As of this writing, unfortunately, you need to have write permission in the directory in which Ptolemy icons are stored to create this new icon. Alternatively, you can create your own version of the star in your own directory (see the programmer's manual). If you have write permission in the directory where the icons are stored, then you can create a new icon with eight inputs as follows.
pigi command "Extend:make-star" ("*"). A dialog box appears. Enter "Add.input=8" for the star name, "SDF" for the domain, and "$PTOLEMY/src/domains/sdf/stars" for the star src directory (assuming this is where the source code is stored). Note that "input" is the name of the particular multiple input that we want to specify. If you do not know where the source code is stored, then just look-inside ("i") an existing instance of the star. The
vem console window and the header of the editing window that open both tell where the star source code is. A second dialog box appears asking you where you would like the icon put. Accept the default, "./user.pal". Then open user.pal using "O" to see the new eight-input adder icon. You may edit this icon, as explained in
"Editing Icons" on page 2-46.
2.12.8 Using delays
In several domains, delays can be placed on arcs. A delay is not a star, but rather is a property of the arc connecting two stars. The interpretation of the delay in the dataflow domains (SDF, DDF, BDF, and most code generation domains) is as an initial particle on the arc. An initial particle for the scalar data types is one whose value is zero. When the arc passes particles containing "message" type data, a delay on the arc will create an "empty" message. Most often, the destination star of the arc must be able to interpret such "empty" messages explicitly in context of the user-defined type because a "zero" might have different meanings depending on the type. Any feedback loop in the SDF domain must have a delay, or the computation in the loop would not be able to begin.
pigi, the user places a delay icon on top of the wire connecting two instances. The delay icon is a white diamond with a green border in the SDF and system palettes. You can specify the number of delays by executing edit-params with the cursor on top of the delay icon.
pigi, a single output can be connected to any number of inputs, as one would expect. The interpretation in most domains is that the one output is broadcast to all the inputs. There are several point-to-point connections, therefore, represented by the net.
vem stores connectivity information in the form of netlists, simply listing all terminals that are connected together. If a delay appears somewhere on a net, and that net has more than one point-to-point connection, then it is not easy to determine for which connection(s) the delay is intended. Consequently, at the time of this writing, delays are disallowed on nets with more than one connection. If you attempt to put a delay on such a net, then when you try to run the system, an error message will be issued, and the offending net will be highlighted. To get rid of the highlighting, execute the
pigi command "Edit:clear-marks". To fix the problem, delete the offending net, and replace it with one or more
fork stars and a set of point-to-point connections. An incorrect and correct example are shown below:
fork star cannot fire until the
add star does, but the
add star cannot fire until the
fork star produces its output.
Vem knows nothing about multiple inputs, so it sees a net with more than one output and more than one input. Ptolemy is not given enough information to reconcile this and figure out which outputs should be connected to which inputs. To avoid this problem, it is again necessary to use explicit fork stars, as shown below:
2.12.10 Dealing with errors
Ptolemy is composed of several components, as shown in figure
2-8 on page 34. When errors occur, it helps to know which component detected the error so that it can be corrected.
When errors occur in
vem prints the error in the console window. For example, if you enter a point argument and execute create when the cursor is not over an instance, then
vem displays the message "Can't find any instance under spot." Usually,
vem errors are easy to fix. In this case,
vem expects the user to specify the instance to be created.
pigiRpc process can occur when any of the
pigi commands are invoked. The error messages, in this case, are displayed in a popup window, which is much more helpful. Error messages may also be displayed in the xterm window in which
pigi was started. In addition,
pigi often highlights in red the object in the schematic associated with the error. When this happens, you can execute the clear-marks command to clear the highlighting. If such an error occurs and the reason for the error is not obvious, try deleting the indicated objects and redrawing them.
2.12.11 Copying and moving designs
In one of our examples, we used
cp -r to make a copy of a facet. In general, however, copying entire designs this way does not work. For it to work in the general case, you must also change some data in the facets that you copy. In particular, each facet has pointers to the icons it uses. If you move a galaxy, for example, then any pointer to the icon for that galaxy becomes invalid (or "inconsistent" in
masters has been provided for this purpose. This replaces the program from the
octtools distribution, called
octmvlib, that was used with earlier versions of Ptolemy.
oct facets. Special care is required when moving or copying
oct facets. First, as emphasized before, every
oct facet is stored as a directory tree, so a copy should use
cp -r. Next, keep in mind that there may be pointers to the moved object in other facets. If you know where all these pointers might be, then moving facets is easy. If you do not know where all the pointers are, then your only practical choice is to leave a symbolic link in place of the old location pointing to the new.
Suppose you have developed a fantastic new galaxy called
alphaCentaur, and you wish to install it in a directory that is available for general use. Since you have developed the galaxy, you know where it is used. The galaxy icon itself is stored in two facets:
alphaTest. This should be modified by running the
masters program as follows:
masters the same way to modify any palettes that reference the moved icon. For instance, the "user.pal" palette in the directory in which you developed
AlphaCentaur is a likely candidate. If you miss a reference,
oct will issue an error message when it tries to open the offending palette, indicating that it is inconsistent.
2.12.12 Environment variables
The following environment variables can be set to customize certain behavior. These should be set (normally) in the user's
vem facets. If you use the provided makefile to print Ptolemy documentation, then this environment variable will determine the printer used. In
$PTOLEMY/.cshrc the pertinent line reads:
lw with whatever printer name you are using.
printf format string with one "%s" in it. That %s is replaced with the name of the file to be viewed. The default value is "
xedit -name ptolemy_code %s", specifying that the program "xedit", part of the standard X Windows distribution, should be used with the command-line option "-name ptolemy_code". Note that, as is lamentably true with so many X Windows programs,
xedit has ludicrous defaults that yield a useless display. If your X installation has not been configured properly, you will want to change this environment variable to specify your favorite text editor. For example, to view files in a new xterm window with the
vi editor, put the following line in your
You may also use
tycho, the Ptolemy syntax manager as an editor by setting
PT_DISPLAY to view files in a separate
tycho window, type:
setenv PT_DISPLAY "tycho %s"
$PTOLEMY/bin.$PTARCH/pigiRpc. An alternative specification might be:
-debug option). An example of a suitable script is
ptgdb, located in
$PTOLEMY/bin. This script invokes
gdb, the Gnu debugger, inside
SHLIB_PATH instead of
LD_LIBRARY_PATH to find shared libraries. See the
LD_LIBRARY_PATH description above for details.
2.12.13 Command-line options
pigi program is actually a
csh script, located in
$PTOLEMY/bin. That script starts two processes:
pigiRpc. The usage is
vem facet that should be opened upon starting the system. The command-line options are:
-debug Invoke Ptolemy running under gdb, a symbolic debugger. If a version of the pigiRpc executable with debug symbols can be found, the script will it. The program looks for
or if the PIGIRPC environment variable is set, $PIGIRPC.debug. If neither is found, then $PIGIRPC is invoked, if set. Otherwise,
gdb, a symbolic debugger. If a version of the
pigiRpc executable with debug symbols can be found, the script will it. The program looks for
or if the
PIGIRPC environment variable is set,
$PIGIRPC.debug. If neither is found, then
$PIGIRPC is invoked, if set. Otherwise,
$PTOLEMY/bin.$PTARCH/pigiRpcis used. If the
PT_DEBUG environment variable is set, then its value is the name of a script used to invoke the debugger. For example, the script
ptgdb, located in
ptinyRpc. This version contains only the SDF, DE, and HOF domains. Equivalently, you can directly call the program
ptrimRpc. This version contains only SDF, BDF, DDF, DE, HOF, and CGC, but without the parallel targets. Equivalently, you can directly call the program