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