System View Description
This chapter contains the introduction and specification of the CMSIS System View Description format (CMSIS-SVD). The introduction section outlines the objectives and benefits CMSIS-SVD.
Introduction
CMSIS-SVD formalizes the description of the programmer's view for the system contained in ARM Cortex-M processor-based microcontrollers, in particular the memory mapped registers of the peripherals. The detail contained in system view descriptions is comparable to what is found in device reference manuals published by silicon vendors.
The information ranges from a high level functional description of a peripheral all the way down to the definition and purpose of an individual bit field in a memory mapped register.
CMSIS-SVD files are developed and maintained by the silicon vendors. Silicon vendors manage their descriptions in a central, web-based Device Database and the CMSIS-SVD files are downloadable via a public web interface once they have been released by the silicon vendor. Tool vendors use these descriptions for providing device-specific debug views of peripherals in their debugger. Last but not least CMSIS compliant device header files are generated from CMSIS-SVD files.
CMSIS-SVD Benefits
The benefits for the Software Developer:
Consistency between device header file and what is being displayed by the debugger.
Detailed information about peripherals, registers, fields, and bit values from within the debugger, without the need to reference device documentation.
Public access via a web interface to new and updated descriptions as they become available from silicon vendors.
Improved software development efficiency.
The benefits for the Silicon Vendor:
A tool vendor independent file format enables early device support by a wide range of toolchains with limited effort.
The XML-based format helps ease the integration into in-house design flows.
Automated generation of CMSIS compliant device header files.
Full control throughout the life cycle of the CMSIS-SVD files from creation to maintenance via the web-based Device Database.
The benefits for the Tool Vendor:
Unified file format across silicon vendors helps the efficiency of supporting a wide range of new devices in a timely manner.
Silicon vendors provide early review access to individuals ahead of the publishing date.
Updated descriptions are available over the web simplifying the maintenance of device support.
SVD File Description
The CMSIS-SVD format is based on XML. The specification of the System View Description format was influenced by IP-XACT, a design description format used in, for example, IP stitching and IP reuse. Due to the much wider scope and complexity of IP-XACT it was decided to specify a separate format, which is focused and tailored toward the description of the programmer's view of a device only.
CMSIS-SVD XML Hierarchy
CMSIS-SVD Hierarchy Levels
One CMSIS-SVD file contains the description of a single device. A device consists of a processor and at least one peripheral. Each peripheral contains at least one register. A register may consist of one or more fields. The range of values for a field may be further described with enumerated values.
Device Level: The top level of a System View Description is the device. On this level, information is captured that is specific to the device as a whole. For example, the device name, description, or version. The minimal addressable unit as well as the bit-width of the data bus are required by the debugger to perform the correct target accesses.
Default values for register attributes like register size, reset value, and access permissions can be set for the whole device on this level and are implicitly inherited by the lower levels of the description. If however specified on a lower level, the default setting from a higher level will get overruled.
Peripherals Level: A peripheral is a named collection of registers. A peripheral is mapped to a defined base address within the device's address space. A peripheral allocates one or more exclusive address blocks relative to its base address, such that all described registers fit into the allocated address blocks. Allocated addresses without an associated register description are automatically considered reserved. The peripheral can be assigned to a group of peripherals and may be associated with one or more interrupts.
Registers Level: A register is a named, programmable resource that belongs to a peripheral. Registers are mapped to a defined address in the address space of the device. An address is specified relative to the peripheral base address. The description of a register documents the purpose and function of the resource. A debugger requires information about the permitted access to a resource as well as side effects triggered by read and write accesses respectively.
Fields Level: Registers may be partitioned into chunks of bits of distinct functionality. A chunk is referred to as field. The field names within a single register must be unique. Only architecturally defined fields shall be described. Any bits not being explicitly described are treated as reserved. They are not displayed in the System Viewer and are padded in the bit fields of the device header file. The case-insensitive field named "reserved" is treated as a keyword and each field with this name is ignored.
Enumerated Values Level: An enumeration maps an unsigned integer constant to a descriptive identifier and, optionally, to a description string. Enumerations are used in C to enhance the readability of source code. Similarly, it can be used by debuggers to provide more instructive information to the programmer, avoiding a lookup in the device documentation.
Vendor Extensions: The CMSIS-SVD format includes a section named vendorExtensions positioned after the closing tag peripherals. This allows silicon vendors and tool partners to innovate and expand the description beyond the current specification.
Multiple Instantiation
CMSIS-SVD supports the reuse of whole sections of the description. The attribute derivedFrom for the peripheral-, register-, and field-section specifies the source of the section to be copied from. Individual tags can be used to redefine specific elements within a copied section. In case the name of the description source is not unique, the name needs to be qualified hierarchically until the element composite name becomes unique. Hierarchies are separated by a dot. For example, <peripheral name>.<register name>.<field name>.
Peripheral Grouping
Peripherals that provide similar functionality (Simple Timer, Complex Timer) can be grouped with the element groupName. 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 in the debugger.
Descriptions
On each level, the tag description provides verbose information about the respective element. The description field plays an important part in improving the software development productivity as it gives instant access to information that otherwise would need to be looked up in the device documentation.
.END
No comments:
Post a Comment