This chapter describes how to port device models, components, and scripts to Simics 6 from Simics 5. For information about what is new in Simics 6, read the product release notes.
In Simics 5, objects are initialized using a deterministic, but undefined, ordering. In Simics 6, the object initialization algorithm has changed to always initialize objects in alphanumeric order, with parents being initialized before children. Device models that happened to work because of a particular device ordering in Simics 5, may break with Simics 6. Such device models should be fixed to not access uninitialized objects, e.g. by making proper use of SIM_require_object.
Simics 6 has native support for Hierarchical Objects. Support for an object hierarchy was previously provided by, and restricted to, the component system. The internals of the component system has been modified extensively to work with the native object hierarchy, and components that depend on undocumented or unsupported features can break in Simics 6. Below is a list with some things that could cause issues:
When creating processor core models with Simics 6, or when integrating them into a platform, the following points should be taken into consideration:
memory_page API has
been removed. Models should make use
the direct_memory interface instead.
Processor core models in Simics 6 should preferably use
the clock-extension extension class instead of
implementing the cycle interface directly.
Using the new CPU API is not a strict requirement, but it
has several benefits:
Simics 6 introduces new target consoles, which are native to
the Simics GUI instead of relying on xterm. Please
refer to Chapter 6 for more details.
From Simics 6, the CPU modules comes only in one variant, the "fast" one. Consequently, "turbo" has been removed from the file names of CPU modules.
Simics 5, and earlier, provided two modules per CPU, a "stall" module and a "fast" module, where the "fast" file had "turbo" in its name. With the added instrumentation and stalling support, there is no longer any need for the "stall" module.
There is no need to upgrade DML code when moving to the Simics 6 from the Simics 5 API.
However, internally I/O and memory BARs mapped on a bank will now map the bank object instead of using function number mappings. Also, SR-IOV virtual functions are mapped to the bank object of the virtual function, instead of mapping port interfaces.This change mainly affects how the memory maps are exposed to the end-user in memory spaces. It should not be visible to target software, and does not affect how to write models.