Release Notes

We are happy to announce Livt 1.0.0, the first stable release of our component-oriented programming language for digital hardware development.

Livt brings ideas such as clear interfaces, reusable packages, composition, and automated testing to FPGA and ASIC development while keeping state, timing, clock domains, concurrency, and resource use explicit.

Get Started with Livt

To use Livt, create an Eccelerators account or sign in to your existing account. Send us a message after registering, and we will help you get started with a trial license.

The easiest way to install Livt is through the Livt extension for Visual Studio Code. The extension guides you through installation and provides the tools needed to create, validate, build, test, and explore Livt projects directly from VS Code.

Explore the Documentation and Examples

Visit the Livt documentation to learn about the language, components, interfaces, processes, contexts, testing, packages, HxS integration, and application development.

Do not forget to explore the open resources, examples, and libraries available through the Eccelerators organization on GitHub. They are a useful starting point for discovering Livt projects and reusable hardware components.

Ask the Livt Agent

You can also ask the Livt Agent included with the VS Code extension. The agent can help you understand Livt, explore an existing project, create components and tests, find reusable packages, and work through compiler diagnostics. It uses the Livt development workflow to validate and test its work, while you remain in control of the design and final result.

The Beginning of a Stable Livt Line

Livt 1.0.0 establishes the foundation for the language, compiler, HDL generation, testing workflow, package ecosystem, documentation, and development tools.

From here, we will continue expanding the Livt base libraries with reusable components for common hardware-development tasks. We will also continue developing AI-assisted workflows that help engineers move from an idea to a structured, tested, and reviewable hardware implementation.

For longer-form background, personal perspectives, and thoughts about Livt, digital hardware development, and AI-assisted engineering, follow Denis Vasilík on Substack.

Have questions, want to try Livt, or would you like to discuss how it could fit into your project? Get in touch with us—we would be happy to hear from you.

HxS 1.0.19 is a focused correctness release for generated VHDL register interfaces. It resolves a naming inconsistency that could appear when an interface used interface-scoped signal names.

Consistent VHDL Output Naming

HxS correctly declared writable output ports with both their register and field names, but the final assignment could omit the register prefix. For example, a port declared as control_enable could be assigned through the non-existent target enable, causing the generated VHDL to fail compilation and requiring a manual correction.

-- HxS 1.0.19 keeps the declared port name and assignment aligned
control_enable <= wreg_enable;
control_duty_cycle <= wreg_duty_cycle;

Output assignments now follow the same naming scope as their port declarations. Register-qualified ports therefore retain their register prefix throughout the generated design, producing self-consistent VHDL that compiles without post-generation edits. Regression coverage protects this behavior across the supported Avalon, AXI4-Lite, and Wishbone interface variants.

HxS 1.0.19 is available from the downloads section.

Livt 0.0.10 is a major quality and integration release that resolves 83 tracked issues. It makes larger applications easier to express and verify, with substantial improvements to HxS register interfaces, numeric conversions, arrays, reusable helper functions, and interface-based component composition.

The release also broadens the range of valid Livt programs that build and simulate predictably, while reporting unsupported or ambiguous source earlier and more clearly.

Complete HxS Register Interfaces

HxS integration is the headline capability in 0.0.10. A Livt component can describe a memory-mapped interface directly on its public fields and functions, connect that interface through Livt.Bus, and test it through the same bus contract used by the surrounding system.

Default layouts are deterministic, while explicit blocks, addresses, reserved bits, selected views, delegated windows, enum metadata, values, and reset information are available when a design needs more control. Functions can act as command triggers, accept register-supplied parameters, and return readable values. AXI4-Lite, Avalon, and Wishbone designs use the same annotation model.

using Livt.HxS
using Livt.Bus.Axi4Lite

@Interface(BusType="AXI4Lite")
component DeviceControl
{
    public enabled: logic

    new(bus: flip IAxi4Lite32Master)
    {
        this.enabled = 0b0
    }

    @Register
    public fn Enable()
    {
        this.enabled = 0b1
    }
}

