An Amalthea model per se is a static, structural model of a HW/SW system. The basic structural model consists of software model elements (tasks, runnables), hardware model elements (processing units, connection handlers), stimuli that are used to activate execution, and mappings of software model elements to hardware model elements. Semantics of the model elements then allows for definite and clear interpretation of the static, structural model regarding its behavior over time. Basically, the initial state of the static system model is used as a starting point, and a series of state changes is subject to model analysis. The state of a model mainly consist of states of HW elements (processing units and connection handlers). During analysis, a state change is then, for example, a processing unit changing from idle to execute.
When we are interested in the timing of a model, a common way is using discrete event simulation. In discrete event simulation, a series of events changes the state of the system and a simulated clock. Such a simulation event is, for instance, a “stimulus event” for a task to execute on a processing unit, what in turn may change the state of this processing unit from idle to execute.
Note that every event occurs at a specified point in simulated time; for instance, think of a new stimulus event that shall activate a task in 10ms from the current value of the simulated clock. Unprocessed (future) events are stored in an event list. The simulator then continuously processes the event occurring next to the current simulated time, and forwards the simulated clock correspondingly, thereby removing the event from the event list. Note that this is a very simplified description. For instance, multiple events at the same point in simulated time are possible. Processing events may lead to generation of new events. For instance, processing a end task execution event may lead to a new stimulus event that shall occur 5ms from the current value of the simulation clock added to the event list.
After sketching the basic idea of discrete event simulation, we can be more precise with the term timing: we call the trace of state changes and events over time the dynamic behavior or simply the timing of the model. This timing of the model than may be further analyzed, for instance, regarding timing constraints.
Stimulation of task execution with corresponding stimuli events, and scheduling in general, is not further discussed here. In the following, we focus on timing of execution at processing units. The basic mechanism to specify execution time at a processing unit is the modeling element ticks. Ticks are a generic abstraction of time. Regarding hardware one may think of ticks as clock ticks or cycles of the processor. You can specify ticks at several places in the model, most prominently as a runnable item of a runnable. The ticks value together with a mapping to a specific processing unit that has a defined frequency then allows computation of an execution time. For instance, 100 ticks require 62.5ns simulated time at a processing unit with 1.6GHz, while 100 ticks require 41.6ns at a processing unit with 2.4GHz.
In general, the runnable items of a runnable are specified as a directed, acyclic graph (DAG). Processing this DAG from perspective of a discrete event simulator then defines the timing of executing the runnable at a specific processing unit. Amalthea allows for many different types of runnable items that can be categorized as: items that branch paths of the DAG (runnable mode switch, runnable probability switch); items that signal other parts of the model (custom event trigger, runnable call, etc.); items that specify data access (channel receive/send, label access); and items that translate in execution time (ticks, execution needs). When the discrete event simulator simulates execution of a runnable at a processing unit, it actually processes runnable items and translates their semantics into simulation events. We already discussed the runnable item ticks: when ticks are processed, a corresponding simulation time value is computed based on the executing processing unit�s frequency, and a simulation event is stored in the list of simulation events for when the execution will finish. While ticks denote a fixed (static) timing, data accesses may result in series of simulation events, depending on access paths and mapping of data to memory. The timing of data accesses then depends on parameters such as delay and state of hardware structure elements such as connection handlers.
Note that the current version of Amalthea (0.9.3) also prepares an additional concept for specification of execution timing besides using ticks: execution needs. Execution needs will allow sophisticated ways of execution time specification, as required for heterogeneous systems: Execution needs define the number of usages of user-defined needs; a later version of Amalthea (> 0.9.3) then will introduce recipes that translate such execution needs into ticks, taking hardware features of the executing processing unit into account. Note that, by definition, a sound model for timing simulation always allows to compute ticks from execution needs. Consequently, for timing analysis using discrete event simulation as described above, we first translate execution needs into ticks, resulting in a model we call ticks-only model. Thus, execution needs can be ignored for timing analysis.