The Iris Debug and Trace interface represents a major step forward in functionality for virtual prototypes incorporating Arm Fast Model. Iris complements and will, in time, replace the existing debug (CADI – Component Architecture Debug Interface) and trace (MTI – Model Trace Interface) APIs so it’s worth explaining why we have decided to introduce a new interface rather than enhancing the existing interfaces. I will also outline the future plans for debug and trace with Arm models.
Before we dive into the specifics of Iris we should look at the key differences between debug & trace (& analysis) on a model (a.k.a. a Virtual Prototype, VP) and hardware. On hardware, the debug typically requires that additional logic be built into the silicon, with a dedicated interface. This interface is connected to the debugger through custom hardware, e.g. a trace probe. The debug capabilities on a SoC are burnt into the device when it’s manufactured thus constraining their flexibility and extensibility. In contrast, debug on a VP is via an API (or multiple APIs). As the VP itself is flexible and editable so are the debug and trace capabilities. They are also more controllable and deterministic. When an attached client, e.g. a debugger such as Arm Development Studio, signals the VP the simulation stops across all cores and peripherals instantly. There is no requirement to keep clocks running and maintain hardware state. All aspects of the model are open to analysis, inspection and modification.
The controllability and visibility of a VP is often posited as a key advantage over debugging on hardware. The APIs that give access to the model information and give model control are critical to these capabilities. Arm Fast Models are used extensively with Arm and by partners from early architectural development through software porting to final system bring up. Over time the range of use cases and applications has broadened building a legacy of requirements on the debug and trace APIs. When we looked into how to address these it became apparent that a new approach to the API was required rather than building on the current capabilities.
Hence Iris.
Iris was designed to address areas that were either difficult or impractical to implement in CADI and its API. Key amongst these are the following:
Iris is network native. Although remote debug is possible through CADI it can be difficult to set up and maintain. In Iris both simulation control and trace access are available across the network. A very common mode of usage is running the simulation on a server whilst the debug interface is run on the local workstation. Iris is significantly more adept at providing this capability than its predecessors. Iris can also run in-process as required.
Iris provides a single interface for both debug and trace. This greatly enhances the ability to provide – and guarantee – synchronous debug and trace when required. This was difficult to achieve with separate debug and trace APIs. Having a single interface also ensures naming consistency, something that could not be guaranteed when maintaining two distinct APIs.
With Iris plug-ins and trace can be loaded at any time during the simulation rather than at start up. This allows for much greater flexibility in operation and potentially improves simulation performance.
Iris provides requested enhancements such as an API for tables to improve debug of caches, TLBs and other integrated memories, asynchronous trace and virtual/physical address translation.
Underlying all this is the capability to add functionality within Iris without breaking compatibility of existing interfaces. This was not possible with CADI/MTI where a user was required to rebuild integrations when changes were made to the APIs.
Overall, Iris provides a major step forward in functionality and usability over the previous generation of interfaces. These improvements further enhance the advantages of using VPs over hardware to develop and debug software for Arm SoCs and unleash the powerful capabilities of VP. Iris is designed to be easy to use. Iris utilizes the widely used JSON format for data and command structures. Iris is scripted through a Python (2.7 or 3.*) interface providing simulation control and data management capabilities.
There are many applications – commercial and proprietary – that leverage the current APIs. To facilitate partners transitioning to Iris, both CADI and MTI will be maintained (but not enhanced) in parallel with Iris being rolled out. Arm’s Development Studio tool suite will support Iris in the fall of 2019 and 3rd party solution providers, that have had early access to the specifications and libraries, will also transition in due course. The current goal is to phase out the CADI interface in mid-2020 and MTI around 1 year after that. It is planned that some capabilities of MTI will be rolled into Iris to provide trace in situations where simulation performance is more important than interactive inspection.
Explore Iris in Arm Fast Models