Read more in the Livt docs: HxS register interfaces.

Predictable Numeric Types and Conversions

Numeric intent is more consistent throughout expressions, comparisons, assignments, assertions, shifts, division, and modulo operations. Livt now applies one clear conversion model across bool, int, uint, byte, logic, and logic[N].

Safe widening remains concise, while conversions that can change meaning or lose information require an explicit as cast. High-bit unsigned values, fixed-width vectors, mixed numeric literals, and byte arithmetic now behave more consistently in both design code and tests.

var data: byte = 0xFF
var widened: int = data as int
var bits: logic[8] = data as logic[8]
var lowNibble: logic[4] = bits as logic[4]
var sum: int = 10 + widened

Read more in the Livt docs: data types, casts, and operators.

Stronger Array Literals and Parameters

Array-heavy components are easier to write and reuse. Array literals support a trailing comma, whole-array assignments are checked consistently, and inferred arrays preserve their required dimensions and element values. Unconstrained array parameters also expose dependable length information, which is particularly useful for reusable helpers that work with several fixed array sizes.

var header: byte[4] = [
    0x45,
    0x00,
    0x00,
    0x14,
]

assert header.Length() == 4

Read more in the Livt docs: arrays and dimensions.

More Dependable Reusable Helpers

Inline and context-free functions now cover more practical control-flow and mutation patterns. Helpers can use early returns, loops, shifts, compound assignments, output parameters, and array parameters more reliably. This makes it easier to keep small calculations and reusable data operations close to the components that use them.

fn Fill[](value: out int)
{
    value = 42
}

public fn ReadFilledValue() int
{
    var result: int
    this.Fill(result)
    return result
}

Read more in the Livt docs: functions and component behavior.

Interface-Based Systems at Larger Scale

Interface-oriented applications are more robust across constructor injection, public interface fields, bus endpoints, scheduled calls, and nested component boundaries. Concrete components can be handed to consumers through their interface contract without exposing implementation-specific behavior, and fully qualified type names can be used where larger projects need explicit namespace clarity.

These improvements are especially valuable for processor cores, bus-connected peripherals, protocol adapters, and other systems assembled from several reusable components.

Read more in the Livt docs: interfaces and composition.

Broader Project Reliability

Livt 0.0.10 verifies many more combinations of literals, conversions, array operations, helper functions, interfaces, contexts, and component wiring. Projects with nested configuration files also fail gracefully when they contain unsupported settings instead of disrupting the development environment.

Together, these changes make the everyday workflow more predictable: valid projects build and simulate across a wider range of real application patterns, and mistakes are surfaced closer to the source that needs attention.

Livt 0.0.10 is available from the downloads section.

Livt 0.0.9 is a reliability release for larger, more connected Livt designs. It resolves 32 tracked compiler issues and focuses on the patterns that matter once a project grows beyond a single component: inherited interfaces, constructor-based wiring, bidirectional endpoints, context-aware timing, named states, inline helpers, arithmetic expressions, and vendor project generation.

The result is a cleaner foundation for building reusable components, protocol controllers, and simulation-backed libraries.

More Reliable Interfaces and Constructor Wiring

Interface-heavy designs are much more dependable in 0.0.9. Components that implement a derived interface can now be used through a parent-interface reference, which makes inheritance useful for real component boundaries. Constructor wiring was strengthened for direct component-to-interface bindings, nested endpoint pass-through, public interface endpoint fields, and bidirectional interface leaves.

This is especially helpful for reusable bus-style components. A component can expose a public endpoint, pass it through a wrapper, or hand a concrete implementation to a consumer that only depends on the interface contract.

interface IBus
{
    observed: out logic
    drive: in logic
}

component BusProvider : IBus
{
}

component Consumer
{
    public ready: logic

    new(bus: flip IBus)
    {
        this.ready = bus.observed
        bus.drive = true
    }
}

Read more in the Livt docs: interfaces and composition.

Stronger State and Process Behavior

Named states and grouped state {} blocks received significant attention. Assignments before goto transitions are preserved, nested if / elif / else branches behave more predictably, local variables inside named states are initialized when their source line executes, and combinational process[] bodies can use local scratch variables without turning a simple process into an unintended multi-step behavior.

public start: bool
public counter: int

process Main()
{
    state Idle
    {
        if (this.start)
        {
            this.counter = 0
            goto Count
        }
    }

    state Count
    {
        var step: int = 0
        step++
        this.counter += step
    }
}

Read more in the Livt docs: control flow and component patterns.

Context Timing as a First-Class Design Idiom

Livt 0.0.9 introduces a clearer timing idiom around component contexts. Components can use their assigned context for timing decisions instead of hard-coded clock constants. The context exposes timing metadata such as ticks per second and period, and the canonical TicksFor(...) helper converts a duration into clock ticks for the component's active context.

component Timeout
{
    public fn TicksForOneMicrosecond() uint
    {
        return this.context.TicksFor(1us)
    }
}

This makes reusable components easier to configure: if a user assigns a different context, timing follows that context; if no context is assigned, the component uses its normal surrounding context.

Read more in the Livt docs: contexts, clock domains, and sync.

Better Arithmetic, Casts, and Helper Functions

Numeric behavior is more consistent across functions, assignments, and tests. Shifts on byte, int, and uint are covered in simple function bodies. Postfix increment and decrement work for supported parameters, variables, and fields. Scalar casts from int and uint to logic now use the low bit. Signed remainder follows signed arithmetic rules, and compound arithmetic assignments preserve the target width before storing the result.

fn Mix(value: int, flags: uint) logic
{
    var next = value++
    var wrapped = next % 3
    return (flags as logic) ^ (wrapped as logic)
}

Inline and context-free helper functions were also hardened, including void helper calls, array field element writes, array-return helpers, and helper calls used inside assertions.

Read more in the Livt docs: data types and operators and organizing code.

Endpoint and Bus-Style Components

Public interface endpoints now behave better when multiple leaves are written in the same step, when endpoint values are held across process iterations, and when a wrapper forwards an endpoint into a nested component. This directly supports component library work such as open-drain buses, protocol adapters, and small reusable I/O building blocks.

component BusCombiner
{
    public controller: IBus
    public target: IBus

    process Combine[]()
    {
        this.controller.observed = this.target.observed
        this.target.drive = this.controller.drive
    }
}

Read more in the Livt docs: interface composition.

Vendor Project Workflow

The vendor flow is more practical for Vivado-based projects. The generated wrapper now receives the full context information required by Livt components, and vendor templates can accept template-specific arguments. For Vivado templates, users can pass the target part directly on the command line and see a configuration overview before the vendor tool is launched.

livt vendor vivado-ip xc7a100tcsg324-1

Read more in the Livt docs: vendor integration.

Verification-Driven Quality

Quality is central to how we work, which is why verification is built into every release. Each fix adds focused tests and simulation coverage, making the language more stable with each release: valid programs build and simulate more reliably, while invalid programs fail earlier with clearer messages.

Livt 0.0.9 is available from the downloads section.

Livt 0.0.8 is a major quality release that resolves 124 tracked improvements and defects. It makes Livt projects easier to write, easier to review, and easier to validate before they reach board-level integration. The release sharpens diagnostics, broadens language coverage, and expands the simulation suite so common combinations of literals, function parameters, arrays, structural references, and directed interfaces are exercised more consistently.

Language Expressiveness

The language continues to move toward a more compact, software-like style for hardware descriptions. Logic and byte arrays support Python-style slicing, including omitted bounds and negative indices. foreach loops work for arrays and iterator components, with multi-cycle sequencing in process contexts. class, static fn, and inline fn provide clean namespaces and reusable helper functions without forcing every helper into a component instance.

var word: logic[8] = 0xA5
var upperNibble = word[4:8]
var lowerNibble = word[:4]

Read more in the Livt docs: data types, control flow, and organizing code.

Type Safety and Literals

