fpgadesign.io #2 — The Shift that Costs Zero Logic Levels

fpgadesign.io #2 — The Shift that Costs Zero Logic Levels

fpgadesign.io — Issue #2
RTL & FPGA design, explained the way interviews actually test it.

👋 Welcome back.

Last issue: timing. Setup, hold, and why a hold violation is the one that should scare you. Several of you replied with your attempts at the skip-3 counter. Exactly what I hoped for. (Haven't tried it? Still worth a shot — just reply.)

This time, something that looks much simpler. Shifting. 🤔

Most answers I hear about it are technically correct.

And completely miss the point.

Shift a value left by a fixed amount, and on an FPGA it can cost nothing. No LUTs. No gates. Not even a logic level.

Make that same shift amount a variable? The cost explodes. A network of muxes that eats area and drags down your clock.

Same operation. Wildly different hardware.

That gap is the whole lesson today.

⚡ Concept of the Week: The shift that's free — until it isn't

Start with the thing everyone half-remembers. Shifting is scaling by powers of 2. Left by 1 is ×2.
Left by 3 is ×8.
Right by 2 is ÷4.
No multiplier. No divider.
Just a reinterpretation of which bit sits in which position.

🔍Now the part interviews are really probing.

When the shift amount is a constant, an FPGA doesn't use any fabric combinatorial logic like LUTs, to implement the shift operation.

data_out = data_in << 1 synthesizes to wires.
Something to think about: Do we even need the << operator or can we just assign a specific bit-slice?

The tool knows at elaboration exactly which input bit feeds which output bit. So it routes bit i to bit i+1 through the interconnect and bypasses the LUTs entirely. Zero logic levels.
The book calls this wire-shifting (Chapter 3, p.167) — one of the most elegant "free lunch" moves in FPGA design. ✅

Now change one thing. Make the shift amount a variable (or a signal) instead of a constant. ⚠️

Everything changes.

The hardware has to be ready to shift by any amount, on any cycle. That's a barrel shifter — a combinational circuit that shifts by a variable number of positions in a single clock. Fast? Yes, single-cycle. But it's built from log₂(width) layers of muxes. Real LUTs. Routing congestion. A live path in your timing report. The book is blunt about it (§6.2, Q.169, p.255): the barrel shifter's speed comes at the cost of resources, congestion, and clock speed.

Its sequential cousin, the shift register, makes the opposite trade. One bit per clock. n clocks to move n positions. Cheap in area, slow in latency. The barrel shifter does in one cycle what the shift register takes n cycles to do. You're trading logic for time. (§6.2, Q.168.)

💡 Here's the main takeaway. The one that separates a textbook answer from an engineer's answer.

The cost was never in "shifting." It's in whether the amount is known at compile time.

Constant → wires. Free.
Variable → barrel shifter. Expensive.

Which is exactly why declaring a shift amount as a parameter instead of a register can collapse an entire shifter down to routing. The tool propagates the constant. The "extra" hardware disappears.

🎯 Interview Question of the Week

Q: "data_out = data_in << 3. How many logic levels does that add? And what changes if the 3 is a signal instead of a constant?"

✏️ How to approach it: Don't just say "it shifts."

Lead with the constant case. Zero logic levels — the tool resolves the connection at elaboration and wire-shifts it through routing.

Then flip it. Make the amount a runtime signal and you've asked for a barrel shifter. A log₂(width)-deep mux tree. Real LUTs. A real timing cost.

The interviewer is watching for one thing: can you connect compile-time vs runtime to actual hardware?

That link is the answer. 📖 (This is Q.168–169, Chapter 6.)

🧩 Design Question of the Week

Design: A continuous bit stream, one bit per clock. Generate a single-cycle pulse whenever the last 12 bits form a palindrome — reads the same forwards and backwards. No start bit. No end bit. The window just slides every clock.

How would you build it?

And how does your approach scale if the window grows to 32 bits? 🤔

Give it a shot. If the problem statement is unclear, or you want to talk through your approach, just reply — I read every email. 🙋

🛠 Author's Note

If a shift amount is fixed by your architecture, declare it as a parameter or localparam. Never a register "just in case."

Reach for a register to "keep it flexible," and you've paid for a full barrel shifter you'll never use. ❌

In my experience, "flexible" hardware that nobody ever reconfigured has cost more timing than almost anything else I've seen.

🎓 From the Field: What the panel is actually scoring

When you answer the shift question, the panel isn't checking whether you know the words "barrel shifter."

They're watching how you get there.

Two candidates. Same knowledge.

✏️ The first says: "I'd use a barrel shifter."

✏️ The second says: "If the shift is constant, it's free — the tool just reroutes. If it's variable, I'd use a barrel shifter, and I'd flag that it costs a mux tree and some fmax."

Identical facts. Completely different score.

💡 What a hiring manager screens for on a design question is rarely the final answer. It's whether you reach for the simplest thing first. Whether you know the cost of what you propose. And whether you volunteer the trade-off before you're asked.

That last one is the tell. Naming the downside of your own design, unprompted, is what senior engineers do without thinking about it.

🔖 Do that, and you've answered a question the interviewer hadn't even gotten to yet.

📌 Latest from fpgadesign.io

✍️ On the blog: Designing a Skip-3 Counter — count up, never land on a multiple of 3. No divider. No modulo. The trick is reading the sequence, not doing the arithmetic. Three ways to build it, and when you'd pick each.

🔄 ICYMI on LinkedIn:

The Skip-3 design challenge — the interview problem behind that blog post. The pattern-over-arithmetic move shows up everywhere.

The 12-bit palindrome detector — this issue's design problem, in its original form. Store the data, test the property. No FSM needed.

A long timing report isn't how much is broken — 4,759 violations rarely means 4,759 problems. They cluster. Group them by root cause.

🔗 Worth Reading

📄 Vivado Design Suite User Guide: Synthesis (UG901) — the free reference for what your RTL operators actually become in hardware. Want to see exactly when a shift stays as routing and when it turns into logic? This is where the tool's behavior is documented.

💬 Reader Mailbag

Last issue I asked what interview topic you find hardest, and why. Those replies are still coming in — keep them coming. They shape these issues. 🙏

This issue's question: what's a piece of RTL you rewrote once you understood what it actually synthesized to?

The "flexible" register that should've been a parameter counts.

Hit reply. The best ones will show up in a future issue. 🙋

📡 On the Radar

🔺 AMD ships Vivado & Vitis 2026.1 with a new tiered licensing model — broad new device support (Versal Gen 2 families, Spartan UltraScale+), and the tools moved to pay-for-what-you-target licensing. Know which tier covers the device family your role actually uses. It now affects what you can even run.

🔷 Altera's Agilex 3 FPGAs are in production and orderable — small form-factor parts with AI and an integrated MCU on-device. The MCU-plus-fabric packaging keeps blurring the MCU/FPGA line. Expect more embedded and PS-PL partitioning questions, not just fabric.

🤖 Altera's FPGA AI Suite adds a spatial architecture that maps AI models directly onto Agilex silicon. "AI on FPGA" is shifting from hand-written HLS toward dedicated flows. Watch this if you're anywhere near ML inference on hardware.

📘 Before you go

New here? The free SystemVerilog and design-problem question banks on fpgadesign.io just got a big update. That's the best place to start. No signup required. 🎁

Until next time,
Milind

📘 Get the book · 🔗 LinkedIn · ✉️ Email

Forward this to one engineer prepping for interviews — that's how this grows.

📰 Missed an issue? All previous newsletters live here.

Subscribe to fpgadesign.io

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe