You copied the Doc URL to your clipboard.

Tarmac trace of AMBA 5 AHB bus accesses from Cortex-M23 and Cortex-M33

Article ID: 128787321

Published date: 06 Mar 2018

Last updated: -

Applies to: Cortex-M23, Cortex-M33, AHB

Problem/Question

How can I see details of the AMBA 5 AHB bus accesses from the Armv8-M Cortex-M23 and Cortex-M33 processors?

Scenario

Tarmac is an execution history log file optionally generated from RTL level logic simulation of Arm processors. The name is an acronym that was created and derived from the phrase, Trace Arm Accesses.

As part of the tarmac log file listing, chip designers using older Cortex-M processors are used to seeing details of the memory accesses that the processor issues, interleaved with:

  • Disassembly of executed instructions.

  • Register value changes.

  • Other events such as exceptions.

From the Cortex-M7 processor onward, Arm moved to a different implementation of tarmac logging, for reasons including standardization and maintainability. The newer version of tarmac format includes most of the information presented in the older tarmac logs. However, the major difference is that the new version of the tarmac format does not provide detailed visibility of the exact memory accesses that the processor issues.

For example, a Cortex-M3 tarmac log, shows individual instruction fetches and data loads and stores as they complete on the AHB-Lite bus. For example, the following segment shows details of the instruction fetch ("__I") of opcode 0x491D, which is an LDR from address [ pc + #116 ], from branch target address 0x0534, and the resulting data memory access ("__D") when this load from address 0x05AC is executed:

     154990 ns MNR4O__I 00000534 7800491d
      154990 ns BNR4O__I 00000534 7800491d
      154990 ns IT (00000548:00001027) 00000548 f7fffff4 T32 BL       {pc} - 0x14  ; 0x534
      155010 ns BNR4O__I 00000538 70086809
      155010 ns MNR4O__I 00000538 70086809
      155030 ns IT (00000534:00001028) 00000534     491d T16 LDR      r1,[pc,#116]  ; [0x5ac]
      155030 ns MNR4O__I 0000053c b5084770
      155030 ns BNR4O__I 0000053c b5084770
      155050 ns R r1 20000004
      155050 ns MNR4___D 000005ac 20000004
      155050 ns BNR4___D 000005ac 20000004

The newer tarmac format does not record instruction fetch activity, and presents data accesses as a summary of the combined effects of single or multiple memory accesses, framed in 128-bit aligned fields. For example, the following tarmact fragment from a Cortex-M33 simulation shows the summary information about an LDM of 4 registers from addresses 0x1048, 0x104C, 0x1050, and 0x1054:

        955 ns  ES  (00000162:e8ba000f) T thrd_s:         LDM      r10!,{r0-r3}                    <__scatterload_null+0xc>
                                        LD 00001050 ........ ........ 0000017c 00000010    S:0000001050    NM NSH
        LD 00001040 20000000 00001068 ........ ........    S:0000001040    NM NSH
        R R0 00001068
        R R1 20000000
        R R2 00000010
        R R3 0000017c
        R R10 00001058

The active bytes included in this transfer are represented as hexadecimal digits aligned into 128-bit segments based at 0x0001040 and 0x0001050, padded with ".." for inactive byte positions, but without detail of which data was transferred in which cycle.

Answer

Unfortunately it is not possible to provide the same level of detail about memory accesses in the new tarmac format as was provided in the older version.

Workaround

Since the bus interface signals are top-level signal ports at the processor boundary, it is relatively easy to add a Verilog module into a simulation environment in order to produce a detailed log of memory accesses. This log then can easily be cross-referenced to the activity listed in the tarmac log.

An example of such a Verilog module, ahb5_logger.v, is attached to this article, together with with instructions on how to use it, in a Unix zipped tarball "ahb5_logger_0.06.tgz". Following these instructions, you can easily incorporate it into the Integration Kit (IK) example MCU design delivered with the processor RTL bundle for Cortex-M23 r1p0 or Cortex-M33 r0p2 and r0p3.

This example implementation of a logging module also supports the Cortex-M33 processor HCLKEN output to suppress AMBA 5 AHB bus tracing when the processor is quiescent, and can log the Cortex-M23 processor CODENSEQ output and the various hint signals of the Cortex-M23 and Cortex-M33 processors (CODEHINT, DATAHINT, HHINTS, HHINTC). These signals provide additional information about causes of various possible sequential or non-sequential bus activity, as described in the processor Integration and Implementation Manual (IIM).

Example

The following truncated AMBA 5 AHB log fragment shows the bus activity generated by the Cortex-M33 processor corresponding to the LDM instruction (opcode 0xE8BA_000F) illustrated in the tarmac log above:

 
    AHB5 Log file:                             ahb_code.log
                     
    time             data phase              address phase                          Sideband hints
                     
                                                                  UD                                   C  NBF HL
                                                         S        S LMBna                              o  oao aiV
                                                         e        b hAoou/t                            d  ncr nte
                                                         c        y alodfP/                            n  |kw dec
                                                  data   u        t rlkifrI                            s Aswa lrt
                                                   or    r        e eoufein                            e ne'r eao
         Resp  hrdata   hwdata        haddr  tran instr  e  r/w s dcpyrvs m-type hburst excl   lock  q yqdd rlr
 ~ ~ ~
905: (D)   OK f2aff841          (A) 00000160 IDLE                                                    . .... ...
915: (D)   OK                   (A) 0000015c NSEQ Instr  S  Read4 sALMbPI WTnS A Incr                . .... ...
925: (D)   OK f2aff841          (A) 00000160 NSEQ Instr  S  Read4 sALMbPI WTnS A Incr                . .... ...
935: (D)   OK e8ba0e09          (A) 00000164 +SEQ Instr  S  Read4 sALMbPI WTnS A Incr                . .... ...
945: (D)   OK f013000f          (A) 00000168 +SEQ Instr  S  Read4 sALMbPI WTnS A Incr                . .... ...
955: (D)   OK bf180f01          (A) 00001048 NSEQ Data   S  Read4 sALMbPD WTnS A Incr                . .... ...
965: (D)   OK 00001068          (A) 0000104c +SEQ Data   S  Read4 sALMbPD WTnS A Incr                . .... ...
975: (D)   OK 20000000          (A) 00001050 +SEQ Data   S  Read4 sALMbPD WTnS A Incr                . .... ...
985: (D)   OK 00000010          (A) 00001054 +SEQ Data   S  Read4 sALMbPD WTnS A Incr                . .... ...
995: (D)   OK 0000017c          (A) 0000016c NSEQ Instr  S  Read4 sALMbPI WTnS A Incr                . .... ...
1005: (D)  OK f0431afb          (A) 00000170 +SEQ Instr  S  Read4 sALMbPI WTnS A Incr                . .... ...
1015: (D)  OK 47180301          (A) 00000000 IDLE                                                    . .... ...

Related Information

N/A

Was this page helpful? Yes No