Literal handling is now much stricter and more predictable. Decimal, binary, hexadecimal, boolean, string, time, and frequency literals are checked against their target types before a build continues. Out-of-range integer and unsigned values are rejected early, single-bit logic is distinguished from logic vectors, and state-bearing logic literals such as 0bZ, 0bU, and 0bX are preserved where they make sense. The same validation is applied consistently in variable initializers, constants, assignments, function calls, constructor calls, explicit casts, and array literals.

var valid: logic = 0b1
var unknown: logic = 0bX
var mask: logic[8] = 0bZZZ0_0000
var marker: byte = 0xFF

Read more in the Livt docs: data types and literals.

Portable Numeric Semantics

Livt defines int and uint as 32-bit types, and this release makes numeric intent more predictable across projects. Signed and unsigned arithmetic, conversions, boundary checks, sign-bit behavior, casts, overflow-sensitive literals, and bitwise masks on logic vectors were tightened so designs behave consistently across common development flows.

var signedCount: int = -1
var packetCount: uint = 0xffffffff
var value: logic[8] = 0xA5
var flags: logic[8] = value & 0x0F

Read more in the Livt docs: primitive types, casts, and operators.

Structural References and Interfaces

Component and interface values are now validated as structural references. A component-typed or interface-typed target must receive either a new Component(...) instance or an existing compatible reference. Livt intentionally has no built-in null value; absence or fallback behavior should be modeled with a real component that implements the required contract. Interface use is also clearer: constructors and processes are rejected in interfaces, process calls are rejected as expressions, override declarations must actually override something, and component construction must use new instead of function-call syntax.

reader: IByteReader

new()
{
    this.reader = new RomByteReader()
}

Read more in the Livt docs: interfaces and composition.

Directed Fields and Constructors

Directed fields now respect the effective receiver orientation. This matters for interfaces that can be used from both sides of a connection, especially when an interface reference is passed through constructors with a flipped parameter view. Livt checks whether a field can be read or written from the current orientation and keeps pass-through connections deterministic. Function calls also check argument direction and assignability for out parameters, so invalid call sites are reported before simulation.

interface IBus
{
    in valid: logic
    out ready: logic
}

slave: IBus

new(bus: flip IBus)
{
    this.slave = bus
}

Read more in the Livt docs: interfaces and component patterns.

Arrays and Vector Operations

Array behavior received another round of hardening. Unsupported arrays of complex types are rejected until their user-facing behavior is deliberately specified. Arithmetic on arrays is rejected with a direct diagnostic, scalar indexing gets a clear error, and Concat now requires known logic-vector widths. Livt can still infer concise declarations such as var a: logic[] = 0xAA and then compute the resulting width of a.Concat(b) when both operands are known.

var a: logic[] = 0xAA
var b: logic[] = 0x55
var c = a.Concat(b)

assert c.Length() == 16

Read more in the Livt docs: arrays and vector types.

Diagnostics and Validation

Many former hard-to-read failures are now friendly validation messages. Livt reports keywords used as identifiers, local variables that shadow callable parameters, parent field redeclarations, constructor-name field ambiguities, unsupported process return syntax, unsupported division on logic operands, and invalid use of component or interface type names as values. Type-related diagnostics were improved as well, so users see Livt concepts instead of implementation details.

fn Accumulate(value: int)
{
    // Invalid: the local variable shadows the parameter.
    var value = 0
}

Read more in the Livt docs: building blocks and control flow.

Project Quality and Verification

Everyday design workflows are more robust around loops, state blocks, component-local instantiation, array element assignment, subcomponent calls, byte-array parameters, boolean conditions, and same-name local component instances in independent functions. The verification suite now covers more function parameter combinations, literals, arrays, signed and unsigned arithmetic, structural calls, constructor wiring, and directed interface behavior. The result is a stronger workflow: more cases are checked early and exercised in simulation.

@Test
fn AddsUnsignedValues()
{
    var result = this.alu.Add(1 as uint, 2 as uint)
    assert result == 3
}

Read more in the Livt docs: testing Livt code.

Tooling and Project Workflow

