C.2.1. SDM format guide

Types are defined based on fundamental types, or composites of types.

Types can be parameterized, with the parameters acting as type-modifiers. All parameters are optional. All parameters are named, and parameters are passed in a named list of (PARAMETER=VALUE, ...).

Types that can be user-visible have:

C++ style // comments are allowed, indicating that the rest of the line is a comment.

Two commands are defined, INCLUDE and TYPEDEF. These commands must appear at the beginning of a line, with no white space in front of them.

Except in definitions contained within an RDI register description file, such as armperip.xml, you can include other register type defintion files, using a #include structure:


INCLUDE “filename” // This is a comment.

The TYPEDEF command creates new types. It takes optional parameters of CLASS and NAME. If a type has a name, then it is user-visible. If it does not have a name, then it is visible only in other type definitions. Examples of types are NUMERIC, FLAG, ENUM, COMPOSITE, and IEEE_FLOAT. See SDM format reference for the definitive list.

For example,


TYPEDEF tZFLAG FLAG (SET="Z", UNSET="z")  // This is a comment.
TYPEDEF tFIQ FLAG (SET="F", UNSET="f")   // So is this.

Type definitions of ENUM and COMPOSITE types require more information than only the type parameter list:


TYPEDEF tMODE ENUM (WIDTH=5, DEFAULT=”Reserved”) 
{
    "User"=0x10,
    "FIQ"=0x11,
    "IRQ"=0x12,
    "SVC"=0x13,
    "Abort"=0x17,
    "Undef"=0x1b,
    "System"=0x1f}

Duplicate definitions are allowed in enums, to account for partially decoded enums. For example, a type given a user-visible name:


TYPEDEF tARMID (NAME=”Chip ID”, CLASS=”ARM”) ENUM (WIDTH=32) 
{
    “ARM720T” = 0x41807200,
    “ARM740T” = 0x41807400,
    ...
}

In the case of composites, each atom is a FIELD or a SEPARATOR. A FIELD is defined as groups of bits:


    FIELD [hi:lo] {,[hi:lo] {...}} (NAME=”<name>”,
                                    TYPE=<type>{(<params>, ...)},
                                    ACCESS=”<access>”)
    SEPARATOR (NAME=“String”)

Atoms combine as follows, optionally grouped using braces to provide grouping as appropriate:


TYPEDEF tPACKEDFLOAT(NAME="2x32bit float", CLASS="Floating Point")
COMPOSITE (WIDTH=64) 
{
    FIELD [63:32] (NAME="High", TYPE=IEEE_FLOAT (WIDTH=32)),
    FIELD [31:0]  (NAME="Low",  TYPE=IEEE_FLOAT (WIDTH=32))
}

TYPEDEF tPACKEDQ15 (NAME="2xQ-15-format", CLASS="DSP")  COMPOSITE (WIDTH=32) 
{
    FIELD [31:16] (NAME="High", TYPE=QFORMAT (N=1,M=15)),
    FIELD [15:0]  (NAME="Low",  TYPE=QFORMAT (N=1,M=15))
}

TYPEDEF tPSR (NAME=”PSR”, CLASS=”ARM”) COMPOSITE (WIDTH=32) 
{
    GROUP (NAME=”Flag bits”)
    {
        FIELD [31] (NAME="Zero Flag",     TYPE=tZFLAG, ACCESS=”RW”),
        FIELD [30] (NAME="Negative Flag", TYPE=tNFLAG, ACCESS=”RW”),
        FIELD [29] (NAME="Carry Flag",    TYPE=tCFLAG, ACCESS=”RW”),
        FIELD [28] (NAME="Overflow Flag", TYPE=tVFLAG, ACCESS=”RW”)
    },
    FIELD [27:8] (TYPE=RESERVED (WIDTH=30), ACCESS=”0”),
    GROUP (NAME=”Mode bits”)
    {
        FIELD [7]  (NAME="Thumb bit",     TYPE=tTHUMB, ACCESS=”RW”),
        FIELD [6]  (NAME="IRQ bit",       TYPE=tIRQ,   ACCESS=”RW”),
        FIELD [5]  (NAME="FIQ bit",       TYPE=tFIQ,   ACCESS=”RW”),
        SEPARATOR (TEXTNAME=”_”)
        FIELD [4:0] (NAME="Mode",         TYPE=tMODE,  ACCESS=”RW”)
    }
}

The access parameter is interpreted as follows:

Table C.7.  Interpretation of access parameter

ValueMeaning
RReadable
WWritable
VReserved (write as read)
ZWrite as zero (read undefined)
0Always 0
1Always 1
UUndefined
XNot readable, but caching any written values is permitted and useful
NNot cacheable (otherwise treated as cacheable)
Copyright © 1999-2006 ARM Limited. All rights reserved.ARM DUI 0066G
Non-Confidential