DynMapBase star in DE domain

This is the base star for a family of stars which supports a mutable system configuration in the DE-domain. This star family implements the functionality of a dynamic map-function for the discrete-event domain. A dynamic map-function works like the map-function in the HOF-domain, but we can change the number of blocks it multiplies during runtime of the simulation. Thus, we support a mutable system configuration. Note, that this star family only works with the two standard DE schedulers.

This class is an abstract class, so it can't be instantiated and can not be used on its own. It contains methods which are used by its childs.

Derived from: DEStar
Location: $PTOLEMY/src/domains/de/contrib/stars
Version: 1.8 "03/27/98"
Author: J. Voigt
Acknowledgements: I use some code from Edward A. Lee's older version of HOFBase. Former versions of DEDynMapBase called that code directly. But, Tom Lane changed the HOF-stars. So, I copied the older code directly into this file, having the advantage of being independent of further changes in HOF now. MutableCQScheduler incorporated by John S. Davis II

States

blocknameStringState The name of the block which 'll be instantiated. ""
where_definedStringState The full path and facet name for the definition of blockname. ""
output_mapStringArrayState The names of the block's outputs for mapping. ""
input_mapStringArrayState The names of the block's inputs for mapping. ""
parameter_mapStringArrayState The mapping of parameters. ""

Details

This star contains methods which are used by DEDynMap and DEDynMapGr for an instantiation of other blocks during runtime of the simulation. The descriptions of these stars explain their application. We here just explain the single methods.

Creating a block dynamically is as follows (createDynBlock):

We create blocks using code from HOFBase::createBlock in createBlock. This method returns a pointer to a newly created block. This block is instantiated, gets a unique name, and is added to the galaxy's blocklist. Furthermore, we put it into an internal list, so that we can find it back lateron when we want to delete it.

Then we look for input and output portholes of that newly created block and create approriate farsides for these portholes in DEDynMerge and DEDynFork using their createPortHole()-method. These portholes are connected afterwards. We here just have pure virtual methods connectXXXports, because these portholes can be of different datatypes and are members of our childs only. Once they are connected, the newly created portholes are initialized.

If parameter_map is not empty, the parameters in the new block are set in setParameter. If it is empty, the initialization()-method sets the default values.

The entire galaxy's connectivity is checked. Then we check for delayfreeloops and update the porthole priorities.

We have to take special care of source-stars in the dynamically created blocks. We look for them in scanGalaxyForSources. If there are any, we have to give them an initial event at the current time. That means, all source-stars derived from DERepeat-star give now out an initial event at the time of their creation (instead of time zero, when they probably don't exist). Otherwise these source-stars would never give out any event. See the description of the DERepeat-star for details.

Deletion of a block dynamically is as follows (deleteDynBlock):

I get a unique identifier for a block to be deleted as parameter. This block is looked for in my internal list of currently existing blocks. I get a pointer to my deleteBlock from this list and remove that block from the list.

Then, the eventqueue is checked for any events pointing to deleteblock using scanEventList. If any events are found, they are deleted from the eventqueue.

Then I look for input and output of the deleteblock. Again, the disconnectXXXPorts are here just pure virtual, because the portholes are members of our childs and of a specila datatype. Inside disconnectXXXPorts we check the eventqueue for any events which are scheduled to the farside of the deleteblock's outputs. These farside are inputs, so events might be sent to them.Since we delete these farside, we better also delete the events. Then I disconnect the portholes from their farside and delete their farside using removePortHole() in DEDynMerge and DEDynFork, respectively.

Next, I remove deleteblock from the galaxy's blocklist, where it was added to by the code from createDynBlock. Once removed there, it can be recycled into our blockpool.

The entire galaxy's connectivity it checked again. Then I check for delayfreeloops again and update the porthole priorities.

Scanning the eventqueue is as follows (scanEventList):

Using scanEventList() and scanGalaxyForContents() I go down the block's hierarchy until I only deal with atomic elements (stars). For each star I check the current eventQueue for any pending pointer to it (CQScheduler and MutableCQSCheduler) or for any pending pointer to any of its input-portholes (DEScheduler) using deletePendingEventsOfStar or deletePendingEventsOfPortHole, which should be self-exploratory both.

Setting parameter values:

All parameters are used in the derived class DEDynMap.

blockname:

Name of the block, which is to multiply. The masterinstance. This block can be any galaxy or star. However, it must not have multiportholes.

where_defined:

The full path and facet name for the definition of blockname.

output_map:

The names of the block's outputs for mapping. The names of the outputs from the masterinstance should be listed in the order in which they should be connected.

input_map:

The names of the block's inputs for mapping. The names of the inputs to the masterblock should be listed in the order in which they should be connected.

parameter_map:

The mapping of parameters like in HOF::Map.

The current limitations are:

A block which is to instantiate must not have multiportholes.

FIXME: The eventlist is to re-sort after the configuration changed. Thanks to Tom Lane for pointing this out.


See: source code, DynMapBase users


copyright (c) 1997 Dresden University of Technology, WiNeS-Project All rights reserved. See the file $PTOLEMY/copyright for copyright notice, limitation of liability, and disclaimer of warranty provisions.