Managing Product Variants with the miniHIL Advanced

Motivation

In many projects a single miniHIL setup is used to test multiple product variants.
Typical examples are different hardware revisions, product sizes, or feature sets that share the same basic interface but differ in configuration, limits, and expected behavior.

This How-To shows how to:

  • create a common test library with shared ROOM models and test logic

  • configure individual product variants via a small C data structure

  • use these variant parameters from CaGe and ROOM in a consistent way

The goal is that test logic is implemented once in a common library, while each variant project only provides its own configuration.

High-level structure

The recommended structure uses:

  • one common test library (e.g. CommonTestLibrary)

    • contains shared ROOM models and CaGe files

    • declares a VariantParameters struct and a global instance

  • one variant project per product variant

    • links against the common test library

    • provides its own variantParameters.c with the concrete values

The structure can be visualized as follows:

CommonTestLibrary and variant projects
Variant handling with common library and variant projects

Creating the common test library project

The common test library holds all reusable logic and models that should be shared across product variants.

  1. Create a new miniHIL project using the library template from the miniHilLib. This will give you a project we will call CommonTestLibrary in this document.

  2. In this project, organize your content e.g. as:

    • model/actors - common ROOM models (actors, protocols, test infrastructure)

    • model/test - common CaGe files (reusable test steps, helper sequences)

    • inc/ - public headers (e.g. variantParameters.h)

    • src/ - C code used by ROOM/CaGe (if needed)

Tip The name CommonTestLibrary is just an example. You can use any project name, as long as your Gradle configuration and model paths refer to it consistently.

Configuring the variant projects (Gradle)

Each variant project (e.g. MiniHilProject_VariantA, MiniHilProject_VariantB, …) should link against the CommonTestLibrary project.

A typical build.gradle in a variant project can look like this:

/**
 * This project assembles the miniHil executable.
 */

ext.userSourceDirs      = [ 'src-user' ]
ext.userCompilerFlags   = [ '-g3', '-Og', '-Wall' ]
ext.userLinkerFlags     = [ ]

ext.userLibraries       = [
    [ project: ':CommonTestLibrary', library: 'CommonTestLibrary' ]
]

// apply defaults
apply from: new File(miniHilLibGradleDir, 'MiniHilProject.gradle')

This tells the miniHIL build system that:

  • variant-specific C code is in src-user

  • a static library called CommonTestLibrary from the Gradle project :CommonTestLibrary is linked in

Configuring the model path

To use ROOM models and CaGe files from the common library, each variant project must reference the common project in its model path.

In the modelpath file, add a reference such as:

    project CommonTestLibrary

This allows imports like:

import actors.SomeReusableActor
import tests.CommonTestSequences

and ensures that both ROOM and CaGe of the respective variant can see the shared models.

Defining variant parameters in the common library

Next we define a small C struct that describes the properties which differ between variants. This struct is declared in the common library and defined in each variant project.

Create the header file inc/variantParameters.h in the CommonTestLibrary project:

#ifndef VARIANTPARAMETERS_H_
#define VARIANTPARAMETERS_H_

typedef struct VariantParameters {
    int   variantId;        // numerical ID used in logs/reports
    float nominalVoltage;   // expected supply voltage of the DUT (e.g. 12.0, 24.0)
    float currentLimitAmp;  // maximum allowed continuous current
} VariantParameters;

// Global instance provided by each variant project
extern VariantParameters vp;

#endif /* VARIANTPARAMETERS_H_ */

This header defines the interface for configuring the CommonTestLibrary:

  • all shared ROOM/CaGe code can include it

  • each variant will provide a concrete definition of vp in its own project

Providing variant parameters in each variant project

For each variant project, create a file src-user/variantParameters.c that initializes the vp instance with variant-specific values.

Example variantParameters.c in Variant A 
#include "variantParameters.h"

VariantParameters vp = {
    .variantId       = 1,
    .nominalVoltage  = 24.0f,
    .currentLimitAmp = 5.0f
};
Example variantParameters.c in Variant B 
#include "variantParameters.h"

VariantParameters vp = {
    .variantId       = 2,
    .nominalVoltage  = 48.0f,
    .currentLimitAmp = 3.0f
};

With this setup:

  • the common test library always uses vp as a single source of truth

  • each variant project provides its own configuration without changing the common code

Using variant parameters in ROOM/CaGe

The common test library can now use the variant parameters from:

  • C helper code, and

  • CaGe steps via embedded targetcode.

  • ROOM usercode blocks.

Including the header in CaGe targetcode

In a CaGe file in the common library, add the include in a targetcode block:

targetcode: ''
    // Includes or defines
    #include "variantParameters.h"
''

Example: configuring the DUT based on the variant

Assume there is a ROOM port dutCtrl that provides a message configureDUT(int variantId). A CaGe step that configures the DUT based on the current variant could look like this:

Step configureDUTForVariant:
    action
        dutCtrl.configureDUT(``vp.variantId``)
;

Here:

  • vp.variantId is inserted as plain C code

  • for Variant A, this translates to dutCtrl.configureDUT(1)

  • for Variant B, it becomes dutCtrl.configureDUT(2)

The CaGe step itself remains unchanged across all variants.

Summary

  • Create a common test library using the library template from the miniHIL library.

  • Configure each variant project to:

    • link the CommonTestLibrary via userLibraries in build.gradle

    • reference the common library in the ROOM model path (project CommonTestLibrary)

  • Define a VariantParameters struct and a global instance vp in variantParameters.h in the common library.

  • Implement variantParameters.c in each variant project to provide concrete values for vp.

  • Use vp in the common library to parameterize the shared logic in C code, ROOM, and CaGe:

    • e.g. configure the DUT for the correct variant

    • adapt limits, timings, and expectations per variant

  • Keep all test logic in the common library - only the configuration changes per variant.