Tooling also received practical polish. Build and test commands report elapsed time, simulator paths can be configured, release profiles can strip simulation helpers, warnings can be controlled per profile, and Vivado project templates now refresh source and simulation file order during project creation. Dependency handling is more predictable too, including local paths, transitive dependencies, same-namespace resolution, name collisions, and reserved identifiers.

[simulator]
path = "/opt/ghdl/bin/ghdl"

[build.release]
warnings = ["all", "no-variable-divisor"]

Read more in the Livt docs: vendor integration, packages and reuse, and CI/CD.

HxS 1.0.18 is a focused quality release for teams building and maintaining hardware/software register interfaces. It improves naming consistency, broadens bus-size support, and makes project results easier to review across common bus configurations.

More Predictable Register Naming

Register-scoped naming is now more consistent for projects that prefer explicit register prefixes. When register naming scope is enabled, fields keep the register prefix even in simple single-reference cases. This makes naming conventions easier to apply across small interfaces and larger register maps alike.

Clearer Reset Defaults

Reset default names now stay aligned with their register context. This helps avoid ambiguous names in interfaces that reuse similar field names across multiple registers, and it makes review of large interface descriptions more predictable.

Improved Bus Interface Support

Avalon users now get response-signal support throughout the HxS flow. The release also strengthens 64-bit and 128-bit bus access for Avalon, AXI4-Lite, and Wishbone configurations, including wider read and write checks.

Updated Verification Environment

The verification projects were refreshed for SimStm 2.0.4 and expanded with bus-size checks, including a 128-bit access test. This gives teams better confidence when using wider bus widths in production interfaces.

HxS 1.0.18 is available from the downloads section.

Livt 0.0.7 improves the everyday reliability of Livt projects across language features, type checking, component composition, loops, interfaces, and project testing. The release resolves more than 88 tracked issues and focuses on making common design patterns easier to express and easier to validate.

Language Features

Compound assignment operators (+=, -=, *=, /=) are now supported in function and process bodies. Array literals can be used directly as field and variable initializers, including nested arrays. const arrays can be declared with bracket-list initializers, initialized from string .Encode() calls, queried with .Length(), and read from function bodies. Cast expressions, string escape sequences, and uppercase or lowercase hexadecimal literals are handled more consistently.

Type Checking

Type checking is stricter and more predictable. Bitwise masks on byte, helper functions with byte[] parameters, subcomponent call arguments, Length() on constant arrays, and narrowing conversions now produce clearer behavior and diagnostics. When a conversion would lose information, Livt reports the problem instead of allowing an unsafe result.

Component Behavior

Component behavior is more reliable around computed arguments, mixed boolean expressions, constructor-time calls, array field updates, process state transitions, public stored fields, and multi-step subcomponent operations. These improvements make process and function behavior easier to reason about in tests and in larger component hierarchies.

Interfaces and Inheritance

Interface and inheritance support is stronger. Interface-typed function parameters, inherited component functions, interface inheritance chains, interface constants, and automatically provided interface fields now behave more consistently. Components can rely on inherited contracts without repeating declarations that already belong to the interface.

Control Flow and Loops

Loop behavior is clearer. for loop variable initializers run on every iteration, var declarations are scoped to their block, and continue advances to the next iteration instead of restarting the surrounding behavior.

Tooling

Test execution and project feedback are more dependable. livt.toml defines the active test components, dependency test runs include the required package context, and parser diagnostics for missing newlines or semicolons point to the specific token that needs attention.

Get ready to explore the latest release of HxS, version 1.0.17! Download it now and uncover a host of enhancements and bug fixes that promise an even smoother experience.

• Added Treat Warnings as Errors Compiler Flag
• Asynchronous BitBehaviour.Transparent and BitBehaviour.WriteTransparent
• Support Byte-wise Bus Access
• Fixed Overlapping Registers
• Fixed Asynchronous Bus Reset Initialization
• Fixed Parameter Syntax Validation
• Eclipse Plugin and VS Code Extension

Added Treat Warnings as Errors Compiler Flag

