HSL and UDDF Overview#

This page provides an overview of two key technologies in the Camera drivers framework:

  • Unified Device Driver Framework (UDDF): A standardized approach for developing user-mode device drivers to control camera hardware.

  • Hardware Sequence Language (HSL): A framework for specifying sequences of hardware accesses.

UDDF drivers communicate with hardware primarily through HSL. HSL is a simple language for specifying I2C and GPIO hardware accesses.

Drivers can use HSL in two ways:

  • They can send precompiled HSL sequences directly to hardware.

  • They can create HSL sequences on the fly (and send them to hardware).

Both approaches are described in detail in Guide to Writing UDDF Drivers.

The SIPL API framework uses UDDF to control camera hardware, but UDDF does not depend on SIPL definitions. You can find details about the integration of SIPL with UDDF in Integrating UDDF Drivers with SIPL.

Unified Device Driver Framework (UDDF)#

What Is UDDF?#

The Unified Device Driver Framework (UDDF) is NVIDIA’s standardized approach for developing device drivers in the camera and multimedia domain. It provides a consistent interface for hardware abstraction, driver discovery, and runtime management.

UDDF is based on the concepts of objects and interfaces. A driver object represents a particular piece of hardware, such as a camera module or a CoE bridge chip. Each driver object exposes a set of interfaces (declared as pure virtual C++ classes) to provide functionality. These interfaces are known collectively as the UDDF Device Driver Interfaces (DDI).

A driver object exposes interfaces that provide the functionality of that hardware. For example, a camera module driver object would expose interfaces for initialization, streaming control, sensor programming, and so forth. In contrast, a deserializer driver object would expose interfaces for initialization, link control, and so forth.

In addition to the DDI interfaces, UDDF defines another set of interfaces: Camera Driver Interfaces (CDI). These are interfaces used by driver code to carry out their tasks. The most important interfaces allow drivers to program hardware (via HSL, as mentioned earlier). Other interfaces provide services such as logging.

UDDF driver objects are packaged into UDDF libraries. A UDDF library is a shared library that exposes a single entry point named uddf_discover_drivers. This entry point describes the various types of driver objects that can be created by this library, and provides factory methods for creating them.

Design Goals#

UDDF is designed to do the following:

  • Enable NVIDIA partners and third parties to develop high-quality, safety-certifiable drivers.

  • Simplify driver development with minimal, clearly-defined interfaces that minimize driver responsibilities.

  • Allow driver developers to focus on sequences of hardware operations rather than driver infrastructure.

  • Provide a unified interface for various types of streaming camera and transport devices.

  • Support multiple camera topologies (such as CoE, MIPI, and GMSL).

Hardware Sequence Language (HSL)#

What Is HSL?#

Hardware Sequence Language (HSL) is a way to represent hardware operations. It defines operations on I2C buses such as write() and poll(). The standard source language for HSL is named PyHSL; it generates HSL bytecode, a compact binary format containing HSL operations.

HSL is a very simple language. It has no flow control or computation abilities. An HSL sequence is executed linearly from start to finish. The only exception to this model is when an instruction fails, such as a poll times out or an I2C transaction fails. In this case, the entire sequence terminates with a failure.

To learn more about HSL, refer to PyHSL.

UDDF and HSL Integration#

UDDF drivers communicate with hardware primarily through HSL:

  • Static Sequences: Drivers can send precompiled HSL bytecode sequences directly to hardware.

  • Dynamic Sequences: Drivers can create HSL sequences on the fly and execute them.

UDDF has strong support for HSL, both in the toolchain and at runtime. It’s easy to write HSL sequences in PyHSL and then use HSL tools to put the resulting bytecode into C++ header files that the driver can include. The bytecode sequences can then be submitted at runtime.

The driver can also generate bytecode sequences at runtime for additional flexibility.

You can find details about these integration features in Guide to Writing UDDF Drivers.

FAQs#

  • Does use of HSL require Python to be used at runtime?

    No. Python is needed only for PyHSL, which is used to compile HSL sequences offline. The bytecode for those sequences can be built into drivers. Python is never invoked at runtime.

  • If we have PyHSL, why do we need to dynamically generate HSL in the driver? For that matter, why do we have C++ drivers at all? Why not just a set of precompiled HSL sequences?

    Because HSL is a simple language. An HSL sequence cannot behave conditionally, nor can it perform any other type of computation. If you want your driver to behave differently based on hardware revision (or any other variation in hardware), you need logic outside of any HSL sequence. Same if you need to write different values based on configuration settings. HSL is an efficient, easy-to-analyze encoding of specific hardware accesses, and nothing more. So it’s quite possible that at least some of your driver entry points will need to dynamically generate sequences, or at least choose from various sequences that were generated from PyHSL.