1157 lines
65 KiB
HTML
1157 lines
65 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml"><head>
|
|
|
|
<title>CMSIS - SVD: Cortex Microcontroller Software Interface Standard - System View Description</title><meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
|
<meta name="ProgId" content="FrontPage.Editor.Document">
|
|
<style type="text">
|
|
|
|
|
|
|
|
</style>
|
|
<style type="text/css">
|
|
.style1 {
|
|
text-align: center;
|
|
}
|
|
.style2 {
|
|
font-weight: normal;
|
|
}
|
|
.style3 {
|
|
text-align: left;
|
|
}
|
|
.style4 {
|
|
color: #008000;
|
|
}
|
|
.style5 {
|
|
color: #0000FF;
|
|
}
|
|
.style6 {
|
|
color: #000000;
|
|
}
|
|
</style>
|
|
</head>
|
|
|
|
<body>
|
|
<h1 class="style1">Cortex Microcontroller Software Interface Standard<br>
|
|
System View Description</h1>
|
|
|
|
<p class="style1">This file describes the Cortex Microcontroller Software
|
|
Interface Standard - System View Description (CMSIS - SVD) concept and syntax.</p>
|
|
<p class="style1">Version: 1.02 - 27. July 2011</p>
|
|
|
|
<p class="style1">Information in this file, the accompany manuals, and software is<br>
|
|
Copyright © ARM Ltd.<br>All rights reserved.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<p><span style="FONT-WEIGHT: bold">Revision History</span></p>
|
|
<ul>
|
|
<li>Version 0.91: initial proposal.</li>
|
|
<li>Version 0.92: revised proposal considering forum feedback (e.g. consider
|
|
IP-XACT constructs and naming scheme)</li>
|
|
<li>Version 1.0: new elements: peripheral version, vendor specific
|
|
extension section, interrupt mapping information, global peripheral disable
|
|
condition, naming of register arrays, enhanced naming schemes, etc.</li>
|
|
<li>Version 1.0: SVD versioning and updated schema file</li>
|
|
<li>Version 1.01: Error corrections in the example code. "include" has been removed. Restricted to one device per file.</li>
|
|
<li>Version 1.02: Adding the use case of device header file generation.</li>
|
|
</ul>
|
|
|
|
<p> </p>
|
|
|
|
<hr>
|
|
|
|
<h2>Contents</h2>
|
|
|
|
<ol>
|
|
<li class="LI2"><a href="#1">About</a></li>
|
|
<li class="LI2"><a href="#2">Motivation</a></li>
|
|
<li class="LI2"><a href="#3">Requirements</a></li>
|
|
<li class="LI2"><a href="#4">Format</a></li>
|
|
<li class="LI2"><a href="#5">Example</a></li>
|
|
<li class="LI2"><a href="#6">Questions & Answers</a></li>
|
|
</ol>
|
|
|
|
<h2><a name="1"></a>About</h2>
|
|
|
|
<p>
|
|
The <strong>Cortex Microcontroller Software Interface Standard - System View
|
|
Description</strong> (CMSIS - SVD) answers the challenges
|
|
of accurate, detailed and timely device aware peripheral debugging support for Cortex
|
|
Microcontroller based devices by the software development
|
|
tools vendor community.
|
|
</p>
|
|
<p>
|
|
Silicon vendors shall create and maintain a formalized description of the
|
|
debug view for all the peripherals contained in their Cortex
|
|
Microcontroller based devices. Tool vendors use such descriptions to
|
|
establish device specific debug support in their debugging tools with minimal turn around times and
|
|
manageable effort. Device support across many development tools is
|
|
essential for silicon provider in order to promote new devices and device
|
|
variants entering the market. Device aware debug views provide fast and
|
|
convenient access to all registers and fields as well as a detailed
|
|
description. This enables software developer to
|
|
develop and debug code most efficiently and adopt new devices early and
|
|
quickly.</p>
|
|
<p>
|
|
A standardized System View Description shall provide a common approach to
|
|
capturing peripheral debug related information in a machine readable files.
|
|
The scope of the contained information is agreed to match the level usually
|
|
provided by silicon vendors in their device reference manuals, however in a
|
|
formalized XML based format. There
|
|
are other description languages already available. IP-XACT from the SPIRIT
|
|
consortium is a prominent example. IP-XACT covers the register description
|
|
sufficiently, however it comprises many other aspects of the devices like
|
|
ports, bus-protocols, modeling, tool flows, etc. making a direct use of
|
|
IP-XACT too complex. The design of the SVD language is
|
|
taking some guidance from IP-XACT thus allowing straight forward conversion
|
|
from IP-XACT to CMSIS-SVD where IP-XACT device information is already
|
|
available.</p>
|
|
<p>
|
|
In a second step the CMSIS-SVD description shall be used for automatically
|
|
generating CMSIS compliant a device header file. This enables the
|
|
information in the header file to be consistent with what the debugger will
|
|
display and CMSIS compliant by construction. The header file generation will
|
|
require some additional pieces of information and therefore a future version
|
|
of the description will need to include some extensions for this purpose.</p>
|
|
<p>
|
|
Device aware debugging support is only one aspect of device
|
|
support essential to software development environments, however it is one of
|
|
the most time consuming and error prone ones.</p>
|
|
<h2><a name="2"></a>Motivation</h2>
|
|
<p>
|
|
|
|
The software developer of microcontroller devices is faced with a growing number
|
|
of devices with an ever increasing number of peripheral blocks providing a wide
|
|
range of distinct and complex functionality. The development of drivers for
|
|
these peripherals is in the critical path of every project. Modern debuggers are supporting the software developer in getting the
|
|
software to run according to the requirements. A debugger providing peripheral awareness improves the
|
|
ability to access and interpret complex configuration and status information of
|
|
peripherals. Even though this is only one aspect of device support within microcontroller
|
|
development environments it is essential for the successful and timely adoption
|
|
of development tools and the device by the market.</p>
|
|
<p>Today software development environments address device aware
|
|
debugging in various ways. They either use documents or proprietary file formats
|
|
as input for providing peripheral views in the debuggers.
|
|
Extracting peripheral information from written documentation is a very time
|
|
consuming, tedious and error prone task. Having a file containing peripheral specific information to generate peripheral views
|
|
is going to make device support more affordable, reliable and timely.
|
|
The challenge for the tool providers is the support of many
|
|
different and incompatible file formats from a growing number of silicon vendors.
|
|
For silicon vendors it is time consuming and costly to engage with many tool
|
|
provider in order to achieve device support in a wide range of development
|
|
environments.</p>
|
|
<p>Standardizing on a System View Description aims to ease this challenge
|
|
by agreeing on a formal XML-based file format. In conjunction with supporting web server infrastructure silicon partner
|
|
shall upload and maintain such descriptions in a tool vendor agnostic device
|
|
database, hosted e.g. by the web server infrastructure
|
|
<a href="http://cmsis.arm.com">
|
|
cmsis.arm.com</a> . Access control to sensitive information is managed on a per user
|
|
basis. This allows silicon vendors to upload information for devices that have
|
|
not been made public. </p>
|
|
<p>Such an approach provides benefits for silicon and tool vendors as well as
|
|
software developers of Cortex-M based microcontroller devices</p>
|
|
<ul>
|
|
<li>timely and accurate device support provided by a whole range of tool providers </li>
|
|
<li>tool providers become more efficient in supporting a multitude of devices
|
|
and device variants</li>
|
|
<li>less interaction required between silicon vendors and the
|
|
tool providers</li>
|
|
<li>silicon provider has control over and maintains the System View
|
|
Description during the life cycle of the device</li>
|
|
<li>high quality device support in terms of completeness and correctness of
|
|
device aware debugging</li>
|
|
<li>improved productivity and user experience for the software developer</li>
|
|
</ul>
|
|
<h2><a name="3"></a>Requirements</h2>
|
|
<p>The debug description shall capture the information about all
|
|
the peripherals contained in a specific device. This section describes which
|
|
items of information are deemed relevant for a debugger. Silicon vendors are expected to
|
|
provide the System View Description for their devices, matching the information
|
|
contained in device reference manuals. The System View Description shall be suitable for straight forward
|
|
generation from existing databases like IP-XACT descriptions or SIDSC. The size
|
|
of device description is a concern and therefore redundancy in the description
|
|
shall be avoided. The size of SVD files affects the efficiency of
|
|
distribution as well as the loading time by the development tools. Last but not least manual editing of SVD files shall be possible for
|
|
the purpose of customization by SW developers.</p>
|
|
<h4>Required content of the description</h4>
|
|
<p>From a programmer's perspective a peripheral can be seen as a set of registers
|
|
with unique<em> names</em> being mapped to fixed<em> addresses</em> allocated
|
|
within a defined <em>range</em> of an address space.</p>
|
|
<p>From a debugger's point of view read accesses to a physical register need to be
|
|
executed in order to display its current value. The debugger executes a write
|
|
access to a register when a user edits its value. For this purpose the debugger
|
|
needs to know about the following additional attributes: </p>
|
|
<ul>
|
|
<li><em>minimal addressable unit </em>= smallest series of bits
|
|
identified by a unique address (e.g. byte-addressable memory) </li>
|
|
<li><em>register size</em> = number of bits forming a register (ARM Cortex-M usually
|
|
32 bits)</li>
|
|
<li><em>access permission</em> = read and write, read only,
|
|
write only</li>
|
|
<li><em>access side effects</em> = accesses by the debugger must
|
|
be avoided if it has side effects. Some side effects may be
|
|
reversed by the debugger to compensate for the side effect</li>
|
|
</ul>
|
|
<p>In many cases peripheral registers are partitioned into chunks of bits of
|
|
distinct functionality. In this document these chunks are referred to as <em>
|
|
field</em>. Each
|
|
register that consists of fields shall be described by a list
|
|
of <em>uniquely named</em> fields (Note: field names are not required to be
|
|
unique across registers). In order for a debugger to extract the
|
|
value of a field from the corresponding register the following attributes are required:</p>
|
|
<ul>
|
|
<li><em>most significant bit </em>= highest bit position of the
|
|
bit-field in the corresponding register</li>
|
|
<li><em>least significant bit</em> = lowest bit position of the
|
|
bit-field within the corresponding register</li>
|
|
<li><em>access permission</em> = read and write, read only,
|
|
write only</li>
|
|
</ul>
|
|
<p>An enumerated value maps a number to a specific descriptive string
|
|
representing the semantics of the value of a field. The debugger displays the
|
|
descriptive string rather than the number to simplify the access to the
|
|
information thus
|
|
avoiding the necessity of a look-up in the device reference manual. Each item of
|
|
an enumerated value has the following attributes:</p>
|
|
<ul>
|
|
<li><em>value</em> = value of the bit-field that corresponds to
|
|
the string attribute</li>
|
|
<li><em>name</em> = short string that describes the semantics of a
|
|
field when the corresponding value is set</li>
|
|
<li><em>description</em> = detailed description of the semantics
|
|
of the field when the corresponding value is set</li>
|
|
</ul>
|
|
<p>The hierarchical structure of the description looks like this:</p>
|
|
<p><strong>Device =</strong></p>
|
|
<ul>
|
|
<li>
|
|
<p> <strong>Peripherals</strong></p>
|
|
<ul>
|
|
<li>
|
|
<p class="style2"><strong>Peripheral</strong></p>
|
|
<ul>
|
|
<li>
|
|
<p class="style2"><strong>Registers</strong></p>
|
|
<ul>
|
|
<li>
|
|
<p class="style2">
|
|
<strong>Register</strong></p>
|
|
<ul>
|
|
<li>
|
|
<p class="style2">
|
|
<strong>Fields</strong></p>
|
|
<ul>
|
|
<li>
|
|
<p class="style2"><strong>Field</strong></p>
|
|
<ul>
|
|
<li>
|
|
<p class="style2"><strong>Enumerated Values</strong></p>
|
|
<ul>
|
|
<li>
|
|
<p class="style2"><strong>Enumerated Value</strong></p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>One file can only contain a description for a single device or device family
|
|
sharing the identical description. Devices consists of a one or more peripherals.
|
|
Each peripheral contains
|
|
one or more registers, where each register may consist of one or more fields.
|
|
The values of a field maybe represented through descriptive strings and detailed
|
|
descriptions, the enumerated values.</p>
|
|
<p>In many cases there are multiple
|
|
instances of the same peripheral in a device (e.g. Timer0, Timer1, etc.). For
|
|
this reason the description has the concept of deriving a peripheral from a peripheral
|
|
that has already been described. The attribute <em>derivedFrom </em>specifies
|
|
such a relationship.
|
|
Similarly registers or fields can be reused within the device description. The
|
|
grouping of peripherals providing
|
|
similar functionality (e.g. Simple Timer, Complex Timer) is controlled via the element <em>groupName</em>.
|
|
All peripherals associated with the same group name are collectively listed under this group
|
|
in the order they have been specified in the file.
|
|
Collecting
|
|
similar or related peripherals into peripheral groups helps structuring the list
|
|
of peripherals e.g. in a drop down menu (tool dependent). Devices with a large
|
|
set of peripherals will benefit from this additional level of structure.</p>
|
|
<p>Each of the items (i.e. Device, Peripheral, Register and
|
|
Field) owns an <em>description </em>element containing verbose information about
|
|
the respective element. The description field plays
|
|
an important part in improving the software development productivity. Instead of
|
|
searching through the reference manual the detailed explanation from the manual
|
|
could become immediately accessible from within the development environment.</p>
|
|
<p>Details about the exact display format and layout of the peripheral view are
|
|
considered beyond the scope of the description. It is up to the tool vendor to
|
|
visualize the contained information appropriately. The
|
|
silicon vendor provides details about the device's peripherals that is commonly available. </p>
|
|
<p>System View Description files need to be validated for:</p>
|
|
<ol>
|
|
<li>syntactical correctness using XML-Schema checking utilities</li>
|
|
<li>consistency of the provided information (e.g. multiple registers mapped to the same address,
|
|
all registers located within the specified address ranges of a
|
|
peripheral, all fields are within the range of the register
|
|
size, etc.) by a utility developed by ARM (SVDConv.exe)</li>
|
|
<li> semantical correctness of the System View Description
|
|
against the silicon specification executed by the silicon vendor</li>
|
|
</ol>
|
|
<p>The SVD description format was extended by numerous elements during the
|
|
review period targeting version 1.0 and new extensions are expected for future
|
|
versions of this format. A new section named "vendorExtensions" has been added
|
|
to the end of the top level to allow silicon vendors and tool partners to
|
|
innovate and expand the description in order to overcome limitations of the
|
|
current specification until these can be incorporated into new versions of
|
|
CMSIS-SVD. <br>
|
|
</p>
|
|
|
|
<h2> <a name="4"></a><span class="style9">Format</span></h2>
|
|
|
|
<p>
|
|
The following section describes the SVD file format in detail. Each subsection
|
|
defines a single hierarchy level of the description and lists all mandatory
|
|
and optional language elements for that specific level including type
|
|
information for each element. Each element is discussed in more detail and a
|
|
brief snippet is provided as an example. The sequence of elements shown
|
|
below is binding. Optional elements are highlighted in green, blue elements
|
|
are mandatory unless they have been already specified globally on a higher
|
|
level.</p>
|
|
<p>
|
|
An XML-schema file is provided alongside this document for syntactical
|
|
checking of descriptions being developed.</p>
|
|
<h4><device schemaVersion="xs:decimal" <span class="style2"><em>xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="CMSIS-SVD_Schema_1_0.xsd</em></span>"></h4>
|
|
<p> <<span class="style2">name><em>xs:Name</em></name><br>
|
|
<version<em>>xs:string<</em>/version><br>
|
|
<description><em>xs:string</em></description><br>
|
|
</span> <<span class="style2">addressUnitBits><em>scaledNonNegativeInteger</em></addressUnitBits><br>
|
|
<width><em>scaledNonNegativeInteger</em> </width></span><br>
|
|
<br>
|
|
<span class="style4"> <</span><span class="style2"><span class="style4">size><em>scaledNonNegativeInteger</em></size><em><br>
|
|
</em> <access><em>accessType</em></access><br>
|
|
<resetValue><em>scaledNonNegativeIntege</em>r</resetValue><br>
|
|
<resetMask><em>scaledNonNegativeInteger</em></resetMask></span></span></p>
|
|
<p> <peripherals><br>
|
|
...<br>
|
|
</peripherals><br>
|
|
<span class="style4"> <vendorExtensions><br>
|
|
...<br>
|
|
</vendorExtensions></span></p>
|
|
<h4></device></h4>
|
|
<p>The <strong>device</strong> provides the outermost frame of the description. All other
|
|
elements like peripherals, registers and fields are described inside of this scope. A device contains one or more peripherals.
|
|
The optional elements size, access, resetValue and resetMask are used as default values throughout the
|
|
device description unless they get overruled on a lower level of the description
|
|
(e.g. peripheral or register).</p>
|
|
<h4>Mandatory items:</h4>
|
|
<p><strong>name = </strong>the unique name string is used to identify the device.
|
|
All devices of a silicon vendor are required to have a unique name. In case an
|
|
SVD description covers a family or series of devices, the name of the series or
|
|
family is placed here. The device names of the members of the series or family
|
|
are listed in <memberDevices></p>
|
|
<p><strong>description = </strong>string describing main features of a device
|
|
(e.g. CPU, clock frequency, peripheral overview, etc.)</p>
|
|
<p><strong>version = </strong>the string is defining the version of the
|
|
description for this device. Silicon vendors will maintain the description
|
|
throughout the lifecycle of the device and need to ensure that all updated and
|
|
released copies have a unique version string indicating the order in which. Note: this must not be used for
|
|
detailing the version of the device.</p>
|
|
<p> </p>
|
|
<p><strong>addressUnitBits = </strong>defines the number of data bits for each address
|
|
increment. The value for Cortex-M based devices is 8 (byte-addressable).</p>
|
|
<p><strong>width = </strong>defines the number of bits for the maximum single
|
|
transfer size allowed by the bus interface hence the maximum size of a single
|
|
register that can be defined for the address space. This information is relevant
|
|
for debuggers when determining the size of debug transfers. The expected value
|
|
for Cortex-M based devices is 32.</p>
|
|
<p><strong>peripherals = </strong>next level of description (see next section
|
|
for details)</p>
|
|
<h4>Optional Items:</h4>
|
|
<p><strong>size = </strong>defines the default bit-width of registers contained
|
|
in the device. This element can be overruled by re-specifying the size element on a lower level of the
|
|
description.</p>
|
|
<p><strong>access =</strong> defines the default access permissions for all
|
|
registers in the device. The allowed tokens are:<br>
|
|
- <em>read-only</em>: read access is permitted. Write operations have an undefined
|
|
result.<br>
|
|
- <em>write-only</em>: write access is permitted. Read operations have an
|
|
undefined result. <br>
|
|
-<em>read-write</em>: both read and write accesses are permitted. Writes affect
|
|
the state of the register and reads return a value related to the register<br>
|
|
-<em>writeOnce</em>: only the first write after reset has an effect on the
|
|
register. Read operations deliver undefined results<br>
|
|
-<em>read-writeOnce</em>: Read operations deliver a result related to the register
|
|
content. Only the first write access to this register after a reset will have an
|
|
effect on the register content.</p>
|
|
<p><strong>resetValue = </strong>defines the default value of all registers
|
|
after a reset. There are scenarios where SW developers need to know, what the
|
|
reset value of a register or field is. Even though listed as optional on this
|
|
level of the description, silicon vendors should ensure that this information is
|
|
provided for all registers. </p>
|
|
<p><strong>resetMask =</strong> defines those bit positions set to one to be
|
|
taken from resetValue element. All other elements are undefined. If a register
|
|
does not have a defined reset value the resetMask needs to be set to 0.</p>
|
|
<p><strong>vendorExtensions </strong>= the content and format of this section of
|
|
the description is unspecified. Silicon vendors may choose to provide additional
|
|
information. The assumption is that by default this section is completely
|
|
ignored by the debugger. It is up to the silicon vendor to specify the content
|
|
of this section and share the specification with the tool vendors. The new
|
|
elements shall be considered for a future version of the description format.</p>
|
|
<h4>Example:</h4>
|
|
<pre><device schemaVersion="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="CMSIS-SVD_Schema_1_0.xsd" >
|
|
<name>CMSIS_Cortex-M3</name>
|
|
<version>0.1</version>
|
|
<description>ARM Cortex-M3 based Microcontroller demonstration device</description>
|
|
<addressUnitBits>8</addressUnitBits>
|
|
<width>32</width>
|
|
<size>32</size>
|
|
<access>read-write</access>
|
|
<resetValue>0</resetValue>
|
|
<resetMask>0xffffffff</resetMask></pre>
|
|
<pre> <peripherals>
|
|
...
|
|
</peripherals>
|
|
</device></pre>
|
|
<p>The device description above is at version 0.1 and uniquely identifies the
|
|
device by the name "CMSIS_Cortex-M3". The peripherals are memory mapped in a
|
|
byte-addressable address space with a bus width of 32 bits. The default size of
|
|
the registers contained in the peripherals is set to 32 bits. Unless redefined
|
|
for specific peripherals, registers or fields all registers are read-write
|
|
accessible. A reset value of 0 valid for all 32 bits as specified by the reset
|
|
mask is set for all registers unless overruled at a lower level of the description.</p>
|
|
<hr>
|
|
<h4><peripherals></h4>
|
|
<p> <peripheral><br>
|
|
...<br>
|
|
</peripheral></p>
|
|
<p> ...</p>
|
|
<p> <peripheral><br>
|
|
...<br>
|
|
</peripheral></p>
|
|
<h4></peripherals></h4>
|
|
<p>This construct sets the frame for all peripherals and peripheral groups contained in a device. This
|
|
creates a container element which ease-up processing with languages like Java.</p>
|
|
<hr>
|
|
<h4><peripheral <span class="style2"><span class="style4">derivedFrom=<em>"xs:Name"</em></span></span>></h4>
|
|
<p> <name><em>xs:Name</em></name><br>
|
|
<span class="style4"><version>xs:string</name></span><br>
|
|
<description><em>xs:string </em></description><br>
|
|
<span class="style4"><groupName><em>xs:string</em></groupName><br>
|
|
<prependToName><em>xs:string</em></prependToName><br>
|
|
<appendToName><em>xs:string</em></appendToName></span><br>
|
|
<span class="style4"><disableCondition><em>xs:string</em></disableCondition></span><br>
|
|
<baseAddress><em>scaledNonNegativeInteger</em></baseAddress><br>
|
|
<span class="style4"> <</span><span class="style2"><span class="style4">size><em>scaledNonNegativeInteger</em></size><em><br>
|
|
</em> <access><em>accessType</em></access><br>
|
|
<resetValue><em>scaledNonNegativeIntege</em>r</resetValue><br>
|
|
<resetMask><em>scaledNonNegativeInteger</em></resetMask></span></span></p>
|
|
<p> <span class="style10"><addressBlock><br>
|
|
<offset></span><em>scaledNonNegativeInteger</em><span class="style10"></offset><br>
|
|
<size></span><em>scaledNonNegativeInteger</em><span class="style10"></size><br>
|
|
<usage<em>>usageType<</em>/usage><br>
|
|
<em> </</em>addressBlock><em><br>
|
|
</em> ...<br>
|
|
</span> <span class="style10"><span class="style4"><addressBlock><br>
|
|
<offset></span></span><span class="style4"><em>scaledNonNegativeInteger</em></span><span class="style10"><span class="style4"></offset><br>
|
|
<size></span></span><span class="style4"><em>scaledNonNegativeInteger</em></span><span class="style10"><span class="style4"></size><br>
|
|
<usage><em>usageType</em></usage><br>
|
|
<em> </</em>addressBlock><br>
|
|
<interrupt><br>
|
|
<name><em>xs:string</em></name><br>
|
|
<value><em>scaledNonNegativeInteger</em></value><br>
|
|
</interrupt></span><em><br>
|
|
</em></span> <registers><br>
|
|
...<br>
|
|
</registers></p>
|
|
<h4></peripheral></h4>
|
|
<p>A peripheral encloses the description of one or more registers belonging to
|
|
this named peripheral. The address range allocated in the address space for this
|
|
peripheral is defined through one or more address ranges. An address range is
|
|
specified relative to the base address of the peripheral. This information
|
|
allows to display a memory map overview for all peripherals. Please note that
|
|
such a memory map does not contain any information for memories and unoccupied
|
|
address ranges.</p>
|
|
<h4>Mandatory items:</h4>
|
|
<p><strong>name = </strong>name string used to identify the peripheral. Peripheral
|
|
names are required to be unique within the scope of a device.</p>
|
|
<p><strong>baseAddress </strong>= lowest address reserved or used by the peripheral</p>
|
|
<p><strong>description = </strong>string providing an overview of the purpose
|
|
and functionality of the peripheral</p>
|
|
<p><strong>addressBlock = </strong>a peripheral may occupy one or more disparate
|
|
blocks in the address space. An addressBlock is a complex element consisting of
|
|
the mandatory elements:<br>
|
|
<strong>offset</strong>: specifying the start address of an address block. It
|
|
is calculated from the sum of baseAddress and offset<br>
|
|
<strong>size</strong>: specifying the number of addressUnitBits being covered
|
|
by this address block. The end address of an address block is the sum of start
|
|
address and the size - 1.<br>
|
|
<strong>usage</strong>: the usage element is of <em>usageType </em>specifying
|
|
if the addresses within the specified address block is used for<strong> </strong>
|
|
<em>registers</em><strong> </strong>or <em>buffer</em><strong> </strong>or is <em>reserved</em>.
|
|
<br>
|
|
Note: registers must not be allocated
|
|
to an address within a reserved or buffer address range.</p>
|
|
<p><strong>registers = </strong>next lower level of description (see next section
|
|
for details)</p>
|
|
<h4>Optional items:</h4>
|
|
<p><strong>derivedFrom = </strong>this attribute specifies the name of a peripheral
|
|
that has already been described for this device. The description of that device
|
|
will be copied. It is mandatory to overwrite the name as well as the
|
|
addressOffset. All other specified information will overwrite the respective
|
|
elements in the copy.</p>
|
|
<p><strong>version = </strong>the string specifies the version of this
|
|
peripheral description.</p>
|
|
<p><strong>disableCondition = </strong>C language compliant logical expression
|
|
resulting in a true or false result. If "true" the refresh of the display
|
|
for this peripheral is disabled
|
|
and related accesses by the debugger are suppressed. Only constants and references to other registers
|
|
contained in the description are allowed:
|
|
<peripheral>-><register>-><field> (e.g.: (System->ClockControl->apbEnable == 0)).
|
|
Only the following operators are allowed [&&,||, ==, !=, >>, <<, &, |]. Warning!
|
|
This feature must only be use in case accesses from the debugger to registers of
|
|
un-clocked peripherals result in severe debugging failures. SVD is intended to
|
|
be fully static information and not include any run-time computation or
|
|
functions such capabilities may be added by the tools but is considered beyond
|
|
the scope of this description language.</p>
|
|
<p><strong>prependToName = </strong>all register names of this peripheral have
|
|
their names prepended with the string specified</p>
|
|
<p><strong>appendToName = </strong>all register names of this peripheral have
|
|
their names appended with the string specified</p>
|
|
<p><strong>size = </strong>defines the default bit-width of registers contained
|
|
in the device. This element can be overruled by re-specifying the size element on a lower level of the
|
|
description.</p>
|
|
<p><strong>access =</strong> defines the default access permissions for all
|
|
registers in the peripheral. The value can be reset on a lower level of the
|
|
description. The allowed tokens are:<br>
|
|
- <em>read-only</em>: read access is permitted. Write operations have an undefined
|
|
result.<br>
|
|
- <em>write-only</em>: write access is permitted. Read operations have an
|
|
undefined result. <br>
|
|
-<em>read-write</em>: both read and write accesses are permitted. Writes affect
|
|
the state of the register and reads return a value related to the register<br>
|
|
-<em>writeOnce</em>: only the first write after reset has an effect on the
|
|
register. Read operations deliver undefined results<br>
|
|
-<em>read-writeOnce</em>: Read operations deliver a result related to the register
|
|
content. Only the first write access to this register after a reset will have an
|
|
effect on the register content.</p>
|
|
<p><strong>resetValue = </strong>defines the default value of all registers
|
|
after a reset but can be set for individual registers and fields on a lower
|
|
level of the description.</p>
|
|
<p><strong>resetMask =</strong> defines those bit positions set to one to be
|
|
taken from resetValue element. All other elements are undefined. This is the
|
|
default value for the whole peripheral but can be readjusted on lower levels. If
|
|
a register does not have a defined reset value the resetMask needs to be set to
|
|
0.</p>
|
|
<p><strong>interrupt = </strong>is a complex type that consists of the <strong>name</strong> of
|
|
the interrupt and the associated enumeration<strong> value</strong>. A peripheral can also have
|
|
multiple associated interrupts. This entry is mainly intended for information
|
|
only purposes in order to display the interrupts and respective interrupt
|
|
numbers associated with a peripheral.</p>
|
|
<h4>Example:</h4>
|
|
<pre>...
|
|
<peripheral>
|
|
<name>Timer0</name>
|
|
<version>1.0.32</version>
|
|
<description>Timer 0 is a simple 16 bit timer counting down ... </description>
|
|
<baseAddress>0x40000000</baseAddress>
|
|
<addressBlock>
|
|
<offset>0x0</offset>
|
|
<size>0x400</size>
|
|
<usage>registers</usage>
|
|
</addressBlock>
|
|
<interrupt><name>TIM0_INT</name><value>34</value></interrupt>
|
|
<registers>
|
|
...
|
|
</registers>
|
|
</peripheral>
|
|
<peripheral derivedFrom="Timer0">
|
|
<name>Timer1</name>
|
|
<baseAddress>0x40000400</baseAddress>
|
|
</peripheral>
|
|
|
|
...</pre>
|
|
<hr>
|
|
<h4><registers> ... </registers></h4>
|
|
<p>This construct sets the frame for all registers contained in a peripheral.
|
|
This creates container elements which ease-up processing with languages like Java.</p>
|
|
<hr>
|
|
<h4><register <span class="style2">derivedFrom=<em>xs:Name</em></span>></h4>
|
|
<p> <span class="style4"><dim><em>scaledNonNegativeInteger</em></dim><br>
|
|
<dimIncrement><em>scaledNonNegativeInteger</em></dimIncrement><br>
|
|
<dimIndex><em>xs:string</em></dimIndex></span><br>
|
|
<<span class="style2">name><em>xs:Name</em></name><br>
|
|
<span class="style4"><displayName><em>xs:string</em></displayName></span><br>
|
|
</span> <span class="style2"><description><em>xs:string</em></description></span><br>
|
|
<span class="style2"> <span class="style4"><alternateGroup><em>xs:Name</em></alternateGroup></span><br>
|
|
</span> <span class="style2"> <addressOffset><em>scaledNonNegativeInteger</em>
|
|
</addressOffset><br>
|
|
<span class="style5"> <size><em>scaledNonNegativeInteger</em></size><br>
|
|
</span><span class="style4"> </span><span class="style5"> <access><em>accessType</em></access><br>
|
|
</span><span class="style4"><</span><span class="style5">resetValue><em>scaledNonNegativeInteger</em></resetValue><br>
|
|
<resetMask><em>scaledNonNegativeInteger</em></resetMask><br>
|
|
</span>
|
|
</span><span class="style4"> <modifiedWriteValues><em>writeValueType</em></modifiedWriteValues><br>
|
|
<writeConstraint><em>writeConstraintType</em></writeConstraint><br>
|
|
<readAction><em>readActionType</em> </readAction></span><span class="style2"><br>
|
|
</span> <span class="style4"><fields><br>
|
|
...<br>
|
|
</fields></span> </p>
|
|
<h4></register></h4>
|
|
<p>The definition of registers is the central part of the description. A
|
|
register may use its complete size for a single purpose and therefore not
|
|
consist of fields. Otherwise the description
|
|
of fields is mandatory.</p>
|
|
<h4>Mandatory items:<br>
|
|
</h4>
|
|
<p><strong>name = </strong>name string used to identify the register. Register
|
|
names are required to be unique within the scope of a peripheral.</p>
|
|
<p><strong>description = </strong>string describing the details of the register.</p>
|
|
<p><strong>addressOffset = </strong>value defining the address of the register relative to
|
|
the baseAddress defined by the peripheral the register belongs to.<br>
|
|
</p>
|
|
<p><span class="style5">The following elements can be omitted</span> if the corresponding value has been set
|
|
on a higher level of the description and matches the value required for this register:</p>
|
|
<p><strong>size =</strong>value defining the bit-width of the register</p>
|
|
<p><strong>access =</strong> predefined tokens: read-only, write-only, read-write,
|
|
writeOnce, read-writeOnce strings defining the allowed
|
|
accesses for this register.</p>
|
|
<p><strong>resetValue =</strong> element defining the value of the register
|
|
immediately after a reset.</p>
|
|
<p><strong>resetMask= </strong>element specifying those bits of the resetValue that
|
|
are defined<strong> </strong>(bit positions containing a 0 bit are ignored, bit
|
|
positions containing a 1 bit are taken from the corresponding bit position of
|
|
the resetValue). If a register does not have a defined reset value the resetMask
|
|
needs to be set to 0.</p>
|
|
<h4>Optional items:</h4>
|
|
<p><strong>dim = </strong>if this field is specified the value defines the
|
|
number of elements in an array of registers.</p>
|
|
<p><strong>dimIncrement =</strong> if dim is specified this element becomes
|
|
mandatory and specifies the address increment in between
|
|
two neighboring registers of the register array in the address map.</p>
|
|
<p><strong>dimIndex = </strong>this element specifies the substrings within the
|
|
register array names that will replace the %s within the register name. By
|
|
default the index is a decimal value starting with 0 for the first register.
|
|
Examples:<br>
|
|
<dim>6</dim> <dimIncrement>4</dimIncrement> <dimIndex>A,B,C,D,E,Z</dimIndex>
|
|
<name>GPIO_%s_CTRL</name> ...<br>
|
|
=> GPIO_A_CTRL, GPIO_B_CTRL, GPIO_C_CTRL, GPIO_D_CTRL, GPIO_E_CTRL,
|
|
GPIO_Z_CTRL<br>
|
|
<dim>4</dim> <dimIncrement>4</dimIncrement> <dimIndex>3-6</dimIndex>
|
|
<name>IRQ%s</name> ... <br>
|
|
=> IRQ3, IRQ4, IRQ5, IRQ6 </p>
|
|
<p><strong>displayName = </strong>when used, this is the string being used by a
|
|
graphical frontend to visualize the register otherwise the name element is used.
|
|
Note: the display name may contain special characters and white spaces. It also
|
|
uses "%s" as the place holder for the dimIndex substring.</p>
|
|
<p><strong>alternateGroup =</strong> when used, this element specifies a name of
|
|
a group that all alternate register with the same name a associated with. At the
|
|
same time it indicates that there is a register description allocating the same
|
|
absolute address in the address space. </p>
|
|
<p><strong>modifiedWriteValues = </strong>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 are bitwise operations: <br>
|
|
<em>oneToClear:</em> write data bits of one shall clear (set to zero) the
|
|
corresponding bit in the register<br>
|
|
<em>oneToSet:</em> write data bits of one shall set (set to one) the
|
|
corresponding bit in the register<br>
|
|
<em>oneToToggle:</em> write data bits of one shall toggle (invert) the
|
|
corresponding bit in the register<br>
|
|
<em>zeroToClear:</em> write data bits of zero shall clear (set to zero)
|
|
the corresponding bit in the register<br>
|
|
<em>zeroToSet:</em> write data bits of zero shall set (set to one) the
|
|
corresponding bit in the register<br>
|
|
<em>zeroToToggle:</em> write data bits of zero shall toggle (invert) the
|
|
corresponding bit in the register<br>
|
|
<em>clear:</em> after a write operation all bits in the field are cleared (set to
|
|
zero)<br>
|
|
<em>set:</em> after a write operation all bits in the field are set (set to one)<br>
|
|
<em>modify:</em> after a write operation all bit in the field may be modified
|
|
(default)</p>
|
|
<p><strong>writeConstraint: </strong>has a set of options:<br>
|
|
<em>writeAsRead</em> = if true only the last read value can be written<br>
|
|
<em>useEnumeratedValues</em> = if true only those values listed in the
|
|
enumeratedValues list are considered valid write values<br>
|
|
<em>minimum</em> = specifies the smallest number to be written to the
|
|
register<br>
|
|
<em>maximum</em> = specifies the largest number to be written to the
|
|
register</p>
|
|
<p><strong>readAction: </strong>if set it specifies the side effect following
|
|
read operations. If not set the register is not modified following a read
|
|
operations. The defined side effects are:<br>
|
|
<em>clear:</em> indicates that the register is cleared (set to zero)
|
|
following a read operation<br>
|
|
<em>set:</em> indicates that the register is set (set to ones) following a
|
|
read operation<br>
|
|
<em>modify</em>: indicates that the register is modified in some way
|
|
after a read operation<br>
|
|
<em>modifyExternal: </em>indicates that one or more dependent resources
|
|
other than the current register
|
|
are immediately affected by a read (it is recommended that the register
|
|
description specifies these dependencies). Debuggers are not expected to read
|
|
this register location unless explicitly instructed by user.</p>
|
|
<p><strong>fields = </strong>next lower level of description (see next section
|
|
for details).</p>
|
|
<h4>Optional attribute:</h4>
|
|
<p><strong>derivedFrom = </strong>specifies the name of the register to be
|
|
replicated. Elements being specified underneath will override the values specified
|
|
from the register being derived from. Note that it is mandatory to overwrite at
|
|
least name and addressOffset.</p>
|
|
<h4>Example:</h4>
|
|
<pre>...
|
|
<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>
|
|
<fields>
|
|
...
|
|
</fields>
|
|
</register>
|
|
<register derivedFrom="TimerCtrl0">
|
|
<name>TimerCtrl1</name>
|
|
<addressOffset>0x4<addressOffset>
|
|
</register>
|
|
...</pre>
|
|
<hr>
|
|
<h4><fields> ... </fields></h4>
|
|
<p>This construct sets the frame for all fields contained in a register.
|
|
This creates container elements which ease-up processing with languages like Java.</p>
|
|
<hr>
|
|
<h4> <field <span class="style2">derivedFrom=<em>"xs:Name</em>"</span>></h4>
|
|
<p> <span class="style2"> <name><em>xs:Name</name><br>
|
|
</em></span> <description><em>xs:string</em></description><br>
|
|
<span class="style5"> </span><span class="style2"><span class="style5"><em> </em>
|
|
</span><<span class="style5">bitOffset><em>scaledNonNegativeInteger</</em>bitOffset>
|
|
</span><<span class="style5">bitWidth><em>scaledNonNegativeInteger</em></bitWidth><br>
|
|
</span><span class="style6">or</span><span class="style5"><br>
|
|
<lsb>scaledNonNegativeInteger</lsb> <msb>scaledNonNegativeInteger</msb><br>
|
|
</span><span class="style6">or</span><span class="style5"><br>
|
|
<bitRange><em>pattern</em></bitRange><br>
|
|
<access><em>accessType</em></access><br>
|
|
</span></span><span class="style4"> <modifiedWriteValues><em>writeValueType</em></modifiedWriteValues><br>
|
|
<writeConstraint><em>writeConstraintType</em></writeConstraint><br>
|
|
<readAction><em>readActionType</em> </readAction></span><span class="style2"><br>
|
|
</span> <span class="style4"><enumeratedValues><br>
|
|
...<br>
|
|
</enumeratedValues></span></p>
|
|
<h4></field></h4>
|
|
<p>A bit-field has a name that is unique for the register it belongs to. The
|
|
position and size within the register is either described by the combination of
|
|
the least significant bit's position (lsb) and the most significant bit's
|
|
position (msb) or the lsb and the size, specifying the bit-width of the
|
|
field. A field may define an enumeratedValue in order to make the display
|
|
more intuitive to read. </p>
|
|
<h4>Mandatory items:</h4>
|
|
<p><strong>name = </strong>name string used to identify the field. Field names
|
|
are required to be unique within the scope of a register.<br>
|
|
</p>
|
|
<p><strong>description = </strong>string describing the details of the register.<br>
|
|
</p>
|
|
<p>There are 3 ways to describe a field to be used mutually exclusive:<br>
|
|
a) specifying bitOffset and bitWidth (IP-XACT like)<br>
|
|
b) specifying lsb and msb of the field.<br>
|
|
c) specifying a bit range in the format "[<msb>:<lsb>]"</p>
|
|
<p><strong>bitOffset = </strong>value defining the position of the least significant bit
|
|
of the field within the register it belongs to.<br>
|
|
<strong>bitWidth = </strong>value defining the bit-width of the bitfield within the
|
|
register it belongs to.<br>
|
|
</p>
|
|
<p>
|
|
<strong>lsb =</strong> value defining the bit position of the least significant
|
|
bit within the register it belongs to.<br>
|
|
<strong>msb =</strong> value defining the bit position of the most significant
|
|
bit within the register it belongs to.
|
|
</p>
|
|
<p><strong>bitRange = </strong>a string in the format: [<msb>:<lsb>]<br>
|
|
</p>
|
|
<h4>Optional items:</h4>
|
|
<p><strong>derivedFrom = </strong>the field is cloned
|
|
from a previously defined field with a unique name.</p>
|
|
<p><strong>access =</strong> predefined strings defining the allowed
|
|
accesses for this register: <em>read-only, write-only, read-write, writeOnce,
|
|
read-writeOnce</em><strong>.</strong> Can be omitted if it matches the access permission set for the parent register.</p>
|
|
<p><strong>enumeratedValues = </strong>next lower level of description (see next section
|
|
for details)</p>
|
|
<p><strong>modifiedWriteValues = </strong>element to 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: <br>
|
|
<em>oneToClear:</em> write data bit of one shall clear (set to zero) the
|
|
corresponding bit in the field<br>
|
|
<em>oneToSet:</em> write data bit of one shall set (set to one) the corresponding
|
|
bit in the field<br>
|
|
<em>oneToToggle:</em> write data bit of one shall toggle (invert) the
|
|
corresponding bit in the field<br>
|
|
<em>zeroToClear:</em> write data bit of zero shall clear (set to zero) the
|
|
corresponding bit in the field<br>
|
|
<em>zeroToSet:</em> write data bit of zero shall set (set to one) the
|
|
corresponding bit in the field<br>
|
|
<em>zeroToToggle:</em> write data bit of zero shall toggle (invert) the
|
|
corresponding bit in the field<br>
|
|
<em>clear:</em> after a write operation all bits in the field are cleared (set to
|
|
zero)<br>
|
|
<em>set:</em> after a write operation all bits in the field are set (set to one)<br>
|
|
<em>modify:</em> after a write operation all bit in the field may be modified
|
|
(default)</p>
|
|
<p><strong>writeConstraint: </strong>has a set of options:<br>
|
|
<em>writeAsRead</em> = if true only the last read value can be written<br>
|
|
<em>useEnumeratedValues</em> = if true only those values listed in the
|
|
enumeratedValues list are considered valid write values<br>
|
|
<em>minimum</em> = specifies the smallest number to be written to the field<br>
|
|
<em>maximum</em> = specifies the largest number to be written to the field</p>
|
|
<p><strong>readAction: </strong>if set it specifies the side effect following
|
|
read operations. If not set the field is not modified following a read
|
|
operations. The defined side effects are:<br>
|
|
<em>clear:</em> indicates that the field is cleared (set to zero)
|
|
following a read operation<br>
|
|
<em>set:</em> indicates that the field is set (set to ones) following a
|
|
read operation<br>
|
|
<em>modify</em>: indicates that the field is modified in some way after a
|
|
read operation
|
|
<br>
|
|
<em>modifyExternal: </em>indicates that one or more dependent resources
|
|
other than this field are immediately affected by a read (it is recommended that
|
|
the field description specifies these dependencies). Debuggers are not expected
|
|
to read the field unless explicitly instructed by user.</p>
|
|
<h4>Example:</h4>
|
|
<pre>...
|
|
<field>
|
|
<name>TimerCtrl0_IntSel</name>
|
|
<description>Select interrupt line t<span class="style8">hat is triggered by timer overflow</span>.</description>
|
|
<bitOffset>1</bitOffset>
|
|
<bitWidth>3</bitWidth>
|
|
<access>read-write</access>
|
|
<resetValue>0x0</resetValue>
|
|
<modifiedWriteValues>oneToSet</modifiedWriteValues>
|
|
<writeConstraint>
|
|
<range>
|
|
<minimum>0</minimum>
|
|
<maximum>5</maximum>
|
|
</range>
|
|
</writeConstraint>
|
|
<readAction>clear</readAction>
|
|
|
|
<enumeratedValues>
|
|
...
|
|
</enumeratedValues>
|
|
</field>
|
|
...</pre>
|
|
<hr>
|
|
<h4 class="style3"><enumeratedValues <span class="style2">
|
|
<span class="style4">derivedFrom=</span><em>"<span class="style4">xs:Name"</span></em></span>></h4>
|
|
<p> <span class="style2"><span class="style4"> <name><em>xs:Name</em></name</span></span>><span class="style4"><br>
|
|
<usage><em>usageType</em></usage></span><br>
|
|
<enumeratedValue><br>
|
|
...<br>
|
|
</enumeratedValue></p>
|
|
<p> ... </p>
|
|
<p> <enumeratedValue><br>
|
|
...<br>
|
|
</enumeratedValue></p>
|
|
<h4></enumeratedValues></h4>
|
|
<p>An enumerated value provides one or more enumeration items (enumeratedValue), defining a map
|
|
between all possible values of the bit-field it belongs to and the corresponding
|
|
human readable semantics of that value.</p>
|
|
<p>Mandatory items:<br>
|
|
<strong>enumeratedValue = </strong>next lower level of description (see next section
|
|
for details)</p>
|
|
<p>Optional items:<br>
|
|
<strong>derivedFrom = </strong>the enumeratedValues can be copied or derived
|
|
from a previously defined enumeratedValue that has been given a unique name.<br>
|
|
<strong>name =</strong> name string to identify an enumeratedValue. Named
|
|
enumeratedValues need to be unique in the scope of a device in order to be reusable
|
|
throughout the description of a device.<br>
|
|
<strong>usage = </strong>possible values are <strong>read, write </strong>or
|
|
<strong>read-write.</strong> This allows to specify two different enumerated values
|
|
depending whether it is to be used for a read or a write access. If not specified the enueratedValues are valid for read and write.</p>
|
|
<h4>Example:</h4>
|
|
<pre>...
|
|
<enumeratedValues>
|
|
<name>TimerIntSelect</name>
|
|
<usage>read-write</usage>
|
|
<enumeratedValue>
|
|
<name>disabled</name>
|
|
<description>disabled bit</description>
|
|
<value>0</value>
|
|
</enumeratedValue>
|
|
...
|
|
<enumeratedValue>
|
|
<name>reserved</name>
|
|
<description>reserved values. Do not use</description>
|
|
<isDefault>true</isDefault>
|
|
</enumeratedValue>
|
|
</enumeratedValues>
|
|
...</pre>
|
|
<hr>
|
|
<h4><enumeratedValue></h4>
|
|
<p> <name<em>>xs:name</em></name><br>
|
|
<span class="style10"><span class="style4"><description>xs:<em>string</em></description></span><br>
|
|
</span><em> <</em>value<span class="style2">><em>scaledNonNegativeInteger</em></value><em><br>
|
|
|
|
</em>or<em><br>
|
|
<</em>isDefault><em>xs:boolean</em></isDefault><em><br>
|
|
</em></span></p>
|
|
<h4></enumeratedValue></h4>
|
|
<p>An enumeratedValue defines a map between a value and the string reading the
|
|
corresponding human readable semantics for that value in a brief and a detailed
|
|
version</p>
|
|
<h4>Mandatory items:</h4>
|
|
<p><strong>name=</strong> brief string verbally describing the semantics of the value
|
|
defined for this enumeratedValue. E.g. used for display in visualization of a bit-field
|
|
instead of the value.</p>
|
|
<p>
|
|
<strong>value = </strong>defines the constant of the bit-field that the name
|
|
corresponds to<strong>.</strong></p>
|
|
<p><strong>isDefault = </strong>defines the name and description for all other
|
|
values that are not explicitly listed</p>
|
|
<h4>Optional item:</h4>
|
|
<p><strong>description = </strong>extended string verbally describing the semantics
|
|
of the value defined for this enumeratedValue in full detail.</p>
|
|
<h4>Example:</h4>
|
|
<pre>...
|
|
<enumeratedValue>
|
|
<name>disabled</name>
|
|
<description>Timer does not generate interrupts</description>
|
|
<value>0</value>
|
|
</enumeratedValue>
|
|
...
|
|
<enumeratedValue>
|
|
<name>enabled</name>
|
|
<description>Timer does not generate interrupts</description>
|
|
<isDefault>true</isDefault>
|
|
</enumeratedValue>
|
|
|
|
...</pre>
|
|
<hr>
|
|
<h4>Names</h4>
|
|
<p>Names shall comply with ANSI C variable naming restrictions.</p>
|
|
<h4>Constants</h4>
|
|
<p>Number constants shall be entered in hexadecimal, decimal or binary format.</p>
|
|
<ul>
|
|
<li>hexadecimal is indicated by a leading "0x"</li>
|
|
<li>binary format is indicated by a leading "#"</li>
|
|
<li>all other formats are interpreted as decimal numbers</li>
|
|
<li>the value tag in enumeratedValue accepts do not care bits
|
|
represented by "x"</li>
|
|
</ul>
|
|
<h4><b>Comments</b> </h4>
|
|
<p>Comments have the standard XML format <strong>"<!--"</strong> starts a comment
|
|
<strong><span class="style2">"-->"</span></strong> terminates a comment</p>
|
|
<h2>Example</h2>
|
|
<pre>
|
|
<?xml version="1.0" encoding="utf-8"?>
|
|
|
|
<device schemaVersion="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="CMSIS-SVD_Schema_1_0.xsd" >
|
|
<name>Cortex_M3_Sample</name>
|
|
<version>0.1</version>
|
|
<description>ARM Cortex-M3 based Microcontroller dummy device</description>
|
|
<!-- Bus Interface Properties -->
|
|
<!-- Cortex-M3 is byte addressable -->
|
|
<addressUnitBits>8</addressUnitBits>
|
|
<!-- the maximum data bit width accessible within a single transfer is 32bits -->
|
|
<width>32</width>
|
|
|
|
<!-- Register Default Properties -->
|
|
<!-- the size of the registers is set to a bit width of 32. This can be overruled for individual peripherals and/or registers -->
|
|
<size>32</size>
|
|
<!-- the access to all registers is set to be readable and writeable. This can be overruled for individual peripherals and/or registers -->
|
|
<access>read-write</access>
|
|
<!-- for demonstration purposes the resetValue for all registers of the device is set to be 0. This can be overruled within the description -->
|
|
<resetValue>0</resetValue>
|
|
<!-- the resetMask = 0 specifies that by default no register of this device has a defined reset value -->
|
|
<resetMask>0</resetMask>
|
|
|
|
<peripherals>
|
|
<peripheral>
|
|
<name>Timer0</name>
|
|
<description>A simple 16 bit timer counting down ... </description>
|
|
<groupName>Timer</groupName>
|
|
<baseAddress>0x40000000</baseAddress>
|
|
<!-- the first addressBlock is occupied by registers. The second block is reserved -> no access permission -->
|
|
<addressBlock>
|
|
<offset>0</offset>
|
|
<size>0x8</size>
|
|
<usage>registers</usage>
|
|
</addressBlock>
|
|
<addressBlock>
|
|
<offset>0x8</offset>
|
|
<size>0x3f8</size>
|
|
<usage>reserved</usage>
|
|
</addressBlock>
|
|
<interrupt>
|
|
<name>TIM0_IRQn</name>
|
|
<value>34</value>
|
|
</interrupt>
|
|
<registers>
|
|
<register>
|
|
<name>TimerCtrl0</name>
|
|
<!-- the display name is an unrestricted string. -->
|
|
<displayName>Timer Ctrl 0</displayName>
|
|
<description>Timer Control Register</description>
|
|
<addressOffset>0x0</addressOffset>
|
|
<!-- size=32, access=read-write, resetValue=0x0, resetMask=0xffffffff, volatile=false -->
|
|
<fields>
|
|
<field>
|
|
<name>TimerCtrl0_En</name>
|
|
<description>Enable Bit activates the timer.</description>
|
|
<!-- Spirit like bit range description: [0:0] -->
|
|
<bitOffset>0</bitOffset>
|
|
<bitWidth>1</bitWidth>
|
|
<!-- Writing 1 enables, writing 0 has no effect -->
|
|
<modifiedWriteValues>oneToSet</modifiedWriteValues>
|
|
<!-- The write constraint is defined to be that only the values provided by the enumeratedValues below are allowed -->
|
|
<writeConstraint>
|
|
<useEnumeratedValues>true</useEnumeratedValues>
|
|
</writeConstraint>
|
|
<!-- there is no side effect on reads, therefore <readAction> is not set -->
|
|
<!-- oneBitEnable named enumeration that can be reused in other parts of the description -->
|
|
<enumeratedValues>
|
|
<name>oneBitEnable</name>
|
|
<!-- the same enumerated Values are used for read and write. This default is assumed when this tag is missing -->
|
|
<usage>read-write</usage>
|
|
<enumeratedValue>
|
|
<name>enabled</name>
|
|
<description>Timer is enabled and active</description>
|
|
<value>0x0</value>
|
|
</enumeratedValue>
|
|
<enumeratedValue>
|
|
<name>disabled</name>
|
|
<description>Timer is disabled and inactive</description>
|
|
<value>0x1</value>
|
|
</enumeratedValue>
|
|
</enumeratedValues>
|
|
</field>
|
|
<field>
|
|
<name>TimerCtrl0_Dis</name>
|
|
<description>Disable Bit deactivates the timer.</description>
|
|
<!-- Spirit like bit range description: [1:1] -->
|
|
<bitOffset>1</bitOffset>
|
|
<bitWidth>1</bitWidth>
|
|
<!-- Writing 1 sets, writing 0 has no effect -->
|
|
<modifiedWriteValues>oneToSet</modifiedWriteValues>
|
|
<!-- The write constraint is defined to be that only the values provided by the enumeratedValues below are allowed -->
|
|
<writeConstraint>
|
|
<useEnumeratedValues>true</useEnumeratedValues>
|
|
</writeConstraint>
|
|
<!-- there is no side effect on reads, therefore <readAction> is not set -->
|
|
<!-- oneBitEnable named enumeration that can be reused in other parts of the description -->
|
|
<enumeratedValues derivedFrom="oneBitEnable"></enumeratedValues>
|
|
</field>
|
|
<field>
|
|
<name>TimerCtrl0_Int</name>
|
|
<description>Select interrupt line that is triggered by timer overflow.</description>
|
|
<!-- the position of the bit field is described in the bitRange style. -->
|
|
<bitRange>[4:2]</bitRange>
|
|
<enumeratedValues>
|
|
<enumeratedValue>
|
|
<name>disabled</name>
|
|
<description>Timer does not generate interrupts</description>
|
|
<value>0</value>
|
|
</enumeratedValue>
|
|
<enumeratedValue>
|
|
<name>int 0</name>
|
|
<description>Timer does generate interrupts on interrupt line 0</description>
|
|
<value>1</value>
|
|
</enumeratedValue>
|
|
<enumeratedValue>
|
|
<name>int 1</name>
|
|
<description>Timer does generate interrupts on interrupt line 1</description>
|
|
<value>2</value>
|
|
</enumeratedValue>
|
|
<enumeratedValue>
|
|
<name>int 2</name>
|
|
<description>Timer does generate interrupts on interrupt line 2</description>
|
|
<value>3</value>
|
|
</enumeratedValue>
|
|
<enumeratedValue>
|
|
<name>int 3</name>
|
|
<description>Timer does generate interrupts on interrupt line 3</description>
|
|
<value>4</value>
|
|
</enumeratedValue>
|
|
<enumeratedValue>
|
|
<name>int 4</name>
|
|
<description>Timer does generate interrupts on interrupt line 4</description>
|
|
<value>5</value>
|
|
</enumeratedValue>
|
|
<!-- this is the default element. All the valid value not listed above (6,7) have the following name and description -->
|
|
<enumeratedValue>
|
|
<name>reserved</name>
|
|
<description>Timer is configured incorrectly and the functionality is considered unpredictable</description>
|
|
<isDefault>true</isDefault>
|
|
</enumeratedValue>
|
|
</enumeratedValues>
|
|
</field>
|
|
</fields>
|
|
</register>
|
|
<register>
|
|
<name>TimerCounter0</name>
|
|
<description>Timer0 16 Bit Counter Register</description>
|
|
<addressOffset>0x4</addressOffset>
|
|
<size>16</size>
|
|
</register>
|
|
<!-- a copy of the counter register TimerCounter0 with the name="TimerCounter1" and the addressOffset="0x8" -->
|
|
<register derivedFrom="TimerCounter0">
|
|
<name>TimerCounter1</name>
|
|
<addressOffset>0x6</addressOffset>
|
|
</register>
|
|
<!-- ... this is a restricted demo example and a real timer peripheral would have more register to be complete -->
|
|
</registers>
|
|
</peripheral>
|
|
<!-- a copy of Timer0 with the name="Timer1 and the baseAddress="0x40000400" -->
|
|
<peripheral derivedFrom="Timer0">
|
|
<name>Timer1</name>
|
|
<baseAddress>0x40000400</baseAddress>
|
|
<interrupt>
|
|
<name>TIM1_IRQn</name>
|
|
<value>35</value>
|
|
</interrupt>
|
|
</peripheral>
|
|
</peripherals>
|
|
</device></pre>
|
|
|
|
<h2><a name="6"></a>Questions & Answers</h2>
|
|
<h3>Is there any relation between the System View Description and the CMSIS
|
|
standard?</h3>
|
|
<p>Initiallly there was no immediate link but both initiatives had a common goal:
|
|
Create a sound software development eco-system for Cortex-M based
|
|
Microcontroller, giving the customers the free choice of devices and software
|
|
development environments and all resources required for a successful product
|
|
development in a single location. Meanwhile we have started to generate
|
|
CMSIS compliant device header files from the same CMSIS-SVD description. We will
|
|
introduce a small number of additional description tags in the next version of
|
|
the specification. The benefit is the synchronization between symbols used in
|
|
the application and the symbols displayed by the debugger. </p>
|
|
<h3>Why does the format not provide constructs like macros and
|
|
conditional statements?</h3>
|
|
<p>It is assumed that the description is generated from other sources and
|
|
therefore such concepts would only complicate the language unnecessarily. It is
|
|
recommended to use a standard C pre-processor to generate the debug description
|
|
format from a redundancy optimized description.</p>
|
|
<h3>Do we need to consider endianess in the description?</h3>
|
|
<p>This should be specified on a device configuration level and is not specific
|
|
to the visualization of peripheral details in a System View. Endianess becomes
|
|
relevant when using bit fields in the CMSIS compliant device header file.</p>
|
|
<h3>Is the System View Description limited to Cortex-M based devices ?</h3>
|
|
|
|
|
|
<p>There may have been assumptions made about the structure of the device due to
|
|
it being developed around a Cortex-M processor. E.g. that all peripherals are
|
|
assumed to be memory mapped and to reside in a single address space. It is quite
|
|
likely that the description format may also serve other architectures
|
|
sufficiently. There is no intent to limit the format to Cortex-M
|
|
processor based devices. </p>
|
|
|
|
|
|
</body></html> |