Platform Description

This module provides information about the host platform where the loaded program will run on. More...

Classes
class	otawa::hard::ModeTransition
	Representation of a memory bank transition. More...
class	otawa::hard::Mode
	A working mode for the hardware memory. More...
class	otawa::hard::Bus
	A bus that tie together several memory banks. More...
class	otawa::hard::Bank
	A bank in the memory. More...
class	otawa::hard::Memory
	Class to represent the whole memory of the platform. More...
class	otawa::hard::Processor
	Description of a processor pipeline. More...
class	otawa::hard::Stage
	This class represents a stage in a pipeline. More...
class	otawa::hard::Queue
	The instructions queues stores instruction that come from one stage to another one. More...
class	otawa::hard::FunctionalUnit
	A functional unit is specialized in the computation of some kinds of instructions. More...
class	otawa::hard::Dispatch
	A dispatch object allows to map some kinds of instructions to a functional unit. More...
class	otawa::hard::Register
	Objects of this class are simple machine register, more accurately unbreakable atomic registers. More...
class	otawa::hard::RegBank
	This class represents a bank of registers. More...
class	otawa::hard::PlainBank
	A plain bank is a register bank whose registers have the same size and the same type. More...
class	otawa::hard::MeltedBank
	A melted bank may contains registers with different sizes and kinds. More...
class	otawa::hard::Cache
	This class contains the configuration of a level of cache of processor. More...
class	otawa::hard::CacheConfiguration
	This class represents the full configuration of caches of a processor. More...
class	otawa::hard::Platform
	This class records information about the architecture where the processed program will run. More...
class	otawa::hard::Platform::Identification
class	otawa::hard::PureCache

Detailed Description

This module provides information about the host platform where the loaded program will run on.

It includes descriptions for:

• processor registers,
• processor pipeline,
• cache hierarchy,
• memory spaces.

The ISA (Instruction Set architecture) is provided by the executable loader. It mainly includes register description and some other description (length of instructions and so on).

Other hardware items like processor, caches and memory are loaded by their own processor and configuration is passed as usual in the configuration property list passed to run a code processor. These configuration properties may be:

• otawa::CACHE_CONFIG – cache configuration
• otawa::CACHE_CONFIG_ELEMENT – cache configuration as an XML element
• otawa::CACHE_CONFIG_PATH – cache configuration contained in a file
• otawa::MEMORY_OBJECT – memory configuration
• otawa::MEMORY_ELEMENT – memory configuration as an XML element
• otawa::MEMORY_PATH – memory configuration contained in a file
• otawa::PROCESSOR – processor configuration
• otawa::PROCESSOR_ELEMENT – processor configuration as an XML element
• @ ref otawa::PROCESSOR_PATH – processor configuration contained in a file

A code processor may get these hardware items from the workspace if it requires the corresponding feature:

• otawa::hard::PROCESSOR_FEATURE
• otawa::hard::CACHE_CONFIGURATION_FEATURE
• otawa::hard::MEMORY_FEATURE

Processor Format

We describe here the format of processor configuration expressed in XML. This file is unserialized according the elm::serial2 module and therefore supports all its features. The XML format notation is detailed in hard_format .

<!-- PROCESSOR ::= -->
     <?xml version="1.0" encoding="UTF-8"?>
     <processor class="otawa::hard::Processor">
        <arch><!-- ISA name --></arch>
        <model><!-- processor model --></model>
        <builder><!-- processor builder --></builder>

        <stages> <!-- STAGE* --> </stages>

        <queues> <!-- QUEUE* --> </queues>
     <processor>

A processor is made of several stages linked by queues. A stage has a type that may be:

• FETCH – this stage gets instruction from the memory (it must the first in the pipeline and only one is accepted)
• LAZY – nothing interesting the analysis, just takes time
• EXEC (execution) – the instruction are executed at this point (this stage may contains functional unit and dispatcher)
• COMMIT – this is the last stage where instruction exits the pipeline

<!-- STAGE ::= -->
     <stage id="STAGE IDENTIFIER">
        <name><!-- name for human user --></name>
        <type><!-- one of FETCH, LAZY, EXEC or COMMIT (default LAZY) --></type>
        <width><!-- number of processed instruction per cycle (default 1) --></width>

        <!-- only for EXEC type of stage -->
        <fus><!-- FU* --></fus>
        <dispatch><!-- INST * --></dispatch>
     </stage>

The "fus" contains the list of available functional units. The dispatching of instructions between the functional units is given in the "dispatch" element.

<!-- FU ::= -->
        <fu id="FU identifier">
                <name><!-- name for human user --></name>
                <width><!-- number of instruction processed by cycle (default 1) --></width>?
                <latency><!-- number of cycle passed in the FU --></latency>?
                <pipelined><!-- TRUE if the FU is pipelined, FALSE else (default) --></pipelined>?
        </fu>

The "inst" allows to dispatch instruction in the FU.

Cache Configuration Format

Memory Description Format