Pixie-16 Omnitool#

Warning

The Pixie-16 Omnitool is designed with XIA staff in mind. It’s not intended to meet any specific external needs or use-case. XIA support staff may direct customers to use this program as part of their diagnosis of a technical support ticket. All other uses come at the user’s own risk, and XIA will not be held liable for any damage done to the user’s environment, system, or hardware.

The Legacy C API was too permissive. Users were able to access low-level functionality and work with the hardware in the same way as our internal teams. Such a model creates situations that prevent long term maintenance, and could break user code when we update the hardware. The Pixie SDK resolves this problem, but creates a new one. The C API is too restrictive for hardware development or quality control. Both of these situations need access to specialized functionality, which should not be exposed in a user API.

The Pixie-16 hardware continues to evolve. The assemblies now contain a motherboard plus 4 daughter cards. The new design creates additional complexity when working with the hardware. The modules are no longer a single unit, but a composite object. Traditional workflows involved updating the software in lockstep with the hardware. This process starts to breakdown when one component of the hardware may change, but others remain the same.

The challenge was to create a tool that allowed quick, developer level access to both the software and the hardware. The tool needs to be general enough to work new hardware as well as old.

The Pixie-16 omnitool is an evolving, generalized command-line tool for working with the Pixie-16 hardware. The tool provides low-level register access, as well as high-level quality control routines. Omnitool provides access to the crate simulation framework, which allows for its usage as a software diagnostic in the absense of hardware. This document details the general design of the program, and some of its basic usage.

Core Features

  • scripting support to allow harmonized QA and development efforts

  • access to the SDK’s crate simulation framework to work in the absense of hardware

  • direct hardware register access