FPGA Logic, Memory and DSP Resources: Building a Requirements Table
An FPGA resource table should begin with the work the design must perform. Translate that work into logic, storage and arithmetic requirements, then compare those requirements with results from the intended device and toolchain.
Keep three columns distinct: required function, estimated resource use and measured implementation use. A family selection chart helps identify candidates. Your engineering record should explain how a candidate will implement the workload.
Define the workload before counting resources
Record the number of channels, sample or transaction rate, data width and acceptable latency. State which operations run concurrently and which may share hardware. Include operating modes that change the workload.
For a hypothetical acquisition design, write “buffer two channels of 16-bit samples, with 2,048 stored samples per channel” rather than “needs some RAM.” Record the producer and consumer clocks, required reads and writes, and the behavior when a buffer fills.
Apply the same discipline to logic. List control functions, interfaces and processing blocks before entering a LUT estimate. Mark each estimate's basis: an existing project, a small synthesis experiment, an IP report or an unresolved assumption.
Preserve each architecture's resource units
Keep manufacturer terminology beside the value. A logic cell, LUT, logic element and adaptive logic module should not be silently converted into one common capacity number.
For a concrete example, AMD's 7 series guide describes a slice with four LUTs and eight storage elements, while distinguishing SLICEM from SLICEL capabilities. That is an architectural definition for 7 series. AMD UG474, v1.9, Slice Description
When comparing different families, ask the engineer to build the same representative functions for each target. Preserve the constraints and tool settings with the results. Compare whether each candidate meets the workload rather than inventing a conversion ratio between marketing counts.
Also keep capacity and usage separate. The device's available resources belong in one column; the design's mapped resources belong in another. A change in either should trigger a fresh comparison.
Describe memory by organization and access
Calculate payload storage first. In the hypothetical example:
2 channels × 2,048 samples × 16 bits = 65,536 payload bits, or 8 KiB.
This is an arithmetic requirement, not a prediction of physical RAM-block use. Add a separate requirement for any metadata, error-detection information or debug capture.
Write down the memory shape: word width, depth, read/write ports and clocks. Record whether reads must occur while writes continue, and whether two operations may address the same location.
AMD's UltraScale memory guide gives a specific architectural example: a 36 Kb block RAM contains two independently controlled 18 Kb RAMs. Use that structure only for the documented architecture. AMD UG573, v1.14, Block RAM Introduction
Have engineering confirm the selected implementation, including how the requested shape maps to blocks. Record the mapped count from the build. Keep unused capacity within an allocated block distinguishable from capacity available to another function.
Specify arithmetic before estimating DSP use
For each arithmetic stage, record operand widths, signed or unsigned interpretation, output precision and operations per sample. Add rounding, saturation and accumulation requirements where applicable.
As a 7 series example, the DSP48E1 primitive exposes a 25-bit multiplier operand and an 18-bit multiplier operand, with additional arithmetic and register functions. That description does not establish the DSP count for an arbitrary algorithm. AMD UG953, 2026.1, DSP48E1
Ask the engineer to state the proposed schedule. If operations will share hardware, record the required internal rate and allowed latency. If they will run in parallel, record how many paths are active together.
Preserve the implemented arithmetic structure with the report. A count is easier to review when another engineer can connect it to the actual processing stages.
Use a requirements table that exposes missing work
The table below is a template, not a completed device recommendation. Add columns for candidate capacity, estimated use and measured use when evaluating a particular part.
| Resource area | Requirement to capture | Evidence needed |
|---|---|---|
| Logic and registers | Functions, state and concurrent processing | Synthesis results with block ownership |
| Buffer memory | Width, depth, ports and clock relationships | Implemented memory configuration and mapped blocks |
| Arithmetic | Precision, operations, schedule and latency | DSP/logic mapping for the selected implementation |
| Clock resources | Required frequencies, relationships and distribution | Clock plan and implementation checks |
| I/O and interfaces | Signals, standards and package access | Approved interface and pin assignment |
| Hard blocks and IP | Required function and configuration | Exact device support and generated design |
| Debug and future work | Planned capture and named additions | Separate estimates with owners |
A blank cell should identify an action. Use “not yet estimated” instead of zero when work has not been assessed.
Replace estimates with build evidence
Run a representative project against each serious candidate. Capture the exact part, tool version, source revision and constraint set with the reports. List any excluded feature so the comparison is not mistaken for a complete design.
Vivado's utilization report can show hierarchical resource use at different stages. AMD notes that optimization can change resource numbers during the flow. AMD UG906, 2026.1, Report Utilization
Track meaningful differences between estimates and measured results. Ask whether the difference comes from a changed requirement, an implementation choice or missing functionality. Update the requirement record rather than adjusting the headline total without explanation.
Review timing and implementation completion alongside utilization. Require engineering to accept the completed design under its constraints; a resource total alone is not the release record.
Describe headroom as planned work
Avoid adding an unexplained percentage to every resource. Instead, list foreseeable additions: another channel, deeper buffering, diagnostics or a planned protocol function. Estimate each separately and show the confidence level.
Keep genuinely unknown growth visible as uncertainty. The team can decide how much contingency to carry, but that decision should have an owner and a rationale.
For a quotation request to FPGAX, provide the exact shortlisted ordering codes, quantity and required date. Include whether the resource review is preliminary or complete. A supplier's alternative should return to engineering for workload and implementation review before it becomes an approved purchase option.
