• 2.12.1 Plotting signals and Fourier transforms
• 2.12.2 Moving objects
• 2.12.3 Copying objects
• 2.12.4 Labeling a design
• 2.12.5 Icon orientation
• 2.12.6 Finding the names of terminals
• 2.12.7 Multiple inputs and outputs
• 2.12.8 Using delays
• 2.12.9 Auto-forking
• 2.12.10 Dealing with errors
• 2.12.11 Copying and moving designs
  • Moving facets
• 2.12.12 Environment variables
• 2.12.13 Command-line options

2.12.1 Plotting signals and Fourier transforms

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

to . The sampling frequency is assumed to be . A simple phase unwrapping algorithm is used to give more meaningful phase plots. A radix-2 FFT is used, so the order (the number of points) of the fast Fourier transform must be a power of two. That is, the user actually specifies . The order can be longer than the signal, in which case, zero-padding will occur.

2.12.2 Moving objects

• Select the objects that you want to move.
• Using the right mouse button, drag the objects to the desired location.
• Execute move-objects, "m".

2.12.3 Copying objects

2.12.4 Labeling a design

2.12.5 Icon orientation

To reflect an object horizontally, select it, and type:

2.12.6 Finding the names of terminals

2.12.7 Multiple inputs and outputs

Ptolemy supports star definitions that do not specify how many inputs or outputs there are. The Add and Fork stars are defined this way, for instance. Consider the following two icons, found in the "arithmetic" palette of the SDF domain:

They both represent exactly the same star, as you can verify with the "look-inside" command. The icon on the right, however, has a peculiar double arrow at its input. This is a "multiple input" terminal that allows you to connect any number of signals to it. All the signals will be added. The icon on the left has two ordinary input terminals. It can add only two signals. Why have both kinds?

Sometimes, multiple input terminals are not convenient. A rather technical reason is given below, in the section "Auto-forking" on page 2-58. A more mundane reason is simply that schematics often look better with two-input adders.

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.

In any facet, execute the 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

To use these delays in 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.

Other domains (besides dataflow) also use delays, but the meaning can be quite different. See the appropriate chapter describing the domain.

A new feature added to Ptolemy releases greater than 0.5 is the support of initializable delays for simulation domains. These delays use a different icon from the old white diamond with green borders. The new delays use an icon that is a green diamond with a white border and has an "I" in the middle of the diamond to signify that it is initializable. We have kept around the old delays for backward compatibility, but the syntax for the two is quite different and the user should probably use just one type to prevent confusion.

The syntax for the new delays is that the arguments to the delay are the initial value themselves. There is no value in the argument that signifies the number of delay particles. Instead, a count of the number of values in the delay arguments is the number of delay particles that will be added to the buffer of the arc corresponding to the delay. These arguments are specified as a string and are parsed according to the data type associated to the arc. For example, an initializable delay with parameter "1 0 1" on an arc passing float particles will have a buffer with three initial particles. The three particles will have the values 1.0, 0.0, and 1.0 respectively. If the arc was working on complex particles instead, an error would be given since complex numbers must be specified using a pair of numbers. A proper argument list for the delay in that case would be "(1,0) (0,0) (1,1)". The shorthand for declaring multiple values in the argument list is valid, just as in the arraystate case. For example, an argument list of "2 [5]" would specify five initial particles with value 2.

Initializable delays also work on arcs which handle matrix particles. The argument string in this case is parsed differently than above. The first two values in the last specify the number of rows and columns in the initial matrix, respectively. For example, an initializable delay with parameter "1 2 3 [2]" on an arc passing integer matrices would place one matrix with dimension one row by two columns, whose entries all have the value three, in the buffer for that arc. For the case where multiple initial matrices are desired, simply give enough entries in the delay argument string to fill multiple numbers of initial matrices of the given size. For example, an initializable delay with parameter "1 2 3 3 4 4 5 5" on an arc passing integer matrices would create three matrices, all of dimension one row by two columns, such that the first initial matrix on the buffer has all entries equal to three, the second has all entries equal to four, and the last matrix has all entries equal to five.

2.12.9 Auto-forking

However, there are restrictions. To understand these restrictions, it is worth explaining that 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:

This example also illustrates the use of a delay on a feedback loop. The delay is required here, assuming we are in the SDF domain, because without it, deadlock would ensue. This is due to the fact that the fork star cannot fire until the add star does, but the add star cannot fire until the fork star produces its output.

A second restriction is that forks must be explicit when connected directly to input or output terminals of a galaxy. An incorrect and correct example are shown below:

There is also a more subtle restriction. Suppose two outputs are connected to a single multiple-input terminal. Then neither of these outputs can also be connected to some other input terminal. If they are, Ptolemy will issue the error message "multiple output ports found on the same node." The reason this happens is simple. 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:

All of the above restrictions may be eliminated in future versions.

2.12.10 Dealing with errors

When errors occur in vem, 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.

Errors in the 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

A utility program called 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.

Palettes, star icons, galaxies, and universes are stored as 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.

Moving facets

2.12.12 Environment variables

---

---

Copyright © 1990-1997, University of California. All rights reserved.