Simics Migration Guide

1 Introduction

This document describes how to migrate to Simics 7 from Simics 6.

Chapter 2 describes how Simics ABI and API compatibility works, including API deprecation and removal, between minor and major versions. Other areas covered include checkpoint compatibility and build environment compatibility.

Chapter 3 gives an overview on how to migrate from an old Simics version to Simics 7.

Finally, chapter 7 lists all currently deprecated functionality and the future release when it is slated for removal.

2 Compatibility

This chapter describes the compatibility Simics provides and how to keep scripts, modules and checkpoints from previous versions of Simics working in new versions.

Simics uses semantic versioning. This is defined at http://semver.org/ and here we use the terminology defined there without further explanation.

This implies that new features can be introduced in minor versions, but in a backwards compatible way, so Simics is ABI backward compatible between minor versions. As a result, user-written modules and add-on packages can be used with a newer minor (or patch) version without recompilation.

Major versions introduce incompatible changes, which are mainly removals of previously deprecated functionality. In rare cases cases there can also be incompatible changes to existing functionality.

This implies that add-on packages compiled for a particular major version will work with the next major version as long as they do not use any deprecated functionality.

Simics maintains backward compatibility for checkpoints one major version older than the oldest of the currently supported API versions, i.e. Simics 7 supports loading checkpoints from versions 6 and 5. This assumes that the model also supports older checkpoints.

2.1 Supported Simics API

The API consists of all functions which have a SIM_ prefix, as well as any types required by those functions. There are also functions prefixed VT_ and DBG_ that are not supported and usually not documented. Such functions may for instance implement experimental functionality or, in rare cases, used to implement parts of the API, e.g. via macros. They should generally be considered internal and not used directly unless explicitly advised to.

The Simics API can be accessed from C/C++ by including one of the simics/device-api.h, simics/processor-api.h and simics/simulator-api.h header files, or in DML by including the corresponding files. There are also several additional header files defining Simics interfaces. The Simics specific memory allocation functions defined in simics/alloc.h are also supported.

Part of the Simics API is only available when programming in Python. The supported classes and functions belonging to the Simics Python API are listed in the Simics API Reference Manual.

Simics also defines some utility functions in simics/utils.h, that can be useful when programming in C/C++. These functions are currently not part of the supported Simics API.

2.2 API Deprecation

In a particular Simics major version, some features can be marked as deprecated. Deprecations are introduced only in major, not in minor, versions.

Features marked as deprecated in a particular major Simics version are supported in the subsequent major release. Using only non-deprecated features of one Simics release guarantees that an upgrade to the next major version will be without major hurdles.

Starting in Simics 7, features can also be marked as legacy in a particular major Simics version. Such features continue to exist until further notice, but are typically not supported for use in new functionality, and receive only critical bug fixes. Legacy features may be re-classified as deprecated in a future major version.

The lifespan of a SIM-prefixed API call is:

Major release A: Supported

The function is a fully supported feature. Most features remain supported for all major releases and are never deprecated.

Major releases B: Deprecated or Legacy

Documented as deprecated or legacy but still supported. Using deprecated functionality generates both compile-time and run-time warnings, which helps in migrating from deprecated API calls. When applicable, documentation in the form of release notes or porting guides points to replacement functionality. Using legacy functionality do not generate any warnings.

By default, deprecated functionality cannot be used when building modules. It is however still available by explicitly specifying an older major version as the API version, see Section 2.3.

Major release C: Removed or still Legacy

Deprecated features are removed in the subsequent major version. Legacy features remain (but can be re-classified as deprecated).

Calls with other prefixes such as VT or DBG do not necessarily follow the same process.

2.3 Compiling Modules Written for an Older Simics Version

Modules from older versions must specify what API they are written for by setting the make variable SIMICS_API. This variable must have one of the following values:

latest

Use the most recent Simics API.

7

Compile module for the 7 API.

6

Compile module for the 6 API.

In order to simplify upgrades to the future major Simics releases, it is recommended that this variable be set even when writing new modules. The recommendation is to always specify an explicit version number, not use latest.

2.3.1 Migrating Modules to the Most Recent Simics Version

Simics features are added and improved with every product release. At major releases some features may be deprecated in favor of improved implementations or solutions to the same problem.