In this release, we have added the compiler option --treat-warnings-as-errors or in short -t. When this option is activated, all warnings are treated as errors. You can apply it as follows:

hxsc -t -o src-gen vhdl MyRegisterInterface.hxs

Asynchronous BitBehaviour.Transparent and BitBehaviour.WriteTransparent

As of now, it is permitted to use bit fields with BitBehaviour.Transparent or BitBehaviour.WriteTransparent together with asynchronous registers. Notably, even when the bit behaviour is set to transparent, the write cycle will be registered to ensure that the data reaches its block.

register MyRegister
{
    Async = true;
    Bits = [MyData];
    
    data MyData
    {
        BitBehaviour = BitBehaviour.Transparent;
    }
}

Support Byte-wise Bus Access

Until now, accessing the bus was constrained to addresses that were multiples of 4. With this release, all three bus interfaces — Avalon, AXI4-Lite, and Wishbone — now support byte-wise bus access.

Fixed Overlapping Registers

We encountered an issue with our automatic register address calculation. When there were, for example, three registers containing only a few bits each, they were incorrectly assigned to the same address. In the following example, MyRegister0, MyRegister1, and MyRegister2 would all have been assigned to address 0x0.

block MyBlock
{
    Registers = [
        MyRegister0,
        MyRegister1,
        MyRegister2
    ];

    register MyRegister0
    {
        Width = 3;
    }
    
    register MyRegister1
    {
        Width = 9;
    }
    
    register MyRegister2
    {
        Width = 8;
    }
}

This behavior was counter-intuitive and has been fixed. Now, registers are padded to the next byte boundary, ensuring that each subsequent register starts at the next available address. For example, with the registers mentioned above, MyRegister0 starts at 0x0, MyRegister1 starts at 0x1, and MyRegister2 starts at 0x3.

Fixed Asynchronous Bus Reset Initialization

We previously missed initializing signals in the asynchronous domain, resulting in undefined signals during simulation. This issue has been addressed. Now, all signals are properly initialized and set to specific values.

Fixed Parameter Syntax Validation

There was an error in the validation process of the parameter syntax used to override properties of existing HxS objects, such as the register in the following example. This validation error prevented the overriding of properties like the Bits property, which expects lists.

block MyBlock
{
    Registers = [
        MyRegister(Bits=[MyData0]),
        MyRegister(Bits=[MyData1])
    ];

    register MyRegister {}

    data MyData0
    {
        Width = 8;
    }
    
    data MyData1
    {
        Width = 24;
    }
}

This issue has been fixed, and the parameter syntax can now be used to override lists as well.

Eclipse Plugin and VS Code Extension

With every release, we ensure the HxS Eclipse plugin and VS Code extension are up-to-date. You can find both IDE integrations ready for download here.

Great news for HxS developers: We are releasing version 1.0.16. In our ongoing commitment to security, we regularly maintain and update our dependencies. With this release, we are ensuring a robust and secure user experience. Please be aware that starting from this release, Java 17 or higher is a requirement.

In addition, we have dedicated efforts to enhance VHDL code integrity, systematically addressing syntax issues of the generated files. HxS 1.0.16 is now available in our download section.

Exciting news for HxS users: version 1.0.15 is here! This release focuses on improving VHDL code integrity, effectively fixing syntax issues across various HxS configurations. Explore these improvements — HxS 1.0.15 is now ready for you in our download section.

We are excited to unveil the newest iteration of HxS. This release brings enhancements to VHDL code's quality, addressing and fixing potential syntax errors in various HxS code configurations. Experience the improvements firsthand — HxS 1.0.14 is now available in our download section.

Get ready to explore the latest release of HxS, version 1.0.13! Download it now and uncover a host of enhancements and bug fixes that promise an even smoother experience.

• References and Scope Enhancements
• Set Default Data Bus Width to 32
• Auto-Calculation of Address Bus Width
• Derive Alignment from Data Bus Width
• Fixed Asynchronous Read-Only / Write-Only Register Bug
• Eclipse Plugin and VS Code Extension

References and Scope Enhancements

