Skip to content
WIP: parts of this documentation are AI-generated and may contain factual errors.

Frontend

Frontend Role

The frontend is the topmost layer of the iDMA pipeline. It provides the software-visible interface through which the host or an accelerator core submits transfer descriptors. iDMA ships three frontend families, each targeting a different integration style:

Choosing a Frontend

RegisterDescriptorSnitch
InterfaceMemory-mapped registers over a selectable config-bus CPUIF (APB4 default, OBI, or AXI4-Lite)Descriptor ring in shared memory (AXI)Custom ISA extension (accelerator bus)
Typical SoCGeneral-purpose (CVA6, RISC-V)CVA6 / Linux-capableSnitch cluster
Data WidthAny64-bitAny (typically 64-512 bit)
ND SupportYes (2D via reg64_2d)No (1D only)Yes (2D, NumDim=2)
Key AdvantageSimple, portableHardware-managed queue, low CPU overheadSingle-cycle launch, zero register overhead
Error VisibilityStatus register (poll done_id, check response)IRQ (if flags.irq set)Poll via DMSTAT

Common Pattern

All frontends produce idma_req_t (or idma_nd_req_t for ND-capable frontends) and consume idma_rsp_t. Frontends are interchangeable at the idma_req_t / idma_rsp_t boundary, but each has a different control plane: config-bus (register), AXI (descriptor fetch), or accelerator interface. Switching frontends requires re-wiring the host-side interface. Requests may also carry an on-the-fly compute op in opt.compute; the register frontend exposes this through its compute_cfg register.

Generated Variants

The register frontend register file is described once in SystemRDL (src/frontend/reg/idma_reg.rdl) and generated by PeakRDL (regblock); a thin config-bus wrapper (src/frontend/reg/tpl/idma_reg.sv.tpl) is rendered by the MARIO framework for the selected CPUIF, producing variants like idma_reg64_2d. The descriptor (desc64) and Snitch (inst64) frontends are hand-written SystemVerilog in src/frontend/desc64/ and src/frontend/inst64/ respectively.