Agentic AI has quickly become a dominant workflow. Give an LLM access to the filesystem and shell, provide it good instructions, and watch it work! It’s that second part that is critical to making the process scalable. LLMs are quite happy to fill in the gaps where instructions are incomplete. Agent Skills help make agentic workflows repeatable and consistent.

Reusable is a great start, but making them context-specific – scoped – is just as important. The skills to which an agent has access should be determined by what the current project actually uses. This post argues that the best way to do this is to deliver skills along with the artifacts that they describe.

Agent Skills in one minute

If you’re already familiar with Agent Skills, skip ahead. If not, the concept is straightforward: a skill is a directory containing a SKILL.md file – a chunk of Markdown with a little YAML frontmatter that gives the skill a name and a description – plus any optional scripts or reference files it needs. The Agent Skills specification and Anthropic’s skills repository are good places to see the shape of them.

Skills solve two problems:

• Discoverability. The agent can see, from a short description, that a capability exists without you having to remember to paste in the relevant instructions every time.
• Progressive disclosure. When an agent loads skills, it only reads the description into the context initially. It only reads more of the skill files if and when it decides that the skill is relevant to the task at hand.

Where skills come from today

Most AI assistants – Claude Code, Codex, and others – let you configure skills through the filesystem or through tool commands, with both directory-specific and global scopes supported. The default tends to be global.

The interactive path to acquiring skills is a marketplace. Several have emerged and they’re growing quickly.

One challenge with the marketplace is that installation and curation are human-driven: you browse a catalog, decide you want a capability, and install it. This makes it available in whichever scope(s) you installed it. But, that either entails having all skills installed always or remembering to install skills whenever you start a create a new workspace.

Skills should travel with the artifact

The person best positioned to write “how to use X” is the author of X. And the most-natural vehicle for shipping that knowledge is X’s own package. This ensures that the skill matches the installed version of X, and gets updated along with the package.

For example:

• A Verilog/RTL IP block can ship a skill that teaches an agent how to wire it up and drive it.
• A verification IP can ship a skill describing how to instantiate it in a testbench.
• A Python package can deliver a skill the same way it delivers any other packaged resource.

In each case the author of the artifact is the author of the skill, and the two stay in sync because they live in the same package. Contrast that with a marketplace listing: standalone, general-purpose, and free to drift out of sync with the thing it describes. When the IP gains a new port or the API changes, the skill that shipped alongside it changes too. A separately curated catalog entry has no such guarantee.

Having skills travel with the artifact provides us a new possibility: to create a project-scoped set of skills that cater to the needs of an engineer developing that project. No need to remember to install skills after setting up a workspace. No potential confusion from skills from a dependency that isn’t relevant to your project.

IVPM: project-specific skillsets

That’s where IVPM comes in. The Integrated View Package Manager’s mission is to fetch a project’s dependencies and integrate the relevant content into project-specific views. For example, a project-local Python virtual environment containing the project’s Python dependencies. IVPM does the same for agent skills: it gathers the skills delivered by a project’s dependencies and links them into the appropriate directory-local assistant configuration.

IVPM discovers skills through four mechanisms, applied in priority order:

1. Consumer-specified paths. The dependency entry in your ivpm.yaml can name a glob (e.g. skills/**/SKILL.md) telling IVPM where the skills live.
2. Package-declared paths. A dependency can advertise its own skill locations via with.agents.skills in its ivpm.yaml.
3. Auto-probe. Absent any declaration, IVPM looks for a SKILL.md at the package root and searches a skills/ directory. Most packages need no configuration at all because of this.
4. Python entry points. For installed Python packages, IVPM queries the agent.skills entry-point group, so a package can register its skills programmatically. (A legacy ivpm.skill group is still accepted for backward compatibility.) Each entry point is a callable that returns a path – or list of paths – to directories containing a SKILL.md.

Once discovered, the skills are linked into your project’s configuration directories. IVPM always populates .agents/skills/ – the toolchain-neutral layout that any skills-aware agent can read – and, when you ask for it, also mirrors into .claude/skills/ so Claude Code picks them up automatically. Links are relative when the target lives inside the project tree and absolute otherwise, with a directory copy as a fallback on platforms that don’t support symlinks. Stale links from previous runs are cleaned up on each update.

The only opt-in is a short block in your project’s ivpm.yaml:

package:
  with:
    agents:
      claude: true   # also mirror skills into .claude/skills/

A worked example

You can find a runnable example in the IVPM repository: examples/agent-skills.

The project depends on three pre-built EDA tools fetched as binary releases from the EDAPack feed – yosys (RTL synthesis), verilator (simulation), and nextpnr (FPGA place-and-route). Each of those release tarballs bundles its agent skills under a skills/ directory, so IVPM auto-discovers them with no extra configuration. The project’s ivpm.yaml does nothing more than list the dependencies and flip on the Claude mirror shown above.

Run a single command:

ivpm update

IVPM fetches the tool binaries and, in the same step, links every discovered skill into the project:

.claude/skills/
├── yosys-bin-yosys     -> ../../packages/yosys-bin/skills/yosys
├── yosys-bin-sby       -> ../../packages/yosys-bin/skills/sby
├── yosys-bin-sv2v      -> ../../packages/yosys-bin/skills/sv2v
├── verilator-verilator -> ../../packages/verilator/skills/verilator
└── nextpnr-bin-nextpnr -> ../../packages/nextpnr-bin/skills/nextpnr

Now open your agent in that directory and ask:

Simulate the blink design and testbench in Verilator, using available skills. Then synthesize the design targeting ecp5 using yosys and nextpnr.

The agent already knows the synth_ecp5 flow, because the skill that explains it shipped with the synthesis binary. Nothing was hand-curated, and no global catalog was browsed. One ivpm update delivered both the toolchain and the know-how to drive it – and the capability tracked the dependency graph exactly.

Conclusions and next steps

Skills are most useful when they’re scoped to what a project actually uses, and the package manager is the right place to do that scoping. By treating skills as artifacts that travel with the artifacts that they describe, you get a project-specific skillset that’s assembled automatically, stays in sync with its sources, and disappears when its dependency does. No catalog to browse, nothing to remember to install.

If you maintain an artifact that others integrate – an IP block, a tool, a library – consider shipping a skill alongside it. You’re the person best positioned to write it, and a skills/ directory is a small thing to add. And if you’d like to try the consuming side, the agent-skills example is a good place to start.

References

• Agent Skills Specification
• Anthropic Skills repository
• Claude Code Plugins
• IVPM
• IVPM Agents Handler
• IVPM agent-skills example

