4.14.1 Ring buffers

Events can optionally be stored in a ring buffer on the simulation side. One reason to do this is to improve runtime performance.

The buffer can also be used if only the most recent events are of interest to the client. This feature could be implemented on the client side using the normal ec_FOO() callbacks but the performance would be slow.

Each client has its own ring buffer on the simulation side. Each ring buffer can buffer events from all instances. The effect is that each client can control its ring buffer as if it was implemented on the client side, with the performance advantages of implementing it on the simulation side. Clients can freely use their own ring buffer without affecting other clients.

Ring buffers support the following modes, see the mode argument of eventRingBuffer_init():

mode="overwrite"
Continuously overwrite old data.
mode="send"
Send buffered events to clients in chunks.
mode="drop"
Fill up only once until full.

Clients can configure the size of their ring buffer, read from it, and clear it.

To keep the internal event infrastructure simple and fast, each client only has one ring buffer. Clients can easily demultiplex the event streams that go into the buffer, so this limitation is rarely a problem. If a client needs multiple ring buffers, it can register extra client instances, each of which has its own ring buffer. This is rarely necessary. A possible use case is to have a large buffer capturing only a PC trace and a smaller buffer capturing the last ten memory transactions, each containing many fields, which would quickly fill up the PC trace buffer.

If a ring buffer is not used for a particular event stream, which is the default, events are sent to the client by the ec_FOO() callback, synchronously or asynchronously, as they occur.

Non-ConfidentialPDF file icon PDF version101196_0100_00_en
Copyright © 2018 Arm Limited or its affiliates. All rights reserved.