5.2 Debug Watchpoint Module

Each XP includes two watchpoints in a Debug Watchpoint Module (DWM). These watchpoints can be used to compare the fields of flits entering or exiting an XP on a device port with the maskable flit-field values that the system programmer provides.

The two watchpoints are shared across both device ports in any configuration:

Each watchpoint includes the following, where * represents 0 or 1:

Each of these covers identical fields of CHI flits. All fields of all flits of all channels in both transmit and receive directions can be compared against, using the watchpoint value and mask, except for the Data field of the DAT channel, although the watchpoint can only be applied to any one channel in any direction at any given time. Because of this, watchpoint matches on pure data are not possible. After you configure the watchpoint compare value and mask, and enable the watchpoint, every flit from the selected channel that enters the XP from a device or exits the XP to a device, depending on which direction is chosen for comparison with the watchpoint, is mask-compared against the compare value.

You can configure watchpoints to qualify the match and trigger capability with other events. Using the wp*_arm_sel fields in the dt_control register, you can configure the watchpoints to only start comparing after a condition has occurred, which arms the watchpoint. Arming conditions include an event on any of the DTB wires or a trigger by the opposite watchpoint. Alternatively, you can configure the watchpoints to be always armed. In addition, using the wp*_event_count fields, you can configure each watchpoint to preclude triggering until the arming condition has occurred a specific number of times.

In case of a watchpoint match, you can optionally configure the watchpoint to snapshot the flit that matched the watchpoint compare value and mask, so that software can read the flit contents for more debug visibility. The flit data is captured in the dt_cmp_val*_l and dt_cmp_val*_h registers, overwriting their compare values. Only the first flit that a watchpoint matches can be snapshotted. The snapshot status is captured in the sscapture_status field in the dt_status register corresponding to the matching watchpoint. This inhibits snapshotting after the first snapshot, although watchpoint matches and their reporting are not affected. When the sscapture_status field is cleared, snapshotting capability resumes.

Note:

Although not essential for correct watchpoint compare functionality, you can rewrite dt_cmp_val*_l and dt_cmp_val*_h fields with your own compare value before clearing the sscapture_status field.

The result of the watchpoint comparison can be written to the Debug and Trace Bus (DTB). This is a single-cycle assertion of the DTB wire indicating the occurrence of an event. From here, it is routed to the Debug Event Module (DEM) for processing. The watchpoint match can be placed on the DTB in various ways, including the following:

The result of a watchpoint match is a watchpoint trigger event. A trigger event consists of a number of optional outcomes including the following:

These optional trigger outcomes are subject to matching and triggering qualifiers.

Because the CHI architecture includes network-addressed flits, a common requirement for a watchpoint is to compare using the Transaction ID (TXNID) field. To set watchpoints to match on both request and responses into and out of a given device, the DWM includes a capability to copy the TXNID field from a flit which matches on watchpoint 0 into the TXNID field of watchpoint 1. This enables watchpoint 1 to uniquely match and trigger only on the corresponding response flit. Using this mechanism:

This has the effect that watchpoint 0 can match on a given request, with the arming and event-count qualifiers. Then, on triggering, it can copy the matching flit TXNID to watchpoint 1, which is then armed and can be expected to match, trigger, and snapshot the response flit corresponding to the original request.

The watchpoint functionality is not limited to a debug usage model, but is also a main part of the PMU architecture.

Non-ConfidentialPDF file icon PDF versionARM 100052_0001_00_en
Copyright © 2014, 2015, 2017 ARM Limited or its affiliates. All rights reserved.