I first learned about direnv from a colleague a little over a year ago.
Initially, I was a bit skeptical because it inverts the typical approach to environment management. Typically, the environment is a session property that persists as the user navigates around the filesystem. direnv treats the environment as a property of the project directory tree. Instead of needing to remember to source a setup file before doing work in a project, the mere act of entering the project directory causes the environment to be configured.

Now, if you’re like me, this initially seems a big odd. And, you might ask if this slows everything down. The good news is that it’s quite fast and, at least for me, it begins to feel ergonomic very quickly.

How does it work?

direnv has three key components:

• .envrc files to configure the environment.
• A lightweight executable, written in Go, to process .envrc files
• A shell alias to ensure direnv runs to configure the environment

.envrc files and the stdlib

.envrc files contain the statements and directives that configure the environment. These files accept bash syntax, providing access to standard control-flow statements. This also enables direnv to work cooperatively with other environment-management tools, such as Environment Modules. Environment modules is quite popular in silicon engineering environments because it provides elegant support for managing multiple versions of a tool. For example, you might load version 5.046 of Verilator using the following command:

module load verilator/5.046

If your environment uses Environment Modules, you can add these same statements to your .envrc file and direnv will configure the proper tool versions in your environment.

In addition to using standard shell syntax to configure environment variables, Direnv provides a standard library of helpful functions. For example, the PATH_add stdlib function adds a directory to the PATH variable:

PATH_add scripts

Shell Alias

Direnv needs to know when the working directory changes so it can update the environment if required. This is done by evaluating direnv’s hook subcommand. In bash, this looks like this:

% eval "$(direnv hook bash)"

Direnv supports a wide variety of shells, including bash, zsh, and tcsh. Add the appropriate statement to your shell’s startup script and direnv will ensure that your environment is properly set whenever you’re within a directory structure containing an .envrc file.

IVPM Support

The Integrated-View Package Manager (IVPM) fetches dependent packages for a project and assembles unified views of those dependencies – and environment variables are a critical view. IVPM creates packages/packages.envrc with variable settings for the project and loaded dependencies. Here is a sampling of what it does:

• Set IVPM_PACKAGES to point to the root deps-dir
• Add the Python virtual environment to the PATH
• Load envrc files from dependencies

This last item is particularly relevant when it comes to open-source EDA tools provided by the EDAPack project. These projects provide export.envrc files that IVPM incorporates into the master packages.envrc file. Doing so ensures that the loaded tools are automatically available in when working in the project tree.

Using the generated envrc file is simple as well. Just add the following to the project .envrc file:

if [ -d packages ]; then
  source_env packages/packages.envrc
fi

Conclusions and Next Steps

The direnv provides a project-centric approach to environment management that ensures that your environment is always properly configured according to your working directory. IVPM assembles a unified view of the environment variables that should be configured based on the dependent projects it has loaded. Together, these two tools provide an easy approach to project environment configuration.

AI has been a hot topic recently, with engineers increasingly using an AI assistant like Claude or Codex to automate their work. Next time we’ll look at how IVPM configures project-specific context data for AI assistants to use.

References

• direnv
• EDAPack
• IVPM

Problem and opportunity

How do you normally install software? While there are many possible paths, a common path is to install new software using your operating system’s package manager. Most Linux variants use something like apt or yum. macOS and Windows have App Stores. These built-in package managers are great for obtaining widely-used, stable software packages. They’re not as great for niche software, software that changes frequently, or software where multiple versions are simultaneously in use. Open-source EDA software, for example.

There are projects that distribute bundles of pre-built open-source EDA software, such as Tabby CAD, or create Docker images with pre-built software. These are great if they supply all the tools and tool versions that you need, and supports the Linux version that you’re using. But, often we only need one or two tools.

One substantial challenge with EDA software is that the community is small enough that it’s not feasible to independently support each Linux distribution with pre-built packages. But, at the same time, Linux distributions are sufficiently different that a single binary can’t support all relevant distributions.

Python and manylinux

As it so happens, the Python ecosystem has developed quite an elegant solution to this problem. Using native-compiled extension code is a key technique to increase Python performance. Obtaining these binary wheels in pre-built form simplifies package installation and avoids users running into compilation errors due to missing development libraries and toolchains.

But, how to ensure broad compatibility across platforms? They key is to build native-compiled code on a platform with the same characteristics as the target platform. The Python Packaging Authority (ppya) defines a set of Docker images https://github.com/pypa/manylinux for just this purpose. Each are based on a specific Linux distribution, and specify a set of compatible Linux distributions. A key benefit of using these images vs just using the base Docker image is that the pypa project keeps manylinux images updated with recent versions of tools such as compilers and Python interpreters. While the software you build with a manylinux image may be compatible with an older Linux distribution versions, you aren’t locked into the old development tools that shipped with that distribution version.

EDAPack - Multi-Platform OSS EDA Binaries

The EDAPack project borrows the Python manylinux infrastructure to build open-source EDA tool binaries that support multiple Linux platforms. In cases where an open-source EDA tool benefits from associated packages, EDAPack includes those as well. For example, the EDAPack release of the Yosys synthesis engine includes associated tools for equivalency checking (eqy), formal verification (sby), and includes the yosys-slang plug-in that supports a broader set of SystemVerilog constructs.

Managing Installed Tools with IVPM

It’s great to have access to pre-built binaries, but downloading and managing multiple versions of tools is cumbersome. Fortunately, we can use IVPM to simplify the setup process even further. IVPM approaches this by having each project capture their dependencies – including tools – in a YAML file named ivpm.yaml. In the case of using packages from EDAPack, a project specifies the dependency source as gh-rls (Github Release).

package:
  name: ivpm-fusesoc-example-registry

  dep-sets:
  - name: default
    deps:
    - name: iverilog
      src: gh-rls
      url: https://github.com/edapack/iverilog-bin
      cache: true

When we fetch the project’s dependencies, we get tools as well. To save both time and disk space, we’ve marked our tools packages as being cached. This means that all projects that use the same version of a given tool simply link to a single installation in IVPM’s cache directory.

The obvious win here is that anyone wanting to a given project can very quickly gather the open-source tools required in order to use the project. But, beyond that, the project creator can pin tools to specific version to reduce issues due to using different tool versions. In addition, it’s easy to different projects to require and use different tool versions. IVPM’s cache holds the total set of active tool versions, and each project holds links to the specific required versions.

Conclusions and Next Steps

The EDAPack organization hosts a growing collection of projects that build and release open-source EDA software. Most packages focus on supporting x86 Linux via the manylinux build system. IVPM supports fetching tools and other artifacts from Github Releases, making it easy to load and configure the precise set of tools and tool versions required by any project managed with IVPM.