Although the recommendation for developers is to avoid such deprecated features, they continue to work until the next major version. In these cases Simics provides both compile-time and run-time checks for use of deprecated features. The compile-time checks make deprecated parts of the API not visible during module compilation, resulting in compilation errors or warnings when such parts are being used. The compile time checks work for modules written in C or DML, but not for modules written in Python. To enable the compile-time checks, set the SIMICS_API make variable to the version of the new Simics release, for example 7:

    SIMICS_API = 7

A run-time check triggers when a feature is actually being used. Run-time checks complement compile time checks, since not all checks can be done statically. For example, static checking can not capture if passing a NULL pointer in an argument is deprecated.

The following Simics command-line options are related to warnings about deprecated features:

-wdeprecated

Issue a warning when a deprecated feature is used, or in many cases when a used feature will become deprecated in the next major release. This is equivalent to setting the sim→deprecation_level attribute to 2.

-no-wdeprecated

Never warn for use of deprecated features. This is equivalent to setting the sim→deprecation_level attribute to 0.

The default warning level, if none of the above flags is given, is for the sim→deprecation_level attribute to have the value 1. The resulting behaviour is to warn about all used features that were deprecated in the latest major release, but to issue no warnings about deprecations that will appear in the next major release.

2.4 Running Python Code Written for an Older Simics Version

To run a Python module, or some other Python code, that was written for an older Simics version, the old API module has to be included early in the Python source file. To run Python code written for Simics 6, add the following line:

import simics_6_api as simics

and then access old API functions as simics.SIM_old_function(), for example.

2.5 Build Environment Compatibility

Only the make variables, and makefiles described in the Model Builder User's Guide are supported. User written scripts and makefiles that rely on the internals of the Simics makefiles and other parts of the build environment may break in future Simics versions.

3 Migrating to a New Simics Version

3.1 Introduction

This chapter gives a short overview of the process of updating code and scripts from any older Simics version to the most recent one. The following chapters, on the other hand, contain version specific descriptions.

It is assumed that the migration is from Simics 6, the supported Simics version at the time of the Simics 7 release.

3.2 Step-by-step Guide

1. First make sure that any C/C++, DML and Python modules compile with the most recent API in the version of Simics that you are migrating from. In Simics 6, set SIMICS_API to 6 in the module Makefile. If the code does not compile cleanly, consult the Migration Guide for that Simics version.
2. Update Python modules to the most recent API in the version of Simics that you are migrating from. This can be done by importing the Simics API using a specified version:

   import simics_6_api as simics

   This will simplify the migration of code to a newer version of Simics later. Please note that you'll need to import modules and components after this.

   from simics import example

3. Run all scripts in Simics with the -wdeprecated command line flag to the Simics binary. This will catch uses of some deprecated features that can only be detected in run time. An alternative is to set the sim→deprecation_level attribute to 2.
4. When all modules and scripts run fine using the most recent API in the old version of Simics, it is time to migrate to Simics 7. Update the existing project to point to a Simics 7 installation or, even better, create a new project for Simics 7 development, since the old project may be needed for comparison purposes.
5. Build all modules using the API version corresponding to the Simics version that you are migrating from. This should simply be a recompilation, since the old API version is already selected in the Makefiles and Python source files.
6. In a few cases there are API changes that the pre-processor cannot hide. They may cause the build to fail even when an old API is selected. Use the table in chapter 7 to figure out what changes are necessary.
7. Run all your tests and scripts to ensure that everything works in Simics 7 when using the old API. Make sure to pass -no-wdeprecated to suppress deprecation warnings in the process. Once everything works, you can start using the new version of Simics for actual work. The following steps are optional at this point, but still strongly recommended.
8. Change the API used for modules and scripts to the most recent version, one module or script at a time. Update the code according to the following chapters.
9. Turn off the -no-wdeprecated flag when running tests and scripts. Update any code that yields deprecation warnings according to the following chapters.

4 Migrating from Simics 6

4.1 Introduction

This chapter describes issues related to migrating to Simics 7 from Simics 6. For information about what is new in Simics 7, read the product release notes.

4.2 Launching Simics

When launching Simics 5 or 6 on Linux, the shell script file $HOME/.simics-5.sh was sourced if it existed. In Simics 7 this is no longer done.

4.3 DML migration

