5.17.1 Ring buffers

Events can optionally be stored in a ring buffer on the simulation side, which can improve runtime performance.

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

Each client has its own ring buffer on the simulation side. A 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, but 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, using 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 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. A possible use case might be to have a large buffer capturing a PC trace and a smaller buffer capturing only the last few 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_03_en
Copyright © 2018, 2019 Arm Limited or its affiliates. All rights reserved.