Modeling Configuration in PSS (Portable Stimulus)

In this blog, we present design patterns for implementing configuration and reconfiguration in a PSS model. Each of these patterns fits a different use model and answers different configuration needs. The main questions we ask ourselves before choosing the constructs to use to model configuration are whether we want the same configuration to apply to all test cases, and whether the configuration is static or can it change during the run.

Static Configuration

Let’s start with static configuration. For attributes of the design that are “hard coded,” their values are fixed, known in advance, and many times – the same value applies for all test cases.  For implementing configuration for such static aspects, we can define attributes in the component. Component attributes are not randomized, hence set procedurally, for example – in the exec init_down. When solving starts, these attributes are already assigned, and the actions can refer to them in constraints.

For example, the following code defines an attribute named speed and assigns it in exec init_down. The traffic action refers to this attribute to constrain its rate. Note that the component attribute is non-rand – its value is just sampled when solving the action constraint. We can say it is an input to the constraint.

enum devA_speed_e {SLOW, FAST};

component IOdevA_c {
    devA_speed_e speed;
    action traffic {
        rand int in [1,2,4,8] rate;
        constraint (comp.speed == FAST) -> (rate == 8);
    };
};

extend component pss_top {
   IOdevA_c IOdevA;
    exec init_down {
      IOdevA.speed = FAST;
    };
};

Randomized Configuration

In the above example, the value of the configuration is assigned in init_down and applies to all test cases. In some projects, we want each test case to work in a different configuration, but actions in each test must be aligned on the same configuration. To be able to constrain the configuration attributes and have multiple actions use the same configuration, we define the configuration as a resource and define a pool of this resource in the component. Many actions can share this resource. Hence, all actions in the test are aligned on the same configuration. 

In the following example, the action uses the devA_config_r resource object and constrains it. Depending on other constraints and randomness, in some tests, the speed value will be FAST and in some SLOW.

resource devA_config_r {
    rand devA_speed_e speed;
};

component IOdevA_c {
    // the configuration is a shared pool of one
    pool[1] devA_config_r devA_config_var;
    bind devA_config_var *;
    action traffic {
        share devA_config_r cfg;
        rand int in [1..2,4,8] rate;
        constraint cfg.speed == FAST -> (rate == 8);
    };
};

Re-Configuration

The two examples we saw implement a configuration that remains unchanged throughout the test. What if we want to perform reconfiguration during the test? For implementing changeable configuration, with the possibility to infer dependencies among actions for automatic scenario creation, we can use a pool of state. Using state, the configuration is generated as part of solving the model, including the actions. We can define the initial value of the configuration using constraint initial and perform reconfiguration by implementing actions that define the configuration state as their output. If there are actions that should take place only on a specific configuration, these actions will define the configuration state as their input, and Perspec will make sure that the required state has been previously established and possibly infer a missing configuration action. In the following example, the initial value of speed is FAST. The traffic action requires the speed to be SLOW. So, the tool will decide to first do the reconfig action to change to SLOW. Then it will do the traffic action.

state devA_config_s {
    rand devA_speed_e speed;

    constraint initial -> speed == FAST;
};
component IOdevA_c {
    pool devA_config_s devA_config_var;
    // action to be used to update configuration
    action reconfig {
        output devA_config_s next_cfg;
        // … define the constraint on the state object
        // instance next_cfg, required for reconfiguration…
    };
    action traffic {
      input devA_config_s cfg;
      constraint cfg.speed == SLOW;
           //.. define the body, etc 
};

We saw here three ways for implementing configuration. There are additional examples in the Perspec release in the Modeling Patterns library. Before you choose how to model configuration in your environment, ask yourself – do you need to define constraints on the configuration attributes? Do you want to make them changeable (reconfigure)? Do you want them to be shared among multiple components and actions?

Choose wisely, and enjoy configuration