When migrating to Simics API 7 from Simics API 6, there are a few differences that may need to be addressed for DML code or modules. It is important to note that the migration to the Simics 7 API can be performed gradually. A single module in a large system can be migrated individually and each feature to be migrated can be migrated individually.

A comprehensive description of migration concerns and a process for migration is documented in Appendix C of the Device Modeling Language 1.4 Reference Manual. The below provide a brief list and brief description of some items to be addressed in the migration.

• The transaction interface was introduced in API 6, and will eventually replace the io_memory interface. In API 7, bank objects will by default implement the transaction interface.
• Log statements in shared methods now log on the nearest enclosing configuration object like non-shared methods. A common example of this, is that logs from certain register/field templates which appeared on the device objects in API 6 will instead appear on the bank objects in API 7.
• The common error of mixing up log level and log group in log statements gives a warning in Simics API 7.

For migrating DML 1.2 code, please refer to Appendix B of the Device Modeling Language 1.4 Reference Manual.

5 Migrating from IO Memory to Transactions

With the io_memory interface now considered legacy in Simics 7, all new modelling should implement the transaction interface. Migrating existing code to transaction interface from io_memory is also strongly recommended. With this in mind, the challenge to port existing platforms to entirely use transactions can be significant. Therefore Simics supports automatic internal conversion from io_memory to transaction and vice versa to allow incremental migration from io_memory to transaction.

To make this work, memory accesses shall not use direct interface calls for memory accesses but shall instead use function SIM_issue_transaction. If your model has to forward a generic_transaction_t and cannot construct the transaction_t itself, then function VT_map_target_access can be used but is considered an exception and the modeller shall construct a transaction_t whenever possible.

An important concept with the new transaction framework is the type map_target_t. Simics objects, i.e. conf_object_t, that implement any of the memory/IO related interfaces can be converted to a map_target_t through function SIM_new_map_target. A map_target_t must be freed at end of use by calling function SIM_free_map_target.
See API Reference Manual Chapter 3.2 Device API Data Types for detailed information about map_target_t.

5.1 Example porting external IO Memory dependency to Transactions in DML

The device example_dev contains two connects: memory and target_dev, implementing interfaces memory_space and io_memory. It contains two methods write_to_dev32 and read_memory32. These methods create a generic_transaction_t to do a 32-bit io_memory write and read. The question now is how to port device example_dev to the new transaction framework.

dml 1.4;

device example_dev;

import "utility.dml";

connect memory {
    interface memory_space;
}
connect target_dev {
    interface io_memory;
}

method write_to_dev32(uint64 addr, uint32 value) {
    local bytes_t buf;
    buf.data = cast(&value, uint8*);
    buf.len = sizeof(value);

    local generic_transaction_t mop = SIM_make_mem_op_write(addr,
                                                            buf,
                                                            false,
                                                            dev.obj);

    local map_info_t map_info;
    dev.target_dev.io_memory.operation(&mop, map_info);
}
method read_memory32(uint64 addr) -> (uint32) {
    local uint32 value;
    local buffer_t buf;
    buf.data = cast(&value, uint8*);
    buf.len = sizeof(value);

    local generic_transaction_t mop = SIM_make_mem_op_read(addr,
                                                           buf,
                                                           false,
                                                           dev.obj);

    dev.memory.memory_space.access(&mop);
    return value;
}
  

The code below ports the device to use transactions and map targets. The model is now ported to the new transaction framework and is at the same time Memory/IO interface agnostic. Making the model possible to be used in legacy platforms where the connected target_dev implements io_memory and in new platforms the connected target_dev can be using transactions. The target_dev object can still use io_memory but can now be ported to transactions at a later point without breaking its dependency to device example_dev. This way, incremental migration of a platform away from io_memory to transactions is possible.

dml 1.4;

device example_dev;

import "utility.dml";

method validate_map_target(conf_object_t *obj) -> (bool) {
    local map_target_t *tmp = SIM_new_map_target(obj, NULL, NULL);
    if (!tmp) {
        local exception_type_t _exc = SIM_clear_exception();
        SIM_attribute_error(SIM_last_error());
        return false;
    }
    SIM_free_map_target(tmp);
    return true;
}
connect memory {
    session map_target_t *map_target;
    method validate(conf_object_t *obj) -> (bool) {
        return validate_map_target(obj);
    }
    method set(conf_object_t *obj) {
        SIM_free_map_target(this.map_target);
        default(obj);
        this.map_target = obj ? SIM_new_map_target(obj, NULL, NULL) : NULL;
    }
}
connect target_dev {
    session map_target_t *map_target;
    method validate(conf_object_t *obj) -> (bool) {
        return validate_map_target(obj);
    }
    method set(conf_object_t *obj) {
        SIM_free_map_target(this.map_target);
        default(obj);
        this.map_target = obj ? SIM_new_map_target(obj, NULL, NULL) : NULL;
    }
}

