Part 2 - Embedded Board Design

VisualSim Tutorials ›› Embedded Board Design ››

Learning Objectives

Use the framework available in VisualSim to design an embedded application made of multiple concurrent tasks that execute on an embedded system board. Objectives of the tutorial are as follows:

Size the system configurations for memory utilization, power consumption, and latency.
Determine possible system bottlenecks.
Compute the latency for each task.
Define software behavior flow with task dependencies.

Introduction

Software application behavior is a unique watermark and requires a hardware configuration that meets the requirements. It is imperative that the application is evaluated on a range of target platforms to determine the most-suitable platform. This ensures that the production software does not have to be modified when the system is integrated.

In this tutorial, you define the behavior of an embedded software application as a sequence of activities that run on a target platform.

Design Methodology

The block diagram of this system is shown in Fig 1.

Figure 1: Embedded Board Design Block Diagram

A correctly assembled model must look as below. You can also compare your model with the following model:

$VS/doc/Training_Material/Tutorial/WebHelp/Tutorial/Performance_Modeling/Embed_Proc_Lab.xml

Embedded Board Design VisualSim Model

Figure 2: VisualSim Model

The system comprises the following hardware components:

A pre-emptive CPU

with an overhead of 3 µs (Task Context Switching Time).
running at a speed of 100 KHz.

System with an initial memory configuration 1 KB.

We intend to process three main tasks. There are three data flows, one for each task. The following table provides details of the three tasks.

Task F1	Task F2	Task F3
Highest priority Inter-arrival time: 2 ms Execution Time: 10 µs Memory: 20 bytes	Medium priority After 5 tasks of F1 Execution length: 4ms Memory: 100 Bytes	Lowest priority Inter-arrival time - Uniform distribution between 80 &120 ms Executes in 3 sequential phases Task F31: Execution length: 10 ms Memory amount: 200 bytes Task F32: Execution length: 5 ms Memory amount: 100 bytes Task F33 : Execution length: 20 ms Memory amount: 300 bytes

Block Diagram Usage of VisualSim

The key concept in modelling is to provide sufficient accuracy for all the relevant components and abstract the rest to delays. The hardware elements (Cache and CPUs) and the task set are relevant. Items such as the RTOS are not included in this study as they are common overhead for all the operations.

To translate the above requirements into model speak, consider the model to have five basic structures - architecture, behavior, workload, model parameters, and analysis. All of the requirements above must fit into one of these structures.

Mapping Block Diagram to VisualSim Model

Mapping of the block diagram to VisualSim Model is listed below:

From the Architecture blocks, CPUs are represented by the SystemResource and the Memory by the VariableList blocks in the VisualSim model.
Use the Mapper block to represent the mapping of tasks on to CPU from the behavioral flow. The task issues a request to the SystemResource representing CPU.
The workload generation represents the traffic sequence to stimulate the model. The workload generation starts with the Traffic block which generates the tasks.
ExpressionList blocks define the parameters for the tasks.
An ExpressionList block helps to decide the selection of tasks and also the availability of the cache memory.
System Resource Statistics are captured using the ResourceStatistics block.

Building of the VisualSim Model

Model construction can be sub-divided into three sections;

Architectural Definitions
Behavioral Definitions
Reports Generation

The following steps help you build the VisualSim Model:

Initial Setup

Open a new block diagram by selecting File >New >Block Diagram.
Drag the Digital block (Model >Simulator >Digital) onto the block diagram.
Set up the parameters (ModelSetup > Parameter=) as given in the following image.

Embedded Board Diagram Parameters
Figure 3: Parameters

Double click on DigitalSimulator and set the stopTime parameter as Sim_Time and the rest of the parameters as default settings.

(Note: VisualSim parameters are case sensitive, make sure to use the exact same parameter name)

Build Architecture

Use the VariableList block (Model_Setup > VariableList) to make sure that every 5 issues of Task1 generates a Task2. Define a local variable called F2_Count and assign with value 0.
Drag the SystemResource block (Resources > SystemResource) to represent the CPU processing of the Tasks. This supports pre-emption and must be used to set to context switching associated with task preparation.
Double-click the block and enter details for the parameters given in the following table. The rest of the parameters remain as default settings.

