Now that you have some idea of what classes exist in the Ptolemy kernel, this section will try to explain flow of control when a
Universe is run. By knowing this, you will get an idea of what additions or changes might be needed to get the functionality you desire and how the code of your new domain will fit in.
First off, a little more about the basics of Ptolemy classes. Almost every object class in Ptolemy is derived from the
NamedObj class. This class simply provides support for a
Name field, a longer
Description field, and a pointer to a
Block. Also, the method
initialize() is declared here to be purely virtual, so every object should have some kind of initialization function.
Block class is derived from
NamedObj and is the main base class for most actors in Ptolemy. It has I/O constructs like
MultiPortHoles, state/parameter constructs like
State, and defines execution methods such as
Block also provides a virtual function to access an associated Scheduler.
A simulation universe is generally of type
DataFlowStar. When a universe is run, the flow of control is as follows, using the SDF domain as an example:
Notice at this point that we have called two domain-specific methods, namely
Target can have a choice of more than one
Scheduler and in this case it called the default
SDFScheduler. We continue here with a more detailed description of a very important function:
checkConnectivity() // Checks that the galaxy is
// properly connected.
prepareGalaxy() // Initializes the portHoles of each star and
// the geodesics that connect them.
checkStars() // Verifies that the type of the Stars are
// compatible with this Scheduler.
repetitions() // Solves the balance equations for the
// system and calculates how many times
// each star should be fired for
// one iteration (specific to dataflow).
computeSchedule() // Compute the actual schedule
adjustSampleRates() // Set the number of tokens transferred
// between EventHorizons if this schedule
// is for a WormHole.
The order of various operations can be different for each scheduler. For example, a new domain may require that the
PortHoles be initialized after the repetitions were calculated but before the schedule was computed. The domain writer may wish to define a new function
prepareForScheduling() that would call the
setup() function of each
Star without initializing the
prepareGalaxy() in more detail:
galaxy()->initialize() // Initialize the galaxy.
InterpGalaxy::initialize() // Causes the initialization of delays
// and the setup of bus widths.
Galaxy::initSubblocks() // Calls initialize() of each star.
DataFlowStar::initialize()// This is a general initialize.
// function for data flow stars.
// Your own Star class might
// redefine it. Sets the number
// of input Ports and clears
// some parameters.
Block::initialize() // Initializes the PortHoles and States
// of the Block/Star. Calls the user
// defined setup() function of each
// star after the portholes and
// geodesics have been initialized.
PortHole::initialize() // General PortHole initialization;
// again you can redefine it for a
// domain specific PortHole.
// Resolves the type of Particles
// to be sent. Allocates a
// buffer and a Plasma. Request
// empty Particles from the Plasma
// to initialize the buffer.
Geodesic::initialize() // General Geodesic initialization,
// called by output PortHole only.
// Clears the buffer and adds any
// initial Particles for delays.
After the schedule is set up and all the actors in the
Universe have been initialized, the flow of control is as follows:
PTcl::computeSchedule() // Described above.
universe->setStopeTime() // Used to set the number of
// iterations to be run.
SDFScheduler::run() // The domain specific Scheduler's
// run() function.
Let's look at what a typical scheduler does when it runs a star.
SDFScheduler::run() // Checks if there has been an error
// in the last iteration. Calls
// runOnce() for each iteration.
runOnce() // Goes through each Star on the
// schedule (which is a list of Stars
// computed by setup() ) and calls
DataFlowStar::run() // The SDF domain uses the general
// run() function. A new Domain
// might want to redefine this.
..Ports->receiveData() // Calls receiveData() for each of
// the PortHoles for this Star.
// Output PortHoles would do nothing
// in this case but input PortHoles
// would get Particles from the
SimControl::doPreActions()// Execute pre-actions for a star.
go() // Call the Star specific go() function
// that will process the input data
// and generate data to be put in the
// output PortHoles.
SimControl::doPostActions() // Execute post-actions for a star
..Ports->sendData() // Calls sendData() for each of the
// PortHoles for this Star.
// Input PortHoles would do nothing
// in this case but output PortHoles
// would put their Particles into
// the Geodesic and refill their
// buffers with empty Particles
// from the Plasma.
Copyright © 1990-1997, University of California. All rights