method write_to_dev32(uint64 addr, uint32 value) throws {
    if (!target_dev.map_target)
        throw;
    local uint8 buf[4];
    local atom_t atoms[5] = {
        ATOM_data(buf),
        ATOM_size(4),
        ATOM_flags(Sim_Transaction_Write),
        ATOM_initiator(dev.obj),
        ATOM_list_end(0)
    };
    local transaction_t t;
    t.atoms = atoms;
    SIM_set_transaction_value_le(&t, value);
    if (SIM_issue_transaction(target_dev.map_target, &t, addr) != Sim_PE_No_Exception)
        throw;
}
method read_memory32(uint64 addr) -> (uint32) throws {
    if (!memory.map_target)
        throw;
    local uint8 val[4];
    local atom_t atoms[4] = {
        ATOM_data(val),
        ATOM_size(4),
        ATOM_initiator(dev.obj),
        ATOM_list_end(0)
    };
    local transaction_t t;
    t.atoms = atoms;
    if (SIM_issue_transaction(memory.map_target, &t, addr) != Sim_PE_No_Exception)
        throw;
    return SIM_get_transaction_value_le(&t);
}
  

In DML there is a template map_target that can be applied to any connect that implements any of the Memory/IO interfaces defined in the bullet list above. The code can be rewritten very compactly because of the helper functions provided by the map_target template. See Device Modeling Language 1.4 Reference Manual chapter Standard Templates for a detailed description of the map_target template.

dml 1.4;

device example_dev;

import "utility.dml";

connect memory is map_target;
connect target_dev is map_target;

method write_to_dev32(uint64 addr, uint32 value) throws {
    target_dev.write(addr, 4, value);
}
method read_memory32(uint64 addr) -> (uint32) throws {
    return memory.read(addr, 4);
}
  

5.2 Porting device implementing IO Memory to Transactions

We have now covered how to remove dependency on external devices implementing io_memory interfaces by interacting with them through a map_target. Another scenario is when the device itself implements an io_memory type of interface and you cannot port that until the devices communicating with it transitions to map_target usage. In cases where the device forwards the memop to another device a partial migration is still possible.

dml 1.4;

device example_dev2;

import "utility.dml";

connect target_dev1 {
    interface io_memory;
}
connect target_dev2 {
    interface io_memory;
}
port demux is signal_port;

implement io_memory {
    method operation(generic_transaction_t *mem_op,
                     map_info_t map_info) -> (exception_type_t) {
        if (demux.signal.high)
            return target_dev1.io_memory.operation(mem_op, map_info);
        else
            return target_dev2.io_memory.operation(mem_op, map_info);
    }
}

Doing a partial migration of this code where we keep our own implementation of io_memory but remove the dependency of target_dev1 and target_dev2 to implement io_memory would require us to either convert generic_transaction_t to a transaction_t and issue a SIM_issue_transaction or to use the convenient help function VT_map_target_access which allows the user to use a generic_transaction_t together with a map_target_t. In the code below we utlize the VT_map_target_access function since it is a lot more convenient in this scenario.

dml 1.4;

device example_dev2;

import "utility.dml";

connect target_dev1 is map_target;
connect target_dev2 is map_target;

port demux is signal_port;

implement io_memory {
    method operation(generic_transaction_t *mem_op,
                     map_info_t map_info) -> (exception_type_t) {
        SIM_set_mem_op_physical_address(mem_op,
            SIM_get_mem_op_physical_address(mem_op) - map_info.base + map_info.start);

        if (demux.signal.high)
            return VT_map_target_access(target_dev1.map_target, mem_op);
        else
            return VT_map_target_access(target_dev2.map_target, mem_op);
    }
}

When a full migration can be done, the code should be rewritten as:

dml 1.4;

device example_dev2;

import "utility.dml";

