level1Cpu State Diagram

Click on the image for a postscript file.....

An event is added to the objects memoryQue. The depth of the memoryQue is an input parameter. If the object is not busy processing an event the event begins to be analyzed. First the latency for input to the L1CPU is determined from the events Bunch Crossing Number and the SimTime (current simulation time). This latency is MONITORED, which means that anytime the variable is updated the information is added to a statistics object which allows the extraction of statistical information on demand.

Whether a CPU hangs on a given event is then determined. The probability of such an occurence is input as the varibale L1HangProb (this is an INTEGER representing %). If a CPU does hang the WAIT period for processing is selected by the input variable, hangTime. Currently this is 3X the average process time for a non-hung CPU. In future upgrades this will be a distribution of times with an average as input. The hung event is "accepted" and flaged as a hung event. This will also be updated in future versions so that only some percentage of hung events will be passed.

If the CPU does not hang then acceptance of the event is chosen randomly based on the L1VetoRate, (the percentage of events rejected) which is an input parameter. The time to process the event is then set from the input parameters L1AnalysisTime and L1ATStdDev. A value for the WAIT period or analysis time is then selected from a Gaussian distribution with mean=L1AnalysisTime and standard deviation=L1ATStdDev, and the object WAITS for the given time. Of course the type of distribution utilized could be modified.

Results from the hang/no-hang process are added to the Level1CpuResultQue. Again, the latency to this point is MONITORED so that statistics can be accumulated. The Level 1 Queue Manager then checks the result que for completed events.

Back to the Object Model .
J.P. Whitfield, Carnegie Mellon 4/20/95