Exercise set

Digital Hardware, FPGA Design, and Timing Verification Exercises

Worked electronic engineering exercises for digital hardware and FPGA design covering clock period, setup slack, hold margin, throughput, latency, FIFO depth, jitter budget, dynamic power, I/O timing, reset synchronization, RPN, and bitstream release evidence.

Branch: Electronic Engineering
Content: Exercise set
Updated: Jun 20, 2026
Revision: v1.1.0 · reviewed

These exercises practise digital hardware and FPGA design as timing, interface, verification, and release evidence work. They cover clock period, setup slack, hold margin, throughput, latency, FIFO depth, jitter budget, dynamic power, I/O timing, reset synchronization, risk priority, and bitstream release evidence.

The goal is not only to calculate a timing number. The goal is to decide whether RTL architecture, timing constraints, board interfaces, clocks, power, reset behavior, verification, and bring-up evidence support the same product requirement.

Assume simplified screening models unless an exercise states otherwise. Real digital hardware projects should also check complete constraints, clock-domain crossings, generated clocks, false paths, multicycle paths, I/O standards, board delay, voltage and temperature corners, tool warnings, firmware state, and production programming records.

How to Use These Exercises

For each exercise, define:

the clock domain, interface, or state machine being assessed;
the timing, throughput, latency, or safety requirement;
the constraint or measurement evidence behind the number;
the hardware behavior during reset, fault, and update states;
the release record needed before the design can be trusted.

The common mistake is treating FPGA or digital hardware design as software that happens to run on silicon. RTL becomes physical logic with timing, power, routing, reset, and board-level consequences.

For each result, state whether it supports architecture sizing, timing closure, CDC acceptance, reset-release review, board-interface validation, power release, or bitstream configuration control. A passing calculation should not be treated as release evidence unless the matching constraint, tool report, board revision, and validation record are identified.

Exercise 1: Clock Period from Frequency

An FPGA clock runs at:

f=125\ \text{MHz}

Calculate the clock period.

Solution

Clock period is:

\displaystyle T=\frac{1}{f}

Substitute:

\displaystyle T=\frac{1}{125\times10^6}=8.0\times10^{-9}\ \text{s}

Therefore:

T=8.0\ \text{ns}

Engineering Comment

An 8 ns period is the total budget before subtracting clock uncertainty, skew, setup time, routing, and logic delay. A design that looks simple in RTL may still fail if one combinational path consumes too much of this period.

Exercise 2: Setup Slack

A register-to-register path has clock period:

T=10.0\ \text{ns}

Clock uncertainty is:

U=0.35\ \text{ns}

Setup time is:

t_{setup}=0.20\ \text{ns}

The data path delay is:

t_{data}=8.90\ \text{ns}

Compute setup slack:

S_{setup}=T-U-t_{setup}-t_{data}

Solution

Substitute:

S_{setup}=10.0-0.35-0.20-8.90=0.55\ \text{ns}

The path has positive setup slack of:

S_{setup}=0.55\ \text{ns}

Engineering Comment

Positive slack indicates this simplified path passes. The remaining margin may still be weak if placement changes, voltage and temperature corners are severe, or constraints fail to include board-level I/O timing.

Exercise 3: Hold Margin

A hold check has minimum data delay:

t_{data,min}=0.42\ \text{ns}

Hold requirement is:

t_{hold}=0.12\ \text{ns}

Clock skew makes capture occur:

t_{skew}=0.18\ \text{ns}

earlier relative to launch. Estimate hold margin:

S_{hold}=t_{data,min}-t_{hold}-t_{skew}

Solution

Substitute:

S_{hold}=0.42-0.12-0.18=0.12\ \text{ns}

The hold margin is:

S_{hold}=0.12\ \text{ns}

Engineering Comment

Hold margin is positive but small. Hold problems cannot be fixed by lowering clock frequency. They need routing delay, constraint correction, clock-tree review, synchronizer review, or tool-driven hold fixing.

