01 — FPGA System Architecture
Start With Data Flow — Not HDL
A professional FPGA project should not begin with: "Let's start writing Verilog."
It should begin with the system.
Engineers first need to understand:
Where does data come from?
How fast does it arrive?
How much processing is required?
What latency is acceptable?
Where is data stored?
How does data leave the device?
Which functions should run in FPGA fabric?
Which should run in software?
Which should use hardened DSP or AI engines?
A high-level architecture might look like: Sensor / ADC → High-Speed Interface → Input Buffer → Preprocessing → DSP Pipeline → Algorithm / Accelerator → Memory → Output Processing → PCIe / Ethernet / Processor
The FPGA is therefore not merely a collection of logic blocks.
It Is a Data-Flow Machine.
02 — FPGA Platform Selection
Different FPGA families are optimized for very different engineering requirements.
Selection can involve platforms from:
AMD / Xilinx
Altera / Intel FPGA
Lattice
Microchip
and other appropriate vendors.
The correct device may depend on:
Logic capacity
LUTs
Flip-flops
BRAM
UltraRAM / embedded memory
DSP blocks
AI engines
Transceiver count
Transceiver speed
DDR capability
HBM
PCIe hard IP
Ethernet hard IP
Processor subsystem
I/O count
package
power
thermal
security
lifecycle
cost
FPGA Selection Is System Architecture Selection.
The largest FPGA is rarely automatically the correct FPGA.
03 — FPGA vs SoC FPGA vs Adaptive SoC
Modern programmable platforms exist at several architectural levels.
Traditional FPGA
Primarily programmable logic, embedded memory, DSP resources and high-speed I/O.
Suitable for:
Programmable Hardware
within one device.
Adaptive SoC
A more heterogeneous architecture may combine:
Application CPU
Real-Time CPU
Programmable Logic
DSP Engines
AI Engines
Network-on-Chip
High-Speed Interfaces
AMD Versal is a prominent example of this direction, integrating scalar processors, programmable logic, DSP/AI engines and a programmable NoC.
Modern FPGA Engineering Is Increasingly Heterogeneous Computing Engineering.
04 — Hardware / Software Partitioning
A sophisticated programmable system may have several possible execution locations:
For example: Software Implementation
May offer:
Easier development
Easier updates
flexibility
FPGA Hardware Pipeline
May provide:
Put Each Function Where the Architecture Executes It Best.
05 — FPGA Resource Budgeting
Before RTL development becomes extensive, engineers should establish a resource budget.
Resources can include:
LUTs
Registers
BRAM
URAM
DSP Slices
PLL / MMCM
SerDes
I/O Banks
Memory Controllers
A preliminary allocation might be:
Input Interface
Processing Pipeline
Memory
Protocol Logic
Control
Debug
Future Margin
The objective is to avoid discovering late in development that the architecture does not fit.
Resource Margin Should Be Planned — Not Discovered at 99% Utilization.
06 — RTL Architecture
RTL should reflect a clear hardware architecture.
The design may be divided into:
Interface Layer
Data Path
Control Path
Memory Layer
Clock / Reset
Configuration Registers
Diagnostics
Security
Processing Pipelines
Good RTL architecture improves:
Timing closure
verification
reuse
debugging
maintainability
portability
Hardware Structure Should Be Visible in the RTL Structure.
07 — Verilog / VHDL / SystemVerilog Development
Depending on project requirements, FPGA development may use:
Different languages and styles can coexist in large systems.
The important factor is disciplined HDL engineering:
synchronous design
clear reset behavior
explicit clock domains
parameterization
reusable interfaces
synthesizable coding
controlled inference
meaningful hierarchy
documented assumptions
The objective is not clever HDL.
The Objective Is Predictable Hardware.
08 — High-Level Synthesis
For certain algorithms, HLS — High-Level Synthesis can accelerate development.
Algorithms written in languages such as C/C++ can be synthesized into hardware structures.
This can be useful for:
But HLS does not eliminate hardware engineering.
Engineers still need to control:
pipeline depth
initiation interval
memory bandwidth
resource use
data types
latency
High-Level Code Still Produces Physical Hardware.
The engineer must understand what hardware the compiler creates.
09 — DSP Algorithm Architecture
FPGA-based DSP is fundamentally different from conventional sequential software DSP.
A CPU may perform: Operation A → Operation B → Operation C
An FPGA can build hardware so that many operations occur: At the Same Time.
DSP architectures may include:
FIR filters
IIR filters
FFT
DFT
DDC
DUC
CIC filters
modulation
demodulation
correlation
convolution
matrix operations
spectral analysis
beamforming
control algorithms
The core advantage is: Spatial Parallelism.
10 — Pipeline Architecture
Pipelining is one of the foundations of high-performance FPGA design.
Instead of performing a complex operation in one long combinational path:
Input → Large Logic → Output
the design can become: Input → Stage 1 → Register → Stage 2 → Register → Stage 3 → Output
This increases latency in clock cycles but can dramatically increase maximum clock frequency and throughput.
After the pipeline fills:
A New Result Can Potentially Be Produced Every Clock Cycle.
That is one of the fundamental differences between hardware processing and sequential software.
11 — Fixed-Point DSP Design
Many high-performance DSP systems do not need floating point everywhere.
Fixed-point arithmetic can significantly reduce:
logic resources
power
latency
while increasing:
parallelism
throughput
But fixed-point engineering requires careful analysis of:
Word Length
Fractional Bits
Quantization
Overflow
Saturation
Rounding
Dynamic Range
A typical process is: Floating-Point Reference Model → Fixed-Point Conversion → Error Analysis → Bit-Width Optimization → RTL Implementation
Every Extra Bit Has Hardware Cost.
But too few bits can destroy algorithm performance.
12 — Floating-Point DSP
Some applications require floating-point arithmetic because of:
Modern FPGA DSP blocks can support increasingly sophisticated floating-point operations.
AMD's current Versal DSP architecture supports operations and data types including single- and half-precision floating point in certain device families.
The engineering trade-off is: Numerical Flexibility vs. Resources + Power + Latency.
13 — FIR Filter Architecture
A high-throughput FIR filter may use:
Sample Input → Delay Line → Parallel Multipliers → Adder Tree → Output
FPGA DSP slices allow multiple multiply-accumulate operations to occur concurrently.
Optimization can involve:
coefficient symmetry
polyphase structure
interpolation
decimation
transposed structures
resource sharing
pipeline balancing
The best architecture depends on: Sample Rate + Filter Length + Clock Rate + Resource Budget.
14 — FFT Architecture
FFT processing is common in:
FPGA architectures can support:
streaming FFT
burst FFT
pipelined FFT
parallel FFT
Engineering variables include:
FFT Size
Sample Rate
Bit Width
Latency
Memory
Scaling
Overflow
FFT Performance Is an Architecture Decision, Not Just an IP Configuration.
15 — Streaming DSP Architecture
For high-data-rate applications, storing every sample before processing may be inefficient.
Streaming architectures process data as it flows.
For example: ADC → Filter → FFT → Detection → Packetization → Ethernet
without writing the full data set to external memory.
Benefits may include:
low latency
reduced memory bandwidth
deterministic throughput
Move the Algorithm to the Data — Instead of Moving the Data Repeatedly.
16 — Parallel Processing Architecture
FPGA performance can scale by duplicating processing engines.
For example:
Channel 0 DSP
Channel 1 DSP
Channel 2 DSP
Channel 3 DSP
can execute simultaneously.
Parallelism may occur at several levels:
Data-Level Parallelism
Process multiple samples simultaneously.
Pipeline Parallelism
Different stages process different samples.
Task Parallelism
Different algorithms execute simultaneously.
Channel Parallelism
Multiple sensor / communication channels run independently.
FPGA Performance Comes From Concurrency.
17 — Clock Architecture
Large FPGA designs can contain many clock domains.
Clock architecture may include:
external oscillators
PLL
MMCM
recovered clocks
SerDes clocks
memory clocks
processing clocks
interface clocks
Engineering must define:
Clock Source
Frequency
Phase Relationship
Jitter
Distribution
Reset
Incorrect clock architecture can create:
Clocks Are the Skeleton of Synchronous FPGA Design.
18 — Clock Domain Crossing — CDC
CDC is one of the most important disciplines in FPGA engineering.
When a signal crosses from:
Clock Domain A
to
Clock Domain B
the receiving flip-flop may violate setup or hold timing and enter a metastable state.
Correct CDC structures may include:
Two-Flip-Flop Synchronizers
for single-bit control signals.
Handshake Synchronizers
for controlled transactions.
Asynchronous FIFO
for multi-bit data streams.
Gray-Code Structures
for certain counters and pointers.
CDC should be formally analyzed where appropriate.
A Simulation That Looks Correct Does Not Prove a CDC Is Safe.
19 — Reset Domain Crossing — RDC
Reset can create similar asynchronous behavior.
Different parts of the FPGA may:
reset at different times
release reset under different clocks
use asynchronous reset assertion
require synchronous release
Poor reset architecture can create:
that are extremely difficult to reproduce.
Modern high-quality design therefore considers:
together.
20 — Reset Architecture
A professional FPGA reset strategy can distinguish:
Power-On Reset
Global Reset
Subsystem Reset
Processor Reset
Interface Reset
Fault Recovery Reset
Reset assertion may be asynchronous in some architectures.
Reset deassertion often requires controlled synchronization.
Reset Release Is a Timing Event.
Not simply a logic level.
21 — AXI & On-Chip Interconnect
Large programmable systems frequently use standardized on-chip buses such as:
These can connect:
processors
DMA
memory
custom IP
PCIe
Ethernet
DSP engines
Architecture should define:
bandwidth
burst length
arbitration
QoS
latency
clock domains
address map
A bus that is logically connected can still become a performance bottleneck.
Interconnect Bandwidth Must Match Compute Bandwidth.
22 — Network-on-Chip Architecture
The highest-end programmable devices increasingly include hardened NoC structures.
AMD Versal uses a programmable NoC to connect processing, memory and acceleration resources and to manage latency/QoS relationships. Intel Agilex 7 M-Series also incorporates hardened memory NoC functionality around its HBM/DDR architecture.
This changes FPGA architecture.
Instead of building every wide datapath from programmable fabric, engineers can use hardened high-bandwidth interconnect.
Important variables include:
bandwidth
routing
QoS
latency
memory access
congestion
At Large Scale, Data Movement Can Become Harder Than Computation.
23 — DMA Architecture
DMA is critical whenever large amounts of data move between:
PCIe
Memory
Processor
FPGA Pipeline
Ethernet
A high-performance DMA architecture may include:
descriptor rings
scatter/gather
multiple channels
interrupts
batching
zero-copy architecture
streaming
The design should minimize unnecessary movement and copying.
High-Performance Computing Is Often High-Performance Data Movement.
24 — DDR Memory Controller Architecture
External DDR can provide large memory capacity.
But memory performance depends on more than raw DDR speed.
Engineering must consider:
controller efficiency
bank structure
row access
arbitration
burst size
refresh
access patterns
A poor memory-access architecture can make a high-speed DDR interface perform poorly.
Memory Bandwidth on the Datasheet Is Not Application Bandwidth.
25 — DDR4 / DDR5 Hardware Integration
At PCB level, DDR interfaces require control of:
impedance
length matching
DQ / DQS relationships
address / command timing
clock
termination
Vref
power integrity
reference planes
As interface rates increase: Package + PCB + Memory Device Must Be Treated as One Timing Channel.
This is where FPGA architecture connects directly with high-speed PCB engineering.
26 — HBM Architecture
For memory-bandwidth-limited workloads, HBM — High Bandwidth Memory can fundamentally change FPGA architecture.
Instead of a relatively narrow external DDR interface, HBM uses extremely wide memory interfaces integrated close to the FPGA die.
Intel's Agilex 7 M-Series currently integrates HBM2e with up to 32 GB capacity and advertises up to 1 TB/s memory bandwidth.
HBM is especially valuable for:
But HBM does not automatically solve memory architecture.
Engineers still need to optimize:
Banking
Parallel Access
Data Locality
Burst Structure
Memory Scheduling
HBM Provides Bandwidth. Architecture Must Learn How to Use It.
27 — High-Speed Serial Transceivers
High-end FPGAs increasingly integrate extremely fast SerDes.
Current devices already reach approximately:
depending on vendor and platform. AMD Versal Premium supports 112 Gb/s PAM4-class interfaces, while Intel Agilex 7 offers transceivers up to 116 Gb/s in selected families.
A SerDes system includes:
Serializer
TX Driver
Channel
RX Equalization
Clock Recovery
Deserializer
Engineering may involve:
PLL
reference clocks
equalization
pre-emphasis
CTLE
DFE
channel loss
jitter
BER
At 100G-Class Lane Rates, the FPGA and PCB Are One Communication System.
28 — SerDes Channel Engineering
A complete SerDes channel may contain: FPGA Package → PCB Via → Trace → Connector → Cable / Backplane → Receiver
Every structure contributes:
loss
reflection
crosstalk
jitter
Channel engineering can involve:
S-Parameters
Insertion Loss
Return Loss
Eye Diagrams
Bathtub Curves
BER
TDR
The FPGA transceiver cannot compensate for unlimited channel loss.
Equalization Is Margin Recovery — Not a Substitute for Good Channel Design.
29 — PCI Express FPGA Design
FPGAs are widely used for PCIe:
accelerators
data acquisition
networking
storage
custom compute devices
Architectures may involve:
PCIe Endpoint
Root Port
DMA Engine
BAR Space
MSI / MSI-X
AXI Bridge
Streaming DMA
Modern high-end FPGA platforms include hardened PCIe Gen5-class capability, and new adaptive SoC generations are moving into PCIe Gen6.
At the broader interconnect level, PCI-SIG released PCIe 7.0 Version 1.0 in June 2025 at 128 GT/s, showing where high-performance digital interconnect requirements are heading.
Protocol Generation Is Advancing Faster Than PCB Margin.
30 — PCIe DMA Architecture
High-throughput PCIe FPGA systems often require carefully engineered DMA.
Performance depends on:
The system may use: Host RAM ↔ PCIe DMA ↔ FPGA Stream
The design objective is often: Move Data Without Making the CPU Touch Every Byte.
31 — CXL-Attached FPGA Architectures
Compute Express Link introduces cache- and memory-oriented connectivity between processors and devices.
Selected high-end FPGA families already integrate CXL-related capability; for example Agilex 7 supports coherent processor attachment options, while AMD's newer Versal platform roadmap includes CXL 3.1 capability in Premium Gen 2.
This creates opportunities for:
But CXL systems add complexity involving: Protocol + Coherency + PCIe PHY + Firmware + Software + SI/PI.
32 — High-Speed Ethernet FPGA Design
FPGAs are widely used in:
Architecture may involve:
and increasingly 800G-class aggregate systems.
The FPGA may implement:
PCS
MAC
FEC
Packet Parser
Classifier
Buffer
Scheduler
Custom Processing
At these rates: Packet Processing Is a Memory, Timing and Data-Flow Problem.
33 — JESD204 High-Speed Converter Interfaces
High-performance data-acquisition systems increasingly connect FPGA logic with:
High-Speed ADC and High-Speed DAC
using JESD204-family interfaces.
The architecture can include: ADC → JESD SerDes → FPGA Receiver → DSP Pipeline
and the reverse path for DAC systems.
Engineering considerations include:
lane rate
lane alignment
deterministic latency
synchronization
SYSREF
reference clock
framing
link initialization
error monitoring
High-Speed Converter Design Is Clock Architecture + SerDes + DSP Architecture.
34 — Multi-Channel Data Acquisition
Advanced FPGA platforms can acquire many channels simultaneously.
A design may need:
16 ADC Channels
or
32 / 64 / More Channels
with strict:
phase alignment
timing synchronization
bandwidth
buffer capacity
The FPGA can perform real-time:
filtering
decimation
triggering
event detection
compression
before storing or transmitting data.
Process Data Before the Data Becomes a Bandwidth Problem.
35 — Deterministic Latency Engineering
Some applications care less about average throughput and more about:
Exactly When the Output Appears.
FPGA pipelines can provide highly deterministic latency.
The path can be measured in:
rather than uncertain operating-system scheduling.
Engineering may define:
Input Capture → 4 cycles
Filter → 12 cycles
Decision → 5 cycles
Output → 2 cycles
Total:
This makes FPGA architecture valuable for precision control and timing-critical systems.
36 — Timing Constraints
The FPGA tool does not know every timing requirement automatically.
Engineers must define constraints.
These may include:
clock definitions
generated clocks
input delays
output delays
clock groups
false paths
multicycle paths
max delay
min delay
Incorrect constraints are dangerous because:
A Design Can Report "Timing Passed" When the Real Timing Requirement Was Never Constrained.
Constraint engineering is therefore part of design engineering.
37 — Static Timing Analysis
STA verifies whether the implemented design meets timing across:
Process
Voltage
Temperature
corners represented by the implementation flow.
Analysis includes:
Setup Timing
Can data arrive before the active clock edge?
Hold Timing
Does data remain stable long enough after the clock edge?
Recovery / Removal
For asynchronous controls.
Clock Uncertainty
Including jitter and distribution effects.
Simulation Tests Logic Behavior.
STA Tests Timing Feasibility.
Both matter.
38 — Timing Closure
Timing closure is often where difficult FPGA projects are won or lost.
A design may be logically perfect but fail its required clock rate.
Timing improvement may involve:
deeper pipelining
register duplication
retiming
logic restructuring
floorplanning
routing control
memory architecture
fanout reduction
clock optimization
The right solution is usually not: Ask the tool to try harder.
It is: Change the Architecture Until the Physical Implementation Can Meet the Requirement.
39 — Floorplanning
Large FPGAs are physical devices.
Logic placement matters.
A design may have functional regions such as:
PCIe
DDR / HBM
DSP Pipeline
Ethernet
Control
AI Engine
Floorplanning can keep related logic near:
hard IP
I/O
memory controllers
transceivers
This can improve:
timing
routing
congestion
predictability
FPGA RTL Eventually Becomes Physical Geography.
40 — Congestion Engineering
Timing problems are not always caused by logic depth.
They can be caused by routing congestion.
High utilization may create:
long routes
unpredictable delays
difficult placement
power density
Optimization may involve:
hierarchy
floorplanning
resource redistribution
memory placement
pipeline insertion
A FPGA at 95% Utilization Is Not Necessarily a Healthy FPGA.
41 — CDC Verification
Because clock-domain errors can be intermittent, they are particularly dangerous.
CDC analysis can identify:
Professional flows may use dedicated static CDC tools.
The objective is: Prove the Crossing Structure — Not Merely Observe It in Simulation.
42 — RTL Simulation
Simulation remains foundational.
A verification environment can include:
DUT
Stimulus
Reference Model
Monitors
Scoreboards
Tests should include:
normal operation
boundary cases
error conditions
invalid input
reset
overflow
protocol errors
Verification Must Try to Break the Design.
Not only demonstrate the expected path.
43 — SystemVerilog Assertions
Assertions allow expected behavior to be expressed formally.
Examples:
Request must eventually receive acknowledgement.
FIFO must never read while empty.
Two mutually exclusive states must never occur together.
Assertions can detect problems much closer to the source.
Encode Design Intent Into Executable Checks.
44 — UVM Verification
For large FPGA designs, UVM — Universal Verification Methodology can provide a scalable verification architecture.
A UVM environment may include:
Sequence
Driver
Monitor
Agent
Scoreboard
Coverage
The standard is maintained by Accellera; the current public UVM reference-implementation line continues to be updated, including a 2026 release.
Benefits can include:
reusable verification components
constrained-random testing
functional coverage
scalable test environments
Large RTL Designs Need Verification Architecture Just as Much as Design Architecture.
45 — Functional Coverage
Passing 10,000 simulations means little if they all test nearly the same behavior.
Functional coverage answers:
Which scenarios have actually been exercised?
Coverage can track:
operating modes
packet types
error conditions
state transitions
boundary values
The objective is not simply 100% coverage as a number.
The Objective Is Confidence That Important Behaviors Have Been Tested.
46 — Formal Verification
Formal verification mathematically explores design state spaces rather than relying only on test vectors.
It can be particularly powerful for:
arbiters
FIFOs
state machines
safety properties
protocol logic
deadlock analysis
Formal methods can answer questions such as:
Can this FIFO ever overflow?
Can two bus masters own the same resource simultaneously?
Can this state machine deadlock?
Simulation Finds Bugs You Thought to Test.
Formal Can Find Bugs You Did Not Think to Test.
47 — Equivalence Checking
When RTL is transformed or optimized, equivalence checking can help verify that two representations preserve intended logical behavior.
This may become relevant for:
The broader principle is: Optimization Should Not Silently Change Function.
48 — DSP Reference Models
Complex DSP should usually begin with a high-level algorithmic model.
Possible environments include:
MATLAB / Simulink
Python
C / C++
The reference model defines expected mathematical behavior.
The implementation can then be compared against it.
A mature flow is: Algorithm → Golden Model → Fixed-Point Model → RTL / HLS → Simulation → Hardware → Measured Output
Keep Mathematical Intent Connected to Hardware Reality.
49 — Bit-Accurate Verification
For fixed-point DSP, it is not enough to say:
The waveform looks similar.
Verification should compare: Input → Golden Model vs. FPGA Output
on a bit-accurate or tolerance-controlled basis.
This is especially important for:
quantization
rounding
saturation
overflow
pipeline delay
Numerical Correctness Is an Engineering Requirement.
50 — Hardware-in-the-Loop Verification
Real FPGA hardware should eventually be tested with realistic data.
HIL setups can connect:
Signal Generator
ADC
FPGA
DAC
Network
Host PC
Real Sensors
depending on the application.
This closes the gap between: Simulation and Real Electrical Hardware.
51 — FPGA Board Bring-Up
The first FPGA board should be brought up methodically.
Typical sequence: Visual Inspection → Resistance Checks → Power Rails → Configuration Power → Core Power → I/O Power → Clocks → JTAG → FPGA Configuration → Memory → Transceivers → Interfaces → Full Application
Large FPGAs can require many power rails and strict sequencing.
Do Not Start With the Full Bitstream.
Start by Proving the Hardware Foundation.
52 — Power Architecture for FPGA
FPGA platforms can require rails such as:
Core
Auxiliary
I/O Banks
Transceiver
PLL
Memory
Different rails may demand:
high current
low ripple
fast transient response
sequencing
A high-performance FPGA may move from idle to heavy computation rapidly.
This places significant demands on the PDN.
FPGA Performance Can Be Limited by Power Delivery.
53 — FPGA Power Estimation
Before layout, engineering can estimate:
static power
dynamic logic power
DSP power
memory power
transceiver power
I/O power
Power depends heavily on:
Frequency
Toggle Rate
Voltage
Resource Utilization
Transceiver Activity
Power analysis should occur before thermal design is finalized.
Thermal Problems Should Be Predicted Before the Board Exists.
54 — Power Integrity
Large programmable devices can draw rapidly changing current.
The PDN must control impedance across a wide frequency range.
Engineering can include:
target impedance
decoupling network
package interaction
plane geometry
VRM response
capacitor placement
At high performance: FPGA + Package + PCB PDN Must Be Engineered as One Power System.
55 — Thermal Engineering
High-end FPGA and adaptive SoC platforms can dissipate substantial power.
Thermal engineering can involve: Junction → Package → TIM → Heat Sink → Air
or conductive cooling paths through the enclosure.
Engineering variables include:
junction temperature
ambient temperature
airflow
heat-sink resistance
workload
transceiver activity
High junction temperature can reduce:
timing margin
reliability
performance headroom
Timing, Power and Thermal Are Connected.
56 — FPGA PCB Escape & BGA Design
Large FPGAs can contain thousands of BGA connections.
The package directly influences:
HDI requirement
microvias
via-in-pad
layer count
stack-up
breakout topology
High-speed transceiver pins, memory pins and power pins each have different routing priorities.
FPGA Selection Can Determine the Entire PCB Technology.
This is an area where 365PCB's ODM + advanced PCB manufacturing integration can become particularly valuable.
57 — FPGA Signal Integrity
High-speed FPGA boards require coordinated SI engineering for:
SI work can involve:
IBIS-AMI
IBIS
S-Parameters
Eye Diagrams
TDR
Crosstalk Analysis
Via Modeling
FPGA Timing Does Not Stop at the Package Ball.
The PCB is part of the timing and communication system.
58 — Reference Clock Engineering
High-speed transceivers depend on low-noise reference clocks.
Engineering can evaluate:
frequency
phase noise
integrated jitter
clock distribution
fanout buffers
supply noise
PCB routing
At very high serial rates: Picoseconds Matter.
A poor reference clock can consume significant SerDes jitter budget.
59 — FPGA Configuration Architecture
SRAM-based FPGAs generally require configuration at power-up.
Architectures can include:
Engineering should define:
Who Loads the FPGA?
Where Is the Bitstream Stored?
What Happens if Configuration Fails?
How Is the Image Updated?
Configuration is part of the system boot architecture.
60 — Secure FPGA Configuration
Depending on device capability, bitstream security may include:
encryption
authentication
secure key storage
secure boot
anti-tamper functions
Security is particularly important where the FPGA implements:
proprietary algorithms
communications
product IP
security functions
The Bitstream Is Executable Product IP.
It should be protected accordingly.
61 — FPGA Remote Update & Recovery
Field-updatable programmable systems need a recovery strategy.
A robust architecture may use:
If the update fails: Fallback → Golden Image
The same questions apply as MCU OTA:
What if power fails?
What if the image is corrupted?
What if authentication fails?
An Update Mechanism Without Recovery Is an Availability Risk.
62 — Embedded Processor + FPGA Software
SoC FPGA platforms add a complete software dimension.
The processor subsystem may run:
Bare Metal
RTOS
Embedded Linux
while communicating with programmable logic through:
AXI
memory-mapped registers
DMA
interrupts
shared memory
This requires coordinated: Hardware + Firmware + Linux Driver + FPGA Design.
63 — Linux FPGA Integration
Linux-based SoC FPGA systems may require:
device tree
kernel drivers
DMA drivers
memory mapping
interrupts
userspace API
bootloader
FPGA manager
networking
At this level: FPGA Development Becomes Full Embedded Platform Development.
64 — AI / ML Acceleration on Adaptive SoCs
Modern adaptive platforms increasingly combine FPGA fabric with specialized vector processors.
AMD's Versal architecture, for example, combines programmable logic with AI Engines optimized for vector-based DSP and ML workloads, connected through high-bandwidth NoC infrastructure.
A heterogeneous AI pipeline may use: Sensor / Camera → Programmable Logic Preprocessing → AI Engine / NPU → Postprocessing → CPU Application
The key is workload partitioning.
Do Not Run Every Algorithm on the Same Compute Engine.
65 — Image & Video Processing
FPGA architectures are particularly effective when data is naturally streaming.
Applications can involve:
The key advantage is processing pixels while they arrive.
Process the Frame Without Waiting for the Frame.
66 — Sensor Fusion
FPGA / SoC systems can synchronize multiple sensor inputs:
Camera
IMU
Encoder
GNSS
Other Sensors
Accurate sensor fusion often depends on:
FPGA hardware can provide precise timing relationships that may be difficult to maintain in software-only architectures.
67 — Real-Time Control with FPGA
FPGA hardware can execute deterministic control loops with fixed timing.
Applications may include:
power electronics
precision motion
high-speed control
instrumentation
Architecture can combine: ADC Sampling → Hardware Control Algorithm → PWM
with deterministic cycle timing.
Control Latency Can Be Designed in Clock Cycles.
68 — FPGA Functional Safety & Reliability Architecture
For appropriate high-reliability applications, FPGA architecture may consider:
The exact techniques depend heavily on product requirements and applicable standards.
Specific safety certifications or compliance should only be claimed where the actual project and development process satisfy them.
69 — Fault Injection
FPGA verification can intentionally test failures such as:
memory error
communication loss
timeout
invalid protocol
clock loss
subsystem reset
The system should define: Detect → Contain → Recover or Enter Safe State
Reliability Engineering Includes Abnormal Behavior.
70 — Design for Test
Production hardware must be testable.
FPGA boards can provide:
JTAG
boundary scan
loopback
built-in test
memory tests
transceiver tests
test registers
The FPGA itself can become a powerful production-test instrument.
Use Programmability to Make the Product Easier to Manufacture.
71 — Boundary Scan
Boundary scan can provide test access to digital pins without requiring physical probes on every signal.
This can be especially useful for:
It can help identify:
opens
shorts
assembly problems
Dense FPGA Boards Need Test Strategies Designed Before Layout.
72 — Production Test Bitstreams
Manufacturing may use a dedicated FPGA image instead of the final product image.
A production image can test:
DDR
interfaces
GPIO
transceivers
Flash
communication ports
This can make production diagnosis much faster.
After PASS:
can be programmed.
73 — Transceiver BER Testing
High-speed serial links may be validated using:
This helps separate:
physical channel problems.
For difficult high-speed systems: BER Is the Final Language of the Channel.
74 — On-Chip Logic Analysis
FPGA tools can insert internal logic analyzers into the design.
These allow engineers to observe signals that do not exist on external pins.
Useful for:
state machines
protocol
internal buses
timing
data pipelines
But debug logic consumes resources and can affect timing.
Debug architecture should therefore be planned rather than added randomly.
75 — Performance Instrumentation
Large FPGA systems benefit from internal performance counters.
These may measure:
packet rate
DMA bandwidth
FIFO occupancy
dropped packets
memory latency
error count
This allows the real hardware to answer: Where Is the Bottleneck?
76 — FPGA Design Reviews
A mature FPGA program should have formal engineering reviews.
Architecture Review
Is the data flow correct?
RTL Review
Is implementation structurally sound?
CDC / RDC Review
Are domain crossings safe?
Verification Review
Has important functionality been covered?
Timing Review
Are constraints and margins correct?
Resource Review
Is there sufficient headroom?
Hardware Review
Can the PCB support the FPGA?
Design Review Is Cheaper Than Debugging a Fundamental Architecture Mistake in Hardware.
77 — FPGA CI / Automated Builds
Large FPGA projects should increasingly be treated like serious software/hardware codebases.
A controlled development pipeline can include: Version Control → Automated Lint → Simulation → Synthesis → Implementation → Timing Check → Bitstream
Build results can be archived with:
commit ID
tool version
constraints
reports
A Production Bitstream Should Be Reproducible.
78 — Tool & IP Version Control
FPGA results can change when:
Therefore the released product should identify:
RTL Revision
IP Revision
Tool Version
Constraint Revision
Bitstream Hash
This is essential for configuration control.
79 — FPGA IP Reuse
Reusable IP can shorten future projects.
Potential internal IP libraries may include:
interfaces
FIFOs
DMA
timestamping
DSP blocks
diagnostics
protocol bridges
But IP reuse should include:
Verification
Documentation
Versioning
rather than simply copying old HDL.
Reuse Verified Engineering — Not Old Bugs.
80 — FPGA Lifecycle Engineering
FPGA-based products can remain in production for many years.
Engineering therefore needs to consider:
AMD currently states long lifecycle commitments extending to 2045+ for major first-generation Versal series, illustrating why lifecycle information matters when selecting a programmable platform for long-lived products.
Programmable Logic Does Not Eliminate Component Lifecycle Risk.
FPGA / DSP Engineering Through EVT / DVT / PVT
EVT — Prove the Architecture
EVT should answer:
Does the FPGA configure reliably?
Does DDR work?
Are clocks stable?
Do core interfaces operate?
Does the DSP algorithm meet performance?
Are transceivers functional?
Is power acceptable?
The goal is to expose fundamental architectural risk.
DVT — Prove the Product
DVT can validate:
The production architecture should now be approaching maturity.
PVT — Prove the Manufacturing System
PVT focuses increasingly on:
board assembly
FPGA programming
production testing
DDR validation
transceiver validation
traceability
test cycle time
yield
One FPGA Board Working Is Engineering.
Hundreds Working Repeatedly Is Industrialization.
What Does World-Class FPGA / DSP Design Look Like?
At the highest level: Product Requirements → Data-Flow Architecture → FPGA / SoC Selection → Hardware / Software Partitioning → DSP Algorithm → Fixed-Point / Numerical Architecture → RTL / HLS → Clock / Reset Architecture → CDC / RDC → AXI / NoC → DDR / HBM → SerDes → PCIe / Ethernet / JESD → Simulation → Assertions / UVM / Formal → STA → Timing Closure → Power / Thermal → SI / PI → PCB Integration → Board Bring-Up → Hardware Verification → EVT → DVT → PVT → Production Test → Deterministic High-Performance Product
That is the difference between: Writing FPGA Code and Engineering a High-Performance Digital Processing Platform.
Typical FPGA / DSP Design Deliverables
Depending on project scope, deliverables may include:
FPGA System Architecture
Device Selection Report
FPGA Resource Budget
Data-Flow Architecture
Hardware / Software Partitioning
DSP Algorithm Architecture
Floating-Point Reference Model
Fixed-Point Model
Numerical Error Analysis
RTL Architecture
Verilog / VHDL / SystemVerilog Source
HLS Source where applicable
Reusable IP Blocks
AXI / NoC Architecture
Address Map
DMA Architecture
DDR Architecture
HBM Architecture
Clock Architecture
Reset Architecture
CDC Analysis
RDC Analysis
PCIe Architecture
Ethernet Architecture
JESD Architecture
SerDes Configuration
Timing Constraints
STA Reports
Timing-Closure Report
Resource-Utilization Report
Power Analysis
Thermal Inputs
SI / PI Requirements
PCB High-Speed Constraints
RTL Testbench
SystemVerilog Assertions
UVM Environment where appropriate
Functional Coverage
Formal Verification Results where appropriate
Bit-Accurate DSP Verification
FPGA Bring-Up Plan
Production-Test Bitstream
Boundary-Scan Strategy
EVT Validation Plan
DVT Validation Plan
PVT Inputs
FPGA Release Package
Bitstream
Tool-Version Record
IP-Version Record
Hardware / FPGA Compatibility Matrix
Production Programming Procedure
Lifecycle & Migration Plan
What Can You Bring to 365PCB?
You can begin with:
or simply: Tell Us How Much Data Must Be Processed — and How Fast.
Engineering can help translate: Algorithm → Architecture → FPGA → PCB → Validation → Production.
Don't Just Make the RTL Simulate.
Make It Meet Timing.
Make It Move the Required Data.
Make It Deterministic.
Make It Verifiable.
Make It Work on the Real PCB.
Make It Production-Ready.
365PCB FPGA / DSP Design connects: Programmable Logic + DSP + High-Speed Interfaces + Memory + Verification + PCB + Manufacturing
English
