The Performance Model version 2 library (Perfmod2) is a branch of the CSIM core model library. It was originally intended to be a few new models within the core model library but as the requirements of the project that supported its creation grew we needed to extend not only the models but the environment as well. Also, rewriting some of the performance models allowed us to take advantage of some of the features of CSIM that were not available when the core models were written. As soon as the perfmod2 environment is considered tried and true we plan to merge the changes back in the core model library.
The Perfmod2 library has quite a few features that add to the already feature rich core model library
Note: This is a reference document. If you are looking for a tutorial you need to head here when it is complete.
I would first like to take a moment and list the files that you do not need, those are the files you need for the core model library (subroutines.sim, parameters.sim, monitor.sim). As a matter of fact it would be bad if you included these files. The Perfmod2 library operates a little different than the core model library, in that you only need to include the files that define the models you want to use. For example to use the GenericComputer model you will want to include the generic_computer.sim file. Order does matter somewhat; if you are using the dynamic scheduler you should include dynamic_sched.sim first.
In order to use the message tracking abilities of the Perfmod2 library you must use the dynamic scheduler. However, if you are not interested in message tracking then the static scheduler will work just fine.
The only boxes you need in your simulation are one and only one PMManager and, if you are using the dynamic scheduler, one and only one SCHEDULER. If you forget the PMManager, the simulation will just hang after all the CPUs print "Waiting for PMManager".
As a perfmod2 simulation runs it will write statistics and event information in various files which can be later interpreted and displayed. The EventHistory.dat file
Data flow graphs (DFGs) created for the perfmod2 library can have attributes. Attributes on task nodes are passed to the mapped CPU when that task is scheduled. For example, if the compute_priority attribute is set, the CPU model will do priority scheduling with that task. Currently, compute_priority is the only generic task node attribute used by the GenericCPU.
Attributes on DFG arcs are passed to the mapped CPU when a send is scheduled and then copied to the PMMessage structure by the GenericCPU when the message sent. This allows protocol stack and network elements read and interpret these attributes. The big advantage to using attributes on messages, especially for the CSIM users who create variant models, is that you no longer have to create a variant message structure or DFG node if you simply want to pass message specific values to network elements. Currently the available attributes for DFG arcs are as follows:
The NewMessage is a DFG model of a message generator. Because it is a custom DFG model, it is only available for the dynamic scheduler. The NewMessage model accepts a couple of attributes to control the message generation. The run_duration attribute controls how long the node will generate messages for from the time of firing. The firing_rate attribute controls the frequency at which messages are generated. The firing_rate attribute may be set to "poisson" to generate at a uniform random rate (poisson, where k=1). If you are using poisson generation you may use the poisson_mean_interarrival_period attribute to control the mean interarrival period.
The FlowEnd is a DFG model of a message sink. Because it is a custom DFG model, it is only available for the dynamic scheduler.
The Probe is a special DFG node that writes the CSIM_TIME to a file every time it fires. Because it is a custom DFG model, it is only available for the dynamic scheduler.
The perfmod2 CPU model is actually designed to model a little more that just a compute resource. In order to facilitate multitasking operation the CPU also models a tiny operating system. This operating system handles loading and scheduling programs (DFGs). It will allow instructions to be sent to the CPU from many sources at once - prog files, the dynamic scheduler, or program lines. Program lines are a new feature unique to perfmod2, they are links on which instructions can be sent to the CPU model.
A running DFG is considered to be a process. The CPU model is designed to maintain a separate list of instructions pertaining to each process for each process. The CPU model is designed to allow only one instruction from one process hold the CPU resource at a time. The default process scheduler in the CPU model is a priority FIFO scheduler. The scheduler will perform a context switch after every compute instruction or when a process of higher priority than the currently running process has instructions to execute.