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 Parent Block. Also, the method initialize() is declared here to be purely virtual, so every object should have some kind of initialization function.
The Block class is derived from NamedObj and is the main base class for most actors in Ptolemy. It has I/O constructs like PortHoles and MultiPortHoles, state/parameter constructs like State, and defines execution methods such as setup(), run() and wrapup(). The 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:
PTcl::dispatcher()
PTcl::run()
PTcl::computeSchedule()
Runnable::initTarget()
Block::initialize()
SDFTarget::setup()
Target::setup()
SDFScheduler::setup()
Notice at this point that we have called two domain-specific methods, namely SDFTarget::setup() and SDFScheduler::setup(). The 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:
SDFScheduler::setup()
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 Star's PortHoles.
Expanding prepareGalaxy() in more detail:
SDFScheduler:: prepareGalaxy()
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::run()
PTcl::computeSchedule() // Described above.
PTcl::cont()
universe->setStopeTime() // Used to set the number of
// iterations to be run.
universe->run()
InterpUniverse::run()
Runnable::run()
target->run()
sched->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
// star->run().
star->run()
DataFlowStar::run() // The SDF domain uses the general
// DataFlowStar
// 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
// Geodesic.
Star::run()
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
reserved.