Feel free to reach out if you’d like to contribute a new open-source EDA tool to the EDAPack collection or add support for a new platform to a supported EDA tool.

Next time we’ll look at direnv, my new favorite tool for project-centric environment management and see how IVPM integrates.

Video

Increasingly, topics on the blog benefit from a demo. I’m experimenting with recording companion videos that provide space for this.

References

• Tabby CAD
• EDAPack
• IVPM

Dependencies in DV Projects

Design and verification projects are unique in the diversity of their dependencies. Mono-language projects tend to have package-management tools focused on the unique aspects of that programming language – for example, Python has pypi and pip/uv. In contrast, design and verification projects tend to leverage artifacts in multiple languages from a variety of sources. You’ll certainly have SystemVerilog and/or VHDL sources, but you might also depend on one or more Python libraries. This can make dependency management cumbersome, since initializing a project involves using all the relevant packages managers to fetch dependencies from those particular ecosystems – in addition to potentially downloading some files not managed by any package manager. Either way, you’ll likely need some sort of project-specific section in your README or a bootstrap.sh script to tie it all together.

IVPM - A Polyglot Package Manager

Integrated-View Package Manager (IVPM) provides another approach. IVPM is a project-local dependency manager whose genesis was my frustration with the limitations of using git submodules to manage DV project source dependencies. IVPM started off as a relatively simple Python script that created local clones of git projects, driven by a manifest file. As new requirements came along, IVPM gradually evolved to where it is today: a flexible and extensible package manager that supports fetching dependencies from a wide variety of sources and synthesizing unified views from a variety of package artifacts, including:

• Python virtual environment from Python packages
• node_modules install from Node.js packages
• Links to available AI agent skills
• … and more

What occurred to me last weekend was to enable IVPM to fetch FuseSoc packages and assemble a unified view of the available FuseSoc libraries inside a project.

IVPM In Action

Let’s look at a small example just to get a sense of what this looks like in practice. Let’s say that we’re developing a little open-source RISC-V core. While developing our project, we benefit from having access to a few things:

• RISC-V ISA manual
• Verilator for simulation
• Common definitions (Verilog packaged with .core files)
• cocotb, fusesoc, and pyelftools for automating tests

While our project README.md will describe what is required in order to work on the core, we also provide an ivpm.yaml file that IVPM uses to automate setup:

package:
  name: my-risc-v

  dep-sets:
  - name: default
    deps:
    - name: riscv-isa-manual
      url: https://github.com/riscv/riscv-isa-manual.git
      anonymous: true
    - name: verilator
      url: https://github.com/edapack/verilator-bin
      src: gh-rls
      cache: true
    - name: fwprotocol-defs.git
      url: https://github.com/featherweight-ip/fwprotocol-defs.git
    - name: cocotb
      src: pypi
    - name: fusesoc
      src: pypi
    - name: pyelftools
      src: pypi

When we run ivpm update in the project, the tool:

• Clones the git repos and downloads the Verilator binary release
• Creates a Python virtual environment and installs packages from pypi
• Creates packages.envrc that adds Python and Verilator to the path
• Updates fusesoc.conf with paths to the protocol defs .core file

When ivpm update completes, the project is ready to run. The environment is configured, required open source software is installed, and FuseSoc is configured to be able to find the installed .core files.

Conclusions and Next Steps

IVPM provides a way to unify your project dependencies and you and your users get up-and-running fast. And, now, it supports FuseSoc-packaged IP as well. If you’re interested in experimenting a bit more, you can find two examples showing IVPM’s support for FuseSoc here.

Next time, we’ll look at leveraging learnings from the Python ecosystem on creating portable binary releases of open source EDA tools. And, of course, fetching these with IVPM.

Verification and Coverage

Coverage is a key metric we use to evaluate how well-verified a design is. We collect and analyze code coverage to identify areas of the design that aren’t exercised. We use assertion and functional coverage to ensure that key conditions are exercised. Combined with the right meta-data, such as test name, we can derive higher-level information such as a small set of tests that will exercise a design change.

Many design verification tools and frameworks support capturing and working with coverage metrics. For example, cocotb-coverage and AVL each support capturing functional coverage data, saving it to a file, and performing post-processing. Verilator supports capturing code and assertion coverage, and the major EDA companies have solutions as well.

But, all of these are independent. How can I view and analyze Verilator code coverage and AVL functional coverage together?

Standards: UCIS

A unique aspect of verification coverage is that we have are larger set of metrics than software projects typically use. Software projects tend to focus on code coverage, while design verification is also interested in functional coverage, FSM coverage, and assertion coverage.

Back in 2012, the Accellera EDA standards body released UCIS, the Unified Coverage Interoperability Standard. UCIS defines a data model and an API for interacting with all the types of coverage data that verification engineers work with. It also defines an XML interchange format supported by some tools and the FC4SC library that implements functional coverage for SystemC.

Having a common API enables the classic separation of concerns that other common APIs, such as LSP and MCP enable. Instead of developing analysis capabilities for each and every coverage format, we can create tools that use the UCIS API, and converters to map coverage formats into the UCIS data model.

Open Source: PyUCIS

I initially created the PyUCIS project because I needed a way to work with coverage data captured by the PyVSC library that I was also working on. At the time, I focused on support for functional coverage (coverpoints, cross-coverage, etc) since that was the data PyVSC produced.

As I noted in the introduction, AI-driven productivity gains have me revisiting projects like PyUCIS to add new features and provide more-comprehensive support. But, also, to ensure that the libraries are properly AI-enabled for users. We’ll cover some of these new feature areas in future posts, but this post focuses on AI enablement.

Three Levels of AI Enablement

I’ve gradually come to apply a three-level approach for enabling a tool for AI agent access that reflect successively-deeper levels of integration with the tool.

AI-Friendly CLI

The first level of integration is via the command-line interface (CLI). AI agents, such as Copilot, Codex, and Claude Code, excel at using command-line tools. Best practices for enhancing the CLI to be AI-friendly include:

• Providing granular data-manipulation commands with good help messages
• Providing JSON output
• Providing a pointer to a SKILL.md file

In the case of PyUCIS, our primary interest is in enabling an AI agent to analyze coverage data, so we focus most of our efforts on the show sub-commands.

usage: ucis show [-h]
                 ...

positional arguments:
    summary             Display overall coverage summary
    gaps                Display coverage gaps (uncovered bins and coverpoints)
    covergroups         Display detailed covergroup information
    bins                Display bin-level coverage details
    tests               Display test execution information
    hierarchy           Display design hierarchy structure
    metrics             Display coverage metrics and statistics
    compare             Compare coverage between two databases
    hotspots            Identify coverage hotspots and high-value targets
    code-coverage       Display code coverage with support for LCOV/Cobertura formats
    assertions          Display assertion coverage information
    toggle              Display toggle coverage information

