Scribd
Upload
313 views8 pages

Tutorial About Cheddar

This document provides an overview of using the Cheddar real-time scheduling analysis tool. It describes editing models in Cheddar, including defining hardware components like cores and processors, and software components like tasks and address spaces. It also explains how to perform analyses in Cheddar, such as scheduling simulations to view task schedules and feasibility tests to check if deadlines are met. Screenshots show examples of the Cheddar interface when editing models and viewing analysis results.

Uploaded by

Mouna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
313 views8 pages

Tutorial About Cheddar

This document provides an overview of using the Cheddar real-time scheduling analysis tool. It describes editing models in Cheddar, including defining hardware components like cores and processors, and software components like tasks and address spaces. It also explains how to perform analyses in Cheddar, such as scheduling simulations to view task schedules and feasibility tests to check if deadlines are met. Screenshots show examples of the Cheddar interface when editing models and viewing analysis results.

Uploaded by

Mouna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Tutorial about Cheddar : an example of

real-time scheduling analysis with Cheddar

The window of the figure 1 should be displayed :

Fig. 1 : main window of Cheddar

The top part of this window (in gray in the figure) displays the time lines computed
during scheduling simulation. The bottom part of this window displays numeric
analysis results.
I.2 Editing the model to analyse

Those models can be written with any editors, but in the sequel, we will use the
graphical editor of Cheddar as follow :

1. First, the hardware components composing the execution environment


running the software must be descrided. With Cheddar, the execution
platform can be composed of one or several processor components
embedding each one or several core components with
optionnal cache components. A core component models a unit of
computation, i.e. an entity providing the support to run one or several tasks.

To describe a core component, use the menu Edit/Hardware/Core which


opens the windows of the figure 2 :

Fig. 2 : editing a core

A core component is defined by the following attributes :

o Name : the unique name of the component, here, core1.


o Scheduler type : RM or DM …...
o Preemptive type : specicy if the scheduler is preemptive or not.
o The other attributes can be ignored for such tutorial.
All the window you may use to edit Cheddar ADL components have the
same interface :

o Button Add : allows you to add a component to the architecture model.


o Button Delete : allows you to delete a component from the
architecture model. Before pushing this button, you must select the
targetted component in the component list in the right side of the
window.
o Button Modify : this button has a behavior similar to the Delete button,
excepts that the component is updated with the values of the attributes
in the left part of the window.
o Button Close : closes the window and validates all the updates made
since the windows was opened.
o Button Cancel : closes the window and cancels all the updates made
since the windows was opened.

Once core1 is defined, we can define processor components that


use core1 with the Edit/Hardware/Processor menu, which displays the
following windows:

Fig. 3 : editing a processor component

In the figure 3, we define a processor named cpu1 which is composed of


the core1 component. Adding or deleting a core inside a processor can be
achieved with the buttons Add and Delete from the subwindows called Cores
Table. In this lab, we restrict ourself with uniprocessor architecture models.
Then, processor only contains one core component and then, we need to
set Processor Type and Migration Type attributes respectively to Monocore
Type and No Migration Type values.

In the sequel, we express the software part of the system to analyse. For this
lab, this software part is mainly composed of the tasks and the shared
resource components. (task Cheddar ADL component type
and resource component type). Other software components exist in Cheddar
ADL, but they are not required there (See the Cheddar ADL reference guide
for further details). task and resource components have to be defined
inside Address Space components An Address Space component can be seen
as a entity modelling the concept of an application, or a Unix process
address space, or even an ARINC 653 partition.

The window of the figure 4 (menu Edit/Software/Address space) shows you


how to define a Address Space for the labs. The only attributes we have to
define are Name and Cpu Name. For the next exercises, we have to define
one Address Space component for each processor component. However, for
specific analysis as ARINC 653 or more generally, hierarchical architecture
models, more attributes have to be specified for such kind of component.

Fig. 4 : editing an address space component

The last step to edit a Cheddar ADL model is to specify task parameters,
which can be achieved with the menu Edit/Software/Task :
Fig. 5 : editing a task component

Again, such component type have mumerous attributes. The most importants
are :

o Name : the unique name of the component


o Task type : the type of the task, which specifies how the task will be
released. A task may be periodic, sporadic, released according to a
poisson process (e.g. poisson task type), GMF, aperiodic, ...
o Capacity : the WCET of the task
o Period : the delay between two successive release times of the task.
o Deadline : the deadline the task has to meet. It is a delay relative to the
period of the task (i.e. not an absolute deadline).
o Address space name and CPU name where the task is supposed to be
located/run.
o Priority : : priority level assigned to the task. 255 is the higher level
of priority ; 0 is the lower.

In the example of the figure 5, we have defined 3 tasks, which were periodic,
synchronous, with deadlines on requests, and then, which were defined with
the following attributes :
o Task T1 : Capacity = 2, Deadline = 6, Period = 6
o Task T2 : Capacity = 2, Deadline = 9, Period = 9
o Task T3 : Capacity = 3, Deadline = 12, Period = 12
o Priority attributes were assigned according to Rate Monotonic within
the allowed priority range (from 1 to 255).
o You should notice that the deadlines are equal to the periods (see
attribute Deadline).
o Finally, the attribute Start time is set to 0 in order to model a
synchronous task set.

I.3 Analysis of a model


In this last section, we show how to perform an analysis of the architecture
model previously designed.

From the menu Tools and for a given architecture model, we can perform 3
types of analysis with Cheddar:

1. We can use simulation tools to compute the scheduling of a task set,


and then, from such scheduling, to compute various performance criteria
(worst/average/best response times, missed deadlines, blocking time on
shared resources, deadlocks, ...).
2. We can also call various feasibility tests that allow the designers to
check deadlines without computing the scheduling of the task set.
3. If the previous tools have shown that some deadlines cannot be met,
we can also improve the architecture model by various means :
priority assignments, task partitionning, task clustering, ...

Under the menu, some buttons allow you to quickly access to a summary of
those Cheddar analysis features (all analysis features can be accessed by
the Tools menu). Indeed, the button starts a scheduling simulation and
the button computes a sample of feasibility tests for a basic periodic task
set. Basically, the button computes worst case task response time
following the Joseph et Pandia [JOS 86] method extended for any Deadline
and classical CPU bound tests. Again, for specific feasibility tests (e.g.
transactions), see the Tools menu.

Figures 6 et 7 show a screenshot of Cheddar for the model edited in section


I.2, and for results produced by buttons and . We can see there worst
case response times computed by the Joseph and Pandia [JOS 86] method
and also by the scheduling simulation on the hyper-period. Feasibility tests
on cpu utilization factor cannot be applied there as the tool cannot be sure
that priorities have been assigned according to Rate Monotonic. To apply
this test, one must change the scheduling policy of the core1 component with
the Rate_Monotonic_Protocol value.

We can also notice in the time lines that red rectangles show task release
times, black rectangles show when tasks are running. Many other display
options exist there and can be modified by the Tools/Scheduling/Scheduling
Options menu (for example : to display a different color for each task).

Fig. 6 : a scheduling simulation


Fig. 7 : compute schedulability feasibility tests

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy