Release candidate enhancements Compiled by Seth Park, May 2009 While piloting the sidsc-component specialization, Freescale Semiconductor identified two critical business requirements that are not supported by the data model. These business requirements are: Must support multiple instantiations of identical registers and enable unique name requirements for register names. This should allow identical registers to be presented as a comprehensive enumeration or a generalized section with redundant data “collapsed”. Must support multiple instantiations of identical components and enable unique name requirements for components and register names This document details the required functionality and a complete description of the changes that must be made to support this proposal. Freescale has implemented these changes for testing and is confident it will support the business requirements of the OASIS member companies and the adopters of the SIDSC deliverable, upon ratification.

Use cases for multiple instances of registers and components This document shows how to encode sidsc-component data to handle the three primary use cases: 1.Multiple instances of registers (must have a pattern) 2.Multiple instances of components (each instance must have identical registers) 3.Multiple instances of registers within components that occur more than once About the example content The example information comes from an externally published reference manual. There are two instances of the same TPM module. The TPM must be documented as a general chapter while making it clear that more than one TPM is available. Each register name must be unique, so in the register summary, register names must appear according to the following pattern: TPM1SC, TPM2SC. When discussed generally (as in the register section heading), the name must be “TPMnSC” Within each TPM instance, there are a range of registers that repeat. Notice in the following image that the TPM1C0VH repeats 3 registers later and receives a unique name of TPM1C1VH. The challenge is to provide a sufficient data model to allow processing to build component names based on instance parameters AND allow register names to be further qualified when they repeat. In the following image, the “TPM1” comes from the component instance parameters. The “C0VH” and “C1VH” come from the register dimension data.

1 2 1.Notice the generic form, “TPMxSC” 2.The address information and unique name for specific instances should go here.

1. Support for multiple instances of registers Vocabulary requirements * add to inform processing how to qualify register names to make them unique * add to inform processing how to implement the About and We understand that qualifiers will not be conceived or applied consistently or by any specific pattern. For instance, you might have UARTA and UARTB. In some cases, the qualifier might not be a logical "adder"; for instance: RAM_INT and RAM_EXT. For this usecase, is designed to accept a comma-delimited list of the strings that are to be added to the component name. Use to explain how the is implemented. NOTE: These two elements are used by sidsc-component.mod and sidsc-register.mod; therefore, the elements are maintained in the sidscDomain.mod file, which is integrated into sidsc-component.dtd and sidsc-register.dtd (for cases where registers are created outside the context of the componet. (see the example on next page)

For example (RAM register): 2 1 _INT,_EXT end This syntax says, "There are two instances of this register. The first one is at the address determined by, and its name is formulated by adding "_INT" to the "end" of the registerName (RAM_INT). The second instance is at the very next register space and has the name "RAM_EXT". The value of namePattern can "start", "end" or an integer. If an integer is supplied, it means the number of characters from the left to insert the unitQualifier. For example (TIMSC register) 2 1 1,2 3 This syntax says, "To build the unique names, I parse the value, count three characters to the right and insert the at that location. The results would be "TIM1SC" and "TIM2SC"

Publishing ramifications. If you build a register summary, you may enumerate all register instances. Or you may wish to "collapse" blocks of identical registers and provide an address range. If you build a register section, you may describe the register (as if it existed only once) and provide specific instance details (such as address) within the same information block. Using the, you can insert a "variable" character within the register name. For example, to describe UARTA and UARTB generically, you can build the name as "UARTn" in processing. You can then render the addresses of each instance using the as the first and the calculated address of subsequent instances by using. When you provide the address information for each instance, you can enumerate the instance names so that your reader knows the precise register name.

2. Support for multiple instances of components When an identical component exists on a product more than once, we should be able to use the same sidsc-component file. The existing data model for is not sufficient to support this business requirement. Vocabulary requirements *add to define the placement and name qualification of instances *add to define the number of instances *add to specify the offset address of each instance *add and (described in the enhancement #1) About This element contains a comma-delimited list of values that designate where the subsequent instances of the block are located, relative to the of the component. (see example on next page)

Here is an example (SCI component): 2 0,A0 1,2 3 The means, "The SCI component exists two times. The first time is my unitAddress plus the first value of instanceOffsets (n + 0). To build the name of the first component name, I will use the componentName, count three characters, and insert the first value in the nameQualifier.... which gives me "SCI1". NOTE: the first value of will always be zero, right? Should we require that users supply the 0? Or should the number of values in always be equal to the value of minus one?

Each register must appear in the register summary with the proper component instance name prefix and unique register names for repeated registers

Inheritance model changes: componentInstanceVariables from: topic/dl reference/dl sidsc-component/componentInstanceVariables to: topic/simpletable dataTableDomain/dataTable/componentInstanceVariables componentData from: topic/dlentry reference/dlentry sidsc-component/componentData to: topic/strow dataTableDomain/dataRow sidsc-component/componentData componentDataKey from: topic/dt reference/dt sidsc-component/componentDataKey to: topic/stentry dataTableDomain/dataEntry sidsc-component/componentDataKey componentDataValue from: topic/dd reference/dd sidsc-component/componentDataValue to: topic/stentry dataTableDomain/dataEntry sidsc-component/componentDataValue Structural changes: componentData from: ((componentDataKey, componentDataValue)) to: (((componentDataKey, componentDataValue)| instanceParameters)*) dimension from: ((dimensionValue, dimensionIncrement)) to: ((dimensionValue, dimensionIncrement, unitQualifier?, namePattern?))