options:
  -h, --help            show this help message and exit

LLMs often work more effectively with JSON data vs unstructured (or, arbitrarily-structured) text. JSON data has a regular structure and associates meta-data with various elements of the output (eg ‘name’, ‘id’, etc). In addition, an LLM can leverage tools like jq to efficiently slice and dice it. Consequently, it’s a very good practice to support JSON output. Enabling this with a specific switch is fine, since most humans won’t want to see JSON.

Agent Skills is an emerging standard for providing instructions to agents.

======================================================================
PyUCIS AgentSkills Information
======================================================================

Skill Definition: /home/.../ucis/share/SKILL.md

Note for LLM Agents:
  This file contains detailed information about PyUCIS capabilities,
  usage patterns, and best practices. LLM agents should reference
  this skill to better understand how to work with UCIS coverage
  databases and leverage PyUCIS tools effectively.

For more information, visit: https://agentskills.io
======================================================================

A skill for a tool provides examples and more in-depth instructions on tool workflows. I like to advertise how to find the tool’s skill in the help message, since AI agents often check this first.

Model Context Protocol

The Model Context Protocol (MCP) is a JSON RPC-based communication protocol that allows AI agents to run external operations. MCP excels in situations where operation setup times are long. For example, loading a waveform database often takes significant time. The overhead of doing so every time the Agent wishes to look at a waveform value is prohibitive. A waveform MCP server, such as pywellen-mcp, loads the waveform database once and allows the Agent to perform many queries.

PyUCIS provides a MCP server with a range of tools, including:

Database Operations

• open_database: Load UCIS databases in XML, YAML, or UCIS binary formats
• close_database: Clean up database resources
• list_databases: List all currently open databases
• get_database_info: Retrieve database metadata and statistics

Coverage Analysis Tools

• get_coverage_summary: Overall coverage statistics by type (statement, branch, etc.)
• get_coverage_gaps: Identify uncovered or low-coverage items with configurable thresholds
• get_covergroups: Retrieve covergroup details with optional bin information
• get_bins: Detailed bin-level coverage with advanced filtering capabilities
• get_tests: Test execution information and results
• get_hierarchy: Navigate and explore the design hierarchy
• get_metrics: Advanced coverage metrics and analysis

Advanced Features

• compare_databases: Compare two databases for regression analysis and coverage deltas
• get_hotspots: Identify high-value coverage targets for optimization
• get_code_coverage: Export code coverage in multiple formats (LCOV, Cobertura, JaCoCo, Clover)
• get_assertions: SVA/PSL assertion coverage details
• get_toggle_coverage: Signal toggle coverage information

Given the speed of the PyUCIS SQLite database, I’ll be interested in point at which using the MCP server becomes beneficial.

API

An API provides an AI agent the most-detailed access to a tool’s capabilities. Both the difficulty of producing an API and the difficult of an AI agent using it depends heavily on the tool’s implementation language. For example, Python is often fairly easy on both counts, since producing an API typically means documenting functions that we’ve already created to implement the tool, and AI agents can simply load the module and go. On the other hand, a compiled languages like C/C++ will likely require explicit action to define and expose an API, and AI agents will need to use the language toolchain to compile, link, and run with the API.

Conclusion and Next Steps

Design verification heavily relies on good coverage data to assess completeness, and AI can play a critical role in analysis. PyUCIS implements the Accellera UCIS API, and supports AI agents via the CLI and a built-in MCP server. As previously mentioned, you can look at the AI-assisted workflow example in the PyUCIS repository to get ideas of how to work with coverage data using the PyUCIS library and AI agents. Next time, we’ll shift focus to look at some of the other new and improved features in PyUCIS that AI agents are helping to rapidly develop.

EDA Software and Domain Expertise

Electronic Design Automation (EDA) software is a unique market. Like any other complex software, developing it requires strong software engineering skills. But, developing good EDA software also requires deep knowledge of the silicon engineering domain.

In my experience with commercial EDA, these two roles are generally handled by different people. Software engineering is handled by teams of software developers that, thinking simplistically, need to know very little about silicon engineering. Silicon engineering expertise is often represented by the product engineering role. This role is responsible for understanding the domain, and the user’s perspective on it, and translating that into requirements that the software engineering team can implement. In practice, of course, each of these disciplines has some cross-over. EDA software engineers have varying degrees of expertise in silicon engineering, and product engineers have varying degrees of software engineering expertise.

AI and Open Source EDA

An open source EDA developer typically doesn’t have the luxury of focusing on a single domain. Open source EDA developers often start from a vision – whether that’s simply the existence of open source tools for a given portion of the silicon engineering workflow, or a vision of a new way to approach a part of that workflow. But, very quickly, the developer must pivot and focus of the nuts and bolts of realizing this vision in code.

My experience, increasingly so over the last 4-6 months, has been that AI allows me to focus much more energy on the Product Engineering aspects of open source EDA, while delegating much of the software engineering aspects.

AI and Open Source EDA Developers

If you’re an open source EDA developer, AI enables you to spend a greater portion of your time in Product Engineer mode. With good requirements and review (all key Product Engineer skills), the bulk of software engineering tasks can be delegated to an agent. Here are a few things to consider as you look for AI opportunities in your project.

Develop ‘Nice to Have’ Features

Being an open source developer fosters a mentality of scarcity, if your experience is anything like mine. Ruthless prioritization is the only way to ensure that something with sufficiently-broad application can be produced by a single developer. ‘Nice to have’ features must be deferred – potentially forever.

AI nicely inverts this equation. When the primary cost of a new feature is specification, it becomes much easier to justify adding helpful features: better error handling, more output formats, etc.

More Communication

Communication tasks such as documentation, project websites, and project news is a task that often gets de-prioritized. After all, we need to get key features developed!

AI-created content has come a long ways. One can argue it still has a ways to go, but it’s often quite good for technical documentation. It works well in incremental mode to document features as they’re developed, but also to improve documentation for an existing codebase. While we should always be cautious about passing off AI-generated ‘slop’ as useful documentation, my current experience is that AI-generated docs are far better than no documentation at all. I’m also finding that providing a little structure and guidance goes a long way in getting better results.

Consider the Agent Experience

As a developer, it’s key to consider how your user will experience your project. Increasingly, you can assume that your users will be using an AI agent of some form to work with your project. This means that your project should expose usage information to make it easy for an agent effectively use your project.

