Modeling System Architecture and Resource Constraints Using

1 MATLAB Digest www.mathworks.com

By Anuja Apte

Optimizing system resource utilization is a key design objective for

system engineers in communications, electronics, and other industries.

System resources such as processors, memory, or bandwidth on a com-

munication bus are often shared by various components in the system. To

understand the utilization of a shared resource, system engineers must do

two things: identify constraints on the resource, such as number of proces-

sors and memory size, and analyze the effect of input traffic or load on

the shared resource.

Modeling System Architecture and Resource Constraints Using Discrete-Event Simulation

MATLAB® Digest

The time-varying nature of the input traffic makes it difficult to analyze behaviors such as congestion, overload, end-to-end latencies, or packet loss. The challenge is to efficiently model the system’s response to changing in-put traffic patterns. These systems are best modeled as event-driven or activity-based systems, since the input traffic activity plac-es the load on the shared resource. Discrete-event simulation (DES) is the most suitable simulation paradigm for modeling event-driven or activity-based systems.

SimEvents™ extends the Simulink® envi-ronment for Model-Based Design into the discrete-event simulation domain. In this article, we use SimEvents to analyze resource constraints on three typical systems:

• An Ethernet communication bus

• A real-time operating system (RTOS) with prioritized task execution

• A shared memory management system

In each case, the simulation results will en-able us to understand the effects of resource constraints on the system and to determine next steps.

Ethernet Communication Bus The system in this example is a LAN consist-ing of three network interface cards (NICs) that share bandwidth on an Ethernet bus. We want to add another NIC and a printer to this bus—but will the bus have enough bandwidth to support them?

To answer this question, we must determine the channel utilization by evaluating the cur-rent load on the bus. As utilization increas-es, the end-to-end latency experienced by a packet increases in a non-linear fashion.

Products Used ■ Simulink®

■ SimEvents™

■ Stateflow®


If the Ethernet bus is heavily utilized by the current load, it cannot support additional devices; connecting new devices will in-crease communication latencies and reduce throughput for all the devices.

Figure 1 shows the SimEvents model of the system. The model includes the application that sends and receives data over the Eth-ernet bus, a medium-access control (MAC)

controller that governs each computer’s use of the shared channel, and a T-junction that connects the computer to the network.

The terminator, T-junction, and cable blocks at the bottom of the model represent physical components of the bus. The blocks labeled “Cable” model the communication latency based on the cable length.

Standard Ethernet networks use a Carrier Sense Multiple Access with Collision Detec-tion (CSMA/CD) protocol to manage use of the shared channel. Within this protocol, a collision occurs if transmissions from two computers compete for use of the channel. The colliding packets can make additional attempts to access the channel. The number of attempts and the time intervals between them are determined by a binary exponen-tial backoff algorithm—implemented in the MAC Controller subsystem in our example. The Stateflow® chart in Figure 2 shows the implementation of the binary exponential backoff algorithm.

In this setup, all applications transmit at an average rate of 100 packets per second and the packet size varies from 64 byte to 1500 bytes. Simulation of this system enables us to visualize characteristics such as the utiliza-tion of the Ethernet bus, the throughput for a particular computer, and the average latency for message transmission.

Figure 1. Ethernet bus.

Figure 2. Stateflow® chart showing binary exponential backoff algorithm.


Figure 3a shows the overall channel utili-zation, or the proportion of time that the channel is in use. We can also visualize other characteristics, such as the through-put of node B (Figure 3b).

Channel utilization is low, indicating that the bus might be able to support additional traf-fic. We can now incorporate the traffic from additional devices into the model and study their effect on overall channel utilization and the throughput of individual devices.

Next steps could include testing the model with different parameter sets and traffic patterns by using SimEvents with System-Test to perform Monte Carlo analysis on the model.

Real-Time Operating System with Prioritized Task ExecutionThis example models the prioritized task exe-cution in an RTOS. Tasks with different prior-ity levels share the processor in such a system. Typical tasks include low-priority application

tasks in the main loop of the RTOS and high- priority interrupt tasks that invoke interrupt service routines (ISRs). Execution of interrupt service routine delays the processing of appli-cation tasks, since the application tasks wait in the task queue while the ISR is executing.

Ideally, the number of tasks waiting in the task queue should not increase and the RTOS should return to the idle task to avoid exces-sive processing delays. How can we verify that the RTOS satisfies this requirement?

To answer this question we must model the shared processor and its interaction with application tasks and interrupts. Specifi - cally, the model should demonstrate prior-ity-based task execution and preemption. Figure 4 shows the SimEvents model of such a system.

Figure 3a. Channel utilization. Figure 3b. Throughput of node B.

Figure 4. Operating system with prioritized task execution.


The Task Token Generators section contains subsystems that generate high-priority to-kens for interrupts and low- priority tokens for application tasks. The tokens carry an attribute (TaskExecTime) that indicates the execution time for that task. The Task Token Manager section contains the task queue and the processor shared by the input tasks. The Priority-Based Task Queue sorts the current queued tasks according to priority. Interrupt task tokens entering this queue preempt the application task token being served in the processor. Upon preemption, the application task returns to the Priority Based Queue. This task resumes its processing when the interrupt service routine is complete. The dashed function-call signal lines are used to generate tasks whose execution depends on the completion of another task.

