Each Process and Data (Process output) specifies a sample rate, stored as a fraction for absolute accuracy. For Processes, these sample rates are specified in the SystemML document; for Datas, these rates are specified by the creating process (and will often match the Process sample rate, though this is not required). Given the integral Base Clock, BRAHMS can generate timing relationships between components with perfect accuracy. To understand these clocks better, review the GUI documentation.
Integral Base Clock
The use of an integral (rather than floating-point) Base Clock has pros and cons: it ensures accuracy and reduces the computational complexity of timing logic; on the other hand, range is limited by the width of the counters used (64-bit, in BRAHMS). However, to give an idea, if the BSR is 1GHz, the latest time on the Execution Clock that the Base Clock can represent is more than half a millenium after
A pathological system may have two processes with sample rates that are interrelated such that their lowest common multiple is extremely large, and in this case the amount of time that can be represented may be practically limited. For instance, if two processes have sample rates of 1GHz and 1GHz plus 1Hz, the BSR will be around 1EHz (ExaHertz, or 1018Hz), and the latest representable time becomes about eighteen and a half seconds. Such a system would still have to compute around 1.8x1010 steps to reach this limit. But if such a limit is reached in a practical situation, the only solution to execute the system in BRAHMS is to tweak the sample rates to avoid the pathological condition - this would not be expected to introduce much inaccuracy, with numbers of this order. Alternatively, the system can be computed in a series of shorter periods.
Calculating the Base Sample Rate
After all temporal components (Processes and Datas, but not Utilities) have been created, the BSR
Why should I care?
The BSR will not be of direct interest to the Process developer. However, if a Process needs to obtain the Execution Clock time whilst servicing an event (rather than just the period between services), the timing data
Relationship with the Wall Clock
The Execution Clock is not explicitly related to the Wall Clock by the framework. Components that interact with hardware may force a relationship of this sort, however. Neither is data on the Wall Clock propagated to the Component, but any Component can obtain this information from the OS (which obtains it from the hardware). Therefore, even an apparently pure software component can force a relationship with the Wall Clock if desired, by interacting with the hardware (motherboard) through the OS. If there is demand, a Wall Clock utility object could be generated fairly easily, simplifying this interaction.
One place that the Wall Clock does come into play is in performance assessment. BRAHMS times executions using OS utilities. Usually, individual calls during run-phase are not timed, since this will often slow execution (however this can be requested; see
|This is a documentation page for the BRAHMS Modular Execution (Simulation) Framework. For details of licensing and distribution, please click here. To advise of an error or omission, please click here.|