One approach that I’ve found effective is to reference a skill.md file for the tool from the help message. For example, here’s the help output from DV Flow Manager, a workflow automation tool I work with.

usage: dfm [-h] [--log-level {NONE,INFO,DEBUG}] [-D NAME=VALUE] [-P FILE_OR_JSON]
           {graph,run,show,cache,validate,context,agent,util} ...

DV Flow Manager (dfm) - A dataflow-based build system

positional arguments:
  {graph,run,show,cache,validate,context,agent,util}
    graph               Generates the graph of a task
    run                 run a flow
    show                Display and search packages, tasks, types, and tags
    cache               Cache management commands
    validate            Validate flow.yaml/flow.dv files for errors and warnings
    context             Output comprehensive project context for LLM agent consumption
    agent               Launch an AI assistant with DV Flow context
    util                Internal utility command

For LLM agents: See the skill file at: /home/mballance/.../share/skill.md

AI agents often check a tool’s help message to better-understand its operation. Including a path to the tool’s “AI Skill” file provides the agent with a pointer to more in-depth information.

If your project produces human-consumable output, such as reports, you should have an option to produce JSON output as well. While JSON isn’t particularly easy for humans to read, agents work well with its regular structure.

Test, Test, Test

We all know that tests are good and important. But, often, we settle for a few basic tests so we can spend more time developing new features.

Here, again, AI can help. But, also, a good test suite is critical to getting good results with AI. Just like a human developer, an agent makes mistakes and a robust test suite catches those errors before they accidentally get committed.

AI and Open Source EDA Users

As an Open Source EDA user, AI provides you tools to make better use of the available software. Don’t hesitate to have your agent look at the source for software that you’re using. If you’re trying to get a case working, ask it to analyze the EDA software source alongside your code and understand what needs to change in your code.

If you hit a bug, use AI to create a reduced testcase in conjunction with the EDA software’s source.

Now, one personal request as an open source developer: please don’t just paste the AI-generated output into an Issue and click submit. The AI-created analysis is important, of course. Please include it in your Issue report. But, it’s likely that the AI-generated analysis is missing critical details about your usecase and intent. Including that critical user perspective helps to ensure that your usecase is well-supported beyond just fixing a point issue.

AI and Open Source EDA Contributors

If you’re trying to move from open source EDA user to open source EDA contributor, welcome! AI is definitely a help here as well.

Any complex codebase is difficult to get started with, and open source EDA is no different. AI offers strong benefits in helping to more-rapidly find key components of the codebase.

A key thing to bear in mind is that LLMs are tools, not oracles. Using AI isn’t going to magically turn you into an expert in a given project. And, all the best practices of contributing to an open source project still apply: ask questions, search issues, ask for feedback on contributions. That said, AI can bring you up to speed on a project far faster than you could on your own.

Set your sights a bit more broadly when it comes to reference materials. Reading an entire standard (SystemVerilog, SystemRDL, PSS) is daunting as a human, but easy with an agent. Use an agent to help explore implementation alternatives and refine requirements.

AI and Open Source EDA Sponsors

Sponsoring open source software development and maintenance has always been a bit tricky – especially for small projects. Large projects with an organization and, often, a team of paid software developers are somewhat easy: donate to the foundation, possibly participate in a steering committee, etc. In this case, there is a clear link between supporting the project financially and the project being able to scale. Smaller projects are much harder. Developers will have a ‘day job’ with contract clauses prohibiting moonlighting. But, even without this obstacle, paying the developer won’t really help the project scale because it won’t lead to more people working on the project.

While it’s still early, AI suggests a new way to support small open-source projects. AI access is typically paid by usage, coarsely denominated in Tokens. Open source developers with an effective AI utilization strategy can easily scale a project based on access to a larger number of tokens each month.

If you’re a would-be sponsor of Open Source EDA software, be on the lookout for organizations and platforms that allow you to contribute AI agent access (LLM tokens) to your favorite projects.

Conclusion

AI has the potential to scale open source EDA software efforts in ways that other technology advances simply have not. In short, allowing us as open source EDA users, contributors, and developers to focus on envisioning the workflows that we want to have, and delegating the bulk of implementation tasks to AI assistants. This new era of open source EDA promises new, more productive, approaches to silicon engineering challenges, easier-to-use tools, and new funding models to help the ecosystem scale. The future of open source EDA in the AI era is bright, and I’m excited to be here for this phase of the journey.

References

• Anthropic Skills

Example Vehicle: DMA Engine

A DMA engine is one of my favorite examples to use. It’s relatively simple, yet highlights several key aspects of a range of hardware devices:

• It is controlled via a software interface (mmio)
• It has characteristics of other bulk data movers, such as accelerators and high-speed communications interfaces
• Its operation often involves arbitration and resource contention

Let’s walk through the process of developing a series of executable and natural-language specifications that will allow us to refine a high-level natural-language specification for a DMA device to a synthesizable executable specification. I’ll store all of the models in the zuspec-example-dma repo so you can follow along if you’re interested.

DMA High-Level Specification

Let’s start with a simple natural-language spec for what we want. You can find the file here: 01_highlevel_spec.md

# DMA: High-Level Requirements

The DMA engine supports fast memory transfer between two 
memory regions. It is intended for use with both storage
and memory-mapped I/O devices.

## Transfer Requirements: General
- Each transfer shall have an associated priority (0..15)
- Each transfer shall have non-overlapping source and destination addresses
- Each transfer shall specifies the total number of bytes to transfer

## Transfer Requirements: Device
In addition to the requirements above:
- Each transfer shall specify an access size (eg 1, 2, 4, 8)
- Each transfer shall specify a chunk size, denominated in <accesses>
- The total transfer size is in bytes, and must be a multiple of <access-size>
- The source and destination addresses shall be aligned to <access-size>
- Each transfer specifies whether the source/dest addresses are incremented
- Device I/O is generally controlled by requests from the device itself
  - Request a chunk -> DMA engine performs <chunk-size> <access-size> accesses

## Transfer Requirements: Chaining
- It shall be possible to specify lists of both general and device transfers

So, these are quite high-level. They focus on the required functionality, while spending little time on how we might implement this.

Already, though, we might want to do some experiments with different executable specifications that implement the natural language one above.

DMA Algorithmic Model

Our first step is to define an algorithmic model with interfaces that satisfy the requirements above. Let’s start with the Logical Interface, since that is often how we phrase high-level requirements.

import zuspec.dataclasses as zdc
from typing import List, Protocol

@zdc.dataclass
class MemCpy(zdc.Struct):
    src: zdc.uptr = zdc.field()
    dst: zdc.uptr = zdc.field()
    sz: zdc.u32 = zdc.field()

