pigi. For example, if the value of the signal parameter is:
1  -1 then the "plot-signal" command will plot ten points with value 1.0 and ten points with value -1.0. The options parameter can accept any options understood by the pxgraph program (see the pxgraph section of the Almagest). To plot a signal stored in a file, simply use the following syntax for the signal parameter:
< filenameYou may need to specify the full path name for the file.
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-14 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:
"mx" t m
To reflect it vertically, type:
"my" t m
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:
There are three ways to work with a star that has a multiple-input or multiple-output connection (technically, a "multiporthole").
Add star, but for some star types it's important to know which connection corresponds to which element of the multiporthole. Also, the connected portholes can't be connected to any other stars, nor can you use delay icons, because
vem will get confused (see
"Auto-forking" on page 2-48).
Second, you can attach a "bus create" or "bus break out" icon to the multiporthole terminal, choosing one that provides the right number of terminals for your schematic. (These icons are available in the "Higher order functions" section of the domain's palette.) This solves both of the problems with multiple connections to a single terminal. It may not make for a very pretty schematic, however.
Add icon actually is.This method takes the most work but may be worth it to make the nicest-looking schematic.
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-34.
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-6 on page 2-22. 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:
The first of these stores the schematic, the second stores the icon. The peculiar semicolon at the end is actually part of the file name. First move the icon:
mv alphaCentaur destinationDirectory
This moves the entire directory tree. You must now change all references to the icon so that they reflect the new location. Suppose you have a test universe called
alphaTest. This should be modified by running the
masters program as follows:
% masters alphaTest
Running masters on wave
Pathname to replace (? for a listing):
User input is shown in bold type; program output is shown in regular (not bold) type. Enter a question mark to get a list of all icons referenced in the facet:
Pathname to replace (? for a listing): ?
Pathnames currently found in the facet:
Pathname to replace (? for help):
The last three items are pointers to official Ptolemy icons. There is no need to change these. You should now enter the string you need to replace and the replacement value:
Pathname to replace (? for help): ~yourname/oldDirectory
New pathname: ~yourname/destinationDirectory
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
$PTOLEMY/bin.$PTARCH/pigiRpc. An alternative specification might be:
setenv PIGIRPC ~myname/Ptolemy/bin.sol2.5/pigiRpc
printf format string with one
%s in it. That
%s is replaced with the name of the file to be viewed. In the default, the
PT_DISPLAY variable is not set, and the Tycho editor is used.For example, to view files in a new xterm window with the
vi editor, put the following line in your
setenv PT_DISPLAY "xterm -e vi %s"
sol2.5. The architecture setting is returned by the
-debug option). An example of a suitable script is
ptgdb, located in
$PTOLEMY/bin. This script invokes
gdb, the Gnu debugger, inside
$DISPLAY, then see
These variables are used by the Gnu compilers to find components of the compilers, see
itclsh and the software that uses
tycho) to work properly.
This variable is used by the run time linker to find shared libraries. If you are using prebuilt binaries, and your Ptolemy installation is not at
/users/ptolemy, then you may need to set this variable, see
$PTOLEMY/.cshrc for guidelines on the proper order.
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:
setenv PRINTER lw
lw with whatever printer name you are using.
SHLIB_PATH instead of
LD_LIBRARY_PATH to find shared libraries. See the
LD_LIBRARY_PATH description above for details.
if (! $?USER) setenv USER $LOGNAME
Many of Ptolemy's domains rely on additional environment variables. The CG56 domain relies on S56DSP to indicate the path name where the tools for the S56X Motorola 56000 board are installed and QCKMON to indicate the path name where the QCK Monitor tools are installed. The VHDL domain relies on SYNOPSYS to indicate the root directory for the installation of Synopsys tools and SIM_ARCH to be set to the computer architecture you are using for the Synopsys tools.
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
pigi [options] [facet-name]
The optional facet name specifies a
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. If $PIGIRPC is set then that binary is used. If $PIGIRPC is not set, then the program first looks for
If that is not found, then the program looks for
If that is not found, then
gdb, a symbolic debugger. If a version of the pigiRpc executable with debug symbols can be found, the script will it. If
$PIGIRPC is set then that binary is used. If
$PIGIRPC is not set, then the program first looks for
$PTOLEMY/bin.$PTARCH/pigiRpc.debugIf that is not found, then the program looks for
$PTOLEMY/obj.$PTARCH/pigiRpc/pigiRpc.debugIf that is not found, then
$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
pigiRpc.ptiny. This version contains only the SDF and DE domains, but without the image processing stars and the user-contributed stars.
pigiRpc.ptrim. This version contains only SDF, BDF, DDF, DE, and CGC domains, but without the parallel targets.
Copyright © 1990-1997, University of California. All rights reserved.