Exercise 4: Usable Data Rate

A streaming interface has data width:

W=32\ \text{bits}

Clock frequency:

f=100\ \text{MHz}

Protocol efficiency:

\eta=0.75

Estimate usable data rate:

R=Wf\eta

Solution

Substitute:

R=(32)(100\times10^6)(0.75)

R=2.4\times10^9\ \text{bit/s}

Therefore:

R=2.4\ \text{Gb/s}

Engineering Comment

This is only a first-pass throughput estimate. Real throughput can be reduced by arbitration, backpressure, packet gaps, memory refresh, software service time, retries, and clock-domain crossings.

Exercise 5: Latency Budget

A digital measurement path has:

Stage	Latency
ADC interface	4 cycles
FPGA filter	18 cycles
Packet formatter	6 cycles
Output interface	12 cycles

The processing clock is:

f=50\ \text{MHz}

Calculate total latency in microseconds.

Solution

Total cycles:

N=4+18+6+12=40\ \text{cycles}

Clock period:

\displaystyle T=\frac{1}{50\times10^6}=20\ \text{ns}

Total latency:

T_{total}=NT=40(20)=800\ \text{ns}

Convert:

T_{total}=0.80\ \mu\text{s}

Engineering Comment

Average latency is not enough for control, protection, or timestamping. Check worst-case buffering, interrupt scheduling, bus arbitration, clock-domain crossings, and firmware service delays.

Exercise 6: FIFO Depth for Rate Mismatch

A producer writes data at:

R_p=120\ \text{MB/s}

A consumer drains data at:

R_c=96\ \text{MB/s}

The burst duration is:

t_b=250\ \mu\text{s}

Estimate the FIFO depth needed to absorb the burst.

Solution

Rate mismatch:

\Delta R=R_p-R_c=120-96=24\ \text{MB/s}

Required storage:

D=\Delta R t_b

Convert burst time:

t_b=250\times10^{-6}\ \text{s}

Compute:

D=(24\times10^6)(250\times10^{-6})=6{,}000\ \text{bytes}

The FIFO needs at least about 6 kB before adding margin.

Engineering Comment

FIFO sizing should include clock tolerance, packet overhead, backpressure latency, almost-full thresholds, reset behavior, and what happens if the consumer stalls longer than expected.

Exercise 7: Jitter Budget Fraction

A serial interface has total allowed RMS jitter:

J_{max}=80\ \text{ps}

The clock source contributes:

J_{clk}=35\ \text{ps}

The board and receiver budget allocate:

J_{other}=50\ \text{ps}

Assuming independent contributors, estimate total jitter:

J_{total}=\sqrt{J_{clk}^2+J_{other}^2}

Solution

Substitute:

J_{total}=\sqrt{35^2+50^2}

J_{total}=\sqrt{1225+2500}=\sqrt{3725}=61.0\ \text{ps}

Compare:

61.0\ \text{ps}<80\ \text{ps}

The simplified jitter budget passes.

Engineering Comment

The RSS assumption needs justification. Correlated jitter, power noise, crosstalk, PLL peaking, spread-spectrum clocking, and measurement bandwidth can make the real margin smaller.

Exercise 8: Dynamic Power Estimate

A digital block has effective switched capacitance:

C=18\ \text{pF}

Supply voltage:

V=1.0\ \text{V}

Clock frequency:

f=200\ \text{MHz}

Activity factor:

\alpha=0.35

Estimate dynamic power:

P=\alpha C V^2 f

Solution

Convert:

C=18\times10^{-12}\ \text{F}

Substitute:

P=(0.35)(18\times10^{-12})(1.0)^2(200\times10^6)

P=1.26\times10^{-3}\ \text{W}

Therefore:

P=1.26\ \text{mW}

Engineering Comment

This is a small block estimate. FPGA total power also includes clock trees, routing, block RAM, DSP blocks, I/O banks, leakage, configuration, and simultaneous switching. Use measured activity or post-implementation power analysis before thermal release.