@zdc.dataclass
class DevCpy(MemCpy):
    acc_sz: zdc.u8 = zdc.field()
    chk_sz: zdc.u32 = zdc.field()
    inc_src: bool = zdc.field()
    inc_dst: bool = zdc.field()


class DmaOp(Protocol):

    async def memcpy(
            self,
            src: zdc.uptr,
            dst: zdc.uptr,
            sz: zdc.u32,
            pri: zdc.i32 = 0):
        ...

    async def memcpy_chain(
            self,
            xfers: List[MemCpy],
            pri: zdc.i32 = 0):
        ...

    async def devcpy(
            self,
            src: zdc.uptr,
            dst: zdc.uptr,
            sz: zdc.u32,
            acc_sz: zdc.u8,
            chk_sz: zdc.u32,
            inc_src: bool,
            inc_dst: bool,
            pri: zdc.i32 = 0):
        ...

    async def devcpy_chain(
            self,
            xfers: List[DevCpy],
            pri: zdc.i32 = 0):
        ...

The API definition above captures how software would interact with the DMA engine. But, we also care about how the DMA engine accesses memory in the environment, and how devices in the environment request service from the DMA engine.

class MemoryOp(Protocol):
    """Memory interface for DMA to access system memory."""

    async def read(self, addr: zdc.u64) -> zdc.u64:
        """Read a word from memory.

        Args:
            addr: Memory address (word-aligned)

        Returns:
            Data value read
        """
        ...

    async def write(self, addr: zdc.u64, data: zdc.u64, size: zdc.i8) -> None:
        """Write a word to memory.

        Args:
            addr: Memory address (word-aligned)
            data: Data value to write
        """
        ...

mem.py defines a memory-access interface that the DMA model implementation will use to access memory in the system.

class ReqOp(Protocol):
    async def req_transfer(self, id: zdc.i32):
        """Request a transfer"""
        ...

req.py defines the API used by devices to request data transfers from the DMA engine.

In total, we’ve define the key operations used to interact with the DMA engine in less than 100 lines of code. Now, to do something with these operations.

Algorithmic Model Implementation

Now that we’ve defined our abstract interfaces, we can create an algorithmic implementation of the DMA engine.

You can find the algorithmic implementation of the DMA engine model here: op_op_alg.py.

@zdc.dataclass
class DmaOpOpAlg(DmaOp, ReqOp, zdc.Component):
    """DMA engine with no fixed channels. Uses MemoryOp for memory access
    and implements ReqOp for device transfer request control."""
    
    mem: MemoryOp = zdc.port()

The interface to the model is shown above. Because we’ve deliberately been abstract about the device’s structure – for example, how many channels it contains – the model simply implements both the DmaOp and ReqOp interfaces.

    async def memcpy(
            self,
            src: zdc.uptr,
            dst: zdc.uptr,
            sz: zdc.u32,
            pri: zdc.i32 = 0):
        """Copy memory from src to dst.
        
        Performs narrow accesses until 8-byte aligned, then wide accesses.
        """
        await self._mem_l.acquire()
        try:
            remaining = sz
            while remaining > 0:
                # Determine access size based on alignment and remaining bytes
                # Use the largest power-of-2 size that is both aligned and fits
                align = src & 0x7  # Low 3 bits give alignment
                if align == 0 and remaining >= 8:
                    xfer_sz = 8
                elif (align & 0x3) == 0 and remaining >= 4:
                    xfer_sz = 4
                elif (align & 0x1) == 0 and remaining >= 2:
                    xfer_sz = 2
                else:
                    xfer_sz = 1
                
                data = await self.mem.read(src)
                await self.mem.write(dst, data, xfer_sz)
                src += xfer_sz
                dst += xfer_sz
                remaining -= xfer_sz
        finally:
            self._mem_l.release()

The implementation of the ‘memcpy’ operation is shown above. The implementation is simple and brief, aside from a little complexity with respect to aligning the address. The total model implementation is ~150 lines of Python code, which is just about 6x the length of the original high-level spec.

Tests and Test Fixture

Now that we have a behavioral model, we need a way to exercise it. Fortunately, we have a couple of tools that simplify the process. pytest is used as the testing framework, and AI assistants are proving to be incredibly capable at creating test fixtures and tests from the behavioral model that we created.

You can find the tests in test_op_op_alg.py. The vast majority of the code was created using an AI assistant: copilot cli and Sonnet 4.5 in this case.

def test_memcpy_basic():
    """Test basic memcpy operation."""
    print("\n=== Test: Basic memcpy ===")

    @zdc.dataclass
    class Top(zdc.Component):
        fixture: DmaTestFixture = zdc.field()

        async def run(self):
            # Initialize source memory
            data = [0x10, 0x20, 0x30, 0x40]
            self.fixture.init_memory(0x1000, data)

            # Perform memcpy
            await self.fixture.dma.memcpy(
                src=0x1000,
                dst=0x2000,
                sz=32  # 4 words * 8 bytes
            )

            # Verify destination
            result = self.fixture.read_memory(0x2000, 4)
            assert result == data, f"Data mismatch: {result} != {data}"

            print("  Basic memcpy test PASSED")

    t = Top()
    asyncio.run(t.run())
    t.shutdown()

A basic transfer test is shown above, showing how the ‘memcpy’ operation is used, and how results are checked.

Conclusions and Next Steps

Engineers spend significant time working with natural-language and executable specifications. Zuspec simplifies the process of creating and testing executable specifications (models) at multiple abstraction levels, which enables greater use of executable models to help refine our natural-language specifications.

Algorithmic modeling of this style is done today – and, often, in Python. The difference with Zuspec is that the models are designed to be reusable for multiple purposes. Over the next few posts, we’ll look at how we continue to refine, reuse, and retarget our DMA model.

Resources

• zuspec-example-dma

The most difficult transition in hardware modeling is the transition from natural-language to executable specification. It is during this transition that the ambiguities inherent in natural-language descriptions are resolved. Maximizing value from a multi-abstraction hardware modeling strategy requires minimizing the number of times a natural-language spec is converted to executable. Zuspec defines interface abstraction levels that provide a basis for comparing implementations with different abstraction levels.

Connecting Modeling Abstractions

In the previous post, we looked at several internal-implementation abstraction levels. These help us explore the architecture and micro-architecture of the design with different cost and performance tradeoffs. However, the internal implementation doesn’t provide a good basis for comparing models. In essence, this means that the natural-language to executable spec translation happens for each model. This raises the cost of modeling, but also increases the risk that each model implements a slightly different interpretation of the original spec.