connect target_dev1 is map_target;
connect target_dev2 is map_target;

port demux is signal_port {
    implement signal {
        method signal_raise() {
            default();
            SIM_translation_changed(dev.obj);
        }
        method signal_lower() {
            default();
            SIM_translation_changed(dev.obj);
        }
    }
}

implement translator {
    method translate(uint64 addr, access_t access,
                     const map_target_t *default_target) -> (translation_t)
    local translation_t t;

    if (demux.signal.high)
        t.target = target_dev1.map_target;
    else
        t.target = target_dev2.map_target;
    return t;
}

5.3 Port usage of generic_transaction_t user_data

5.3.1 IO Memory with user_data

With generic_transaction_t custom meta data could be added to IO Memory transactions through user_data.
The example device below showcases setting user_data to a generic_transaction_t through function SIM_set_mem_op_user_data.

dml 1.4;

device example_user_data_set;

typedef struct {
    int id;
} example_message_t;

connect endpoint {
    interface io_memory;
}

bank regs {
    register msg_id size 4 @ 0x0 "Message id";
    register msg_send size 8 @ 0x8 "Send message" {
        is write;
        method write(uint64 value) {
            if (endpoint.io_memory.val) {
                local bytes_t buf;
                buf.data = cast(&value, uint8*);
                buf.len = sizeof(value);

                local generic_transaction_t mop = SIM_make_mem_op_write(0,
                                                                        buf,
                                                                        false,
                                                                        dev.obj);
                local example_message_t msg = { .id = msg_id.val, ... };
                SIM_set_mem_op_user_data(&mop, &msg);
                local map_info_t map_info;
                endpoint.io_memory.operation(&mop, map_info);
            }
        }
    }
}

The example device below showcases retrieving the meta data from a generic_transaction_t through function SIM_get_mem_op_user_data.

dml 1.4;

device example_user_data_read;

typedef struct {
    int id;
} example_message_t;

implement io_memory {
    method operation(generic_transaction_t *mem_op,
                     map_info_t map_info) -> (exception_type_t) {
        local example_message_t* msg = SIM_get_mem_op_user_data(mem_op);

        if (msg != NULL)
            log info, 1: "Received message #%d", msg->id;
        return Sim_PE_No_Exception;
    }
}

5.3.2 Transactions with atoms

With generic_transaction_t a void pointer is passed between the initiator and the target making the data type unsafe. With transactions meta data can be shared through atoms which are type safe. The target shall declare its own custom atoms for the meta data. A declaration consists of a type and methods to create, retrieve and set atom values. The target can check if a specific atom is part of the transaction making the meta data exchange type safe. Custom atoms are defined in a Simics Interface Module similar to custom interfaces.

The below file example-atom.h declares an atom with the same signature as in the previous example.

#ifndef MESSAGE_ATOM_H
#define MESSAGE_ATOM_H
#include  <simics/device-api.h>

#if defined(__cplusplus)
extern "C" {
#endif

typedef struct {
        int id;
} example_message_t;

// Allow creation from Python, if required
SIM_PY_ALLOCATABLE(example_message_t);
#define ATOM_TYPE_example_message example_message_t *
SIM_CUSTOM_ATOM(example_message);

#if defined(__cplusplus)
}
#endif

#endif /* MESSAGE_ATOM_H */

File example-atom.c creates an interface module which at runtime registers the example_message atom for runtime usage.

#include "example-atom.h"

void
init_local(void)
{
        ATOM_register_example_message();
}

File example-atom.dml adds DML wrappers for the example_message atom data type and its accessors. Devices written in DML shall import this file.

dml 1.4;

header %{
#include "example-atom.h"
%}

extern typedef struct {
    int id;
} example_message_t;

// Create atom
extern atom_t ATOM_example_message(const example_message_t *msg);
// Get atom
extern const example_message_t* ATOM_get_transaction_example_message(const transaction_t *t);

The code below is class example_user_data_set ported to instead use an atom for sending the message.

dml 1.4;

device example_user_data_set;

import "utility.dml";
import "example-atom.dml";

connect endpoint is map_target;