We simulate this model and generate a plot showing the number of tasks in the task queue changing over simulation time (Figure 5).

The plot indicates that the number of tasks waiting to be processed increases over time, and that the task queue does not return to an empty state. It seems that the processor is not fast enough to support the high input rate of tasks.

Figure 5. Task queue length.

Since we cannot control the input rate of tasks, next steps might include exploring the use of a high-speed processor to reduce the number of tasks waiting in the task queue.

Shared Memory ManagementThe system in this example is a communication device on a custom hardware board or a system on a chip that manages a buffer shared by the transmit buffering and receive buffering func-tions. Messages are dropped when the buffer is full. Low packet drop rate for the receive buffer is more important than the transmit buffer because packets can be retransmitted if they are dropped from the transmit buffer.

The quality of service (QoS) requirements limit the probability of losing received pack-ets to 1%. How do we determine whether the design has enough memory to satisfy this requirement? To answer this question we need

to model behaviors such as packet loss from the receive buffer and its relation to the size of the shared memory.

Figure 6 shows the SimEvents model of this system. The upper part of the model describes a receive buffer, where messages arrive from an I/O device such as a universal asynchro-nous receiver transmitter (UART). The lower part of the model describes a transmit buffer, where messages wait before transmission.

Both receive and transmit buffers model the following processes:

Generation of variable-size messages. The traffic-generation process generates messages with variable size. Each message consumes a certain space from the shared memory, de-pending on its size.

Figure 6. Shared memory management.


Regulation of the messages that cannot be stored in the buffer. When a buffer size crosses a user-defined threshold, the Message Flow Regulation subsystems begin to drop incoming messages.

Storage of messages in a buffer. The receive and transmit buffers share memory, and the receive buffer is given a preference. The memory available for transmitting messages is limited to that which is unused by the receive buffer. The Transmit Buffer and Receive Buffer subsystems both have input signals labeled “cap” that represent the capacity of each buffer.

Service of messages. The block labeled Rx Message Server models the delay in forward-ing messages over the I/O bus that connects to other components. The block labeled Tx Message Server models the delay in trans-mitting messages.

During simulation, the Rx Message Loss Rate block displays packet loss rate for receive buffer. As Figure 6 shows, the packet loss rate at the receive buffer is 6%, which does not satisfy the QoS requirement of 1% .

To study the effect of memory size on this packet loss rate, we simulate this system with increased memory size. The following packet loss rates are observed for these simu-lation runs:

Memory Size Rx Packet Loss without Priority based QoS 8192 6.6% 10240 4.4% 16384 0%

These results indicate that packet loss rates decrease as memory size increases. As a system engineer, however, you might want to explore other techniques to reduce the packet loss rate, such as implementing pri-oritized regulation of messages (dropping low-priority messages before high-priority messages) and clearing the oldest messages

from a buffer when the buffer size crosses the threshold. An advanced version of this model shows that the packet loss rate can be reduced using these techniques. The follow-ing table shows the packet loss rates with this advanced model.

Memory Size Rx Packet Loss without Priority based QoS 8192 Packet Loss

(Low Priority): 1.13% Packet Loss (High Priority): 0 %

Benefits of this ApproachThis article illustrates the value of discrete-event simulation using SimEvents to per-form the following design tasks:

• Identify constraints on shared resources and bottlenecks in a system

• Simulate the effects of variable input traffic, such as congestion, packet loss, and increased end-to-end latencies

• Explore different design techniques and algorithms to optimize resource allocation

The real strength of this approach comes from the integration of SimEvents with MATLAB® and Simulink. In addition, inte-gration with tools such as SystemTest™ and Stateflow enable many other design tasks, such as Monte Carlo analysis or implement-ing control logic in event-driven systems for Model-Based Design. ■

ReferencesCassandras, C. G. and S. Lafortune. Introduc-tion to Discrete Event Systems. 2nd edition. Springer Publishers (2007).

Lenand, W.; Taqqu, M; Willinger, W; and Wilson, D. “On the Self Similar Nature of Ethernet Traffic (Extended Version).” IEEE/ACM Transactions on Networking, February 1994.

5 MATLAB Digest


Resources

visit www.mathworks.com

technical support www.mathworks.com/support

online user community www.mathworks.com/matlabcentral

Demos www.mathworks.com/demos

training services www.mathworks.com/training

thirD-party proDucts anD services www.mathworks.com/connections

Worldwide contactswww.mathworks.com/contact

e-mail [email protected]

91564v00 03/08

© 2008 The MathWorks, Inc. MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See www.mathworks.com/trademarks for a list of additional trade-marks. Other product or brand names may be trademarks or registered trademarks of their respective holders.

For More Information Demos

■ Distributed Processing of Packets: www.mathworks.com/des_packets

■ Modeling a Multitasking Operating System: www.mathworks.com/des_operatingsys

■ Performance Evaluation of a Distributed Processing Network using SimEvents and SystemTest: www.mathworks.com/des_network

Webinars

■ Discrete Event and Hybrid Modeling with SimEvents: www.mathworks.com/wbnr14278

■ Integrating MATLAB, Simulink and Stateflow Components in a SimEvents Model: www.mathworks.com/wbnr15638

Documents

Modeling System Architecture and Resource Constraints Using