All registers of a peripheral are enclosed between the <registers> opening and closing tags. Clusters define a set of registers. You can either use the <cluster> or the <register> element.

Example:

...
<peripheral>
  <registers>
    ...
  </registers>
</peripheral>
...

/device/peripherals/peripheral/registers

Parent Element	Element Chain
peripheral	/device/peripherals/peripheral element
Child Elements	Description	Type	Occurrence
cluster	Define the sequence of register clusters.	clusterType	0..*
register	Define the sequence of registers.	registerType	1..*

/device/pripherals/peripheral/registers/.../cluster element

Cluster describes a sequence of neighboring registers within a peripheral. A <cluster> specifies the addressOffset relative to the baseAddress of the grouping element. All <register> elements within a <cluster> specify their addressOffset relative to the cluster base address (<peripheral.baseAddress> + <cluster.addressOffset>).

Multiple <register> and <cluster> sections may occur in any order. Since version 1.3 of the specification, the nesting of <cluster> elements is supported. Nested clusters express hierarchical structures of registers. It is predominantely targeted at the generation of device header files to create a C-data structure within the peripheral structure instead of a flat list of registers. Note, you can also specify an array of a cluster using the <dim> element.

/device/pripherals/peripheral/registers/.../cluster

Parent Element	Element Chain
registers	/device/peripherals/peripheral/registers element
cluster	/device/pripherals/peripheral/registers/.../cluster element
Attributes	Description	Type	Occurrence
derivedFrom	Specify the cluster name from which to inherit data. Elements specified subsequently override inherited values. Usage: Always use the full qualifying path, which must start with the peripheral <name>, when deriving from another scope. (for example, in periperhal B, derive from peripheralA.clusterX). You can use the cluster <name> when both clusters are in the same scope. No relative paths will work. Remarks: When deriving a cluster, it is mandatory to specify at least the <name>, the <description>, and the <addressOffset>.	registerType	0..1
Child Elements	Description	Type	Occurrence
	Refer to dimElementGroup for details.
dim	Define the number of elements in an array of clusters.	scaledNonNegativeInteger	1..1
dimIncrement	Specify the address increment, in Bytes, between two neighboring clusters of the cluster array.	scaledNonNegativeInteger	1..1
dimIndex	Specify the strings that substitute the placeholder [%s] within the cluster <name>. Use the placeholder %s in <name> when <dimIndex> is specified.	dimIndexType	0..1
dimName	Specify the name of the C-type structure. If not defined, then the entry of the <name> element is used.	identifierType	0..1
dimArrayIndex	Grouping element to create enumerations in the header file.	dimArrayIndexType	0..1
name	String to identify the cluster. Cluster names are required to be unique within the scope of a peripheral. A list of cluster names can be build using the placeholder %s. Use the placeholder [%s] at the end of the identifier to generate arrays in the header file. The placeholder [%s] cannot be used together with <dimIndex>.	dimableIdentifierType	1..1
description	String describing the details of the register cluster.	xs:string	0..1
alternateCluster	Specify the name of the original cluster if this cluster provides an alternative description.	dimableIdentifierType	0..1
headerStructName	Specify the struct type name created in the device header file. If not specified, then the name of the cluster is used.	identifierType	0..1
addressOffset	Cluster address relative to the <baseAddress> of the peripheral.	scaledNonNegativeInteger	1..1
	Refer to registerPropertiesGroup for details.
size	Define the default bit-width of any device register (implicit inheritance).	scaledNonNegativeInteger	0..1
access	Define access rights.	accessType	0..1
protection	Specify the security privilege to access an address region.	protectionStringType	0..1
resetValue	Define the default value for all registers at RESET.	scaledNonNegativeInteger	0..1
resetMask	Identify register bits that have a defined reset value.	scaledNonNegativeInteger	0..1
register	Define a sequence of register within a cluster.	registerType	0..*
cluster	Element to nest cluster definitions.	clusterType	0..*