bank regs {
    register msg_id size 4 @ 0x0 "Message id";
    register msg_send size 8 @ 0x8 "Send message" {
        is write;
        method write(uint64 value) {
            local buffer_t buf;
            buf.data = cast(&value, uint8*);
            buf.len = sizeof(value);
            local example_message_t msg = { .id = msg_id.val, ... };

            local atom_t atoms[6] = {
                ATOM_initiator(dev.obj),
                ATOM_data(buf.data),
                ATOM_size(buf.len),
                ATOM_flags(Sim_Transaction_Write),
                ATOM_example_message(&msg),
                ATOM_list_end(0)
            };
            local transaction_t t;
            t.atoms = atoms;
            endpoint.issue(&t, 0);
        }
    }
}

The code below is class example_user_data_read ported to instead use an atom for the message.

dml 1.4;

device example_user_data_read;
import "example-atom.dml";

implement transaction {
    method issue(transaction_t *t, uint64 addr) -> (exception_type_t) {
        local example_message_t* msg = ATOM_get_transaction_example_message(t);

        if (msg != NULL)
            log info, 1: "Received message #%d", msg->id;
        return Sim_PE_No_Exception;
    }
}

5.4 Devices that rely on align-size based transaction splitting

For interfaces that used the generic_transaction_t structure a memory space would split transactions into individual transactions according to the align-size setting of the memory space map entry. For transaction_t based interfaces this is no longer the case. The memory space will still apply byte swapping according to the byte swap and align-size settings, but it will no longer split the transactions.

There are some rare cases where a device might rely on the fact that transactions arrive only in chunks that are equal to or smaller than the align-size setting of its mapping. In such a case, the splitting needs to be handled by the device code or a transaction splitter needs to be inserted between the memory space and the device expecting the split transactions.

Device code handling of splitting is case specific and depends on the language used. In DML or C++, one can address oversized transactions in the function transaction_access of a bank, while in C one might do that directly in the implementation of the issue function of the transaction interface.

The easiest and a language agnostic way is inserting a transaction splitter. An example of such a splitter is the class transaction_splitter shipped with Simics. The source code can be found in src/devices/transaction-splitter. Assume that originally you had a case like shown below in Python.

# - mem refers to a memory space object
# - dev refers to an io-memory based device with a bank called "regs"

# map regs at offset 0x30, with length 0x100 and an align-size of 2
mem.map.append([0x30, dev.bank.regs, 0, 0, 0x100, None, 0, 2])

If that device was migrated from IO Memory to transaction but you still want to ensure that all transactions carry at most 2 bytes, you could insert the transaction splitter as shown below.

# - mem refers to a memory space object
# - dev refers to an io-memory based device with a bank called "regs"

# create a splitter, point it to the actual bank and configure it to split
# into two bytes
splitter = SIM_create_object('transaction_splitter',
                              'splitter',
                              target = dev.bank.regs,
                              split_size = 2)

# only change in the mapping is that it now points to the splitter object
mem.map.append([0x30, splitter, 0, 0, 0x100, None, 0, 2])

6 SystemC Library

6.1 Package 1013

The SystemC Library has been moved out of the Simics Base package to a separate package 1013 (*SystemC-Library*). Users migrating to Simics version 6.0.207 or later will need to install package 1013 to continue using SystemC.

The build process and usage of the SystemC Library remain unchanged, and no modifications are required for users' existing SystemC modules. However, since the SCL_VERSION has been updated, both the SystemC Library and the SystemC modules must be rebuilt following the migration.

7 Deprecated and Legacy Functionality

This chapter describes all functionality that is currently deprecated or legacy, and, in the former case, when it will be removed, including items removed in the current release. There are also suggestions on replacements.

7.1 Legacy in Simics 7

Functionality classified as legacy in Simics 7.

7.1.1 Product Features

7.1.2 CLI

7.1.3 Interfaces

7.1.4 API

7.2 To Be Removed in Simics 7

Functionality deprecated in Simics 6.

7.2.1 Product Features

7.2.2 CLI

7.2.3 Classes and Attributes

7.2.4 Interfaces

7.2.5 API

7.2.6 Other

7.3 To Be Removed in Simics 8

Functionality deprecated in Simics 7.

7.3.1 Product Features

7.3.2 CLI

7.3.3 Classes and Attributes

7.3.4 Interfaces

7.3.5 API

7.4 To Be Removed in Simics 9

Functionality deprecated in Simics 8.

7.4.1 Product Features

7.4.2 CLI

7.4.3 Classes and Attributes

7.4.4 Interfaces

7.4.5 API