Resource Analysis Tools

Any hardware module occupies resources — physical components of the silicon it is built from. An ASIC flow measures these as area and power. Waveflow’s initial focus is FPGA flows, specifically Xilinx / AMD parts, where a design’s resource utilization is instead counted in the fabric’s fixed primitives: LUTs, flip-flops, DSPs and memory blocks.

Whatever the target, hardware design inevitably trades resource consumption against the other design metrics — throughput, accuracy, features. Making that trade deliberately requires knowing what a module actually costs, measured as part of the design flow rather than discovered at the end of it.

This section describes Waveflow’s tools for measuring real utilization from Vitis synthesis on FPGAs. Tools for other flows, including ASIC, may follow.

In this section

  • FPGA resources — what a LUT, FF, DSP, BRAM and URAM actually are, and how Vitis produces a utilization estimate after C-synthesis (including what that estimate is and is not good for).
  • Reading the report — CsynthParser — the parser over csynth.xml: totals, the per-module breakdown, and the per-loop pipeline table.
  • Composite kernels — decomposing a multi-task kernel’s total into its modules and the interface logic between them, and the two traps that otherwise corrupt the arithmetic.

See also

Table of contents

  • FPGA resources - What the counters mean — LUT, FF, DSP, BRAM, URAM, SRL — and how Vitis produces a utilization estimate after C-synthesis. The estimate comes from HLS's own binding decisions plus per-part characterization, before Vivado has optimized anything, which is why DSP and BRAM track well while LUT and FF are genuinely estimates.
  • Reading the report — CsynthParser - The parser over a Vitis solution's csynth.xml: get_total_resources() for the design total and the device capacity, get_module_resources() for the per-RTL-module breakdown, and get_loop_pipeline_info() for per-loop II / depth / trip count. Documents the quirks — get_resources() returns None and populates res_df, and Vitis's own top-row total can disagree with its AreaEstimates total by a couple of LUTs.
  • Composite kernels - Decomposing a multi-task kernel's utilization into the parts that caused it. report_from_solution does it against the elaborated module graph; this page explains why that is not the same as summing the report's rows. The rows NEST (a function row already contains its pipelined loops), and a whole class of generated RTL — the m_axi adapters, the inter-task FIFOs, the AXI-Lite control — gets no row at all. What is left after the modules are claimed is the integration term, in one-to-one correspondence with the elaborated interface graph rather than being a residue.