Exercise 9: Board I/O Timing Margin

An FPGA output interface has available clock-to-capture period:

T=6.0\ \text{ns}

FPGA clock-to-output delay:

t_{co}=1.2\ \text{ns}

Board trace delay:

t_{pcb}=0.8\ \text{ns}

Receiver setup time:

t_{setup}=1.1\ \text{ns}

Clock uncertainty:

U=0.4\ \text{ns}

Calculate timing margin:

M=T-t_{co}-t_{pcb}-t_{setup}-U

Solution

Substitute:

M=6.0-1.2-0.8-1.1-0.4=2.5\ \text{ns}

The interface has 2.5 ns simplified setup margin.

Engineering Comment

This margin is useful only if constraints include external device timing, board delay, clock relationship, voltage and temperature variation, and the correct I/O standard. Unconstrained I/O paths can pass internal timing and fail on the board.

Exercise 10: Reset Synchronizer Latency

A reset release is passed through a three-flip-flop synchronizer in a clock domain running at:

f=75\ \text{MHz}

Estimate reset-release latency in nanoseconds.

Solution

Clock period:

\displaystyle T=\frac{1}{75\times10^6}=13.33\ \text{ns}

Three cycles:

T_{reset}=3T=3(13.33)=40.0\ \text{ns}

Engineering Comment

The synchronizer adds a small deterministic release delay and reduces unsafe asynchronous release. The reset strategy still needs review for multiple clock domains, reset ordering, external peripherals, configuration pins, and safe output states.

Exercise 11: Risk Priority Number for a CDC Fault

A clock-domain crossing fault has ratings:

S=9

O=3

D=6

Calculate risk priority number:

RPN=SOD

Solution

Compute:

RPN=(9)(3)(6)=162

Engineering Comment

CDC failures can be intermittent and hard to reproduce, so detection rating is often worse than teams expect. A high-severity CDC risk should trigger structural review, synchronizer or handshake design, CDC tool checks, simulation, and hardware stress testing.

Exercise 12: Bitstream Release Evidence Completion

A digital hardware release package requires ten evidence items:

RTL revision identified;
constraints file revision archived;
static timing report clean;
unconstrained paths reviewed;
clock-domain crossing review complete;
reset behavior tested;
resource utilization archived;
power estimate reviewed;
board revision and bitstream ID matched;
production programming procedure released.

Eight items are complete.

Calculate completion percentage and decide whether release is acceptable if all ten items are mandatory.

Solution

Completion fraction:

\displaystyle f=\frac{8}{10}=0.80

Convert:

f=80\%

Because all ten items are mandatory, release is not acceptable.

Engineering Comment

A bitstream without matching constraints, timing reports, board revision, and programming procedure is not a controlled product configuration. Digital hardware release is evidence control, not only successful compilation.

Review Checklist

When reviewing digital hardware or FPGA evidence, ask:

Are all clocks, generated clocks, I/O paths, false paths, and multicycle paths intentionally constrained?
Is setup slack positive with realistic uncertainty, and is hold timing clean?
Are clock-domain crossings handled structurally rather than assumed safe?
Are reset assertion and reset release safe in every clock domain?
Do throughput and latency calculations include worst-case stalls, backpressure, and firmware interaction?
Are power and thermal estimates based on realistic switching activity?
Does hardware bring-up measure clocks, rails, interfaces, and fault states under real board conditions?
Are setup, hold, CDC, reset, I/O, and power results reviewed at the voltage, temperature, and process corners used for release?
Are waived warnings, unconstrained paths, false paths, and multicycle paths justified by design intent rather than convenience?
Can the released bitstream be traced to RTL, constraints, tool version, board revision, and validation evidence?

Good digital hardware design is controlled timing plus controlled evidence. Logic is ready only when simulation, constraints, timing reports, board behavior, and release records all describe the same system.

REF