S.No.	Parameters	Value	Details
1.	Resource_Name	“Processor”	This is the name of this SystemResource block and is used by the Mapper to call this block to execute a transaction.
2.	Task_Context_Switch_Time	3.0	Task_Context_Switch_Time is used to model the time to switch between one scheduler task and another task. If the value is greater than 0.0, it is added to all new tasks starting, and before and after a task is pre-empted.
3.	Clock_Rate_Mhz	1.0	The Clock_Rate_Mhz is used to model delays, only if the Time_Type is 'Number_Clocks'. Scheduler delay is 'Task_Time' / (Clock_Rate_Mhz * 1000000.0). This value is ignored if the Time_Type is set to "Relative_Time.
4.	Time_Type	Number Clocks	Use 'Number_Clocks' to model more detailed behavior, such as a bus. In this case, the Task_Time in the Mapper blocks is the number of cycles. The Clock_Rate_Mhz of the System_Resource is used. The Delay Time = Task_Time / (Clock_Rate_Mhz * 1000000.0). If the Data Structure arrives out of sync with the clock, the processing does not start until the next clock cycle.
5.	Scheduler_Type	FCFS + Preempt	'FCFS + Preempt' is a First-Come-First-Serve scheduler that supports priority and preempts an executing task, if a higher priority task arrives.

Workflow Generation

Instantiate two Traffic (Traffic->Traffic) blocks to trigger tasks F1 and F2 from Traffic and F3 from Traffic2.
Double-click the Traffic blocks and enter details for the parameters given in the following table. The rest of the parameters remain as default settings.

S.No.	Parameters	Value	Details
1.	Start_Time	0.0 (For Traffic) 0.1 (For Traffic1)	This Parameter is the time delay before the first data structure is generated. The Default Value : 0.0 which is equal to one (1) TimeResolution value.
2.	Value_1	0.002 (For Traffic) 0.08 (For Traffic1)	Value1 is a parameter for the Time_Distribution. This is in units of time where 1.0 = 1 Second. Based on the selected distribution, this value is used differently.
3.	Value_2	2.0 (For Traffic) 0.12 (For Traffic1)	Value2 is a parameter for the Time_Distribution. This is in units of time where 1.0 = 1 second. Based on the selected distribution, this value is used differently.
4.	Time_Distribution	Fixed (Value_1) (For Traffic) Uniform (Value_1, Value_2) (For Traffic1)	Fixed (value1) selection means a packet will be generated for every Value_1 seconds Uniform (value1,value2) selection means the packet will generated for a uniform time between value1 and value2

Instantiate a ExpressionList block and connect the output port of Traffic block to ExpressionList block. Double click on the ExpressionList block and define the task definitions for function F1 as below.

S.No.	Parameter	Value
1.	Expression_List	input.Execution_Length = 0.00001 / Clock input.Memory_Amount = 20 input.Priority = 2 input.Task_Number = 1
2.	Output_Ports	Output
3.	Output_Values	Input
4.	Output_Conditions	true

Here, we have defined that the function F1 requires 20 bytes, priority as 2 and the unique identifier for the task Task_Number as 1.

Instantiate Fork (Behavior > Fork) block to allow F1 to spawn F2 after the 5th transaction. Connect the output port of ExpressionList block to input port of Fork block.
Instantiate an ExpressionList block to determine to send one F2 task after five F1 tasks.
Double-click the blocks and enter details for the parameters given in the following table.

S.No.	Parameter	Value
1.	Expression_List	F2_Count = F2_Count + 1 Result_A = (F2_Count == 5)?True:False F2_Count = (Result_A == True)?0:F2_Count /* F2 Task Definitions */ input.Execution_Length = 0.004 / Clock input.Memory_Amount = 100 input.Priority = 1 input.Task_Number = 2
2.	Output_Ports	output
3.	Output_Values	input
4.	Output_Conditions	Result_A

Connect second output port of Fork block to input port of ExpressionList2 block.

We have generated F1 and F2 tasks now, let us generate F3.

Instantiate an ExpressionList block (Behavior > ExpressionList) to define F3.
Double-click the block and enter the parameters for ExpressionsList3 as given in the following table. The rest of the parameters remain as default settings.

