How to use Chipmind Agents and RTL Canvas with IP-XACT

IP-XACT describes an SoC the way an engineer thinks about it: component instances, bus interfaces, port maps, memory maps, and the RTL files behind each instance. The problem is that nobody wants to really read it. One apb_uart component in the open PULPino packaging runs to 882 lines of XML. What if engineers could condense all of this into a single diagram? Chipmind RTL Canvas does exactly that. It turns this metadata into something you can see, point at and change, while Chipmind Agents do the editing underneath.

Why the visual value matters

Checking that RTL and IP-XACT still agree is useful, but it is not the main story. Existing tools already handle port consistency well, and agents are good at spotting mismatches, so drift detection comes along as a side effect. The real gain is in how you interact with the design and how you put IP together. You do not open a SystemVerilog file to count instances, and you do not open IEEE 1685 XML to read a port map. The canvas draws the structure, and the agents generate the views you need for the question at hand, whether that is a register map, a port map table or the RTL files bonded to each interface. This generative UI is what lets the engineer stay the referee once agents are allowed to edit both the RTL and the packaging metadata.

Interaction and stitching

When an agent proposes a change, you should not have to read a patch to understand it. RTL Canvas shows the proposal as a Visual Diff on the schematic, with the added block, the new edge or the changed register row highlighted against the baseline, and you accept or reject it right there. We used Croc, the open PULP Croc design, as an example. After a second timer was added to the RTL, the canvas drew the IP-XACT baseline and the RTL delta on the same croc_domain schematic, and the extra instance i_timer1, its extra demux slot and its IRQ nets stood out at a glance. The agent explained that the RTL was internally consistent, recommended merging the timer into the IP-XACT metadata, and then waited. Nothing changed until a decision was made.

The canvas also shows what an accept costs. Say an agent changes the port map of a supplier IP. That change is not local to the IP: it ripples through every connection up to the top level, and the canvas draws that path, so the engineer sees the implications before saying yes. Reject, and the agents re-run the task while sticking to the contract. Accept, and the packaging metadata is updated and further agents pick up the follow-on work. The same loop makes large refactors practical. Changes that usually take days of manual work can start from a single prompt, such as swapping a bus protocol or pushing a parameterized configuration from the leaf modules up to the top level. The agents keep RTL, IP-XACT, parameters and pragmas in step, and you review the result as one visual diff instead of a stack of file edits.

Stitching is the other half, and it opens up architectural exploration. Even with a library of verified IP, trying a new idea usually means defining interfaces, wiring ports, setting parameters and writing glue logic just to see whether it holds. RTL Canvas separates the thinking from the assembly: you place IP on the canvas and connect bus interfaces, and the agents do the wiring. Connections stay at the level of clean bus interfaces rather than flattened port lists, and where two protocols do not match, the agents infer the small RTL changes and glue logic needed to make the pieces fit. Instantiation is context-aware, too. Adding a timer to Croc is not just one more block. It needs a slot on the OBI bus, an incremented peripheral count in the address decoder and demux, and IRQ lines wired to the right places, and the agents read that context from the surrounding design and propose all of it together.

Underneath, the agents do not write raw XML. They act on the structure layer through typed operations such as add_instance, connect, set_field and rebind_config. A connect call is validated against the abstraction definitions of both bus interfaces, so an incompatible connection is rejected as an operation rather than discovered later in a file. Each operation produces a structured delta, which is exactly what the canvas renders as a diff. IP-XACT is the serialization, not the API.

What the Canvas shows

IP-XACT metadata is already canvas-shaped, so rendering is a projection rather than a transformation. Blocks are component instances, edges are interconnections, and external ports appear as diamonds. Edges are coloured by bus type (AXI, APB, clock, debug, IRQ), and parallel edges of the same type are bundled. Physical ports stay collapsed behind bus interfaces and resolve through the port map on demand. Hierarchy is zoom: you double-click to descend into a sub-design and use the breadcrumb to climb back up. A design configuration becomes a variant toggle on the block, for example switching the PULPino core between RI5CY and zero-riscy.

Building the prototype on the Kactus2 packaging of PULPino taught us why these choices matter. Verbosity is in the leaves, not the structure: those 882 UART lines are almost all port maps and register fields. Structure is compact, so drawing it is cheap, but ports have to collapse into bus interfaces by default or the canvas drowns. Bus definitions also fragment more than expected. The PULPino library splits AXI4 into separate per-channel definitions, so the canvas needs a bundling layer above IP-XACT to show one meaningful connection. And semantics stop at structure. IP-XACT says a register field exists at an offset, never what its values mean or how the RTL behaves. It is a structural contract, and behaviour needs a different instrument.

None of this replaces what is already there. Kactus2, Arteris Magillem, Agnisys IDesignSpec and PeakRDL already package, check and generate from IP-XACT and SystemRDL. RTL Canvas sits on top of the packaging metadata and changes how engineers work with it.

Look at the SoC, not the lines

IEEE 1685 stays the structural record and SystemVerilog stays the implementation. Neither is a good human interface once agents are allowed to edit both. RTL Canvas gives the engineer a view where proposals show up as diffs, costs show up as ripples, and new architectures come together by placing and connecting blocks.

Want to try this on your own IP? Book a call now.