Now, you can refer to objects from the same or outer scopes without the need for their fully qualified names. When looking up a reference, the first object found is used, starting from the reference's scope and going up to the outer scope.

interface MyInterface
{
    block MyBlock
    {
        Registers = [MyRegister];

        register MyRegister {} // Hides MyRegister of outer scope
    }

    register MyRegister {} // Is hidden for MyBlock.Registers
}

This makes the code cleaner and more concise, as it is possible to reference objects directly without specifying their full paths each time.

Set Default Data Bus Width to 32

In this update, we have introduced a breaking change by transitioning the default data bus width from 8 to 32 bits. This modification may require adjustments in existing HxS descriptions.

interface MyInterface
{
    DataBusWidth = 32; // Defaults to 32-bits and can be left out
}

Auto-Calculation of Address Bus Width

In our continuous pursuit of user comfort, we have introduced an automated calculation for the Interface.AddressBusWidth property. Now, if no specific value is provided, it derives the value from the blocks, eliminating the need for manual adjustments.

interface MyInterface
{
    AddressBusWidth = 8; // Is calculated and can be left out
}

Derive Alignment from Data Bus Width

The Alignment property of the Block object now determines the address alignment of contiguous registers in bytes by deriving its value from the DataBusWidth property of the associated Interface object. Given the default DataBusWidth of 32-bits, the alignment's default value is set to 4 bytes.

interface MyInterface
{
    DataBusWidth = 32;
}

block MyBlock
{
    Alignment = 4; // Is calculated and can be left out
    Registers = [
        MyRegister0,
        MyRegister1,
        MyRegister2
    ]
}

Fixed Asynchronous Read-Only / Write-Only Register Bug

Previously, defining a register as asynchronous with exclusively readable or writable bit fields could inadvertently trigger the generation of corresponding read or write parts using properties like ReadAckDelay or WriteAckDelay. This resulted in incorrect register interface behavior. We've addressed this issue, ensuring proper functionality, and now provide clear information that such properties have no effect and will be ignored.

register MyRegister
{
    Async = true;
    ReadAckDelay = 3;
    WriteAckDelay = 3; // Ignored
    Bits = [MyData];
}

data MyData
{
    Width = 32;
    Behaviour = BitBehaviour.Constant;
}

Eclipse Plugin and VS Code Extension

With every release, we ensure the HxS Eclipse plugin and VS Code extension are up-to-date. You can find both IDE integrations ready for download here.

We are excited to unveil HxS 1.0.12. It is now available for download. Discover a range of exciting new features such as AXI4-Lite support and improvements for IP-XACT.

• AXI4-Lite
• IP-XACT VHDL Wrapper
• Bus Reset Objects
• SPI Controller Example
• Eclipse Plugin and VS Code Extension

AXI4-Lite

After months of development and verification we added our third bus interface AXI4-Lite. Setting the BusType property of an interface to BusType.AXI4Lite is enough to create an AXI4-Lite register interface.

interface MyInterface
{
    BusType = BusType.AXI4Lite;
}

An AXI4-Lite HxS example can be found at the playground.

IP-XACT VHDL Wrapper

We always strive to reduce complexity and to keep tedious work away from developers. Therefore, we introduced the vhdl.ipxact.wrapper annotation. It instructs the VHDL generater to create a VHDL entity without any records for use by IP-XACT. The annotation is part of an interface object and can be used as follows.

interface MyInterface
{
    @Generator('vhdl.ipxact.wrapper', 'true')
}

Bus Reset Objects

We added the following bus reset objects to the HxS Base Library:

• BusReset.None - Bit field is not affected by bus reset
• BusReset.Sync - Bit field is affected by synchronous bus reset
• BusReset.Async - Bit field is affected by asynchronous bus reset

data MyData
{
    Width = 4;
    Resets = [
        BusReset.None,
        MySoftReset0,
        MySoftReset1
    ];
}

The dictionary syntax can be used as well. It enhances the readability if multiple resets are defined. Here is an example:

