Is this page helpful?

HSL and UDDF Overview#

The Unified Device Driver Framework (UDDF) is a framework for writing user-mode drivers to control camera hardware. UDDF has the following goals:

  • Enable NVIDIA partners 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.

  • Support multiple camera topologies (GMSL and CoE).

NVIDIA’s SIPL camera API uses UDDF to control camera hardware, but UDDF does not depend on SIPL definitions. The SIPL component that directly interacts with UDDF is called the camera HAL.

UDDF drivers communicate with hardware primarily through Hardware Sequence Language (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).

Using HSL in UDDF describes both approaches in detail.

UDDF Basics#

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 form the UDDF Device Driver Interfaces (DDI). For example, a camera module driver object exposes interfaces for initialization, streaming control, sensor programming, and so forth. In contrast, a deserializer driver object exposes interfaces for initialization, link control, and the like.

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 (using 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 entrypoint called uddf_discover_drivers. This entrypoint describes the different types of driver objects that can be created by this library, and provides factory methods for creating them.

HSL Basics#

HSL is a way to represent hardware operations. It defines operations on I2C busses such as write() and poll(). HSL’s standard source language is called 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—for example, if 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 Programmer Guide.

UDDF/HSL Integration#

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

For details on these integration features, refer to Using HSL in UDDF.