Crate Simulator#

The Legacy API implemented an “offline” mode. This mode populated the global data structures with some predefined module types. The API calls checked whether or not the global “offline” variable was set. Offline mode caused most of the API calls return a successful execution without executing any additional code. The mode didn’t allow for tests of the underlying API functionality. I.e. did the function behave as expected? While this was useful for integration, it didn’t allow more comprehensive testing.

The Pixie SDK includes a crate simulation framework that replaces the concept of an offline mode. Simulated crates behave like a physical crate. You can boot it, set/get parameters, start data runs, load firmware, etc. For example, if you attempt to setup a system with more than one crate leader (ex. MODULE_CSRB=81 for more than one module), then the simulation will return an error.

There are limitations to the simulation. It doesn’t produce any data. So, you can’t actually “read” out histograms after starting an MCA run. It doesn’t simulate any EEPROM data handling. The fixtures and daughter boards receive only passing simulation. You can load firmware into the crate but it’s not used for anything.

We’ve been adding functionality as needed. Some use-cases include, but are not limited to,

  • Validating a settings file before importing it to a physical crate.

  • Developing integrations with the SDK in the absence of a physical system.

  • Writing integration and unit tests to test the SDK functionality.

Users can access the simulation framework from the C API using Pixie16InitSystem(). The simulation uses a fixed set of modules in this mode.

To see the simulation in action you can execute the pixie_sdk_integration_test_runner program. This sets up a simulated crate and then executes a series of tests to verify that the parameter to variable conversions are happening as expected for each module type.