|Home > Iris APIs > Events and trace API > 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
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.