/device/peripherals/peripheral/registers/.../register element

The description of registers is the most essential part of SVD. If the elements <size>, <access>, <resetValue>, and <resetMask> have not been specified on a higher level, then these elements are mandatory on register level.

A register can represent a single value or can be subdivided into individual bit-fields of specific functionality and semantics. From a schema perspective, the element <fields> is optional, however, from a specification perspective, <fields> are mandatory when they are described in the device documentation.

You can define register arrays where the single description gets duplicated automatically. The size of the array is specified by the <dim> element. Register names get composed by the element <name> and the index-specific string defined in <dimIndex>. The element <dimIncrement> specifies the address offset between two registers.

Example:

...
<register>
  <name>TimerCtrl0</name>
  <description>Timer Control Register</description>
  <addressOffset>0x0</addressOffset>
  <access>read-write</access>
  <resetValue>0x00008001</resetValue>
  <resetMask>0x0000ffff</resetMask>
  <size>32</size>
</register>
<register derivedFrom="TimerCtrl0">
  <name>TimerCtrl1</name>
  <description>Derived Timer</description>
  <addressOffset>0x4</addressOffset>
</register>
...

This example describes two registers, TimerCtrl0 and TimerCtrl1. The values defined for TimerCtrl0 are inherited by the derived register TimerCtrl1, except for the value in <addressOffset>.

Example:

...
<register>
    <name>TIM_MODEA</name>
    <description>In mode A this register acts as a reload value</description>
    <addressOffset>0xC</addressOffset>
</register>
<register>
    <name>TIM_MODEB</name>
    <description>In mode B this register acts as the compare value</description>
    <alternateRegister>TIM_MODEA</alternateRegister>
    <addressOffset>0xC</addressOffset>
</register>
<register>
    <name>DMA_DATA</name>
    <description>This register contains the address of the data being transferred</description>
    <dataType>uint32_t *</dataType>
    <addressOffset>0xf0</addressOffset>
</register>
...

This example describes two registers, TIM_MODEA and TIM_MODEB. Both have the same address offset. Based on the configured operation model being A or B, the register acts as reload or compare value. The register DMA_DATA is specified as a pointer to unsigned word data. The code generated for the device header file is:

typedef struct {
  union {
    __IO   uint32_t TIM_MODEA;
    __IO   uint32_t TIM_MODEB;
    };
  __IO uint32_t * DMA_DATA; 
  ...
} <peripheral:name>_Type;

/device/peripherals/peripheral/registers/.../register

