Integration breaks at the seams between teams, and the seams are descriptions: a block arrives with a port list in a spreadsheet, a register map in a document and parameters in an email, and the integrator becomes the fourth, lossy transcription. A standard, machine-readable description removes the transcription. IP-XACT exists so that a component can describe itself once, precisely, in a form both people and generators can read. Knowing what it carries, and just as importantly what it does not, is what lets an integrator demand the right deliverable.
A component description names the block and its view of itself: its bus interfaces, each declaring a protocol role such as master or slave and mapping the interface's logical ports onto the module's physical ports; its plain ports that are not part of a bus; its parameters with defaults; and its memory maps, the address blocks and registers reachable through a slave interface, with base addresses, ranges, widths and access types. That last part should look familiar: it is the register table from the register topic, in standard form. A design description then assembles components: it lists instances of components, connects their bus interfaces and ports, assigns parameters per instance, and describes the address map of the whole assembly by assigning each slave interface a base in a shared address space. Access is declared per field (read-write, read-only, write-only and so on), and write-1-to-clear is a modified-write-value on the field, not an access type of the register. The slave's base address is not in the component at all: the component only knows offsets inside its own address block, and the base is assigned in the design description, where the master's address space maps the slave interface. The fragment below is illustrative generic format in that spirit, trimmed to the DMA's register interface.
# not-run: format fragment, not executable here
component: nano_dma
busInterface regs (slave, APB-style):
portMap: paddr -> paddr, psel -> psel, penable -> penable,
pwrite -> pwrite, pwdata -> pwdata, prdata -> prdata,
pready -> pready, pslverr -> pslverr
memoryMap regs:
addressBlock: base 0x0, range 0x100, width 32
register CTRL offset 0x00 width 32 access read-write
register STATUS offset 0x04 width 32
field BUSY bits [0:0] access read-only
field DONE bits [1:1] access read-write, modifiedWriteValue oneToClear
field ERR bits [2:2] access read-write, modifiedWriteValue oneToClear
register LEN offset 0x08 width 32 access read-write
register KEY offset 0x0C width 32 access read-write
register COUNT offset 0x10 width 32 access read-onlyWhat the format does not carry matters as much. It describes structure and addressing, not behaviour: the DMA's rule that LEN writes are ignored while BUSY, or that every CTRL write stores IRQ_EN, lives in the RTL and in prose documentation, not in any structural description. It describes intent, not correctness: a component can describe a register that its RTL does not implement, and only cross-checks against the RTL and the register model catch that. And it does not assemble itself: a generator consumes the design description and emits wiring, decode and collateral, which is the next lesson. Treat the description as the single source for facts it can express, and keep a written list of the facts it cannot.
Every delivered block has a component description whose port maps match its RTL port list, checked mechanically.
Register maps in descriptions match the register tables block for block, offset for offset, generated or compared in the build.
The facts the format cannot express (behavioural rules, timing, clock and reset intent) are listed explicitly as separate deliverables, not assumed covered.
Cross-check one component end to end: pick the DMA, walk its port map against the module ports, its register block against the register table, and its parameters against the instantiation. Any mismatch is a description bug, and it is cheap exactly because it is found before generation. If a block cannot produce a description, that is itself the finding: its facts exist only in somebody's head or inbox.
That LEN and KEY writes are silently ignored while BUSY (and that CTRL stores IRQ_EN on every write). Structural descriptions carry ports, maps and parameters only; behavioural rules live in the RTL, the register documentation and the errata-style driver rules.