xactflow-sv
A XactFlow importer plugin that reads a SystemVerilog
module plus a JSON metadata file (and, optionally, a SystemRDL register map) and produces an
ipxact.Component object, built on
ipxact-compiler's
IEEE 1685-2022 object model.
ipxact-compiler parses IP-XACT and hands back Python objects; XactFlow's Importer interface
is for the other direction, reading some non-IP-XACT source and producing that object model.
This package is one such importer: it does not write XML itself, turning the resulting
Component into a file is a separate exporter's job (see
xactflow-component).
The SystemVerilog parsing and metadata-driven design was informed by
ipxact-sv2ipxact, an earlier, experimental
standalone tool that solves a closely related problem by writing IP-XACT XML directly. This
package is a from-scratch implementation built against ipxact-compiler's object model rather
than a fork of it, and its scope, dependencies, and error handling are its own.
Installation
pip install xactflow-sv
For local development, requirements-dev.txt overrides ipxact-compiler and xactflow to
local installations. It can be modified to adapt the paths or to keep either version on PyPI.
pip install -r requirements-dev.txt -e .
Requires Python >= 3.9. Runtime dependencies beyond ipxact-compiler/xactflow:
pyslang for SystemVerilog parsing, and
systemrdl-compiler/
peakrdl-ipxact for register map conversion.
Usage
An importer's job stops at producing an ipxact.Component object; it does not write anything
out on its own, so getting an actual IP-XACT XML file also needs an exporter, like
xactflow-component. Once both are installed,
the importer registers itself under the xactflow.importers entry point group as sv, so
it can run as one XactFlow CLI command, --then chaining straight into the exporter
in the same process (requires xactflow>=0.1.1):
xactflow sv my_module.sv --option metadata=my_module_ipxact.json --then component --output out/
# writes out/<name>.xml
Or as a library, e.g. to inspect or modify the Component before exporting it:
from pathlib import Path
from xactflow_sv import SVImporter
from xactflow_component import ComponentExporter
component = SVImporter().import_(Path("my_module.sv"), metadata="my_module_ipxact.json")
component.vlnv # VLNV
component.model.ports # list[Port]
component.bus_interfaces # list[BusInterface]
component.memory_maps # list[MemoryMap]
ComponentExporter().export(component, Path("out")) # writes out/<name>.xml
Only the SystemVerilog module header (parameters and ports) is inspected, with no elaboration, no package loading, no symbol resolution: types, values, and dimension expressions are taken verbatim from the source text, matching how IP-XACT's own expression model treats them.
Metadata file
A small JSON file supplies what can't be inferred from the SV source alone:
{
"vendor": "Vendor",
"library": "Library",
"version": "1.0",
"busInterfaces": {
"apb": {
"bus": "Vendor:Library:apb4:1.0",
"mode": "target",
"ports": {"PSEL": "psel", "PADDR": "bus_req_i.paddr"}
}
},
"registerFile": "register_map.rdl"
}
vendor/libraryare required,versiondefaults to"1.0". The component'snamealways comes from the parsed module name, not from this file.busInterfacesmaps a bus interface name to its bus VLNV, mode (initiator/target, ormaster/slave), and either aportsmapping of logical bus signal names onto physical SV port names, or aninterfacePortnaming a genuine SVinterface-typed port that already groups its own signals. Aportsvalue can be a plain port name or a dottedport.fieldreference into a struct-typed port (e.g.bus_req_i.paddr). The abstraction definition is derived by convention as<bus-def-name>_rtlat the same vendor/library/version asbus. Everyinterface-typed port in the module must be described this way; there is no fallback guess for its bus VLNV or mode.registerFileis a path, relative to the metadata file, to a SystemRDL file describing the component's register map. It is compiled withsystemrdl-compiler, converted withpeakrdl-ipxact, and merged in as the component'smemory_maps.
--option define=SYM1,SYM2 (or defines=[...] when calling import_ directly) predefines
preprocessor symbols before parsing.
Design notes
- Three independent stages, each targeting
ipxact-compilerdataclasses directly rather than XML:sv_parser.pyparses the module header into plain dicts,component_builder.pyturns those intoipxact.Port/ipxact.Parameter/the component'sModel,bus_interfaces.pybuildsipxact.BusInterfacefrom the metadata'sbusInterfaces, andregister_map.pybuildsipxact.MemoryMapfrom a SystemRDL file. register_map.pyreadspeakrdl-ipxact's own XML output, not throughipxact-compiler's parser.peakrdl-ipxactonly supports IEEE 1685-2014, whileipxact-compileronly supports IEEE 1685-2022. A namespace swap alone would silently lose that data (a field's access policy, or a register's array dimensions, would just come back empty rather than erroring), so a dedicated reader is used instead. This is a keep-it-simple choice for now, maybe not permanent, see Ideas for later.- Fails loudly instead of silently dropping data. Constructs this package does not yet
support (see below) raise
NotImplementedError/ValueErrorrather than producing aComponentthat quietly leaves something out.
Known limitations
- Explicit ANSI ports (
.name(expr)syntax) and non-ANSI port lists (module m(a, b); input a; ...) are not supported. Only implicit ANSI-style ports are. A direction-less first port defaults toinout, per the SystemVerilog LRM. - Indexed part-select dimensions are not supported, e.g.
[base+:width]/[base-:width]. Only a plain[left:right]range is. - Register/register file arrays are not supported.
- A
registerFiledefining anaddrmapthat is never used under the chosen top-leveladdrmapis rejected, rather than silently ignored as SystemRDL itself would. A reusable sub-blockaddrmapinstantiated under a real top is unaffected. - A register/field/register file/address block with
ispresent = falseis not supported. IEEE 1685-2022 has no equivalent ofisPresent, so there is no way to represent one as conditionally absent rather than silently promoting it to always-present. - A SystemRDL construct
peakrdl-ipxactcannot export at all raises an error, e.g. amemnode nested inside another node's hierarchy, rather than silently producing an incomplete memory map. fileSetsare not generated. The component never records which.svfile the module actually came from.
Ideas for later
- Have
register_map.pybuild onipxact-compiler's own parser instead of its own ElementTree reader. Not a quick swap:peakrdl-ipxactonly emits IEEE 1685-2014 XML, andipxact-compiler's parser expects 2022's structure for field access and array dimensions (see Design notes). Feeding it 2014 XML after only a namespace fix-up parses without error but silently comes back missing that data, confirmed by testing it directly. Doing this properly needs a 2014-to-2022 XML restructuring step first (in this package, not inipxact-compiler, which is a 1685-2022 parser by design), or forpeakrdl-ipxactto gain 2022 output support upstream.
License
LGPL-3.0. See LICENSE.
Release files for xactflow-sv 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| xactflow_sv-0.1.0.tar.gz | 25.8 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| xactflow_sv-0.1.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 45.7 kB
Release files / xactflow_sv-0.1.0.tar.gz
| Download URL | xactflow_sv-0.1.0.tar.gz |
|---|---|
| Size | 25.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
8114d132fc418d56e870cf4f38c6015d55ea3f1fe557466a8e9c4ac2b315d9cd
|
|
BLAKE2b-256 checksum How to use checksums |
510100fd1b047f538482a3fb3268145e4afd8215d359f2c90d439018591bbd66
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 25, 2026.
Transparency logRelease files / xactflow_sv-0.1.0-py3-none-any.whl
| Download URL | xactflow_sv-0.1.0-py3-none-any.whl |
|---|---|
| Size | 20.0 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
fd4a48bbada469181168c301e79114badbe55b3e29adbdb0685b0dea513a880e
|
|
BLAKE2b-256 checksum How to use checksums |
9d5a44a0647073fa16069de7dcec9dd005b340d7ffa7d4355333079f5250269b
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 25, 2026.
Transparency log