The Iris interface consists of the following:
- A generic function call interface. Functions are called by name.
Arguments and return values are passed by name and by value.
- An object model. Iris systems consist of a set of instances. Instances are entities that can send and
receive Iris function calls, for instance modeled components, hardware targets,
debuggers, plug-ins, and framework components. All instances can:
Each instance is identified by an instance id,
- Discover and communicate with all other instances.
- Call functions on and receive function calls from all
- A defined set of functions that are supported by instances. Most are
It has the following design principles:
- Function calls are generally split into a request and an asynchronous response.
- Function calls and responses are represented using JSON data types, for example
integers, strings, arrays, objects, and booleans.
- All types of events, for instance trace, debug, and semihosting events, are
exposed through the same event mechanism.
- When calling a function, the caller can generally choose between sending:
- A request. The callee sends a response back to the
caller when it has finished processing the function. This is called a
synchronous or blocking function call, as the caller is blocked while
waiting for the response.
- A notification. The callee does not send a response, so
the caller does not know when the callee has finished. This is called an
asynchronous or non-blocking function
call. It is faster than a request and is preferred.
- Instances can connect to a simulation either using Inter-Process
Communication (IPC) or within the same process. In either case, the
interface is the same.
- JSON RPC 2.0 semantics are used for all function calls, whether using IPC or
- It uses U64JSON, a proprietary binary equivalent of JSON that is based on a sequence of
uint64_t values, in-process to remove the JSON parsing overhead.