Parent Element	Element Chain
cluster	/device/pripherals/peripheral/registers/.../cluster element
registers	/device/peripherals/peripheral/registers element
Attributes	Description	Type	Occurrence
derivedFrom	Specify the register name from which to inherit data. Elements specified subsequently override inherited values. Usage: Always use the full qualifying path, which must start with the peripheral <name>, when deriving from another scope. (for example, in periperhal B, derive from peripheralA.registerX. You can use the register <name> only when both registers are in the same scope. No relative paths will work. Remarks: When deriving, it is mandatory to specify at least the <name>, the <description>, and the <addressOffset>.	xs:Name	0..1
Child Elements	Description	Type	Occurrence
	Refer to dimElementGroup for details.
dim	Define the number of elements in an array of registers. If <dimIncrement> is specified, this element becomes mandatory.	scaledNonNegativeInteger	1..1
dimIncrement	Specify the address increment, in Bytes, between two neighboring registers.	scaledNonNegativeInteger	1..1
dimIndex	Specify the substrings that replaces the %s placeholder within name and displayName. By default, the index is a decimal value starting with 0 for the first register. dimIndex should not be used together with the placeholder [%s], but rather with %s.	dimIndexType	0..1
dimName	Specify the name of the C-type structure. If not defined, then the entry of the <name> element is used.	identifyerType	0..1
dimArrayIndex	Grouping element to create enumerations in the header file.	dimArrayIndexType	0..1
name	String to identify the register. Register names are required to be unique within the scope of a peripheral. You can use the placeholder %s, which is replaced by the dimIndex substring. Use the placeholder [%s] only at the end of the identifier to generate arrays in the header file. The placeholder [%s] cannot be used together with dimIndex.	registerNameType	1..1
displayName	When specified, then this string can be used by a graphical frontend to visualize the register. Otherwise the name element is displayed. displayName may contain special characters and white spaces. You can use the placeholder %s, which is replaced by the dimIndex substring. Use the placeholder [%s] only at the end of the identifier. The placeholder [%s] cannot be used together with dimIndex.	xs:string	0..1
description	String describing the details of the register.	xs:string	0..1
alternateGroup	Specifies a group name associated with all alternate register that have the same name. At the same time, it indicates that there is a register definition allocating the same absolute address in the address space.	xs:Name	0..1
alternateRegister	This tag can reference a register that has been defined above to current location in the description and that describes the memory location already. This tells the SVDConv's address checker that the redefinition of this particular register is intentional. The register name needs to be unique within the scope of the current peripheral. A register description is defined either for a unique address location or could be a redefinition of an already described address. In the latter case, the register can be either marked alternateRegister and needs to have a unique name, or it can have the same register name but is assigned to a register subgroup through the tag alternateGroup (specified in version 1.0).	identifierType	0..1
addressOffset	Define the address offset relative to the enclosing element.	scaledNonNegativeInteger	1..1
	Refer to registerPropertiesGroup for details about the colored elements.
size	Defines the default bit-width of any register contained in the device (implicit inheritance).	scaledNonNegativeInteger	0..1
access	Defines the default access rights for all registers.	accessType	0..1
protection	Defines the protection rights for all registers.	protectionStringType	0..1
resetValue	Defines the default value for all registers at RESET.	scaledNonNegativeInteger	0..1
resetMask	Identifies which register bits have a defined reset value.	scaledNonNegativeInteger	0..1
dataType	It can be useful to assign a specific native C datatype to a register. This helps avoiding type casts. For example, if a 32 bit register shall act as a pointer to a 32 bit unsigned data item, then dataType can be set to "uint32_t ". The following simple data types are predefined: uint8_t: unsigned byte uint16_t: unsigned half word uint32_t: unsigned word uint64_t: unsigned double word int8_t: signed byte int16_t: signed half word int32_t: signed world int64_t: signed double word uint8_t : pointer to unsigned byte uint16_t : pointer to unsigned half word uint32_t : pointer to unsigned word uint64_t : pointer to unsigned double word int8_t : pointer to signed byte int16_t : pointer to signed half word int32_t : pointer to signed world int64_t *: pointer to signed double word	dataTypeType	0..1
modifiedWriteValues	Element to describe the manipulation of data written to a register. If not specified, the value written to the field is the value stored in the field. The other options define bitwise operations: oneToClear: write data bits of one shall clear (set to zero) the corresponding bit in the register. oneToSet: write data bits of one shall set (set to one) the corresponding bit in the register. oneToToggle: write data bits of one shall toggle (invert) the corresponding bit in the register. zeroToClear: write data bits of zero shall clear (set to zero) the corresponding bit in the register. zeroToSet: write data bits of zero shall set (set to one) the corresponding bit in the register. zeroToToggle: write data bits of zero shall toggle (invert) the corresponding bit in the register. clear: after a write operation all bits in the field are cleared (set to zero). set: after a write operation all bits in the field are set (set to one). modify: after a write operation all bit in the field may be modified (default).	modifiedWriteValuesType	0..1
writeConstraint	Three mutually exclusive options exist to set write-constraints.	writeConstraintType	0..1
readAction	If set, it specifies the side effect following a read operation. If not set, the register is not modified. The defined side effects are: clear: The register is cleared (set to zero) following a read operation. set: The register is set (set to ones) following a read operation. modify: The register is modified in some way after a read operation. modifyExternal: One or more dependent resources other than the current register are immediately affected by a read operation (it is recommended that the register description specifies these dependencies). Debuggers are not expected to read this register location unless explicitly instructed by the user.	readActionType	0..1
fields	In case a register is subdivided into bit fields, it should be reflected in the SVD description file to create bit-access macros and bit-field structures in the header file.	fieldsType	0..1

/device/peripherals/peripheral/registers/.../register/.../writeConstraint element

Define constraints for writing values to a field. You can choose between three options, which are mutualy exclusive.

Example:

<register>
  ...
  <writeConstraint>
    <useEnumeratedValues>true</useEnumeratedValues>
  </writeConstraint>
  ...
  <field>
    <name>F_ONE</name>
    ...
    <writeConstraint>
      <range>
        <minimum>2</minimum>
        <maximum>4</maximum>
      </range>
    </writeConstraint>
    ...
  <field>
  <field>
    <name>F_TWO</name>
    ...
    <writeConstraint>
      <writeAsRead>true</writeAsRead>
    </writeConstraint>
    ...
  <field>
  <field>
    <name>F_N</name>
    ...
  <field>
  ... 
<register>  

The example shows write constraints defined on different levels. The write constrains on <register> level are propagated as default to all subsequent fields, especially to field F_N. Field F_ONE overwrites the default and sets the write range between 2..4. Other values cannot be written to this field. Field F_TWO overwrites the default and allows to write only the last read value.

/device/peripherals/peripheral/registers/.../register/.../writeConstraint

Parent Element	Element Chain
register	/device/peripherals/peripheral/registers/.../register element
field	/device/peripherals/peripheral/registers/.../fields/field element
Child Elements	Description	Type	Occurrence
writeAsRead	If true, only the last read value can be written.	xs:boolean	0..1
useEnumeratedValues	If true, only the values listed in the enumeratedValues list can be written.	xs:boolean	0..1
range	Contains the following two elements:		0..1
minimum	Specify the smallest number to be written to the field.	scaledNonNegativeInteger	1..1
maximum	Specify the largest number to be written to the field.	scaledNonNegativeInteger	1..1

/device/peripherals/peripheral/registers/.../register/fields element

Grouping element to define bit-field properties of a register.

Example:

...
<fields>
  ...
  <field>
    <name>TimerCtrl0_IntSel</name>
    <description>Select interrupt line that is triggered by timer overflow.</description>
    <bitOffset>1</bitOffset>
    <bitWidth>3</bitWidth>
    <access>read-write</access>
    <modifiedWriteValues>oneToSet</modifiedWriteValues>
    <writeConstraint>
      <range>
        <minimum>0</minimum>
        <maximum>5</maximum>
      </range>
    </writeConstraint>
    <readAction>clear</readAction>
  <field>
  ...
  <field>
    <name>BIT1</name> 
    <description>test</description>
    <bitRange>[7:0]</bitRange> 
    <access>read-write</access>
  </field>
  ... 
</fields>
...

The example creates two bit-files TimerCtrl0_IntSel and BIT1. The bit-field TimerCtrl0_IntSel has an bit offset of 1 and a depth of 3 bits, with unrestricted read and write access, a reset value of 0 and a write constraint of oneToSet, which means that only the written bit is changed. The value allowed to be written to the field range between 0-5. After a read operation, all bits are set to zero.

The bit-field BIT1, described as a test field, has the size of 8 bits and can be unlimited read and written.

/device/peripherals/peripheral/registers/.../register/fields

Parent Element	Element Chain
register	/device/peripherals/peripheral/registers/.../register element
Child Elements	Description	Type	Occurrence
field	Define the bit-field properties of a register.	fieldType	1..*

/device/peripherals/peripheral/registers/.../fields/field element

All fields of a register are enclosed between the <fields> opening and closing tags.

A bit-field has a name that is unique within the register. The position and size within the register can be decsribed in two ways:

by the combination of the least significant bit's position (lsb) and the most significant bit's position (msb), or
the lsb and the bit-width of the field.

A field may define an enumeratedValue in order to make the display more intuitive to read.

/device/peripherals/peripheral/registers/.../fields/field

Parent Element	Element Chain
fields	/device/peripherals/peripheral/registers/.../register/fields element
Attributes	Description	Type	Occurrence
derivedFrom	Specify the field name from which to inherit data. Elements specified subsequently override inherited values. Usage: Always use the full qualifying path, which must start with the peripheral <name>, when deriving from another scope. (for example, in periperhal A and registerX, derive from peripheralA.registerYY.fieldYY. You can use the field <name> only when both fields are in the same scope. No relative paths will work. Remarks: When deriving, it is mandatory to specify at least the <name> and <description>.	xs:Name	0..1
Child Elements	Description	Type	Occurrence
	Refer to dimElementGroup for details.
dim	Defines the number of elements in a list.	scaledNonNegativeInteger	1..1
dimIncrement	Specify the address increment, in bits, between two neighboring list members in the address map.	scaledNonNegativeInteger	1..1
dimIndex	Specify the strings that substitue the placeholder %s within <name> and <displayName>.	dimIndexType	0..1
dimName	Specify the name of the C-type structure. If not defined, then the entry in the <name> element is used.	identifierType	0..1
dimArrayIndex	Grouping element to create enumerations in the header file.	dimArrayIndexType	0..1
name	Name string used to identify the field. Field names must be unique within a register.	dimableIdentifierType	1..1
description	String describing the details of the register.	stringType	0..1
Choice of	Three mutually exclusive options exist to describe the bit-range:		1..1
1. bitRangeLsbMsbStyle
bitOffset	Value defining the position of the least significant bit of the field within the register.	scaledNonNegativeInteger	1..1
bitWidth	Value defining the bit-width of the bitfield within the register.	scaledNonNegativeInteger	0..1
2. bitRangeOffsetWidthStyle
lsb	Value defining the bit position of the least significant bit within the register.	scaledNonNegativeInteger	1..1
msb	Value defining the bit position of the most significant bit within the register.	scaledNonNegativeInteger	1..1
3. bitRangePattern
bitRange	A string in the format: "[<msb>:<lsb>]"	bitRangeType	0..1
access	Predefined strings set the access type. The element can be omitted if access rights get inherited from parent elements.	accessType	0..1
modifiedWriteValues	Describe the manipulation of data written to a field. If not specified, the value written to the field is the value stored in the field. The other options are bitwise operations: oneToClear: write data bit of one shall clear (set to zero) the corresponding bit in the field. oneToSet: write data bit of one shall set (set to one) the corresponding bit in the field. oneToToggle: write data bit of one shall toggle (invert) the corresponding bit in the field. zeroToClear: write data bit of zero shall clear (set to zero) the corresponding bit in the field. zeroToSet: write data bit of zero shall set (set to one) the corresponding bit in the field. zeroToToggle: write data bit of zero shall toggle (invert) the corresponding bit in the field. clear: after a write operation all bits in the field are cleared (set to zero). set: after a write operation all bits in the field are set (set to one). modify: after a write operation all bit in the field may be modified (default).	modifiedWriteValuesType	0..1
writeConstraint	Three mutually exclusive options exist to set write-constraints.	writeConstraintType	0..1
readAction	If set, it specifies the side effect following a read operation. If not set, the field is not modified after a read. The defined side effects are: clear: The field is cleared (set to zero) following a read operation. set: The field is set (set to ones) following a read operation. modify: The field is modified in some way after a read operation. modifyExternal: One or more dependent resources other than the current field are immediately affected by a read operation (it is recommended that the field description specifies these dependencies). Debuggers are not expected to read this field location unless explicitly instructed by the user.	readActionType	0..1 register
enumeratedValues	Next lower level of description.	enumerationType	0..2

/device/peripherals/peripheral/registers/.../field/enumeratedValues element

The concept of enumerated values creates a map between unsigned integers and an identifier string. In addition, a description string can be associated with each entry in the map.

  0 <-> disabled -> "The clock source clk0 is turned off."
  1 <-> enabled  -> "The clock source clk1 is running."
  2 <-> reserved -> "Reserved values. Do not use."
  3 <-> reserved -> "Reserved values. Do not use."

This information generates an enum in the device header file. The debugger may use this information to display the identifier string as well as the description. Just like symbolic constants making source code more readable, the system view in the debugger becomes more instructive. The detailed description can provide reference manual level details within the debugger.

Example:

<enumeratedValues>
    <name>TimerIntSelect</name>
    <usage>read-write</usage>
    <enumeratedValue>
        <name>disabled</name>
        <description>The clock source clk0 is turned off.</description>
        <value>0</value>
    </enumeratedValue>
    <enumeratedValue>
        <name>enabled</name>
        <description>The clock source clk1 is running.</description>
        <value>1</value>
    </enumeratedValue>
    <enumeratedValue>
        <name>reserved</name>
        <description>Reserved values. Do not use.</description>
        <isDefault>true</isDefault>
    </enumeratedValue>
</enumeratedValues>

/device/peripherals/peripheral/registers/.../field/enumeratedValues

Parent Element	Element Chain
field	/device/peripherals/peripheral/registers/.../fields/field element
Attributes	Description	Type	Occurrence
derivedFrom	Makes a copy from a previously defined enumeratedValues section. No modifications are allowed. An enumeratedValues entry is referenced by its name. If the name is not unique throughout the description, it needs to be further qualified by specifying the associated field, register, and peripheral as required. For example: field: clk.dis_en_enum register + field: ctrl.clk.dis_en_enum peripheral + register + field: timer0.ctrl.clk.dis_en_enum	xs:Name	0..1
Child Elements	Description	Type	Occurrence
name	Identifier for the whole enumeration section.	xs:Name	0..1
headerEnumName	Identifier for the enumeration section. Overwrites the hierarchical enumeration type in the device header file. User is responsible for uniqueness across description.	identifierType	0..1
usage	Possible values are read, write, or read-write. This allows specifying two different enumerated values depending whether it is to be used for a read or a write access. If not specified, the default value read-write is used.	enumUsageType	0..1
enumeratedValue	Describes a single entry in the enumeration. The number of required items depends on the bit-width of the associated field.	enumeratedValueType	1..*

/device/peripherals/peripheral/registers/.../enumeratedValue element

An enumeratedValue defines a map between an unsigned integer and a string.

/device/peripherals/peripheral/registers/.../enumeratedValue

Parent Element	Element Chain
enumeratedValues	/device/peripherals/peripheral/registers/.../field/enumeratedValues element
dimArrayIndex	/device/peripherals/peripheral/.../dimArrayIndex element
Child Elements	Description	Type	Occurrence
name	String describing the semantics of the value. Can be displayed instead of the value.	identifierType	0..1
description	Extended string describing the value.	xs:string	0..1
choice of			1..1
value	Defines the constant for the bit-field as decimal, hexadecimal (0x...) or binary (0b... or #...) number. E.g.: <value>15</value> <value>0xf</value> <value>0b1111</value> <value>#1111</value> In addition the binary format supports 'do not care' bits represented by x. E.g. specifying value 14 and 15 as: <value>0b111x</value> <value>#111x</value>	scaledNonNegativeInteger	0..1
isDefault	Defines the name and description for all other values that are not listed explicitly.	xs:boolean	0..1