You copied the Doc URL to your clipboard.

PeripheralID values for the CoreSight ROM Table

Article ID: 103489663

Published date: 24 Jul 2017

Last updated: -

Applies to: Debug Access Port (DAP)

Question

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

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, and so on), 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 that is pointed to by the Debug Base Address or Debug ROM Address register of an Access Port (that is, 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).

The 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 2017) costs US$500:

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 has Identity Code of 0x3B and Continuation Code of 0x4.

After 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 (that is, debug subsystems) present on the chip.

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

The RevAnd field is intended to be implemented in a way that can be updated easily to indicate a late ECO revision of the mask set, so it is helpful if this is implemented in some way that can be updated through a minimal mask edit (for example, 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 might not expect this use and therefore might not distinguish between parts whose numbers differ only in this field.

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

Related information

None.

Was this page helpful? Yes No