Ideally, we want some basis for mechanically comparing two models with different implementations such that we can easily establish whether they are equivalent according to that basis. Each model still needs to incorporate abstraction-specific details from the spec, but isn’t a full from-spec implementation.

Breaking Down Device Abstraction

Zuspec uses interface abstraction levels as this basis of comparison. The first thing to note is that there are two levels of interface: logical and physical.

The same set of interface abstractions apply to logical and physical interfaces, so let’s explore the abstraction levels first.

Abstraction: Scenario

A scenario-level interface captures rules about how a device may be used. The Portable Test and Stimulus (PSS) standard is likely the best-known example of a scenario-level interface abstraction. PSS uses scheduling rules and constraints to specify data, data-flow, and resource utilization rules. The rules of a scenario-level description assist in automating test creation and simplifying the integration of content from multiple IPs.

Abstraction: Operation

An operation-level interface captures the device interface in terms of operations that the device can perform. Think of the API of a software driver for a device. An operation-level interface lets us exercise key functions of a device without worrying too much about the details.

Abstraction: MMIO

A memory-mapped I/O (MMIO) interface uses memory-mapped registers and interrupts as the device interface.

Abstraction: TLM

A transaction-level modeling (TLM) interface uses packet-like messages. The TLM 1.0 and 2.0 standards provide good examples of this level of modeling. TLM is also heavily used in UVM testbench environments.

Abstraction: Protocol

Protocol-level interfaces are the familiar signal-level interfaces used in register-transfer level (RTL) designs.

Physical Interfaces

We’re all familiar with physical device interfaces. In RTL, these are the Protocol-level interfaces with signal-level ports at the boundary of the device. Every hardware model has physical interfaces, and these typically

Logical Interfaces

A logical interface is typically a software interface. Software, firmware, and test environments interact with a device via logical interfaces. A key attribute of a logical interface is that it is independent of the physical interface and can be virtualized.

Useful Combinations

The combination of logical and physical interface abstraction levels, combined with internal implementation abstraction level, provides a flexible way to characterize a given model. The table below summarizes how the abstraction levels apply to logical and physical interfaces.

Interface Roles

In addition to abstraction level and interface type, interface roles are also worth considering when characterizing a device.

• Initiator interfaces make requests to targets. Think: memory interface on a RISC-V core
• Target interfaces respond to requests from an initiator. Think: register interface on a UART
• Monitor interfaces passively view interaction between initiator and target

Relating Interface Abstractions

Abstractors, a term used by the IP-XACT standard, provide a mechanism for bridging abstraction levels in a reusable way. An abstractor has two or more physical interfaces with different abstraction levels and different roles. Specific kinds of abstractors often go by names like bus functional model or transactor.

With the right set of abstractors, we can provide multiple views of the same model implementation. For example, an algorithmic implementation of a device with MMIO physical interfaces can be used as a stand-in for the RTL implementation of the device with protocol-level interfaces in a verification testbench simply by adding the right protocol transactors from a library.

Next Steps

Interface abstraction levels and interface types (logical, physical) enable model reuse and provide a basis for comparing models with very different internal implementations. While there are many legal combinations of logical interface, physical interface, and internal implementation, there are a few key combinations. In the next post, we’ll start to look at how some of these key combinations, and how they are captured and evaluated in Zuspec.

A simplified silicon design process

The gantt chart above illustrates a simplified silicon design process. It deliberately makes no attempt to assign accurate relative times to any step in the process. The key challenge is that starting most steps is gated by the previous step either completing, or reaching some fairly advanced state of readiness. For example, the DV team can’t really start verifying the design until RTL is available. They can study the spec and, perhaps even, write some tests speculatively while the RTL is under development. But, validating assumptions must wait until RTL exists.

Note that these tasks are grouped by the design-model abstraction level, with most activity centering around a register-transfer-level (RTL) model of the design. This poses several challenges, but one of the biggest is that the abstraction difference between Spec and RTL is enormous.

A closer look

While the diagram above is straightforward, it hides some useful details about what is actually happening during each of the steps above.

Let’s walk through to look at the changes. First, you’ll notice that there are now four abstraction levels:

• Spec - Typically a natural-language description
• Algorithmic - A behavioral model with limited timing fidelity
• Cycle Accurate - A behavioral (non-synthesizable) model that reflects the intended micro-architecture of the design
• RTL - Synthesizable model

Spec Development

During spec development, it’s natural to use some high-level models to validate assumptions. These models are captured at a high level of abstraction, and support one of two methods of evaluation. A model intended for dynamic evaluation will be behavioral, and supports activities such as running existing software workloads. A statistical model (e.g. an Excel sheet) enables what-if analysis by adjusting control parameters. These are typically two distinct models because of the two different evaluation approaches.

RTL Implementation

The RTL development process is also not a monolith. Generally, you could think of a process by which the design is partitioned into independent sub-IP that can be implemented by different engineers. Once the design is partitioned, engineers can work in parallel to implement and test their assigned sub-IP. Finally, sub-IPs are integrated back into the overall structure of the design.

Design Verification

The design verification process is also step-wise, typically starting with basic bring-up tests to ensure that simple operations, such as register accesses, make it past the interfaces and properly interact with the design. Verification then proceeds to exercise key device usescases and, finally, exercise key implementation details.

The DV team will often create some type of reference model or predictor to use in checking results from the design. Sometimes this will be cycle accurate, but it might also be at an algorithmic level of abstraction.

Looking in more detail, it becomes clear that modeling at different abstarction levels is being done. But, too often, these models are only used within a specific silo. There are many reasons for this, including the language(s) used to implement models and integration challenges.

Shifting Left with Model Reuse

The Zuspec ‘bet’ is that we can reorganize the silicon development process by making models easier to create, easier to reuse and transform, and easier to integrate. Future posts will go into more depth on how Zuspec enables this. For now, let’s look at how different modeling abstractions are used across the silicon development process.

Let’s look at some of the key points:

• A single algorithmic model is used to serve both dynamic (simulation) and static/formal evaluation during the spec development process.
  • The DV team can use this algorithmic model, with a few modifications, as a substitute for RTL while they setup the testbench environment and write tests that exercise the specified design behavior.
  • The Firmware team can also get started writing firmware using the algorithmic model.
• The RTL implementation team develops a cycle-accurate model of the design as part of the process of partitioning the design.
  • The RTL implementation team selectively replaces sub-IPs within the cycle-accurate model to test a particular sub-IP’s implementation together with the more-abstract remainder of the design model.
  • The DV team can move to running their tests against the more-accurate model. This helps to highlight different interpretations of the spec much earlier.
  • The DV team can also run their tests against various configurations of the hybrid cycle accurate / RTL model of the device to begin exercising sub-IPs prior to availability of the fully-integrated RTL. Doing this can also enable tests that target implementation coverage to be developed incrementally as the relevant sub-IPs are ready.
