What a mux is

A 2:1 multiplexer implements y = s′·a + s·b. An N:1 mux generalizes this: the select value picks one input for the output.

In hardware it is a tree of 2:1 muxes. Its depth is ⌈log₂ N⌉.

Read the tree from the inputs on the left to y on the right. Each column is one level of 2:1 muxes.

• Level 1: sel[0] picks one input from each pair, so both first-level muxes switch together.

• Level 2: sel[1] picks which pair wins.

• Depth: four inputs need two levels; eight would need three. That is ⌈log₂ N⌉.

The bottom row, y, always copies the input that sel names.

• Slot 1: sel 0 selects a (1).

• Slot 2: sel 1 selects b (2).

• Slot 3: sel 2 selects c (3).

• Slot 4: sel 3 selects d (4).

Coding styles

Three listings describe one hardware. The full code sits under Testbench below; the table summarizes the trade-offs.

case, casez, casex, unique and priority

Start with plain case plus a default.

• Plain case with a default is the safe choice. Every selector value maps somewhere, so no latch is inferred.

• unique case promises non-overlapping matches. Without a default, simulation also warns when nothing matches, and synthesis may optimize unmatched values as don't-cares. A default is legal and gives fallback behavior, but suppresses that no-match warning. If unmatched selectors are illegal, check legality separately even when a safe default is present.

• priority case is for planned overlap. Branch order picks the winner.

• casez treats Z (including ?) in either the selector or the case items as wildcards. Masked constants are useful, but a disconnected selector bit can therefore match a real request. Check that the selector is known before relying on the decoded result.

• casex also treats X and Z in the selector as wildcards. So an unknown selector can match the wrong branch. Avoid it.

For this decoder, req = 4'b000z matches ???1 and reports request 0. The test deliberately injects that disconnected bit: the known-input assertion must reject it even though the decoder produces a plausible index. In a normal protocol monitor, use $error in the assertion's failure branch; here the expected rejection is counted so the demonstration itself can pass.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

module req_decode (
  input  logic [3:0] req,
  output logic [1:0] idx,
  output logic       valid
);
  always_comb begin
    idx = 2'd0; valid = 1'b0;
    casez (req)
      4'b???1: begin idx = 2'd0; valid = 1'b1; end
      4'b??10: begin idx = 2'd1; valid = 1'b1; end
      4'b?100: begin idx = 2'd2; valid = 1'b1; end
      4'b1000: begin idx = 2'd3; valid = 1'b1; end
      default: begin idx = 2'd0; valid = 1'b0; end
    endcase
  end
endmodule

module tb_req_decode;
  logic [3:0] req;
  logic [1:0] idx;
  logic valid;
  int errors = 0, rejected = 0;
  req_decode dut (.*);

  initial begin
    req = 4'b0001; #1;
    assert (!$isunknown(req)) else errors++;
    if ({valid, idx} !== 3'b100) errors++;
    req = 4'b0000; #1;
    if (valid !== 1'b0) errors++;

    req = 4'b000z; #1;
    assert (!$isunknown(req)) else rejected++;
    if ({valid, idx} !== 3'b100) errors++; // Z is a wildcard, not an idle request
    if (rejected != 1) errors++;
    if (errors == 0) $display("PASS: known requests decode; the input guard catches selector Z");
    else $display("FAIL: errors=%0d rejected=%0d", errors, rejected);
    $finish;
  end
endmodule

AND-OR form

A mux can also use AND-OR form: y = (s0 & a) | (s1 & b) | ....

Use it when the selects are already one-hot, like decoder or arbiter outputs. It has shallow depth: one AND stage plus one wide OR.

With bounded fan-in f, the OR becomes a tree: the idealized AND-OR depth is roughly 1 + ceil(log_f N), plus routing and load. It grows more slowly than a literal N-deep priority chain, not at constant cost. It works only if at most one select is active (all-zero selects give 0).

Common mistakes

Testbench

All three styles plus the testbench that proves they agree for binary select values.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// 1) ternary chain: compact for 2:1, grows unreadable beyond that
module mux4_ternary (input logic [7:0] a, b, c, d, input logic [1:0] sel, output logic [7:0] y);
  assign y = (sel == 2'd0) ? a :
             (sel == 2'd1) ? b :
             (sel == 2'd2) ? c : d;
endmodule

// 2) case statement: clear, easy to extend, the usual choice
module mux4_case (input logic [7:0] a, b, c, d, input logic [1:0] sel, output logic [7:0] y);
  always_comb begin
    case (sel)
      2'd0:    y = a;
      2'd1:    y = b;
      2'd2:    y = c;
      default: y = d;
    endcase
  end
endmodule

// 3) array index: scales to any N and is easy to parameterize
module mux4_index (input logic [7:0] a, b, c, d, input logic [1:0] sel, output logic [7:0] y);
  logic [7:0] in [4];
  always_comb begin
    in[0] = a; in[1] = b; in[2] = c; in[3] = d;
    y = in[sel];
  end
endmodule

Related topics

• Parameterized mux

• Latch inference