data MyData
{
    Width = 4;
    Resets = {
        0xU : BusReset.None,
        0x5 : MySoftReset0,
        0xF : MySoftReset1
    };
}

Further information about the reset behaviour can be found in the documentation of the data and enum objects.

SPI Controller Example

In addition to the smaller examples at the playground, we continuously add practical examples to our the publicly available repository at GitHub. This time we added a SPI controller example, which shows advanced features of HxS.

Eclipse Plugin and VS Code Extension

We update the HxS Eclipse plugin and VS Code extension with each release. Both IDE integrations are available at the download section.

Great news! HxS 1.0.11 is now available for download. Discover a range of exciting new features and improvements.

• Added IP-XACT Extension
• Added Annotation for Identifier Customization
• Added a Playground
• Added Example Projects on GitHub
• Fixed Synchronous Registers with Asynchronous Properties

Added IP-XACT Extension

In order to improve our efforts for making HxS even more useful we added the IP-XACT extension. It can be used as follows:

hxsc -o src-gen ipxact src/MyInterface.hxs

The IP-XACT extension supports the standards spirit._1685_2009, and accellera._1685_2014. By default, the extension generates IP-XACT files compliant to the accellera._1685_2014 standard. It can be changed using an annotation for the interface.

interface MyInterface
{
    @Generator('ipxact.standard', 'spirit._1685_2009')
}

We are eager to improve the IP-XACT extension with each future release, so if you have any ideas how we might improve let us know.

Added Annotation for Identifier Customization

The VHDL, Python and C generators support the {vhdl, python, c}.naming.scope annotation to influence the creation of identifers. By default, generators create identifiers that are unique and short in length. Depending on the use case, it might be necessary to customize the creation of identifers. The annotation can be used as follows:

interface MyInterface
{
    @Generator('vhdl.naming.scope', 'interface')
    Blocks = [MyBlock];
}

block MyBlock
{
    Registers = [MyRegister];
}

register MyRegister
{
    Bits = [MyData];
}

data MyData
{
    Width = 8;
}

The example above will create the following identifiers for the VHDL package. The parts that are bold are influenced by the annotation.

    constant MYINTERFACE_MYBLOCK_BASE_ADDRESS : std_logic_vector(31 downto 0) := x"00000000";
    constant MYINTERFACE_MYBLOCK_SIZE : std_logic_vector(31 downto 0) := x"00000001";

    constant MYINTERFACE_MYBLOCK_MYREGISTER_WIDTH : integer := 8;
    constant MYINTERFACE_MYBLOCK_MYREGISTER_ADDRESS : std_logic_vector(31 downto 0) := std_logic_vector(x"00000000" + unsigned(MYINTERFACE_MYBLOCK_BASE_ADDRESS));

    constant MYINTERFACE_MYBLOCK_MYREGISTER_MYDATA_MASK : std_logic_vector(7 downto 0) := x"FF";
                

Using the interface scope will create the longest identifers, but ensures uniqueness. Further details and examples can be found in the documentation.

Added a Playground

In order to get to know HxS and its capabilities, we have created a playground that shows small examples of register interfaces and their corresponding HxS compiler output. The playground can be found here.

Example Projects on GitHub

In addition to our playground that provides small examples for learning purposes, we continuously work on repositories on GitHub offering practical examples.

• Interrupt Controller
• SPI Controller
• Double Buffer Controller
• Event Catcher

Fixed Synchronous Registers with Asynchronous Properties

If a register has been defined as synchronous, but has asynchronous properties like AsyncClk, AsyncRst, ReadAckDelay or WriteAckDelay, the generator has not ignored them. This lead to invalid VHDL code and has been fixed in this release. In addition, a warning is shown in case a register mixes synchronous and asynchronous properties.

register MyRegister
{
    Async = false; // Default value
    AsyncClk = "MyAsyncClkSignalName"; // Is ignored, because Async = false
    AsyncRst = "MyAsyncRstSignalName"; // Is ignored, because Async = false
    ReadAckDelay = 3; // Is ignored, because Async = false
    WriteAckDelay = 3; // Is ignored, because Async = false
}