2.7.2. STM enabled

The following sections describe the operation when the STM is enabled:

Guaranteed and invariant timing transactions

The STM supports both types of software stimulus transfers, that is, guaranteed and invariant timing. Transaction properties, such as master enable, stimulus port enable, override controls, and guaranteed or invariant timing, are considered for each AXI burst beat.

Behavior on guaranteed transactions

If a guaranteed transaction is made while the STM is unable to accept it immediately, the STM stalls the AXI write data channel until the write can be accepted, inserting as many wait states as necessary by keeping WREADY LOW.

Only use a guaranteed write for critical trace information, because it guarantees a trace packet is generated for that write. The wait states can adversely affect system performance.

Behavior on invariant timing transactions

If an invariant timing transaction is made while the STM is unable to trace it immediately, the STM does not stall the AXI. After the address is transferred, WREADY is driven HIGH enabling the data to be transferred. The write data is discarded if it cannot be traced.

There is no guarantee that an invariant timing write results in a trace packet appearing in the trace stream.

Multiple STPv2 master support

Multiple STPv2 master support is implemented based on the type of AXI access, either secure or non-secure, and upper bits of AXI address.

Software stimulus has 128 master IDs, 0x00-0x7F, allocated. The lower half of the master ID space is allocated for secure accesses and the upper half for non-secure accesses.

The STPv2 master ID from the AXI stimulus port is constructed as:

  • [7] = b0

  • [6] = AWPROTS[1]

  • [5:0] = AWADDRS[29:24].

In the above ID, master IDs 0-63 are allocated to secure transactions and master IDs 64-127 to non-secure transactions.

Timestamp requests

Transactions to the extended stimulus ports can include a timestamp request. You can promote transactions to the extended stimulus ports to include a timestamp request by writing b1 STMTSSTIMR.FORCETS. If transaction already includes timestamp request, FORCETS has no effect.

Timestamping guaranteed writes

Timestamp requests from guaranteed writes are compulsory. This guarantees that a timestamp is included in the packet generated from the write. The AXI slave stalls all further writes if the timestamp request cannot be accommodated.

Timestamping invariant timing writes

Timestamp requests in invariant timing transaction are treated as sticky. A sticky timestamp request means that if timestamp cannot be accommodated on the STM FIFO the request remains pending and timestamp is inserted at the next opportunity. Sticky timestamp requests do not cause the STM to stall.

The pending sticky timestamp state is cleared when timestamp is output regardless of whether new transaction has its own timestamp request or not. This guarantees that a timestamp is eventually inserted into the trace stream because of the transaction. However, the timestamp might be attached to a different packet, and the number of timestamps generated might be fewer than the number requested.

Unaligned transfers

The STM does not support unaligned accesses, they are architecturally unpredictable. The STM ignores the bottom three address bits for data accesses, which ensures writes are always aligned from the STM perspective.

Unaligned data in writes and use of WSTRBS

All write data must be bottom aligned with WDATA[0] as the LSB.

AXI byte strobes, WSTRBS, are used only for narrow incrementing bursts. These are INCR bursts where data size is 8 or 16 bits. The first burst beat must have bottom aligned data.

Table 2.3 shows an example of a 4-beat 8-bit burst .

Table 2.3. Example burst

BeatWSTRBSWDATAS
10001[7:0]
20010[15:8]
30100[23:16]
41000[31:24]

Writes to disabled stimulus ports

The STM responds to writes to disabled stimulus ports in the same way as for invariant timing transactions. However, no error packets are added to the trace, and the request is dropped.

Access control based on AWPROT

On writes, the value of AWPROT[1] is checked against the current authentication status of the STM. If this value corresponds to a secure transaction when secure accesses are disabled, the access is dropped as if the stimulus port were disabled.

See the CoreSight Architecture Specification for more information on secure and non-secure accesses to CoreSight components.

Note

The STM ignores the value of AWPROT[2] and AWPROT[0].

Table 2.4 shows the authentication control with non-secure access for AWPROT[1].

Table 2.4. Authentication control with non-secure access

AWPROT[1]Permitted level of debugAction on write
Secure invasiveNon-secure invasiveSecure non-invasiveNon-secure non-invasive
1, non-secure---1Capture
1---0Drop
0, secure--1-Capture
0--0-Drop

See the CoreSight Architecture Specification for the mapping of the authentication signals, DBGEN, NIDEN, SPIDEN, and SPNIDEN, to the permitted level of debug.

Non-secure guaranteed access control

The top-level static configuration port, NSGUAREN, controls the behavior of the STM for non-secure guaranteed AXI accesses:

  • when NSGUAREN is tied LOW, non-secure guaranteed accesses behave like invariant timing, that is, the AXI does not stall

  • when NSGUAREN is tied HIGH, non-secure guaranteed accesses are enabled, that is, the AXI can stall and trace output is guaranteed.

Overrides

The debugger can override the stimulus ports selected with the STMSPOVERRIDER and STMSPMOVERRIDER to enable transactions to be always treated as guaranteed or as invariant timing.When overriding transactions to be guaranteed, this is considered invasive debug because the debugger might increase the level of intrusion defined by system software. The guaranteed override is possible only when invasive debug is permitted. When invasive debug is disabled, override has no effect.

Table 2.5 shows the authentication control with guaranteed override.

Table 2.5. Authentication control with guaranteed override

AWPROT[1]Permitted level of debugGuaranteed
Secure invasiveNon-secure invasiveSecure non-invasiveNon-secure non-invasive
1, non-secure-1--Allowed
1-0--Not allowed
0, secure1---Allowed
00---Not allowed

See the CoreSight Architecture Specification for the mapping of the authentication signals, DBGEN, NIDEN, SPIDEN, and SPNIDEN, to the permitted level of debug.

There are no requirements for debug permissions when overriding transactions to be invariant timing.

Copyright © 2010 ARM. All rights reserved.ARM DDI 0444A
Non-ConfidentialID090310