Day 2 · Combinational Building Blocks

Sized Literals & Width Matching

Video 3 of 4 · ~10 minutes

Dr. Mike Borowczak · Electrical & Computer Engineering · CECS · UCF

Video 3 of 4 for Day 2. This topic looks like syntactic fussiness but it's the #1 source of silent bugs in student Verilog. By the end you'll never write a naked 0 or 1 again.

🌍 Where This Lives

In Industry

Every corporate Verilog lint rule includes “no unsized literals.” Mentor Verissimo, Spyglass, Verilator — all of them flag this. “Explicit width” is the most common lint rule in existence. Why? Because the failure mode is silent data loss.

In This Course

Your Day 3 ALU result width matters. Day 4 counter rollover depends on it. Day 9 address math fails silently if widths mismatch. Day 11 UART baud-rate counters — same. This one skill protects you across the whole course.

Career tag: A senior engineer scanning your code can tell in 10 seconds whether you size your literals. If you don't, you're still thinking in software. If you do, you're thinking in bits.

⚠️ Numbers Without Widths Are Booby Traps

❌ Wrong Model

“Writing 0 or 1 is just like in C — the compiler figures out the width from context.”

✓ Right Model

Unsized literals in Verilog default to 32 bits (not “whatever fits”). Width mismatches are silently zero-extended or truncated. Your simulation might pass. Your synthesis might pass. Your waveform will lie.

The receipt: wire [3:0] x = 4'b1111 + 1; — the 1 is 32 bits. The addition is 32-bit. The assignment truncates. Result: x = 0. iverilog warns if you use -Wall (and almost nobody does by default).

👁️ I Do — The Sized-Literal Format

// Format: <width>'<base><value>
4'b1010          // 4 bits, binary
8'hFF            // 8 bits, hex (= 8'd255 = 8'b11111111)
4'd9             // 4 bits, decimal
1'b0             // single bit zero
32'd0            // 32-bit zero (explicit)
16'hABCD         // 16 bits, hex

// Underscores for readability (ignored by tools):
32'h1234_5678    // 32-bit hex, easier to read
8'b1011_0010     // 8-bit binary grouped by nibble

My habit: Always specify width. Always use hex for multi-bit constants unless I'm encoding a specific bit pattern (then binary). Underscores every 4 bits for anything 8+ bits wide.

🤝 We Do — Spot the Width Bug

wire [3:0] w_a = 4'b1010;     // 10
wire [3:0] w_b = 4'b0110;     //  6
wire [3:0] w_sum = w_a + w_b; // expect 16 → ???
wire [3:0] w_doubled = w_a << 1; // expect 20 → ???

Answers (reveal after discussion): w_sum = 4'b0000 = 0 (silent overflow: 16 doesn't fit in 4 bits). w_doubled = 4'b0100 = 4 (MSB shifted off). The simulation “works” — it just gives wrong answers.

Fix: wire [4:0] w_sum = w_a + w_b; — widen the result by one bit to catch the carry. For multiplication, widen by 2N bits.

🧪 You Do — Predict, Then Verify

For each expression, what value does x hold?

// 1.
wire [3:0] x1 = 4'd5 + 4'd12;
// 2.
wire [4:0] x2 = 4'd5 + 4'd12;
// 3.
wire [7:0] x3 = 8'hFF + 1;
// 4.
wire [7:0] x4 = 8'hFF + 8'd1;

Answers: (1) 4'b0001 = 1 — 17 truncated to 4 bits. (2) 5'b10001 = 17 — widened to 5 bits, correct. (3) 8'h00 = 0 — the literal 1 is 32-bit, addition is 32-bit (256), truncated to 8-bit. (4) 8'h00 = 0 — same 8+8 overflow. At least this one is explicit. Fix: make result 9 bits.

The interesting comparison is (3) vs (4). Both truncate. But (4) is explicit — a reader can see the 8-bit addition. (3) is a booby trap — the 1 looks innocent. Always prefer (4).

▶ LIVE DEMO

Width Mismatch — Compiler & Synthesis Warnings

~4 minutes

▸ COMMANDS

cd labs/week1_day02/ex3_width_bugs/
iverilog -g2012 -Wall -o sim.vvp width_bugs.v
vvp sim.vvp
yosys -p "read_verilog width_bugs.v; \
    synth_ice40" 2>&1 | grep -i 'warn'

▸ EXPECTED OUTPUT

width_bugs.v:12: warning:
  Operand of 32-bit width added to
  4-bit result; truncation occurs.

Warning: Result of addition to
  4-bit signal ignores upper bits.

▸ KEY OBSERVATION

Without -Wall, iverilog is silent by default. Run any sim with -Wall once per session. Warnings that mention “truncation,” “width,” or “widen” are almost always real bugs. Treat them as errors.

🔧 What Did the Tool Build?

Same code, with and without the width fix:

Buggy

wire [3:0] x = a + b;
// → 4 LUTs + 4 carry
// → result wraps at 16

Fixed

wire [4:0] x = a + b;
// → 5 LUTs + 4 carry
// → result 0..30 accurately

Cost of correctness: one extra LUT. That's it. There is almost never a good reason to undersize a sum or product — the hardware savings are trivial compared to the debugging time saved.

🤖 Check the Machine

Ask AI: “In Verilog, what is the bit-width of 1? What about 8'd1? What about 1'b1?”

TASK

Ask AI about widths of three literal forms.

BEFORE

Predict: 1 = 32 bits. 8'd1 = 8 bits. 1'b1 = 1 bit. All = value 1.

AFTER

Good AI gets this right. Some models say 1 is 1-bit — wrong. That model is unreliable for Verilog.

TAKEAWAY

Quick diagnostic: if AI says 1 is 1 bit, switch models.

Authoritative reference: IEEE 1364-2005 §4.1: unsized numbers are at least 32 bits. This is why 32'd1 and bare 1 behave identically in most expressions.

Good diagnostic test for AI models. If it says unsized 1 is 1-bit, the model is confused about Verilog vs. C. Use a different model for HDL work.

Key Takeaways

① Unsized literals are 32 bits, not “auto-sized.”

② Always size your literals: 4'd1, not 1.

③ N+N addition needs N+1 bits of result to avoid overflow.

④ Use iverilog -Wall every session. Read the warnings.

If the width isn't written down, you're guessing. Hardware doesn't guess.

🔗 Transfer

The 7-Segment Display

Video 4 of 4 · ~10 minutes

▸ WHY THIS MATTERS NEXT

Time to put it all together. Video 4 builds a hex-to-7-segment decoder — your first real peripheral. It uses vectors (from Video 1), case statements (preview of Day 3), sized literals (from this video), and actually lights up your Go Board. This is the first moment where you'll see your code become real, glowing hardware.