S.No.	Parameter	Value
1.	Expression_List	input.Execution_Length = 0.010 / Clock input.Memory_Amount = 500 input.Priority = 0 input.Task_Number = 3

Connect ExpressionList3 block to output port of Traffic2 block.
Now, Instantiate 2 Join blocks. Connect the blocks as below.

Figure 4: VisualSim Blocks 1

Instantiate an “Resource_QS_Allocate_Priority” block from Full Library > Resource > Quantity Based > Resource_QS_Allocate_Priority. The purpose of using this library is to allocate memory for the tasks and release allocated memory once the task processing is over. Releasing allocated memory is not performed by this Resource_QS_Allocate_Priority block but requires a block called Resource_QS_Free from Full Library > Resource > Quantity Based > Resource_QS_Free.
Configure Resource_QS_Allocate_Priority block as below. Remaining parameters can be left as default.

S.No.	Parameter	Value
1.	Resource_Capacity	Mem_Capacity
2.	Max_Queue_Occupancy	30

Here Resource_Capacity parameter defines the Memory Size; Max_Queue_Occupancy defines the Buffer to hold maximum outstanding memory requests.

Connect an ExpressionList block to reject_output port of Resource_QS_Allocate_Priority block. Double click on the ExpressionList block and configure as below.

S.No.	Parameter	Value
1.	Expression_List	/* none required */
2.	Output_Ports	output
3.	Output_Values	true
4.	Output_Conditions	true

Configure the output port of ExpressionList4 block as Boolean.
Connect a ThrowException (Full Library > Delay and utilities > Execution Control > ThrowException) to the output port of the ExpressionList4 block and set the message as Not enough Memory!!
Connect a TextDisplay to stats_output port to capture memory statistics.

The Resource_QS_Allocate_Priority requires integer value arriving at Quantity_Request port to request for memory, integer value arriving at Priority port to allocate priority for the requests, and integer value arriving at dimension port to select the right memory bank. In this case, we are assuming only one memory bank and hence value 1 will be expected at dimension port.

If multiple memory banks are used, then the memory capacity must be split among the banks.

As the required values are arriving as a data structure, we need to take these values and forward to the right ports. To do this, we use a ExpressionList block to forward the right values to right ports.

Instantiate ExpressionList block and configure the block as below.

S.No.	Parameter	Value
1.	Expression_List	/* none required */
2.	Output_Ports	output, MemReq, Priority, memBank
3.	Output_Values	input, input.Memory_Amount, input.Priority, 1
4.	Output_Conditions	true, true, true, true

Right click on the ExpressionList5 block and select Configure > Ports and add additional ports MemReq, Priority and memBank and assign the port type as below.

Figure 5: ExpressionList Additional Port

The Assembled model must look as below.

Figure 6: VisualSim Blocks 2

Use the Mapper (Mappers > Mapper) block to issue a request to the CPU represented using a SystemResource block.

At the output of the Mapper block, three different actions are performed. The first is the release of the memory using Resource_QS_Free block, the second is to compute the latency if the task executed is TaskF1 or TaskF2 or TaskF5. And the third one is to initiate another process if the Task is TaskF3 or TaskF4. Use the "Script" block to write a logic to spawn dependent processes.

Double-click the Mapper block and enter the parameters as given in the following table.

S.No.	Parameters	Value
1.	Target_Resource	"Processor"
2.	Task_Number	"Task_Number"
3.	Task_Priority	"Priority"
4.	Task_Time	"Execution_Length"
5.	Task_Plot_ID	1

Right-click the Script block to Customize->Configure Parameters from the right context menu and enter the parameter given in the following table. The rest of the parameters remain as default settings.

S.No.	Parameters	Value
1.	Block_Name	"Next_Task"

Now, Double-click the Script block (Or Select Script block and press CTRL+L) and enter the following script in the text window.

/* Start of Statistics                   */

if (input.Task_Number == 1 || input.Task_Number == 2 || input.Task_Number == 5) /* Indicates end of task */
{
if (input.Task_Number == 1) {
     Latency = TNow - input.TIME
     SEND (Plot, Latency)
}
else if (input.Task_Number == 2) {
     Latency = TNow - input.TIME
     SEND (Plot1, Latency)
}
else if (input.Task_Number == 5) {
     Latency = TNow - input.TIME
     SEND (Plot2, Latency)
}
}
else if (input.Task_Number == 3) /* Spawns new task 4 */
{
input.Execution_Length = 0.005 / Clock
input.Memory_Amount = 100
input.Priority      = 0
input.Task_Number   = 4
SEND (Next_Task, input)
}
else if (input.Task_Number == 4) /* Spawns new task 5 */
{
input.Execution_Length = 0.020 / Clock
input.Memory_Amount    = 300
input.Priority         = 0
input.Task_Number      = 5
SEND (Next_Task, input)
}
/* End of Script                       */

Close the Text Window and select Apply Changes.
Right click the Script block and select Customize > Ports. Add additional output ports called Plot1, Plot2, and Next_Task.

Figure 7: Script Block Additional Ports

Now, connect the port Next_Task back to second input port of Join2 block using a relation block. Successful connection looks as given in the below image. The reason for doing this is to process the tasks F4 and F5 that are generated in Script block.

Figure 8: VisualSim Model Blocks 3

Gathering Resource Statistics and Reports

To gather resource statistics and reports, use the following details:

Use the Results >ResourceStatistics to capture the statistics of the CPU. Configure the block as below.

Figure 9: Resource Statistics Parameters

To get a running average of the memory usage, use the SingleEvent block and set the time as Sim_Time. Connect the output port of SingleEvent block to Stats_input port of Resource_QS_Allocate_Priority block.
Latency computations are defined in the Script block, connect a TimeData plotter to Plot, Plot1 and Plot2 ports of the Script block
Connect a TimeData plotter block to task_plot port of SystemResource block.

Illustration of the Model

A correctly assembled model must look as given below. You can also compare your model with the following model:

$VS/doc/Training_Material/Tutorial/WebHelp/Tutorial/Performance_Modeling/Embed_Proc_Lab.xml

Figure 10: VisualSim Model

Caevats in Model Construction

If there is no data flowing through the model, then a problem arose due to incorrect parameter settings or mismatches in the port data Type. Due to this problem, a user-defined exception is displayed. The exception also indicates a possible solution.

For Example, if the DS name has been set incorrectly then the user might get the following Exception.

Exception Details
Block_Name	Embed_Proc_Lab.Traffic
Error	Creation of a Data Structure (DS) failed
Error_Number	Transaction_Source_02
Possible_Solution	Creation of a Data Structure (DS) failed Check Path if not in data folder Spelling of DS Name
Description	Data Structure Path.Name or Name: CPU_DS

Simulation Results

Simulation reports must help the designer to make architectural decisions. In this tutorial, we defined the behavior flow for three functions with and without dependency. We also considered the priorities for the tasks that are mapped on to the target platform and study the impact of priority on the performance of the tasks.

The following images depict the statistics.

Figure 11: Analysis Task Scheduling

In Figure 4, X-axis shows the CPU time spent on each task processing, Y-axis shows the task number. Zoom into a small region to see the activity time.

Figure 12: Analysis Latency

X-Axis is the simulation time and Y-Axis is the end-to-end latency for the Function 3.

EBD Analysis Collective Statistics
Figure 13: Analysis - Collective Statistics

Figure 6 suggests that there are about 1887 tasks entered and exited in the Processor. There is a maximum occupancy of 3 tasks waiting for processing and approximately 1 task will be in queue waiting for processing. Utilization of 7.4% suggests that CPU is underutilized and can be replaced with a low performance processor for the current requirements.

EBD Memory Status
Figure 14: Analysis - Memory Status

The Memory Stats suggests that the maximum memory requested collectively by all the tasks is 620 bytes.

Looking at Fig 6 and Fig7, we can come to a conclusion that the design requires a maximum of 700 Bytes memory and the processor can be run at much lower clock speed for example 100KHz instead of 1 MHz.

Modeling Consideration for Learners

The learners may consider the following details when modeling the system:

What is the minimum amount of memory necessary to design this system?
What is the average execution time for Task 3?
Could a CPU with 80% of the original power be used?
Is the initial memory sufficient?
Could a CPU with 75% of the original power be used?
What causes the increase in Latency for a particular Task?