The MLDesigner kernel does not define any model of computation. Every effort has been made to keep data flow semantics out of the kernel. Thus, for example, a network of blocks could just as easily represent a finite state machine, where each block represents a state. It is up to a particular domain to define the semantics of a computational model.
The semantics of a domain is defined by classes that manage the execution of a specification. These classes could invoke a simulator, could generate code, or could invoke a sophisticated compiler. The principal classes responsible for control and execution of the system model are the target and the scheduler.
Targets take on particular importance in code generation domains where they describe all the features of the target of execution, but they are used to control execution in simulation domains as well. Since class Target is derived from the most common kernel class Block, the target object itself has methods called setup, run, and wrapup. To define a simulation domain called XXX, for example, one would define at least one object derived from Target that runs the simulation. A Target can be quite sophisticated. It can, for example, partition a simulation for parallel execution, handing off the partitions to other targets compatible with the domain. See Targets for a more in-depth look at how targets function.
A target will typically perform its function via scheduler objects derived from class Scheduler. The schedulers control the order of execution of blocks under their control. In some domains, the scheduler does almost everything. In such domains, the target simply starts it up. In others, the scheduler determines an execution order and the target takes care of many other details, such as generating code in accordance with the schedule, downloading the code to an embedded processor, and executing it.
The Scheduler defines the operational semantics of a domain by controlling the order of execution of functional modules. Sometimes, schedulers can be specialized. For instance, a subset of the data flow model of computation called Synchronous Data Flow (SDF) allows all scheduling to be done at compile time. The MLDesigner kernel supports such specialization by allowing nested domains. For example, the SDF domain, is a sub domain of the Boolean Data flow (BDF) domain. Thus, a scheduler in the BDF domain can handle all primitives in the SDF domain, but a scheduler in the SDF domain may not be able to handle primitives in the BDF domain. A domain may have more than one scheduler and more than one target.
Large systems often mix hardware, software, and communication subsystems. The hardware subsystems may include prefabricated components such as: custom logic processors with varying degrees of programmability, systolic arrays, and multiprocessor subsystems. Tools supporting each of these components are different and possibly use different data flow principles such as: regular iterative algorithms, communicating sequential processes, control/data flow hybrids, functional languages, finite-state machines, and discrete-event system theory and simulation.
In MLDesigner, domains can be mixed and even nested. Thus, a system-level description can contain multiple subsystems that are designed or specified using different styles.
An object of class XXXWormhole in the XXX domain is derived from class XXXStar, so that from the outside it looks just like a primitive in the XXX domain. Thus, the schedulers and targets of the XXX domain can handle it just as they would any other primitive block. However, inside, hidden from the XXX domain, is another complete subsystem defined in another domain, say YYY. That domain gets invoked through the setup, run, and wrapup methods of XXXWormhole. Thus, in a broad sense, the wormhole is polymorphic. The wormhole mechanism allows domains to be nested on many levels, for example, one could have a DE domain within an SDF domain within a BDF domain. The FSM domain is designed to always be used in combination with other domains.