Difference between Flush & sending data out in AMBA ATB?

Question

I am new to AMBA ATB protocol and trying to understand it.

I found that Transmitter can send the trace data to the receiver using Data signals,

• ATBYTES
• ATDATA
• ATID
• ATREADY
• ATVALID

There is another feature called Buffer flush to remove the trace data from the transmitter source . This is initiated by Receiver by asserting AFVALID. So my doubt is,

1. What's the difference between 2 approaches? Does data be retained in FIFO in the first approach?
2. Since the FIFO is inside transmitter , how can receiver decide on when to flush?

Answer 1

There are some confusing aspect.

Signalling interface

The 'transmitter' is a peripheral. The receiver is a controller or bus master. It is important to note that the controller initiates all consumption over the ATB.

What is data?

What the flush is referring to? It does not refer to the peripheral data (ie device data, like ethernet, comm port, etc). It refers to trace buffer data. The peripheral may not report events immediately as they are read by the controller. If several events occur, a trace data buffer is desired.

Answers

What's the difference between 2 approaches? Does data be retained in FIFO in the first approach?

FLUSH discards all data; more efficient than reading out and discarding. Both approaches will empty any FIFO.

Since the FIFO is inside transmitter , how can receiver decide on when to flush?

The trace data is related to the operation of the peripheral. The controller always initiate use of the peripheral. If there is old stale trace data from prior use, the controller can flush it. The use case is up to the controller. The controller may have it's own buffers (of both trace data and peripheral data), but this management is outside the interface. It is up to the controller (typically a CPU; or ultimately driven by some CPU).

So there is only one real 'buffer' of concern. It is trace data buffered in the peripheral that is waiting (AT_VALID). If the controller, asserts AT_READY, either then next value in the buffer is placed on data, or AT_VALID de-asserts.

ETM as an example.

A concrete example of ATB data is the Cortex-M4 ETM. This defines the data format for tracing program execution on the Cortex-M4 CPU. It feeds an ETB (embedded trace buffer) which can be read by the CPU through another gasket/AHB interface, or it can also be sent to JTAG interfaces. Ie, the ATB specification is not meant to answer your question, it remains vague in order to allow multiple (re)uses.

Data/Transmit Signals

• ATBYTES[m:0] - Bus from peripheral to controller. The number of bytes on ATDATA to be captured, minus 1.
• ATDATA[n:0] - Bus from peripheral to controller. Trace data.
• ATID[6:0] - Constant bus from peripheral. An ID that uniquely identifies the source of the trace.
• ATREADY - Line from controller. The controller is ready to accept data
• ATVALID - Line from peripheral. Indicates that ATDATA bus holds data.

Global Signals

• ATCLK - Global ATB clock.
• ATCLKEN - Enable signal for ATCLK domain (optional).
• ATRESETn - Interface reset, active LOW async/sync.

Flush Signals

• AFVALID - flush signal to indicate that all buffers must be flushed because trace capture is about to stop.
• AFREADY - Acknowledge flush operation.

Importantly, there is ATCLK, which is used to latch/setup the ATDATA lines. If both ATREADY and ATVALID are asserted, the the ATDATA is to be consider 'read' or consumed. The flush line will do this for all data; not needing multiple clocks. The documentation also indicates another use besides a start of measurement; a stop measurement which is a better time to assert the signal. In both cases, this prevents stale data.