translate

Description

The translate interface is implemented by objects that bridge between memory spaces.

Note: There is the translator interface which is a more restricted version of the translate interface and should be used when possible. It allows for better control of memory operations in the Simics core and can therefore allow optimizations in the memory handling.

The return value of the translate method should be a memory space, to which the access is translated at the offset given by the physical address of mem_op. If the return value is NULL, then the access is translated to the default target provided in the configuration (in a memory-space object, this is the 6th index, target, of an entry in the map attribute).

If the translator marks mem_op as ignored before returning NULL (using the function SIM_set_mem_op_ignore), then the return value is ignored, and the transaction is instead terminated in the translator and handled as an ordinary I/O access.

During a translation, the translator may modify the physical address of mem_op, but may have no other side-effects. This is because the caller can choose to cache the translation, in which case the translator is bypassed in subsequent accesses.

The translator can use SIM_mem_op_ensure_future_visibility to inhibit caching. Inhibiting caching can be useful for debugging, but typically comes with a significant performance cost if there is RAM behind the translator.

The addition of the direct_memory interface in Simics 5 results in new typical access patterns for the translate interface. Where previously non-inquiry accesses of any size would result in caching in initiating CPU objects, with the use of direct_memory no such implicit caching ever takes place. Instead, caching requests are separate and fed through the translate method as inquiry accesses of the size that is intended to be cached. This means that for a translate object to work properly in a configuration with CPUs using direct_memory, inquiry accesses must be properly handled. Routing such inquiry accesses to non-memory, terminating them in the translator (which is not an allowed behavior for a translate object), or calling SIM_mem_op_ensure_future_visibility on them results in the requesting CPU not being able to cache the requested memory region.

Using the translate interface in models is error prone and usually not recommended unless all alternatives have been exhausted. Explicit map and demap operations in a memory space avoid the problems with translate interface implementation correctness.

The usage of the translate interface is by necessity less optimal than the usage of the memory-space class as a call out from the simulation kernel should be made. That said when the translate() method is called the transaction may be cached in the STC if the user code does not explicitly block such caching, though depending on a number of factors it may not always be cached. If the translation is cached in the STC then performance is the same as with a memory-space.

There are two reasons to use the translate interface rather than a simple memory-space: 1) To implement something that the memory-space does not support, such as different read and write translations, or manipulation of the transaction, or 2) the translation is accessed infrequently, but updated on most accesses.

Note: Up to and including Simics 4.8, inhibiting caching for the instruction stream did not prevent Simics-provided CPU models from caching. Models therefore had to use flush or SIM_flush_cell_caches on mapping changes to get the desired effect. This is no longer needed since Simics 5.

Up to and including Simics 4.8, CPU models would cache memory for transactions that pass through a translator in blocks that are larger than the size provided in the transaction. This meant that a translator needed to invalidate caches even if a translation changed that had strictly not passed through the interface. For correctness, when any state that had an effect on the translation logic changed, the translator would therefore invalidate all mappings in all initiators, even for mappings that are outside of what has passed through the translator. These types of workarounds are no longer required since Simics 5.

SIM_INTERFACE(translate) {
        conf_object_t *(*translate)(conf_object_t *NOTNULL obj,
                                    generic_transaction_t *NOTNULL mem_op,
                                    map_info_t mapinfo);
};

#define TRANSLATE_INTERFACE "translate"

Execution Context

Cell Context for all methods.