• Once the RTL is ready, the DV team proceeds to run bring-up activities. Final issues are much easier to track down because the tests are known to run against the cycle-accurate model and various combinations of RTL sub-IPs.

So, how much time will we save? That, of course, heavily depends on the relative size of the tasks shown above, as well as on the cost of creating the set of models used above. But, the savings should be significant.

Next Stes

We’ve looked at several implementation abstraction levels for device models. In the next post, we’ll dig into interface abstraction levels and see how these enable incremental refinement of models.

DSL or Class Library?

In my experience, the use of hardware modeling varies widely across project teams. At the extremes, some attempt to maintain a consistent set of models across various abstraction levels, while others focus on producing RTL for their piece of the design and create models on an as-needed basis to achieve that task. While these approaches seem very different there are points of intersection. For example, both teams will likely have a predictor model for use in verification. Both teams will likely find that model creation is time consuming and, depending on their choice of modeling language, both may have challenges integrating a predictor model into their verification environment.

Modeling language is one of the first choices to be made when creating a hardware model. In general, there are two choices: select a domain-specific language such as SystemVerilog, or select a class library, such as SystemC, that is implemented in terms of a general-purpose language.

Both of these approaches have benefits and drawbacks.

Benefits

• Language
  • Full flexibility to have domain-specific features
  • Clear boundaries between what is the ‘language’ and the rest of the
  • Full flexibility to process a model
• Class Library
  • Leverage existing tools (compilers, editors, linters, debuggers) for the base language
  • Leverage existing expertise in the base language
  • Easily expand the class library to add new capabilities

Drawbacks

• Language
  • Expensive to implement and add new features
  • Must convince users to learn and become proficient in the language
  • Interoperability with existing languages and tools can be a challenge
• Class Library
  • Existing tools don’t comprehend domain-specifics encoded by the library
  • The need to work with base-language compilers limits how the model can be processed
  • The base language often limits how easily/naturally domain-specific features can be described

We currently use a variety of domain-specific languages across the design and verification process. Ideally, we could apply a modeling approach that retains the key benefits of both approaches much more broadly.

Zuspec: A DSL / Class Library Hybrid

Zuspec is a Python class library with a twist. A model described with Zuspec dataclasses is completely valid Python syntax, and can be validated with existing Python static checkers. But, due to some key Python capabilities, a Zuspec model can also be processed as if it were a domain-specific language.

Python offers benefits both to the Zuspec users (ie the author of a Zuspec model) and to tool implementors. For users, large portions of the existing tool ecosystem can be leveraged natively with a Zuspec description. Because the Zuspec library adheres to Python type rules, content-assist and navigation features in integrated developement environments, such as VSCode, work properly. For the same reason, static type checkers can help detect issues, such as incorrect use of functions, early.

But, what’s even more attractive about Python is that it provides parsing infrastructure that helps Zuspec construct an intermediate-representation (IR) data model that captures details that would impossible for a pure class library to capture. This IR also allows Zuspec to map a Zuspec model to a variety of implementations.

Let’s look at a simple example:

    @zdc.dataclass
    class Prod(zdc.Component):
        p : zdc.PutIF[int] = zdc.port()

        async def _send(self):
            for i in range(16):
                await self.p.put(i)
                await self.wait(zdc.Time.ns(10))

    @zdc.dataclass
    class Cons(zdc.Component):
        c : zdc.GetIF[int] = zdc.port()

        @zdc.process
        async def _recv(self):
            while True:
                i = await self.c.get()
                print("Received %d" % i)

    @zdc.dataclass
    class Top(zdc.Component):
        p : Prod = zdc.inst()
        c : Cons = zdc.inst()
        ch : zdc.Channel[int] = zdc.inst()

        def __bind__(self): return (
            (self.p.p, self.ch.put),
            (self.c.c, self.ch.get)
        )

    t = Top()

    asyncio.run(t.p._send())

This is a simple producer-consumer model. The producer and consumer communicate via a channel, and the testbench is responsible for activating the producer. As a side-note, a comparable case in SystemC is roughly twice as many lines of code, so there are already some measurable efficiencies.

Staying inside Python early in the model-development process is attractive due to the fast turnaround time and access to existing Python libraries. Any Zuspec model can be run directly in Python and can access all Python language and library features.

If you look closely at the description above, you might find yourself wondering how it executes. For example, how are ports connected? This is where some of the ‘declarative’ aspects of this description come into play. Despite the description looking and behaving like a class library, there is still some “magic” behind the scenes. In the case of port connections, the Zuspec library takes the user’s bind specification and determines how to properly connect ports and channels. And, of course, there are many other cases where Zuspec allows the user to specify what is desired and have the library determine how that intent is implemented.

Beyond Pure Python

There are quite a few projects that seek to translate Python to a more-performant implementation. Python ahead-of-time (AOT) compilers typically work with a Python script (and it dependent libraries) as a whole. Zuspec looks at the world differently.

Identifying the Model Boundary

Zuspec uses types defined in zuspec.dataclasses to identify the boundary of a model. For example, in the example above, the ‘Top’ class defines such a boundary. Tools that map a Zuspec description to a non-Python implementation operate on such boundaries.

Pure Python vs Retargetable

The other place where Zuspec is a bit different is in defining ‘Profiles’ for content. This has significant similarities to the SystemVerilog “synthesizable” subset. The first choice is whether a model is Retargetable or not. Retargetable models can be mapped to non-Python implementations.

In order to be retargetable, a model can only contain elements of Zuspec-recognized types. The ‘Top’ class above matches this criteria. That said, as long as running in Python is sufficient, a Zuspec model is free to use any Python construct.

Checking Profile compliance is another place where the Python ecosystem helps. Zuspec implements a plug-in to the flake8 linter that allows Zuspec to check profile compliance along with other Python rules that flake8 checks. This allows Zuspec-specific checks to be performed on-the-fly as code is developed, providing much faster feedback to the developer (or LLM, as is often the case today).

The diagram above shows several options for how a Retargetable Zuspec model might be implemented. Several of these targets, such as SystemVerilog RTL, have their own Profile that further restricts available features.

Conclusions and Next Steps

Zuspec is showing early promise in simplifying hardware model creation, and allowing those models to be reused and retargeted to a variety of environments. Next time, we’ll look at modeling abstraction-level methodology, and how this helps humans (and LLMs) to more-effectively discuss and implement the hardware models they care about.

References

• Zuspec: Pythonic Model-Driven Hardware Development