Performance Modeling and Analysis Using VHDL and System:An Interface for Mixed-Level Modeling with Complex Sequential Components

An Interface for Mixed-Level Modeling with Complex Sequential Components

A methodology and components for constructing a mixed-level interface involving general sequential interpreted components that can be described as FSMDs was detailed in the previous section. However,

many useful mixed-level models can be constructed that include sequential interpreted components that are too complex to be represented as FSMDs, such as microprocessors, complex coprocessors, network interfaces, etc. In these cases, a more “programmable” mixed-level interface that is able to deal with the additional complexity in the timing abstraction problem was needed. This section describes the “watch- and-react” interface that was created to be a generalized, flexible interface between these complex sequential interpreted components and performance models.

The two main elements in the watch-and-react interface are the Trigger and the Driver. Figure 77.28 illustrates how the Trigger and Driver are used in a mixed-level interface. Both elements have ports that can connect to signals in the interpreted components of a model. Collectively, these ports are referred to as the probe. The primary job of the Trigger is to detect events on the signals attached to its probe, while the primary job of the Driver is to force values onto the signals attached to its probe. The Driver decodes information carried in tokens to determine what values to force onto signals in the interpreted model (the U/I interface) and the Trigger encodes information about events in the interpreted model onto tokens in the performance model (the I/U interface).

The Trigger and Driver were designed to be as generic as possible. A command language was designed that specifies how the Trigger and Driver should behave to allow users to easily customize the behavior of the Trigger and Driver elements without having to modify their VHDL implementation. This command language is interpreted by the Trigger and Driver during simulation. Because the language is interpreted, changes can be made to the Trigger and Driver programs without having to recompile the model, thus minimizing the time required to make changes to the mixed-level model.

The schematic symbol for the Trigger is shown in Figure 77.29. The primary job of the Trigger is to detect events in the interpreted model. The probe on the Trigger is a bus of std_logic signals probe_size bits wide, where probe_size is a generic on the symbol. There is one token output called out_event_token and one token output called out_color_token. Tokens generated by the Trigger when events are detected are placed on the out_event_token port. The condition number (an integer) of the event that caused the token to be generated is placed on the condition tag field, which is specified as a generic on the symbol. Also, each time a signal changes on the probe, the color of the token on the out_color_token port changes appropriately regardless of whether an event was detected or not. The probe value is placed on the probe_value tag field of the out_color_token port. The sync port is used to synchronize the actions of the Trigger element with the Driver element as explained below.

The name of the file containing the Trigger’s program is specified by the filename generic on the symbol. The delay_unit generic on the symbol is a multiple that is used to resolve the actual length of an arbitrary number of delay units specified by some of the interface language statements.

The schematic symbol for the Driver element is shown in Figure 77.30. The primary job of the Driver is to create events in the interpreted model by driving values on its probe. These values come from either the command program, or from the values of tag fields on the input tokens to the Driver. The probe on the Driver is a bus of std_logic signals probe_size bits wide, where the probe_size is a generic on the symbol. There is one token input called in_event_token, one token input called in_color_token, and a special input for a std_logic type clock signal called clk. The clk input allows Driver to synchronize its actions with an external interpreted clock source. The sync port is used to synchronize the actions of the Driver element with the Trigger element. The filename and delay_unit generic on the symbol function the same as for the Trigger.

As discussed previously, a command language was developed to allow the user to program the actions

of the Trigger and Driver. This command language is read by the Trigger and Driver at the beginning of the simulation. Constructs are available within the command language to allow waiting on events of various signals and driving values or series of values on various signals, either asynchronously, or synchronous

with a specified clock signal. In addition, several looping and go-to constructs are available to implement complex behaviors more easily. A summary of the syntax of the command language constructs is shown in Table 77.4.

Example of Mixed-Level Modeling with a Complex Sequential Element

This section presents an example which demonstrates how the Trigger and Driver elements can be used to interface an interpreted model of a complex sequential component with an uninterpreted model. In this example, the interpreted model is a microprocessor-based controller and the uninterpreted model is that of a motor control system including a motor controller and a motor. The motor controller periodically asserts the microcontroller’s interrupt line. The microcontroller reacts by reading the motor’s current speed from a sensor register on the motor controller, calculating the new control information, and writing the control information to the motor controller.

The microcontroller system consists of interpreted models of eight-bit, RISC-like microprocessor, RAM, memory controller, I/O controller, and clock. The memory controller handles read and write requests issued by the processor to the RAM, while the I/O controller handles read and write request issued by the processor to an I/O device. In the system model, the I/O device is the uninterpreted model of a motor controller. A schematic of the model is shown in Figure 77.31.

Three Triggers and two Drivers are used to construct the mixed-level interface for the control system model. One of the Triggers is used to detect when the I/O controller is doing a read or write. The other two Triggers are used to collect auxiliary information about the operation, such as the address on the address bus and data on the data bus. One of the Drivers is used to create a microcontroller interrupt and the other Driver is used to force data onto the data bus when the processor reads from the speed sensor register on the motor controller.

The interrupt Driver’s program is listed in Figure 77.32. The program begins by forcing the interrupt line to ‘Z’ and then waiting for a token from the uninterpreted model of the motor controller to arrive. Once a token arrives, the program forces the interrupt line high for 10 clock cycles. This condition is accomplished by using a for-next statement with a wait_on_rclk as the loop body. After 10 clock cycles, the program jumps to line 10 where the cycle begins again.

The data Driver’s program is listed in Figure 77.33.The program begins by also waiting for a token from the uninterpreted model of the motor controller to arrive. If the value on the condition tag field of the token is 1, then “ZZZZZZZZ” is forced onto the data bus. If the condition tag field value is 3, then the value on the probe_value tag field of the in_color_token input is forced on the data bus. This process is repeated for every token that arrives.

The I/O Trigger’s program is listed in Figure 77.34. This Trigger waits until there is a change on the probe. Once there is a change, the program checks to see if the I/O device is being unselected, written

to, or read from. If one of the when statements matches the probe value, then its corresponding output statement is executed. An output of 1 corresponds to the I/O device not being selected. An output of 2 corresponds to the processor writing control information to the motor controller. An output of 3 corresponds to the processor reading the motor’s speed from the sensor register on the motor controller. Figure 77.35 shows the results from the mixed-level model as a plot of the sensor output and the processor’s control response. Some random error was introduced to the sensor’s output to reflect variations

in the motor’s load as well as sensor noise. The target speed for the system was 63 ticks per sample time (a measure of the motor’s RPM). The system oscillates slightly around the target value because of the randomness introduced into the system.