ARM Technical Support Knowledge Articles

How should I set the Peripheral ID register values in my CoreSight ROM Table?

Applies to: Generic CoreSight Components

Answer

You can find descriptions of these fields in the CoreSight v1.0 Architecture Specification and the ARM Debug Interface v5 Architecture Specification (ADIv5).

In most CoreSight components (ETM, ITM, TPIU, etc.), these fields identify the designer of the component and the specific component type and version number.

However, ROM Tables use these fields slightly differently; for a ROM Table which is pointed to by the Debug Base Address or Debug ROM Address register of an Access Port (ie. a top level ROM Table), the Peripheral ID registers should be configured to provide a unique identification of the chip (or more specifically, a unique identification of the subsystem controlled from that Access Port).

JEP106 Identity Code and Continuation Code represent your company's entry in the JEP106 JEDEC Standard Manufacturer’s Identification Code list. JEDEC registration currently (in 2011) costs US$200: http://www.jedec.org/standards-documents/id-codes-order-form

The Identity Code field is bits [6:0] of the JEP106 code, and the Continuation Code is the number of 0x7F continuation codes prefixing your Id. For example, ARM is number 59 in bank 5, so therefore has Identity Code of 0x3B and Continuation Code of 0x4.

Once you have your own JEP106 Code, the Part Number is then your own numbering space for your company to allocate as you desire. You may, for example, simply number your designs in incrementing Part Numbers, or you may choose to allocate blocks of Part Numbers for different classes of chip or different departments or divisions.

To be specific, the Part Number identifies the debug subsystem behind an individual Access Port in the DAP, and the identity of the chip is considered to be the combined identities of all such top level ROM Tables (ie. debug subsystems) present on the chip.

The revision field should normally be used to indicate different revisions of the same chip or subsystem design.

The RevAnd field is intended to be implemented in a way which can easily be updated to indicate a late ECO revision of the mask set, so it is helpful if this is implemented in some way which can be updated through a minimal mask edit (eg via-only).

The Customer Modified field is reserved for authorized variations of a standard CoreSight component, and is generally a redundant field in a ROM Table. Although it could potentially be used to extend the part numbering space, debug tools may not expect this usage and may therefore not distinguish between parts whose numbers differ only in this field.

The 4kB count of a ROM Table must always be 4'b0000.

Rate this article

[Bad]
|
|
[Good]
Disagree? Move your mouse over the bar and click

Did you find this article helpful? Yes No

How can we improve this article?

Link to this article
Copyright © 2011 ARM Limited. All rights reserved. External (Open), Non-Confidential