Modern SoCs are 80–90% integration, not new design. A Qualcomm Snapdragon contains ARM CPUs, Arm Mali GPU, Qualcomm DSPs, Synopsys USB controllers, Cadence DDR controllers, and hundreds of third-party blocks. The integrator's job is to read datasheets, understand interfaces, wire them up correctly, and verify the composition. That's a whole engineering discipline — SoC integration — with its own career track, salary band, and skill set.
In This Course
Today you've seen UART TX, UART RX, and SPI all built by composing Week 1-2 primitives. The capstone in Week 4 integrates UART + counter + FSM into a controller. Senior design projects live and die by integration. Today's video gives you the principles and the checklist.
Build vs. Integrate
Build
Starting from the spec, you design the RTL, write the testbench, synthesize, optimize, and validate. You own every line. It's creative, slow, and specific to your use case.
When to build: When no IP exists (truly novel problem), when cost matters more than time, when you need IP-level expertise, or when the block is the differentiator of your product.
Integrate
You take an existing module — yours from a previous project, open-source, or commercial — and wire it into your design. You own the wires and the testbench at your boundary, not the internals. Fast, productive, and standardized.
When to integrate: When a good IP exists (UART, SPI, I²C, USB, Ethernet — never reinvent), when time-to-market matters, when the function is commodity (not a differentiator).
The professional's balance: Build the parts that make your product unique. Integrate everything else. The iPhone's Apple Silicon differentiates via CPU/GPU/Neural Engine (built). USB-C, DDR5 memory controller, WiFi, Bluetooth (integrated). You cannot build everything — nor should you.
⚠️ “I'll Just Drop It In”
❌ Wrong Model
“The IP works. I'll just connect its ports to my wires and be done. What could go wrong?”
✓ Right Model
Integration has its own failure modes. Clock domain mismatches. Reset polarity mismatches. Signaling convention mismatches (active-low vs active-high, valid/ready vs req/ack). Timing expectations (is the input stable for the whole cycle?). You must verify the boundary with at least as much care as you'd verify the internals. Most integration bugs aren't in the IP — they're in the glue.
The receipt: Professional IP comes with a datasheet and integration guide. The guide is often longer than the datasheet. If you're integrating an IP without reading its integration guide, you're guessing.
IP Integration Checklist
☐ Read the datasheet — every parameter, every port, every timing diagram. Yes, all of it.
☐ Verify clock domain — is it same-clock as your logic? If not, synchronizers required at the boundary.
☐ Verify reset behavior — synchronous or asynchronous? Active high or active low? Duration requirement?
☐ Verify timing assumptions — is the input expected stable for the whole cycle, or is a transition mid-cycle OK?
☐ Check parameter defaults — do they match your usage? Always set parameters explicitly, don't trust defaults.
☐ Write a boundary testbench — tests your wiring, not the IP. Assumes IP is correct.
☐ Integration test at FPGA level — waveform + real hardware. Simulation won't catch every boundary bug.
☐ Document the interface — so the next person (or future-you) knows how to use the composition.
👁️ I Do — Composing Your Week 1-3 Library
Look at what you've built. Here's what a complete “echo server” (PC sends bytes, FPGA echoes back) needs:
FROM YOUR LIBRARY (reuse)
sync_2ff — CDC on RX input
debounce — if using button control
mod_n_counter — baud rate generation
piso_shift / sipo_shift — frame shifters
fifo — buffer between RX and TX
uart_tx — Day 11 composition
uart_rx — Day 12 composition
NEW FOR THIS DESIGN (build)
Top-level wrapper module
Pin constraints file (.pcf) for Go Board UART pins
FIFO sizing / backpressure decision
LED indicator logic (optional)
That's it. Four small new things; the rest is composition.
My thinking: The ratio of reused to new code on this project is ~10:1. That's because your Week 1-2 investment in parameterization and testability paid off: each primitive dropped in without modification.
🤝 Third-Party IP — What Commercial Looks Like
Open-source example: OpenCores, LiteX, picorv32. Commercial: ARM AMBA IP, Synopsys DesignWare. A commercial IP package typically ships:
File / artifact
Purpose
Datasheet PDF
Parameters, ports, timing diagrams, use cases
Integration guide PDF
CDC handling, reset requirements, coding examples
SystemVerilog / Verilog sources
Often encrypted for commercial IP — you never see the code
Testbench templates
How to drive the IP's ports for various scenarios
Example integrations
Working projects showing IP wired into SoC
Release notes
Known bugs, version changes, tool compatibility
Timing constraints
.sdc file with setup/hold on IP ports
Together: Your Week 1-2 modules could become commercial IP if you added these artifacts. The distinction between “student work” and “product” isn't the Verilog — it's the documentation. Professionals pay for the docs.
🧪 You Do — Score Your Echo-Server Design
You're about to integrate UART TX + UART RX + FIFO into an echo server. Walk the IP Integration Checklist for this composition. Which boxes are trivially checked? Which require work?
Expected audit:
☑ Datasheet — you wrote the header comments, you know the ports.
☑ Clock domain — all three modules use i_clk, same domain.
☑ Reset — all modules use synchronous active-high reset per convention.
☑ Signaling — all modules use valid/busy; FIFO uses full/empty.
⚠ Timing — need to verify FIFO never asserts full during active RX. Backpressure path!
⚠ Parameters — must set UART baud rate to match between TX and RX, and in two places.
☐ Boundary testbench — new: stress FIFO between RX and TX.
☐ FPGA bring-up — new: confirm loopback on real Go Board.
What to notice: The wrapper is 15 cells — tiny. The sub-modules dominate. That's the signature of a well-composed design: the wrapper is small because the components do the work. If your top-level ever grows larger than any individual sub-module, you're probably not composing properly — you're re-implementing.
🤖 Check the Machine
Ask AI: “I have uart_tx, uart_rx, and fifo modules. Write a top-level echo_server module that wires the RX into the FIFO and the FIFO into the TX, with proper handshaking. Include a boundary testbench.”
Strong AI handles FIFO full (dropped bytes). Weak AI ignores backpressure.
TAKEAWAY
Backpressure is the classic integration blind spot. Always ask about it explicitly.
Key Takeaways
① Modern hardware is 80–90% integration. Build only your differentiator.
② Integration bugs live at boundaries: clocks, resets, conventions, timing.
③ The IP Integration Checklist is not optional. Every integrated block passes it.
④ Your Week 1-2 library + Week 3 protocols = your personal IP portfolio.
A wrapper that's smaller than any of its sub-modules is doing its job right.
Pre-Class Self-Check
Q1: You integrate a UART IP written for a 50 MHz clock into your 25 MHz design. What's the most likely failure mode?
The baud-rate counter was sized for 50 MHz. At 25 MHz, the bit period is twice as long as it should be — effectively half the configured baud rate. Fix: either change the IP's clock parameter, or re-instantiate with the correct CLKS_PER_BIT.
Q2: You drop a third-party FIFO into your design but the simulator reports X on the output. What's the first thing to check?
Reset. Most FIFOs require reset to initialize internal pointers; without it, the read pointer starts uninitialized and the output is X. Check reset polarity and duration per the IP's datasheet.
Pre-Class Self-Check (cont.)
Q3: What's the single most important difference between a “student work” module and a “commercial IP” module?
Documentation and verification artifacts. The Verilog itself may be identical in quality. The difference is datasheet, integration guide, release notes, timing constraints, and a test suite that stranger-integrators can run. Professionals pay for docs.
Q4: When composing three modules into a top wrapper, how big (in cells) should the wrapper itself be?
Much smaller than any sub-module. The wrapper wires things together; it doesn't do work. If your wrapper is the biggest block, you're re-implementing instead of composing. Refactor the work into a named sub-module.
🔗 End of Week 3
Week 4: PPA & Capstone Integration
Design Space Exploration · Full-Stack Capstone
▸ WHY THIS MATTERS NEXT
You now have a complete personal IP library — primitives from Weeks 1-2, protocols from Week 3. Week 4 asks the question every product team asks: how good is it? You'll run the PPA exercise on a real integrated design, explore the tradeoff space (speed vs. area vs. power), and compose your library into a capstone integration — something demonstrable on the Go Board that's more than a homework problem. This is where the course stops teaching you RTL and starts teaching you product engineering. See you Day 13.