Hardware and software interfaces are often still specified in prose and then translated manually into HDL, driver code, and documentation. That workflow creates avoidable gaps between hardware and software teams: names drift, addresses get copied twice, bit assignments are rechecked by hand, and documentation becomes outdated as soon as the interface evolves.
Why HxS Exists
HxS, short for Hardware x Software, was created to close that gap. The name reflects the central idea of the language: the interface is where hardware and software meet, and both sides need a shared, precise contract. Instead of treating the interface description as a document that engineers interpret differently, HxS treats it as an executable model of the hardware/software contract. You describe the interface once, and HxS generates the artifacts needed by hardware, software, and documentation workflows from the same source.
This idea grew out of years of practical work on real projects. Earlier generations of HxS already helped teams reduce development effort, improve quality, and adapt faster to requirement changes. The current language continues that direction with a concise textual syntax, namespaces for reusable libraries, inheritance, sensible defaults, and editor support for modern development environments.
What You Model In HxS
HxS is a declarative language for describing CPU-visible interfaces. Its core building blocks are easy to read: namespaces organize definitions, interfaces describe the top-level contract, blocks structure the register map, and registers contain fields such as data, enums, reserved areas, reset behavior, values, delegates, and selects.
The language is designed to reduce ceremony. Many properties have sensible defaults, and several values such as sizes, addresses, offsets, widths, and positions can be calculated automatically. That lets you focus on interface intent instead of repeating mechanical details.
namespace Demo.Interfaces
{
interface ControlInterface
{
Name = "Control Interface";
Description = "Simple control and status register map.";
Blocks = [ControlBlock];
}
block ControlBlock
{
Registers = [ControlRegister];
}
register ControlRegister
{
Address = 0x0;
Bits = [Enable, Mode];
}
data Enable
{
Width = 1;
}
data Mode
{
Width = 2;
}
}
What HxS Generates
From that single interface model, HxS can generate production-ready outputs for multiple target domains. Typical outputs include HDL for the hardware side, software access layers for languages such as C, Python, and Rust, and interface documentation in formats such as HTML, ReStructuredText, PDF, or Word.
The practical benefit is straightforward: when the interface changes, you update the HxS model and regenerate. Hardware, software, and documentation stay synchronized without manual copy-paste steps.
How The Language Helps
The HxS language is built around a few guiding ideas: reduce complexity, stay concise, support readability and reusability, and make documentation a first-class outcome instead of an afterthought. Namespaces and qualified names help organize larger libraries, annotations let generators be configured where needed, and inheritance supports reuse without duplication.
Because the language is intentionally declarative, HxS is especially useful when teams want a precise interface contract without mixing that contract with implementation-specific HDL logic or software boilerplate.
How To Use These Docs
This documentation is organized to move from concepts to details. Start with the language page for syntax and general rules, continue with the objects reference to understand the available interface building blocks and their properties, and use the annotations reference when you want to control generator-specific output.
If you are new to HxS, a good mental model is this: first define the interface contract, then refine individual objects, and finally add generator annotations only where your project needs them.