Read the complete curriculum

Focus: A digital signal has a name and a value. Here, 0 means LOW and 1 means HIGH. Each exercise gives the input and asks for one exact output.

Worked example: A = 0 → Y = 0
A = 1 → Y = 1

Learner activity: The circuit directly connects A to Y. If A is 1, what exact value must Y have?

Lab: Implement and observe Signals: 0 and 1

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: A, Y
Interactive inputs: A

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: AND produces Y=1 only when both A and B are 1. Every other input pair produces Y=0.

Worked example: A B | Y
0 0 | 0
0 1 | 0
1 0 | 0
1 1 | 1

Learner activity: Use the complete truth table. For A=1 and B=0, select the required output.

Lab: Implement and observe AND: both inputs required

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: A, B, Y
Interactive inputs: A, B

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: OR produces Y=1 when either input is 1. It produces Y=0 only when both inputs are 0.

Worked example: A B | Y
0 0 | 0
0 1 | 1
1 0 | 1
1 1 | 1

Learner activity: Use the complete truth table. For A=0 and B=1, select the required output.

Lab: Implement and observe OR: either input is enough

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: A, B, Y
Interactive inputs: A, B

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: NOT reverses one input: when A is 0, Y is 1; when A is 1, Y is 0.

Worked example: A | Y
0 | 1
1 | 0

Learner activity: Use the table. For A=1, what exact output is produced?

Lab: Implement and observe NOT: invert one input

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: A, Y
Interactive inputs: A

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: NAND means NOT-AND: Y is 0 only when both A and B are 1. Its ANSI symbol is an AND gate with an inversion bubble at the output.

Worked example: Y = NOT(A AND B)
A B | Y
0 0 | 1
0 1 | 1
1 0 | 1
1 1 | 0

Learner activity: For A=1 and B=1, what output does NAND produce?

Lab: Implement and observe NAND: inverted AND

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: A, B, Y
Interactive inputs: A, B

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: NOR means NOT-OR: Y is 1 only when both A and B are 0. Its ANSI symbol is an OR gate with an inversion bubble at the output.

Worked example: Y = NOT(A OR B)
A B | Y
0 0 | 1
0 1 | 0
1 0 | 0
1 1 | 0

Learner activity: For A=0 and B=0, what output does NOR produce?

Lab: Implement and observe NOR: inverted OR

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: A, B, Y
Interactive inputs: A, B

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: XOR produces Y=1 when A and B are different. Its ANSI symbol is an OR shape with one additional curved line on the input side.

Worked example: Y = A XOR B
A B | Y
0 0 | 0
0 1 | 1
1 0 | 1
1 1 | 0

Learner activity: For A=1 and B=0, what output does XOR produce?

Lab: Implement and observe XOR: inputs are different

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: A, B, Y
Interactive inputs: A, B

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: XNOR is inverted XOR: Y=1 when A and B are equal. Its ANSI symbol adds an output inversion bubble to the XOR symbol.

Worked example: Y = NOT(A XOR B)
A B | Y
0 0 | 1
0 1 | 0
1 0 | 0
1 1 | 1

Learner activity: For A=1 and B=1, what output does XNOR produce?

Lab: Implement and observe XNOR: inputs are equal

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: A, B, Y
Interactive inputs: A, B

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A 2:1 multiplexer sends A to Y when select S=0, and sends B to Y when S=1.

Worked example: A B S | Y
0 0 0 | 0
0 1 0 | 0
1 0 0 | 1
1 1 0 | 1
0 0 1 | 0
0 1 1 | 1
1 0 1 | 0
1 1 1 | 1

Learner activity: With S=1 and B=0, what is Y?

Lab: Implement and observe Multiplexer: choose one input

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: A, B, S, Y
Interactive inputs: A, B, S

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A demultiplexer sends one input D to exactly one selected output; the other output is 0.

Worked example: D S | Y0 Y1
0 0 | 0 0
1 0 | 1 0
0 1 | 0 0
1 1 | 0 1

Learner activity: With S=1 and D=1, what is Y1?

Lab: Implement and observe Demultiplexer: route one input

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: D, S, Y0, Y1
Interactive inputs: D, S

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A 2-to-4 decoder activates exactly one output for each two-bit input.

Worked example: A1 A0 | Y3 Y2 Y1 Y0
0 0 | 0 0 0 1
0 1 | 0 0 1 0
1 0 | 0 1 0 0
1 1 | 1 0 0 0

Learner activity: Which output is active for input 10?

Lab: Implement and observe Decoder: binary to one-hot

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: A1, A0, Y0, Y1, Y2, Y3
Interactive inputs: A1, A0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An encoder performs the reverse operation: the active input position becomes a binary code.

Worked example: D3 D2 D1 D0 | Y1 Y0
0 0 0 1 | 0 0
0 0 1 0 | 0 1
0 1 0 0 | 1 0
1 0 0 0 | 1 1

Learner activity: If D3 is active, what code is produced?

Lab: Implement and observe Encoder: one-hot to binary

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: D0, D1, D2, D3, Y1, Y0
Interactive inputs: D0, D1, D2, D3

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An 8:1 multiplexer uses three select bits S2:S0 to connect exactly one of D0 through D7 to Y.

Worked example: S2 S1 S0 | Y
0 0 0 | D0
0 0 1 | D1
0 1 0 | D2
0 1 1 | D3
1 0 0 | D4
1 0 1 | D5
1 1 0 | D6
1 1 1 | D7

Learner activity: When S2:S0 = 101, which input is connected to Y?

Lab: Implement and observe 8:1 multiplexer: eight data inputs

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: D0, D1, D2, D3, D4, D5, D6, D7, S2, S1, S0, Y
Interactive inputs: D0, D1, D2, D3, D4, D5, D6, D7, S2, S1, S0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A 1:8 demultiplexer uses S2:S0 to route D to one of eight outputs. All unselected outputs remain 0.

Worked example: S2:S0=000 → Y0=D
001 → Y1=D
010 → Y2=D
011 → Y3=D
100 → Y4=D
101 → Y5=D
110 → Y6=D
111 → Y7=D

Learner activity: With D=1 and S2:S0=110, which output becomes 1?

Lab: Implement and observe 1:8 demultiplexer: eight outputs

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: D, S2, S1, S0, Y0, Y1, Y2, Y3, Y4, Y5, Y6, Y7
Interactive inputs: D, S2, S1, S0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A 3-to-8 decoder converts A2:A0 into eight one-hot outputs. Exactly one of Y0 through Y7 is active.

Worked example: A2:A0=000→Y0 001→Y1 010→Y2 011→Y3
100→Y4 101→Y5 110→Y6 111→Y7

Learner activity: Which output is active when A2:A0=111?

Lab: Implement and observe 3-to-8 decoder: eight one-hot outputs

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: A2, A1, A0, Y0, Y1, Y2, Y3, Y4, Y5, Y6, Y7
Interactive inputs: A2, A1, A0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An 8-to-3 encoder converts one active input D0 through D7 into a three-bit binary output Y2:Y0.

Worked example: D0→000 D1→001 D2→010 D3→011
D4→100 D5→101 D6→110 D7→111

Learner activity: If D6 is the active input, what code is produced?

Lab: Implement and observe 8-to-3 encoder: eight one-hot inputs

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: D0, D1, D2, D3, D4, D5, D6, D7, Y2, Y1, Y0
Interactive inputs: D0, D1, D2, D3, D4, D5, D6, D7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An arithmetic logic unit computes a selected operation such as add, subtract, AND, or OR.

Worked example: OP1 OP0 | FUNCTION
0 0 | A AND B
0 1 | A OR B
1 0 | A + B
1 1 | A XOR B

For ADD: A=2, B=3 → Y=5

Learner activity: For ADD with A=2 and B=3, select Y.

Lab: Implement and observe ALU: select an operation

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: OP1, OP0, A0, B0, Y0, CARRY
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An 8-bit ALU accepts A[7:0], B[7:0], and operation controls. It produces Y[7:0] plus status such as carry and zero.

Worked example: OP=ADD, A=11111111, B=00000001
Y=00000000, CARRY=1, ZERO=1

Learner activity: What carry is produced by 255 + 1 in an 8-bit ALU?

Lab: Implement and observe 8-bit ALU: buses, result, and flags

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: Y7, Y6, Y5, Y4, Y3, Y2, Y1, Y0
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A D flip-flop copies D to Q only at its active clock edge, then holds Q steady between edges.

Worked example: At rising CLK: Q(next) = D
Between edges: Q holds its value

Learner activity: D is 1 at the rising edge. What does Q become?

Lab: Implement and observe D flip-flop: capture one bit

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, D, Q
Interactive inputs: D

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: At an active clock edge, a T flip-flop holds when T=0 and toggles Q when T=1.

Worked example: T | Q(next)
0 | Q (hold)
1 | NOT Q (toggle)

Learner activity: Q is 0 and T=1 at the clock edge. What is Q next?

Lab: Implement and observe T flip-flop: toggle state

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, T, Q
Interactive inputs: T

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A JK flip-flop holds for 00, resets for 01, sets for 10, and toggles for 11 at the active edge.

Worked example: J K | Q(next)
0 0 | hold
0 1 | 0
1 0 | 1
1 1 | toggle

Learner activity: Q is 1 and J=K=1 at the edge. What is Q next?

Lab: Implement and observe JK flip-flop: set, reset, and toggle

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, J, K, Q
Interactive inputs: J, K

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A clocked SR flip-flop holds for S=R=0, sets for S=1,R=0, and resets for S=0,R=1. S=R=1 is forbidden in the basic form.

Worked example: S R | Q(next)
0 0 | hold
0 1 | 0
1 0 | 1
1 1 | forbidden

Learner activity: For S=1 and R=0 at the edge, what does Q become?

Lab: Implement and observe SR flip-flop: set and reset

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, S, R, Q
Interactive inputs: S, R

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A register stores a multi-bit value at a clock edge and keeps it until the next enabled edge.

Worked example: Before edge: D=1010
At edge: Q becomes 1010

Learner activity: What does Q hold immediately after the edge?

Lab: Implement and observe Register: store a value

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, D7, D6, D5, D4, D3, D2, D1, D0, Q7, Q6, Q5, Q4, Q3, Q2, Q1, Q0
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A Karnaugh map groups adjacent 1 cells so a Boolean expression can use fewer gates. Groups must contain 1, 2, 4, or 8 cells and may wrap around the edges.

Worked example: F(A,B,C)=Σm(1,3,5,7)
All four cells share C=1, therefore F=C.

Learner activity: Simplify F(A,B,C)=Σm(1,3,5,7). Which single signal is the result?

Lab: Implement and observe Karnaugh map: simplify a Boolean function

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: NAND and NOR are universal gates: by tying or repeating their inputs you can construct NOT, AND, and OR, and therefore any combinational function.

Worked example: NOT A = A NAND A
AND(A,B) = (A NAND B) NAND (A NAND B)

Learner activity: How can a two-input NAND act as an inverter?

Lab: Implement and observe Universal gates: build any logic

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A half adder produces SUM=A XOR B and CARRY=A AND B. A full adder adds a carry-in, allowing multi-bit addition; subtraction uses two’s-complement inversion and carry-in.

Worked example: A=1, B=1 → SUM=0, CARRY=1
A=1, B=0, CIN=1 → SUM=0, COUT=1

Learner activity: For a half adder with A=1 and B=1, what are SUM and CARRY?

Lab: Implement and observe Adder and subtractor: arithmetic from gates

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A comparator examines two unsigned buses and asserts exactly one relation: A<B, A=B, or A>B. Equality is commonly built from XNOR bits followed by an AND.

Worked example: A[3:0]=0101, B[3:0]=0110
LT=1, EQ=0, GT=0

Learner activity: For A=9 and B=6, which comparator output is asserted?

Lab: Implement and observe Magnitude comparator: less, equal, or greater

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A latch is transparent while its enable level is active; a flip-flop samples only at a clock edge. Accidental latches often indicate an incomplete combinational assignment.

Worked example: D latch: EN=1 → Q follows D
D flip-flop: rising edge → Q samples D

Learner activity: When does an edge-triggered D flip-flop capture D?

Lab: Implement and observe Latch versus flip-flop: level and edge storage

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A clock-enable pulse lets a register update on a selected cycle while all logic keeps one clean clock. This is safer than creating a divided clock in ordinary RTL.

Worked example: always_ff @(posedge clk)
if (ce) q <= d; // otherwise q holds

Learner activity: If CE=0 at the rising edge, what happens to Q?

Lab: Implement and observe Clock enable: slow logic without a new clock

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, D, Q
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Mechanical switches bounce. A counter-based debounce waits for several equal samples; comparing the current sample with a delayed sample creates a one-cycle rising-edge pulse.

Worked example: rise = sample & ~sample_d
Only a stable 0→1 transition creates rise=1.

Learner activity: What does a rising-edge detector output for a stable 1 held for many cycles?

Lab: Implement and observe Debounce and edge detection: clean switch events

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Real gates do not change instantaneously. Unequal path delays can create a short hazard (glitch), even when the steady-state Boolean result is correct. Register critical outputs when a clean signal is required.

Worked example: Two paths to Y change at slightly different times
→ transient pulse → registered Y removes it.

Learner activity: What is the safest way to present a glitch-sensitive output?

Lab: Implement and observe Propagation delay and glitches

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A tri-state driver outputs 0, 1, or high-impedance Z. Only one device may drive a shared bus at a time. Open-drain style drivers release the line for a pull-up to create wired signaling.

Worked example: oe=1 → bus=data
oe=0 → bus=Z (released)

Learner activity: What must an inactive tri-state driver place on a shared bus?

Lab: Implement and observe Tri-state and open-drain buses

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: INPUT, STATE, OUTPUT
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Even parity appends one bit so the total number of 1s is even. XOR reduction computes parity; it detects any odd number of bit flips but cannot correct an error.

Worked example: Data=1011001 has four 1s → even parity bit=0
Data=1011000 has three 1s → parity bit=1

Learner activity: What can a single parity bit reliably detect?

Lab: Implement and observe Parity: detect a one-bit error

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An FPGA is a configurable digital device. A hardware description describes the logic and connections that tools can implement inside it. Independent parts of that circuit can operate at the same time.

This course uses SystemVerilog, including logic, always_comb and always_ff. These extend Verilog; use SystemVerilog mode and .sv files in external tools.

In this lesson, sw and led are names for eight-bit input and output signals. The statement assign led = ~sw describes eight parallel inversions. The ~ operator flips each bit, and the eight-bit output keeps eight result bits. A continuous assignment responds to input changes; it does not wait for a clock or execute once and stop.

The app models logical behavior. Its LED display is not a programmed board, and the model does not represent propagation delays or voltage levels.

Worked example: module lesson(input logic [7:0] sw, output logic [7:0] led);
assign led = ~sw;
endmodule

Learner activity: What does synthesizable Verilog describe?

Lab: Build an eight-bit inverter: each LED must be the opposite of its switch. Replace sw with ~sw in the assignment. Compile, set switches, predict the decimal LED byte, then run and verify. Changing switches updates a combinational circuit without recompiling.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A module is a named hardware block with a defined interface. Its port list declares which signals arrive from outside and which signals it drives. input logic [7:0] sw names eight input bits, indexed 7 through 0. output logic [7:0] led names eight output bits. endmodule closes the definition.

A scalar declaration such as output logic led has only one bit. Connecting an eight-bit value to it cannot preserve every bit: high bits are discarded. A design may be syntactically valid and still violate its interface requirements.

The exercise harness connects to sw and led by name. Keep those port names, directions and widths while repairing the source. A module name is a block type; it is not a physical pin assignment.

Worked example: module lesson(input logic [7:0] sw, output logic [7:0] led);
assign led = sw;
endmodule

Learner activity: Which keywords surround a complete hardware block?

Lab: Repair the module interface: declare led as an eight-bit output, then replace __REPLACE__ with sw. Keep port names sw and led so the controls connect. You may rename the module itself. All eight LEDs must reproduce all eight switches.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A scalar carries one bit. A packed vector such as logic [7:0] data groups eight bits into an ordered value. data[3:0] selects only the low four bits, called a nibble.

A literal such as 4'b0101 specifies its width (4), base (binary) and digits (0101). Its decimal value is 5. The width is part of the design contract, not just formatting.

Concatenation uses braces to join bit groups. In {data[3:0], 4'b0101}, the left group becomes the high nibble and the right group becomes the low nibble. Four bits plus four bits produce eight bits. The upper four input bits are intentionally unused. This is wiring and constant logic; it does not require stored state.

Worked example: module lesson(input logic [7:0] data, output logic [7:0] led);
assign led = {data[3:0], 4'b0101};
endmodule

Learner activity: What does logic [7:0] data declare?

Lab: Build a nibble formatter: copy DATA[3:0] to LED[7:4] and put binary 0101 in LED[3:0]. Change the sized literal in the concatenation from 1010 to 0101. For DATA=3 predict 00110101 (53). Higher DATA bits must have no effect.

Controls: DATA byte. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: DATA, LED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A Boolean requirement should be read before its implementation. Here LED0 must be (A AND B) OR (C XOR D). A and B must both be high for the first term. Exactly one of C and D must be high for the second term. Either true term makes LED0 high.

The bitwise operators are & for AND, | for OR and ^ for XOR. Each selected switch bit is one bit wide. Parentheses make the structure explicit, so a reviewer can compare it directly with the requirement.

The output is still eight bits wide. Concatenating seven zero bits with the one-bit expression ensures LED7 through LED1 stay zero. Naming widths prevents unrelated output bits from appearing meaningful.

Worked example: module lesson(input logic [3:0] sw, output logic [7:0] led);
assign led = {7'b0, ((sw[0] & sw[1]) | (sw[2] ^ sw[3]))};
endmodule

Learner activity: Why use parentheses in a mixed Boolean expression?

Lab: Build LED0 = (A AND B) OR (C XOR D); keep LED7:1 zero. A=sw[0], B=sw[1], C=sw[2], D=sw[3]. Replace the first OR operator with AND. Predict LED0 for A=1 B=0 C=0 D=0 before testing.

Controls: A · sw[0], B · sw[1], C · sw[2], D · sw[3]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: A · sw[0], B · sw[1], C · sw[2], D · sw[3], LED
Interactive inputs: A · sw[0], B · sw[1], C · sw[2], D · sw[3]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Two eight-bit input buses can be compared bit by bit. assign led = sw ^ data describes eight XOR functions: LED[i] is high exactly when SW[i] and DATA[i] differ. The result is a difference mask, not the arithmetic distance between two numbers.

There is no clock or stored history in this design. When either input changes, the logical output follows the new pair. In the app, RUN evaluates the current stimulus. Recompilation is needed after a source edit, not after every input change.

Each output signal should have one intended driver in these exercises. Adding a second competing assignment is not a way to combine two formulas; combine the intended logic within the expression instead.

Worked example: module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw ^ data;
endmodule

Learner activity: When does a continuous assignment update its output?

Lab: Build an eight-bit difference detector: LED[i] must be 1 exactly when SW[i] and DATA[i] differ. Replace the AND operator with XOR. Predict 15 for SW=5 and DATA=10. Change either operand after compiling and observe the immediate result.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: always_comb expresses combinational procedural logic. The output should be determined by current inputs for every possible branch. In this selector, SEL=0 must produce zero and SEL=1 must produce DATA.

A default led = 8'h00 before the if defines the output for the unselected path. When SEL is high, led = data replaces that default during evaluation. Blocking assignments (=) make this order explicit within the block.

If no assignment occurs for SEL=0, the description asks the output to retain an earlier value on that path. That contradicts the requested combinational behavior and can imply a latch. The teaching interpreter rejects incomplete paths rather than presenting them as a working combinational selector.

Worked example: module lesson(input logic sel, input logic [7:0] data, output logic [7:0] led);
always_comb begin
led = 8'h00;
if (sel) led = data;
end
endmodule

Learner activity: Why assign a default at the start of always_comb?

Lab: Build a selector: when SEL=0 output zero; when SEL=1 output DATA. Add the missing default assignment led = 8'h00 before if. Observe the incomplete-path error first. Then implement the same behavior using case(sel) with default and verify again.

Controls: SEL. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SEL, DATA, LED
Interactive inputs: SEL

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A register stores a value. always_ff @(posedge clk) describes state updated at a rising edge, when the clock transitions from low to high. The input can change between edges while the stored output remains unchanged.

Use nonblocking assignment (<=) for clocked state in this course. Right-hand values are evaluated for the clock event and state updates are scheduled afterward. This supports multiple registers observing their old state together. The single register here introduces that convention before pipelines.

The app initializes its simulated storage to zero for exploration. That is a modeling choice, not a guarantee about a physical register. Tests should establish a known state by capture or a defined reset before relying on it.

Worked example: module lesson(input logic clk, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) led <= data;
endmodule

Learner activity: Why is <= used for clocked state?

Lab: Build an eight-bit clocked register. Change the blocking = to nonblocking <=. Enter DATA=37 and press CLOCK EDGE; Q becomes 37. Change DATA to 82 without an edge; Q must stay 37. The next edge captures 82. The app initializes simulated storage to zero; real registers need reset or device initialization.

Controls: DATA byte. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, DATA, LED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A reset defines a known state. In this design rst_n is active low: a value of 0 requests reset. Because the process responds only to posedge clk, this reset is synchronous. Asserting it between edges does not immediately clear the stored output.

At each rising edge the block first tests !rst_n. If true, it clears led to zero. Otherwise, an asserted enable captures data. If neither condition requests an update, the register retains its value. This missing final else intentionally describes a register hold, unlike a missing assignment in combinational logic.

Priority follows the branch order. Reset wins even if enable is also high. A reliable test suite exercises conflicting controls as well as normal captures.

Worked example: module lesson(input logic clk, rst_n, enable, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00;
else if (enable) led <= data;
end
endmodule

Learner activity: What happens on a rising edge when reset is inactive and enable is 0?

Lab: Build a register with synchronous active-low reset and enable. Replace if (rst_n) with if (!rst_n). RST_N=0 clears Q only at a clock edge and has priority over ENABLE. Release reset (RST_N=1), enable capture, then disable ENABLE and prove Q holds while DATA changes.

Controls: RST_N · 0 resets, ENABLE. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, ENABLE, DATA, LED
Interactive inputs: RST_N · 0 resets, ENABLE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Hierarchy builds a larger circuit by connecting smaller modules. A module definition describes a reusable block type; an instance places one occurrence in the design. Named connections such as .a(sw) connect the child port a to the parent signal sw.

The mask child computes a & b. At the parent level, sw and data connect to those inputs and led receives the result. A bug inside the child therefore changes the visible parent output even if every parent connection is correct.

WIDTH is a parameter that sets the bus sizes when the design is elaborated. WIDTH=8 selects eight-bit ports. It is not a run-time input that switches can modify. The app supports a restricted parameterized child-module pattern; more general hierarchy needs an external simulator.

Worked example: module mask #(parameter WIDTH=8)(input logic [WIDTH-1:0] a, b, output logic [WIDTH-1:0] y);
assign y = a & b;
endmodule
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
mask #(.WIDTH(8)) u_mask(.a(sw), .b(data), .y(led));
endmodule

Learner activity: What is u_register in the example?

Lab: Build a reusable mask module with parameter WIDTH. The top-level lesson instantiates it with WIDTH=8. Repair the child operation from OR to AND; sw connects to a, data to b, and led to y. Changing the child changes the instantiated hardware. This lab supports a flat child with named ports and integer width parameters.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Compilation checks whether source can be interpreted by a tool; it does not establish that the circuit meets its requirements. A subtractor can compile perfectly while failing an adder specification. Simulation supplies inputs and observes the described behavior. Verification compares those observations with expected results derived from the requirement.

This adder returns only eight bits. Its contract is unsigned addition modulo 256: retain the low eight result bits. For example, 255+1 is mathematically 256 but the eight-bit output is zero. A carry-preserving adder would require a different, wider output contract.

The acceptance cases include ordinary values and width boundaries. Their expected values are independent of the edited source. Passing this finite suite is evidence for these cases, not a proof of every possible circuit behavior or physical timing.

Worked example: module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw + data;
endmodule

Learner activity: What is required before accepting a lesson implementation?

Lab: Implement an eight-bit adder. The result wraps modulo 256. Repair the minus sign to plus. Predict 255+1 = 0, compile, run, and verify all ten vectors. A compiling subtractor must fail functional verification. The test harness supplies expected results independently; matching two manually entered numbers is not verification of an adder.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Start a code review at the module boundary. The parent circuit or testbench supplies sw and data; the module drives led. All three are eight-bit buses in this exercise. A port declaration describes direction and width, not a board pin.

The required adapter places the low nibble of sw in the high nibble of led, and the low nibble of data in the low nibble of led. Read {sw[3:0], data[3:0]} from left to right: the first group occupies bits 7:4, the second bits 3:0. The upper halves of both inputs are intentionally unused.

The starter crosses the two sources. It still compiles, and tests using equal nibbles will not reveal the error. Derive a distinguishing input from the contract before changing code.

Worked example: module and_gate(input a, input b, output y);

Learner activity: In the example, which name is the output signal?

Lab: Implement and observe Module, inputs, and outputs

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A continuous assignment describes a combinational driver that responds when its inputs change. Multiple continuous assignments do not execute once from top to bottom like a software script. The simulation settles their dependencies.

Here masked must be sw & data, and led must be masked ^ 8'h3C. The output assignment appears before the masked assignment on purpose. Trace the chain sw/data → AND → masked → XOR constant → led. An internal wire makes the intermediate result explicit; it adds neither storage nor a clock.

To localize a failure, predict masked first and led second. The starter uses OR in place of AND. Inputs with both shared and unshared one bits reveal the difference.

Worked example: assign y = a & b;

Learner activity: What circuit does the expression create?

Lab: Implement and observe Continuous assignment

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An override is a condition that can assert an output independently of a normal condition. This alarm requires LED0=(SW0 AND SW1) OR SW2. SW2 alone must be enough to assert LED0. LED7:1 must remain zero.

The starter instead groups the expression as SW0 AND (SW1 OR SW2), which incorrectly requires SW0 even for the override. Parentheses make this difference visible in a review. The relevant inputs are three one-bit signals, so eight combinations cover their two-state truth table. Upper switch bits are outside the alarm contract.

Do not test only all zeros and all ones: both versions agree there. Choose a case in which the override is requested while the normal path is false.

Worked example: assign y = (a & b) | enable;

Learner activity: What makes y equal to 1 in this example?

Lab: Implement and observe Operators you can see

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A driver is an assignment or connected output that supplies a signal value. Before running a circuit, list the drivers of each output and internal net. A logic declaration alone does not mean a flip-flop exists; storage follows the procedural behavior. wire explicitly declares a net.

This contract requires active=sw & data and led=active. The starter also continuously drives led with ~active. These are competing drivers, not two sequential updates. The supported app model rejects this conflict instead of pretending that the last assignment wins. A full HDL simulator may diagnose an invalid variable driver or show resolved unknown values for conflicting net drivers. Neither establishes the required output.

Remove the unintended connection. Changing logic to wire does not turn conflicting values into the specified AND result.

Worked example: module lesson(input logic [7:0] sw, data, output logic [7:0] led);
wire [7:0] active;
assign active = sw & data;
assign led = active;
endmodule

Learner activity: How many intended RTL drivers should a logic signal normally have?

Lab: Build a driver inventory before running. The active bus is SW AND DATA and must be the sole source of LED. The starter gives LED a second conflicting driver. Remove the unintended driver; changing a declaration alone does not repair the circuit.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Bit order describes where each source bit appears, not whether the bit is zero or one. In this adapter LED7 receives SW0, LED6 receives SW1, and so on until LED0 receives SW7. The concatenation lists output contents from most significant to least significant.

The starter repeats the original order instead of reversing it. Correcting this requires moving the source indices, not complementing their values. A walking-one test puts a single one at each input position in turn. Only one output should light, at its mirrored position.

All-zero and all-one patterns are useful boundary checks but cannot distinguish many incorrect permutations. Include both directional and boundary tests.

Worked example: module lesson(input logic [7:0] sw, output logic [7:0] led);
assign led = {sw[0], sw[1], sw[2], sw[3], sw[4], sw[5], sw[6], sw[7]};
endmodule

Learner activity: Which slice selects the upper nibble?

Lab: Read an eight-bit bit-order adapter. LED[7] must receive SW[0], LED[6] SW[1], and so on through LED[0] = SW[7]. Repair the concatenation. Use walking-one inputs to prove every destination, then check zero and all ones.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A width review starts with the mathematical range. Each low nibble is 0–15, so their sum is 0–30 and needs five bits. Doubling it produces 0–60 and needs six bits. The LED bus is eight bits, but that does not automatically protect every intermediate value.

The starter stores the sum in four bits. A value of 16 loses its carry there and becomes zero before it is doubled. Widen sum to five bits and explicitly zero-extend both operands with {1'b0, input[3:0]}. Then {2'b0, sum, 1'b0} makes an eight-bit result: the low zero bit multiplies by two and the two high zeros fill unused bits.

This explicit construction makes the intended unsigned widths visible without relying on subtle context-dependent expression sizing.

Worked example: module lesson(input logic [7:0] sw, data, output logic [7:0] led);
logic [4:0] sum;
assign sum = {1'b0, sw[3:0]} + {1'b0, data[3:0]};
assign led = {2'b0, sum, 1'b0};
endmodule

Learner activity: Why extend both operands before an addition?

Lab: Trace a scaled nibble sum: LED = 2 * (SW[3:0] + DATA[3:0]), including the carry. The maximum result is 60. The starter loses carry in its intermediate four-bit sum. Widen that sum to five bits, explicitly extend the operands, and pack the six-bit scaled result into LED[5:0] with LED[7:6] zero.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An instance places a module inside a parent design. In reader u_reader, reader is the module type and u_reader identifies this particular instance. A named binding such as .a(sw) connects parent signal sw to child port a; the names on the two sides have different roles.

The child function is y=a & ~b. The parent contract connects sw to a, data to b and y to led. The starter swaps the input bindings. Because this expression is not commutative, swapping its operands can change the result. Keep the child equation unchanged and repair the parent wiring.

A good review follows each named connection across the hierarchy boundary and checks widths in both declarations.

Worked example: module reader #(parameter WIDTH=4)(input logic [WIDTH-1:0] a, b, output logic [WIDTH-1:0] y);
assign y = a & ~b;
endmodule
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
reader #(.WIDTH(8)) u_reader(.a(sw), .b(data), .y(led));
endmodule

Learner activity: What is u_count?

Lab: Trace a noncommutative child module: y = a AND NOT b. Parent SW must connect to a, DATA to b and LED to y. The starter swaps the two input bindings. Repair the named connections without changing the child equation. Explain a test that exposes the swap.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A parameter selects a design constant when the hierarchy is elaborated. It is not a switch input that changes each clock cycle. In a reusable child, [WIDTH-1:0] derives each bus width from WIDTH. The default of four bits applies only when an instance does not provide a different value.

This parent requires eight-bit SW, DATA and LED buses, so the child OR combiner must be instantiated with #(.WIDTH(8)). The starter retains WIDTH=4. The app rejects this unsupported parent/child width mismatch instead of certifying an eight-bit design from low-nibble results. A full simulator may issue connection width warnings and pad or truncate; read those diagnostics.

Change the override, rebuild and exercise the upper bits. Leave the child parameterized so it remains reusable.

Worked example: module reader #(parameter WIDTH=4)(input logic [WIDTH-1:0] a, b, output logic [WIDTH-1:0] y);
assign y = a | b;
endmodule
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
reader #(.WIDTH(8)) u_reader(.a(sw), .b(data), .y(led));
endmodule

Learner activity: When are WIDTH and DEPTH used to create hardware?

Lab: The child OR combiner defaults to four bits, but the parent contract requires eight. Repair the WIDTH override to match every parent port. Keep the child definition reusable and prove that high bits, not only the low nibble, reach LED. The teaching interpreter rejects mismatched child and parent widths.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: REQUEST_N is an active-low request carried by SW0: zero means asserted and one means inactive. The suffix is a naming convention; the language does not invert a signal because its name ends in _N. The expression must implement the intended polarity.

This design creates request_active=~sw[0], then selects data when request_active is one and zero otherwise. Because sw[0] is one bit, its bitwise inversion is also one bit. DATA and LED represent unsigned byte values, not seconds or voltages. This combinational lesson models no elapsed physical time.

Use nonzero data to test request polarity. DATA=0 produces zero in both branches and therefore cannot expose an inverted condition.

Worked example: module lesson(input logic [7:0] sw, data, output logic [7:0] led);
wire request_active;
assign request_active = ~sw[0];
assign led = request_active ? data : 8'h00;
endmodule

Learner activity: What does the suffix _n normally communicate?

Lab: SW0 is REQUEST_N, an active-low request. LED must copy the DATA byte when REQUEST_N=0 and be zero when REQUEST_N=1. Trace the polarity conversion into request_active and repair it. DATA is an unsigned byte; no clock or physical time is modeled here.

Controls: REQUEST_N · sw[0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: REQUEST_N · sw[0], DATA, LED
Interactive inputs: REQUEST_N · sw[0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Read a clocked subsystem using a cycle table. Record DATA, enable and rst_n before each rising edge, then derive both register values after it. Nonblocking assignments evaluate their right-hand sides from the pre-edge state before committing the updates.

At an enabled edge, captured receives DATA while LED receives the OLD captured value. Thus a sample reaches LED on the next enabled edge after capture. Disabled edges hold both stages. This reset is synchronous and active low: rst_n=0 clears both stages only at a rising edge, with priority over enable.

The starter assigns DATA directly to LED and bypasses the first stage. Repair the LED source rather than inserting software-like delays. Test sequences, not isolated input values, because the output depends on stored history.

Worked example: module lesson(input logic clk, rst_n, enable, input logic [7:0] data, output logic [7:0] led);
logic [7:0] captured;
always_ff @(posedge clk) begin
if (!rst_n) begin
captured <= 8'h00;
led <= 8'h00;
end else if (enable) begin
captured <= data;
led <= captured;
end
end
endmodule

Learner activity: What should be traced first?

Lab: Trace two eight-bit register stages with a shared enable and synchronous active-low reset. At an enabled rising edge, captured takes DATA and LED takes the OLD captured value. Reset clears both stages; disabled edges and no-edge input changes hold both stages. The starter bypasses the first stage. Repair only the LED data source and verify the full sequence.

Controls: RST_N · 0 resets, ENABLE. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, ENABLE, DATA, LED
Interactive inputs: RST_N · 0 resets, ENABLE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A complete design needs a named module, a declared interface, statements describing its hardware and endmodule. Write the interface contract first: SW and DATA are independent unsigned eight-bit inputs, and LED is their bitwise AND. Each output bit is high only if both corresponding input bits are high.

The editor contains a deliberately unfinished expression. Replace it with sw & data, preserving the named ports. Compile to detect malformed syntax and unsupported constructs, then apply inputs to test the meaning. A compiler cannot infer your intent from the lesson title.

The on-screen LED byte is a logical result, not a physical board pin mapping. The exported SystemVerilog requires an external simulator and a reviewed board adapter for hardware deployment.

Worked example: module top(input a, b, output y);
assign y = a & b;
endmodule

Learner activity: Which line creates the actual logic?

Lab: Implement and observe Write the first module

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: The design under test, or DUT, is the hardware being checked. A testbench is simulation-only code that instantiates the DUT, drives its inputs, allows scheduled updates to settle, and compares outputs with independently derived expectations. Testbench delays and failure-reporting tasks are not FPGA logic.

This DUT must implement OR on SW0 and SW1 while keeping upper LED bits zero. The starter implements AND. Both produce zero for 00 and one for 11, so those cases cannot distinguish them. Inputs 01 and 10 can.

After repairing and verifying, export the lesson. Read the input assignments, settling delay, !== comparison and $fatal call in sim/tb_lesson_core.sv. The mobile app runs an equivalent bounded case sequence; it does not execute arbitrary testbench syntax.

Worked example: Set a=1 and b=1; wait; check that y is 1.

Learner activity: Why test before programming the board?

Lab: Implement and observe What a testbench does

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A waveform is a time-ordered record of signal values. Read the signal names and units before interpreting it. For a combinational circuit, compare the settled output with the inputs that apply at that observation; for clocked circuits, identify the active edge first.

The app uses actual event and terminal values for FPGA lessons rather than an unrelated animated graph. This selector must route DATA when SW0 is one and its eight-bit inverse when SW0 is zero. The starter crosses these branches. Alternate the select control while holding data constant to expose the error.

The mobile model provides logical ordering, not propagation delays or analog transitions. The exported testbench can be run in a full HDL simulator, with a VCD trace for a waveform viewer. Do not use an animated display to infer setup or hold margins.

Worked example: When a=1 and b=1, an AND design must show y=1. For the other three input pairs, y=0.

Learner activity: For a=1 and b=0, what must y be?

Lab: Implement and observe Read a waveform

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Combinational outputs need assignments for every relevant input path. If a path leaves the output unchanged from a prior evaluation, the description can imply storage instead of the intended combinational network. A default branch closes a case statement, but its expression must also match the contract.

Here SW[1:0] selects four modes: zero, DATA, inverted DATA, or SW XOR DATA. The starter defines only the first three. Add the missing mode using a default branch and preserve the other behavior. The remaining SW bits still matter in XOR mode, so do not silently reduce that input to two bits.

Compile for coverage diagnostics, then test every mode with multiple data patterns. Completeness and correctness are different checks.

Worked example: module lesson(input logic [7:0] sw, data, output logic [7:0] led);
always_comb begin
case (sw[1:0])
2'd0: led=0;
2'd1: led=data;
2'd2: led=~data;
default: led=sw ^ data;
endcase
end
endmodule

Learner activity: What happens if y has no assignment when enable is 0?

Lab: Complete a four-mode combinational selector. SW[1:0]: 00 outputs zero, 01 copies DATA, 10 inverts DATA, 11 outputs SW XOR DATA. The starter omits the default mode. Add that branch and test all modes with more than one data value.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Three independent binary inputs have 2^3=8 possible combinations. Exhaustive testing applies every one of them and checks the specified result. This is practical for a small combinational function, but does not cover analog behavior, propagation delay or every condition on a physical board.

The majority voter must assert LED0 when at least two of SW0, SW1 and SW2 are one. Its sum-of-products expression contains the three pairwise AND terms. The starter omits the SW1 AND SW2 term. Inputs 110 expose the defect while 111 can still pass through the other terms.

LED7:1 must be zero. Check an unused high switch bit as an additional interface test; it does not create a ninth combination of the three relevant inputs.

Worked example: module lesson(input logic [7:0] sw, output logic [7:0] led);
assign led = {7'b0, ((sw[0]&sw[1]) | (sw[0]&sw[2]) | (sw[1]&sw[2]))};
endmodule

Learner activity: How many vectors exhaustively test two binary inputs?

Lab: Build a three-input majority voter: LED0 is 1 if at least two of SW0, SW1 and SW2 are 1. Keep LED7:1 zero. Repair the missing third product term, then cover all eight relevant input combinations. Upper switch bits must not affect the vote.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A clocked testbench should present input data before the active sampling edge, then check outputs after nonblocking updates have committed. Driving inputs or checking outputs in a competing same-time event can create a race that obscures the intended behavior. A short testbench wait is simulation scheduling, not synthesized delay logic.

This register resets to zero when SW0 is low at an edge. Otherwise it captures DATA XOR 8'h80, which flips only the high bit. The starter captures unchanged DATA. Changing DATA without an edge must leave the stored output unchanged. Asserting this synchronous reset without an edge must also hold the previous output until the next edge.

The app explicitly separates input changes from its CLOCK action. The exported testbench expresses the same sequence with input assignments and clock transitions.

Worked example: module lesson(input logic clk, input logic [7:0] sw, data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!sw[0]) led <= 0;
else led <= data ^ 8'h80;
end
endmodule

Learner activity: When must D be valid for a rising-edge register test?

Lab: At a rising edge, SW0=0 resets LED to zero. With SW0=1, capture DATA XOR 8'h80 into LED. Between edges LED must hold. The starter captures untransformed DATA. Repair the transform and distinguish drive time from the sampling edge.

Controls: RST_N · sw[0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · sw[0], DATA, LED
Interactive inputs: RST_N · sw[0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A self-checking test compares the observed DUT result with a value derived from the requirement. A useful failure includes the stimulus, expected result and observed result. In a four-state simulator, !== also identifies unknown or high-impedance bits as mismatches. The task $fatal terminates a failing simulation.

This lesson requires a saturating unsigned adder: results above 255 clamp to 255. That differs from the wrapping adder in Module 1. The starter adds directly into eight output bits and discards carry. Create a nine-bit intermediate with explicitly extended operands, then use its carry to select 255 or the low eight sum bits.

Do not repair a failing test by changing its expectation to match the broken output. Fix the circuit or justify a requirement change separately.

Worked example: module lesson(input logic [7:0] sw, data, output logic [7:0] led);
logic [8:0] sum;
assign sum = {1'b0,sw} + {1'b0,data};
assign led = sum[8] ? 8'hFF : sum[7:0];
endmodule

Learner activity: What must a useful failure report identify?

Lab: Implement an unsigned saturating adder: if SW+DATA exceeds 255, LED must be 255; otherwise LED is the sum. The starter wraps and loses overflow. Extend both operands into a nine-bit sum, then select 255 on carry. Use 255+1 to reproduce the defect.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A four-state HDL simulator can represent zero, one, unknown X and high impedance Z. An undriven wire ordinarily resolves to Z; using it in logic can produce X. Conflicting equally strong zero and one net drivers can also resolve to X. Declaration type, initialization and driver strength affect exact behavior.

The mobile teaching interpreter intentionally models only two-state unsigned behavior. It rejects unsupported X/Z syntax and undriven internal reads rather than inventing a zero. To observe actual four-state resolution, use an external HDL simulator.

In this exercise combined must be SW OR DATA, and LED is its inverse. The starter declares combined but never assigns it. Identify the missing driver from the diagnostic, add the required OR assignment, then verify the now-defined binary behavior.

Worked example: module lesson(input logic [7:0] sw, data, output logic [7:0] led);
wire [7:0] combined;
assign combined = sw | data;
assign led = ~combined;
endmodule

Learner activity: What does Z usually mean?

Lab: Repair an undriven internal bus: combined must be SW OR DATA and LED must be its bitwise inverse. The starter never drives combined. Compile and read the diagnostic, add the missing driver, then verify. This two-state app rejects undriven/X/Z behavior; use a full external simulator to observe four-state resolution.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A regression is a stable set of tests rerun after changes. Pseudo-random stimulus is reproducible only when the seed, generator algorithm and relevant tool/version behavior are recorded. A seed alone does not describe every generator. Keep directed boundary tests because random samples may miss a critical condition.

This datapath rotates SW right by one, moving SW0 into bit7, then XORs DATA. The starter shifts in zero and loses SW0. The acceptance sequence includes SW=1, DATA=0 to guarantee that this defect is exercised, followed by deterministic vectors generated with the documented 32-bit recurrence from seed 4721.

The exported testbench contains explicit vectors, so replay does not depend on a simulator's random implementation. This is test stimulus, not a cryptographically secure random source.

Worked example: module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = {sw[0], sw[7:1]} ^ data;
endmodule

Learner activity: Why record the random seed?

Lab: Repair a rotate-and-mask datapath: rotate SW right by one bit, wrapping SW0 into bit7, then XOR DATA. The starter shifts in zero instead. Verify the directed wrap case and a reproducible pseudo-random sequence generated from seed 4721.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A verified subsystem begins with an interface contract, not an attractive output animation. Define the meaning of each control, the priority of simultaneous conditions, when stored data changes and the required response to boundary cases. Then implement the circuit and derive independent tests.

SW0 is synchronous active-low reset. SW1 enables capture. At an enabled rising edge, SW2 selects DATA when high or inverted DATA when low. Reset has priority over enable. Disabled edges and input changes without edges must hold the output. The starter ignores selection and always captures DATA.

The ten cases cover a representative sequence, including no-edge reset assertion. Passing them is finite functional evidence, not a physical timing result. Export source and tests, explain coverage, and use vendor tools plus reviewed constraints before programming hardware.

Worked example: module lesson(input logic clk, input logic [7:0] sw, data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!sw[0]) led <= 0;
else if (sw[1]) led <= sw[2] ? data : ~data;
end
endmodule

Learner activity: What is required in addition to a passing example?

Lab: Build a selected-data register. At an edge SW0=0 resets LED to zero. Otherwise SW1=1 enables capture: SW2=1 selects DATA, SW2=0 selects inverted DATA. Disabled edges and no-edge input changes hold LED. The starter ignores SW2. Repair the data selector, then verify the full reset/enable/select sequence.

Controls: RST_N · sw[0], ENABLE · sw[1], SELECT · sw[2]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · sw[0], ENABLE · sw[1], SELECT · sw[2], DATA, LED
Interactive inputs: RST_N · sw[0], ENABLE · sw[1], SELECT · sw[2]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A flip-flop stores a bit. Its D input is the candidate value, and its Q output is the stored value. A bank of eight flip-flops stores a byte. A rising-edge-triggered register samples D when the clock changes from low to high; changing D between edges does not immediately replace Q.

The expression {data[3:0], data[7:4]} exchanges the two four-bit groups before capture. This exchange is wiring, not an extra sequence of processing steps. The always_ff block describes storage, and nonblocking <= records an update using values from before the edge.

First apply a reset edge with SW0 low. Then release reset, change DATA and observe that the amber input differs from the green output until CLOCK EDGE. The mobile model provides discrete events, not setup/hold timing or a physical oscillator.

Worked example: always_ff @(posedge clk) q <= d;

Learner activity: When does q copy d?

Lab: Implement and observe The clock edge

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, D, Q
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Reset establishes a documented state from which the circuit can operate. That state need not be zero: a protocol, state encoding or output contract may require another value. This register requires 0xA5, which is decimal 165. Reset priority is explicit because the if (!sw[0]) branch is checked before the data-capture branch.

This is synchronous reset. Asserting the control between edges does not change Q; the next rising edge loads 0xA5. Keeping reset asserted makes each edge reload that same value. Releasing it allows a later edge to capture DATA.

Do not assume a zero value shown by a two-state simulator is a guaranteed power-up value on a physical FPGA. Real initialization and reset behavior depend on the device, configuration flow and implementation. Establish a reset sequence and review the board design before deployment.

Worked example: if (!rst_n) q <= 0; else q <= d;

Learner activity: What value is loaded while rst_n is low?

Lab: Implement and observe Reset gives a known start

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, RST, Q
Interactive inputs: RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A counter combines storage with arithmetic feedback. The current Q value enters an incrementer; on an enabled rising edge, the register captures Q+1. This feedback passes through flip-flops, so it is not an uncontrolled combinational loop. Eight-bit storage retains values from 0 through 255 and wraps after 255.

SW0 is an active-low synchronous reset and SW1 is enable. Reset has priority. If reset is inactive and enable is low, no assignment is executed and the existing count is retained. Pressing a switch changes a control; it does not itself constitute a clock edge.

Use clock enables for this basic design rather than constructing a clock with arbitrary logic. Physical clock gating and generated clocks need dedicated resources and constraints. The app demonstrates the state sequence, not clock routing or timing closure.

Worked example: count <= count + 1;

Learner activity: If count is 7 before the clock edge, what is it after the edge?

Lab: Implement and observe Build a counter

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, D, Q
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An enabled register accepts a new value only when its enable control is active at the sampling edge. With enable inactive, it keeps its previous contents. The required behavior can be understood as a multiplexer before the flip-flops: select new DATA when enabled, otherwise feed old Q back to D. Synthesis may use an equivalent dedicated enable resource.

In this clocked block, omitting an else assignment means hold. It does not infer a transparent latch. That rule must not be confused with incomplete assignments in a combinational block, where an unintended dependence on previous values is an error for this course.

The amber LEDs show the current candidate DATA, and green LEDs show stored Q. Different values are expected when DATA changes while disabled or before the next active edge. The reset branch remains highest priority.

Worked example: module lesson(input logic clk, input logic [7:0] sw, data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!sw[0]) led <= 8'd0;
else if (sw[1]) led <= data;
end
endmodule

Learner activity: What does q do on an edge with enable=0?

Lab: Build an eight-bit enabled register: at a rising edge reset wins, then enable captures DATA; otherwise LED holds. SW0 is active-low synchronous reset and SW1 is enable. Repair the starter that overwrites the register with zero when enable is low.

Controls: RESET_N · sw[0], ENABLE · sw[1]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], ENABLE · sw[1], DATA, LED
Interactive inputs: RESET_N · sw[0], ENABLE · sw[1]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Synchronous reset is checked only on the active clock edge. Asynchronous reset adds an event that can change stored state even when the clock is not toggling. The supported example uses always_ff @(posedge clk or negedge rst_n) and gives reset priority inside the process. Both registers capture the same DATA nibble.

The upper LED nibble is synchronous Q and the lower nibble is asynchronous Q. Start with an explicit reset edge so both are known. After capturing a nonzero value, assert reset without an edge: only the lower nibble should clear. Releasing reset alone should not capture DATA.

Physical asynchronous reset deassertion must satisfy recovery and removal timing; designs often synchronize its release for each clock domain. The app models logical reset events only. It does not simulate metastability, recovery/removal violations or establish that a board reset network is safe.

Worked example: module lesson(input logic clk, rst_n, input logic [7:0] data, output logic [7:0] led);
logic [3:0] sync_q, async_q;
always_ff @(posedge clk) begin if (!rst_n) sync_q<=0; else sync_q<=data[3:0]; end
always_ff @(posedge clk or negedge rst_n) begin if (!rst_n) async_q<=0; else async_q<=data[3:0]; end
assign led={sync_q,async_q};
endmodule

Learner activity: Which transition requires special synchronization?

Lab: Compare two four-bit registers capturing DATA[3:0]. LED[7:4] is synchronous-reset Q; LED[3:0] is asynchronous-reset Q. Both resets are active low on RESET_N. Repair the lower register so reset assertion works without a clock. Releasing reset alone must not capture data. Apply an initial reset edge before comparing.

Controls: RESET_N. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N, DATA, LED
Interactive inputs: RESET_N, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A shift register stores a sequence of bits and moves them one position per enabled edge. The expression {led[6:0], data[0]} forms the next eight-bit value: old bit0 moves to bit1, old bit6 moves to bit7, old bit7 is discarded and the incoming serial bit occupies bit0.

This is a left shift with external serial input, not a rotation. A rotation would reconnect the discarded bit to the other end. Nonblocking assignment ensures every destination uses the old stored value on the same edge; the bits do not ripple through eight procedural updates during one clock.

Use a mixed serial pattern such as 1,0,1,1 rather than only zeros. Its visible movement reveals direction, enable behavior and latency. The full DATA byte is available as a convenient input control, but only DATA0 is part of this specified serial interface.

Worked example: module lesson(input logic clk, input logic [7:0] sw, data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!sw[0]) led <= 8'd0;
else if (sw[1]) led <= {led[6:0], data[0]};
end
endmodule

Learner activity: How many enabled edges move a bit across an 8-stage register?

Lab: Build an eight-bit serial-in shift register. SW0=0 synchronously resets; SW1=1 shifts left by one and inserts DATA0 at bit0 on the rising edge. When disabled it holds. Repair the starter that inserts the bit at the wrong end, and track a serial pattern as it moves toward bit7.

Controls: RESET_N · sw[0], SHIFT ENABLE · sw[1]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], SHIFT ENABLE · sw[1], DATA, LED
Interactive inputs: RESET_N · sw[0], SHIFT ENABLE · sw[1]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A four-bit register has sixteen possible encodings, 0 through 15. Adding one to 15 and keeping four bits gives zero. This modulo-16 behavior is different from saturation, which would remain at 15. The exercise deliberately starts with that wrong saturation condition.

Loading a chosen value makes boundary tests practical. SW2 loads DATA[3:0] on an edge, so the upper DATA nibble is discarded explicitly. Reset has first priority, load second and enable third. Thus simultaneous load and enable must load the requested value rather than incrementing the old one.

LED[7:4] is tied to zero while LED[3:0] displays count. Connecting a four-bit counter to eight visual indicators does not make it an eight-bit counter. Check the declared storage width and expression width when predicting arithmetic results.

Worked example: module lesson(input logic clk, input logic [7:0] sw, data, output logic [7:0] led);
logic [3:0] count;
always_ff @(posedge clk) begin
if (!sw[0]) count<=0;
else if (sw[2]) count<=data[3:0];
else if (sw[1]) count<=count+4'd1;
end
assign led={4'b0,count};
endmodule

Learner activity: What follows 255 in an 8-bit free-running counter?

Lab: Implement a four-bit modulo-16 counter displayed in LED[3:0]; upper LEDs must be zero. At an edge reset (SW0=0) wins, then LOAD (SW2=1) loads DATA[3:0], then ENABLE (SW1=1) increments. Repair the starter that saturates at 15. Load 14 to test 14->15->0 without waiting many cycles.

Controls: RESET_N · sw[0], ENABLE · sw[1], LOAD / SELECT · sw[2]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], ENABLE · sw[1], LOAD / SELECT · sw[2], DATA, LED
Interactive inputs: RESET_N · sw[0], ENABLE · sw[1], LOAD / SELECT · sw[2]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A finite-state machine combines a state register with logic that decides the next state. Current state summarizes relevant past events. The combinational block examines that state and current inputs; the clocked block captures its decision on the next rising edge.

This controller has IDLE=0, RUN=1 and DONE=2. START matters only in IDLE, FINISH matters only in RUN, and DONE returns to IDLE on the next edge. A default branch sends the unused encoding back to IDLE. Complete next-state assignments prevent unintended storage in the decision logic.

The starter incorrectly skips RUN. Test the transition sequence, not only final LED values. Holding START high while RUN is active must not restart or advance the machine; FINISH controls that transition. The numeric state display is an instructional observation port, not a required production interface.

Worked example: module lesson(input logic clk, input logic [7:0] sw, output logic [7:0] led);
logic [1:0] state, next_state;
always_comb begin
case(state)
2'd0: if(sw[1]) next_state=2'd1; else next_state=0;
2'd1: if(sw[2]) next_state=2; else next_state=1;
2'd2: next_state=0;
default: next_state=0;
endcase
end
always_ff @(posedge clk) begin if(!sw[0]) state<=0; else state<=next_state; end
assign led={6'b0,state};
endmodule

Learner activity: Which block stores the active FSM state?

Lab: Build a three-state controller: IDLE=0, RUN=1, DONE=2 on LED. SW0 resets synchronously. In IDLE, SW1 START moves to RUN; in RUN, SW2 FINISH moves to DONE; DONE returns to IDLE on the next edge. Repair the starter that skips RUN. Separate combinational next-state decisions from registered state updates.

Controls: RESET_N · sw[0], START · sw[1], FINISH · sw[2]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], START · sw[1], FINISH · sw[2], LED
Interactive inputs: RESET_N · sw[0], START · sw[1], FINISH · sw[2]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An external control may change independently of the destination clock. A commonly used single-bit synchronizer samples it through two flip-flops. The second stage receives the previous first-stage value, not the newly sampled input. A third delayed copy allows a rising indication to be formed as stage2 AND NOT delayed.

LED0 shows stage1, LED1 stage2, and LED2 the one-cycle rising indication. The deliberately faulty starter bypasses the first stage when assigning stage2. Repair it and count edges from the external transition to the synchronized observation.

Real synchronizers reduce, not eliminate, the probability of metastability propagation. Vendor-recognized placement, timing and CDC review are needed. A short pulse can be missed, and independently synchronizing each bit of an arbitrary changing bus does not ensure a coherent word. Handshakes, pulse-transfer schemes or asynchronous FIFOs may be required. This two-state exercise demonstrates logical latency only.

Worked example: module lesson(input logic clk, input logic [7:0] sw, output logic [7:0] led);
logic stage1, stage2, delayed;
always_ff @(posedge clk) begin
if(!sw[0]) begin stage1<=0; stage2<=0; delayed<=0; end
else begin stage1<=sw[1]; stage2<=stage1; delayed<=stage2; end
end
assign led={5'b0,(stage2 & ~delayed),stage2,stage1};
endmodule

Learner activity: Why not feed a raw button directly to many registers?

Lab: Model a two-flip-flop synchronizer followed by a delayed sample for edge detection. SW0 resets synchronously; SW1 is the external input. LED0 is stage1, LED1 stage2, LED2 a rising indication (stage2 AND NOT its delayed value). Repair the missing second-stage delay. This digital model teaches latency, not analog metastability safety.

Controls: RESET_N · sw[0], EXTERNAL INPUT · sw[1]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], EXTERNAL INPUT · sw[1], LED
Interactive inputs: RESET_N · sw[0], EXTERNAL INPUT · sw[1]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A small job controller combines state, a counter and a completion pulse. START is accepted only when remaining is zero. Acceptance loads three; subsequent work edges decrement it. The edge that changes one to zero raises DONE for one cycle. Starting a job is therefore separate from its three work edges.

The nonblocking assignments use pre-edge remaining to decide completion. done<=0 provides the normal next value, and the later executed done<=1 overrides it on the terminal work edge. These statements belong to one process, not competing hardware drivers. Reset overrides the entire operation.

The starter accepts START even while busy, so a held request repeatedly reloads three and prevents completion. Test that adversarial sequence. With a level-sensitive START, a request still high on a later idle edge can begin a new job; edge-detecting requests would be a different contract.

Worked example: module lesson(input logic clk, input logic [7:0] sw, output logic [7:0] led);
logic [1:0] remaining;
logic done;
always_ff @(posedge clk) begin
if(!sw[0]) begin remaining<=0; done<=0; end
else begin
done<=0;
if(sw[1] && remaining==0) remaining<=3;
else if(remaining!=0) begin remaining<=remaining-2'd1; if(remaining==1) done<=1; end
end
end
assign led={done,5'b0,remaining};
endmodule

Learner activity: What must verification prove about start while busy?

Lab: Create a three-work-edge job controller. SW0 resets; SW1 START is accepted only while idle. Starting loads remaining=3, then each edge counts down. LED[1:0] shows remaining and LED7 pulses for one cycle when remaining transitions 1->0. Starts during work are ignored. Repair a starter that continually restarts an active job.

Controls: RESET_N · sw[0], START · sw[1]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], START · sw[1], LED
Interactive inputs: RESET_N · sw[0], START · sw[1]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Synthesis converts a synthesizable hardware description into a netlist suitable for a target technology. It may simplify logic, remove unused terms and select equivalent structures. A textual operator is therefore not necessarily a separate physical gate.

In this example A AND B OR A AND NOT B equals A: whether B is zero or one, exactly the relevant A term remains. LED0 must follow SW0 independently of DATA0. The broken OR expression incorrectly lets DATA0 force the output high. Compare the original and simplified correct forms using the same tests before comparing their mapped netlists.

The mobile exercise checks logical behavior through the supported SystemVerilog model. It does not run synthesis, choose device resources, assign package pins or measure physical delays. After functional verification, export the design and use the exact board/device configuration in Libero. Preserve the synthesis and implementation reports, check constraints and warnings, and distinguish a predicted resource from one actually reported by the tools.

Worked example: assign y=a&b normally maps into a lookup table; a clocked q normally maps into a flip-flop.

Learner activity: Which result belongs to synthesis?

Lab: Implement and observe Synthesis

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Placement selects physical sites for logic, registers and other resources. Routing connects those placed resources through available interconnect. A logical connection does not state a geometric position or a route length.

The exercise exchanges adjacent bits rather than implementing new Boolean logic. LED7 receives SW6, LED6 receives SW7, and the same exchange applies to the other pairs. An all-zero or all-one test cannot expose a straight-through wiring mistake; alternating and walking-one patterns can. In a physical design, the logical ports must also be assigned to suitable package pins, with board-specific electrical constraints.

The mobile exercise checks logical behavior through the supported SystemVerilog model. It does not run synthesis, choose device resources, assign package pins or measure physical delays. After functional verification, export the design and use the exact board/device configuration in Libero. Preserve the synthesis and implementation reports, check constraints and warnings, and distinguish a predicted resource from one actually reported by the tools.

Worked example: The tool places a LUT and output cell, then routes the LUT result to that cell.

Learner activity: What does routing create?

Lab: Implement and observe Place and route

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A pipeline breaks a computation into sections separated by registers. This can shorten a register-to-register combinational path, but introduces latency and does not by itself prove that timing passes. Setup and hold checks depend on clocks, constraints, mapped cells and routed delays.

Here stage1 stores a five-bit sum of the two DATA nibbles. LED stores the previous stage1 value XOR 128. The starter incorrectly computes from current DATA for the output, bypassing the intended state boundary. Use changing values on consecutive edges to expose that latency error; constant data can hide it.

The mobile exercise checks logical behavior through the supported SystemVerilog model. It does not run synthesis, choose device resources, assign package pins or measure physical delays. After functional verification, export the design and use the exact board/device configuration in Libero. Preserve the synthesis and implementation reports, check constraints and warnings, and distinguish a predicted resource from one actually reported by the tools.

Worked example: A 10 ns clock period requires the relevant path to complete within its available time.

Learner activity: What does a timing failure mean?

Lab: Implement and observe Timing must pass

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: SOURCE, DESTINATION, SLACK PASS
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A lookup table represents a Boolean function by associating each input combination with an output bit. Three binary inputs have eight combinations. A synthesis tool can map expressions into available LUT structures and may merge or simplify logic.

This function asserts LED0 when SW0 differs from SW1 and SW2 is zero. SW2 is an inhibit, so it must force the result low when asserted. The starter uses SW2 without inversion, reversing that behavior. Upper switch bits are irrelevant to the equation, and upper output bits must be defined as zero rather than left undriven.

The mobile exercise checks logical behavior through the supported SystemVerilog model. It does not run synthesis, choose device resources, assign package pins or measure physical delays. After functional verification, export the design and use the exact board/device configuration in Libero. Preserve the synthesis and implementation reports, check constraints and warnings, and distinguish a predicted resource from one actually reported by the tools.

Worked example: module lesson(input logic [7:0] sw, output logic [7:0] led);
assign led = {7'b0,((sw[0]^sw[1]) & ~sw[2])};
endmodule

Learner activity: What does a LUT fundamentally store?

Lab: Build a three-input function: LED0=(SW0 XOR SW1) AND NOT SW2; upper LED bits are zero. Repair the missing inversion on SW2. Enumerate all eight low-bit combinations, then relate that truth table to LUT mapping without assuming an exact physical LUT count. Mobile verification checks the logical contract only. Use the exported source in the vendor flow for your selected FPGA and inspect the requested reports to establish physical mapping; the app does not synthesize or place-and-route. Microchip Libero is an optional reference.

Controls: A · sw[0], B · sw[1], INHIBIT · sw[2]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: A · sw[0], B · sw[1], INHIBIT · sw[2], LED
Interactive inputs: A · sw[0], B · sw[1], INHIBIT · sw[2]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A logic expression can feed a register, creating a boundary between computation and stored state. FPGA architectures provide combinations of logic and storage resources, but actual packing depends on supported controls and implementation decisions. Source lines placed next to each other do not prove physical adjacency.

The exercise computes XOR reduction of all eight DATA bits. That parity bit is one for an odd number of ones; adding it to the data creates even overall parity. SW1 enables capture, and SW0 is active-low synchronous reset. The incorrect starter samples only DATA0, so choose values where another bit changes parity.

The mobile exercise checks logical behavior through the supported SystemVerilog model. It does not run synthesis, choose device resources, assign package pins or measure physical delays. After functional verification, export the design and use the exact board/device configuration in Libero. Preserve the synthesis and implementation reports, check constraints and warnings, and distinguish a predicted resource from one actually reported by the tools.

Worked example: module lesson(input logic clk, input logic [7:0] sw, data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!sw[0]) led <= 8'd0;
else if(sw[1]) led<={7'b0,(^data)};
end
endmodule

Learner activity: Why register a long combinational result?

Lab: Store the even-parity bit of DATA on enabled rising edges: LED0=^DATA, upper LEDs zero. SW0 resets synchronously and SW1 enables capture. Repair the starter that stores only DATA0. After behavior passes, inspect whether synthesis recognizes storage and enable resources. Mobile verification checks the logical contract only. Use the exported source in the vendor flow for your selected FPGA and inspect the requested reports to establish physical mapping; the app does not synthesize or place-and-route. Microchip Libero is an optional reference.

Controls: RESET_N · sw[0], ENABLE · sw[1]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], ENABLE · sw[1], DATA, LED
Interactive inputs: RESET_N · sw[0], ENABLE · sw[1]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: FPGA tools may implement arithmetic using dedicated carry structures, DSP resources or ordinary fabric, depending on the operation, width, constraints and target. A multiplication symbol does not guarantee a DSP block, especially for very small operands.

The required unsigned expression multiplies the low SW nibble by the low DATA nibble, then adds the upper DATA nibble as a bias. Its maximum is 15 times 15 plus 15, or 240, so an eight-bit output can represent every result. The starter substitutes addition for multiplication, which some zero or small input patterns may fail to expose.

The mobile exercise checks logical behavior through the supported SystemVerilog model. It does not run synthesis, choose device resources, assign package pins or measure physical delays. After functional verification, export the design and use the exact board/device configuration in Libero. Preserve the synthesis and implementation reports, check constraints and warnings, and distinguish a predicted resource from one actually reported by the tools.

Worked example: module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led=sw[3:0]*data[3:0]+data[7:4];
endmodule

Learner activity: Which resource best fits repeated multiply-accumulate?

Lab: Implement an unsigned multiply-add: LED=SW[3:0]*DATA[3:0]+DATA[7:4]. The largest result is 240, so eight output bits suffice. Repair the starter that adds instead of multiplying. Compare multiply/add structures in reports; a tiny multiply is not guaranteed to consume a DSP block. Mobile verification checks the logical contract only. Use the exported source in the vendor flow for your selected FPGA and inspect the requested reports to establish physical mapping; the app does not synthesize or place-and-route. Microchip Libero is an optional reference.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Memory inference depends on supported access patterns, size, ports, clocks and reset behavior. For a larger design, start with the vendor-supported template and check the synthesis report for the intended memory resource. A case statement alone does not prove embedded RAM usage.

This small ROM is deliberately a four-word educational model. Address SW[3:2] chooses 3, 17, 85 or 170. An enabled rising edge captures the selected word; disabled edges hold, and reset clears the output. Changing the address without an edge must not change the stored result. Distinct words reveal address mistakes.

The mobile exercise checks logical behavior through the supported SystemVerilog model. It does not run synthesis, choose device resources, assign package pins or measure physical delays. After functional verification, export the design and use the exact board/device configuration in Libero. Preserve the synthesis and implementation reports, check constraints and warnings, and distinguish a predicted resource from one actually reported by the tools.

Worked example: module lesson(input logic clk, input logic [7:0] sw, output logic [7:0] led);
always_ff @(posedge clk) begin
if(!sw[0]) led<=0;
else if(sw[1]) begin
case(sw[3:2])
0:led<=3; 1:led<=17; 2:led<=85; default:led<=170;
endcase
end
end
endmodule

Learner activity: What should be checked after synthesis?

Lab: Repair a four-word synchronous ROM: address SW[3:2] maps 0->3, 1->17, 2->85, 3->170. SW0 resets output to zero, SW1 enables a read on the edge; otherwise hold. The starter has word2 wrong. This tiny case-ROM teaches access timing; it does not claim to infer block RAM. Mobile verification checks the logical contract only. Use the exported source in the vendor flow for your selected FPGA and inspect the requested reports to establish physical mapping; the app does not synthesize or place-and-route. Microchip Libero is an optional reference.

Controls: RESET_N · sw[0], READ ENABLE · sw[1], ADDR0 · sw[2], ADDR1 · sw[3]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], READ ENABLE · sw[1], ADDR0 · sw[2], ADDR1 · sw[3], LED
Interactive inputs: RESET_N · sw[0], READ ENABLE · sw[1], ADDR0 · sw[2], ADDR1 · sw[3]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Clock distribution is a physical design concern. FPGA devices provide supported clock resources and networks; arbitrary combinational logic should not be treated as a substitute for a reviewed clocking structure. Generated clocks need appropriate relationships and constraints.

This exercise does not generate a new clock. The single clock continues, while enable decides whether LED0 toggles at an edge. Reset has priority and upper LEDs remain zero. The faulty starter toggles when disabled rather than enabled. Changing enable between edges should not toggle Q; this is an important observation for separating data control from clock control.

The mobile exercise checks logical behavior through the supported SystemVerilog model. It does not run synthesis, choose device resources, assign package pins or measure physical delays. After functional verification, export the design and use the exact board/device configuration in Libero. Preserve the synthesis and implementation reports, check constraints and warnings, and distinguish a predicted resource from one actually reported by the tools.

Worked example: module lesson(input logic clk, input logic [7:0] sw, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!sw[0]) led <= 8'd0;
else if(sw[1]) led<={7'b0,~led[0]};
end
endmodule

Learner activity: What is the preferred way to pause state updates?

Lab: Toggle LED0 on each enabled rising edge of the single clock, keeping upper bits zero. SW0 resets synchronously; SW1 is a clock enable. Repair the starter that toggles when disabled. No combinationally gated or generated clock is needed for this pause function. Mobile verification checks the logical contract only. Use the exported source in the vendor flow for your selected FPGA and inspect the requested reports to establish physical mapping; the app does not synthesize or place-and-route. Microchip Libero is an optional reference.

Controls: RESET_N · sw[0], ENABLE · sw[1]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], ENABLE · sw[1], LED
Interactive inputs: RESET_N · sw[0], ENABLE · sw[1]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An RTL port is a logical interface. Physical I/O cells and package pins must satisfy bank voltage, I/O standard and board wiring requirements. A logical one in simulation does not specify an electrical voltage or prove that an external device can safely drive that pin.

This hypothetical adapter reverses lane order and inverts every bit. It is not the Discovery Kit pinout or a claim about that board’s LED polarity. Green monitor bits represent raw logic levels in this exercise; for an active-low lamp circuit, a raw zero could mean illuminated. Keep that distinction explicit when explaining results.

The mobile exercise checks logical behavior through the supported SystemVerilog model. It does not run synthesis, choose device resources, assign package pins or measure physical delays. After functional verification, export the design and use the exact board/device configuration in Libero. Preserve the synthesis and implementation reports, check constraints and warnings, and distinguish a predicted resource from one actually reported by the tools.

Worked example: module lesson(input logic [7:0] sw, output logic [7:0] led);
assign led = ~{sw[0],sw[1],sw[2],sw[3],sw[4],sw[5],sw[6],sw[7]};
endmodule

Learner activity: What must be checked before assigning an I/O standard?

Lab: Build a hypothetical active-low output adapter with reversed lane order: LED[i]=NOT SW[7-i]. Green monitor bits show raw logic levels, not physical lamp illumination. Repair the missing inversion. This is a logical wiring exercise, not the pinout or polarity of the Discovery Kit. Mobile verification checks the logical contract only. Use the exported source in the vendor flow for your selected FPGA and inspect the requested reports to establish physical mapping; the app does not synthesize or place-and-route. Microchip Libero is an optional reference.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A useful mapping review traces each functional part to evidence: storage for count, arithmetic for increment, selection for load/hold, and comparison for a status flag. Tools can optimize or combine those functions, so predictions must be checked against the mapped design.

Here a four-bit counter supports reset, load and enable in that order. The upper DATA nibble is a live threshold. LED7 asserts when count is greater than or equal to it, while low LED bits show count. The starter incorrectly excludes equality. Threshold changes may update LED7 without an edge even though count remains stored.

The mobile exercise checks logical behavior through the supported SystemVerilog model. It does not run synthesis, choose device resources, assign package pins or measure physical delays. After functional verification, export the design and use the exact board/device configuration in Libero. Preserve the synthesis and implementation reports, check constraints and warnings, and distinguish a predicted resource from one actually reported by the tools.

Worked example: module lesson(input logic clk, input logic [7:0] sw, data, output logic [7:0] led);
logic [3:0] count;
always_ff @(posedge clk) begin
if(!sw[0]) count<=0; else if(sw[2]) count<=data[3:0]; else if(sw[1]) count<=count+4'd1;
end
assign led={(count >= data[7:4]),3'b0,count};
endmodule

Learner activity: What validates a mapping claim?

Lab: Build a four-bit count-and-compare subsystem. At an edge SW0 resets count, SW2 loads DATA[3:0], otherwise SW1 enables increment. LED[3:0]=count; LED7=1 when count>=DATA[7:4]; other bits zero. Repair the strict-greater-than comparator. Changing the threshold may change LED7 without changing stored count. Mobile verification checks the logical contract only. Use the exported source in the vendor flow for your selected FPGA and inspect the requested reports to establish physical mapping; the app does not synthesize or place-and-route. Microchip Libero is an optional reference.

Controls: RESET_N · sw[0], ENABLE · sw[1], LOAD · sw[2]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], ENABLE · sw[1], LOAD · sw[2], DATA, LED
Interactive inputs: RESET_N · sw[0], ENABLE · sw[1], LOAD · sw[2]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Create a new Libero project on a supported workstation and record the tool version. For the PolarFire SoC Discovery Kit, verify the installed device and board revision against its documentation before selecting the family, device and package. Add only the intended source hierarchy and identify one top module. Save a screenshot or report showing the selection and resolve missing modules before synthesis. The mobile app does not create a Libero project or validate the physical target.

Create the Libero project is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Choose the device used by the PolarFire SoC Discovery Kit, add the top-level Verilog module, and build hierarchy.

Learner activity: Why must the exact device and package be selected?

Lab: Implement and observe Create the Libero project

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Build a pin review table before writing constraints: logical port, direction, board net, package pin, bank supply, I/O standard and active polarity. Check every row against the exact board revision. The Discovery Kit exposes seven fabric LEDs; do not assume that eight on-screen logical LED bits correspond to eight fabric-connected lamps. Detect duplicate pin assignments and unassigned ports, then review the generated I/O report. Never infer voltage compatibility from a successful simulation.

Assign board pins is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: The port led must use the board pin connected to the chosen LED, with the correct I/O standard.

Learner activity: What happens if led is assigned to the wrong pin?

Lab: Implement and observe Assign board pins

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Use a staged acceptance record: passing core and wrapper simulation, reviewed synthesis warnings, complete pin and clock constraints, and reviewed setup/hold timing. Only then generate programming data for the exact device. Record the image identity, programmer result and reset sequence. Apply documented inputs and record expected versus observed outputs, including reset and repeated runs. A successful programmer message proves transfer, not functional correctness; a phone simulation does not prove board operation.

Program and verify is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Press the assigned switch and confirm the assigned LED follows the behavior already proven in simulation.

Learner activity: What is the strongest completion evidence?

Lab: Implement and observe Program and verify

Controls: Apply controlled stimulus and compare the output

Expected evidence: Verified waveform and explained result

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Identify the actual clock source before writing SDC. The Discovery Kit reference workflow uses its 50 MHz oscillator, corresponding to a 20 ns period. Confirm the selected port and source in the exact schematic rather than copying another board’s frequency. Review clock coverage, generated clocks and I/O timing separately. For reset, follow the device initialization and reset IP guidance: a two-state model starting at zero is not a power-up reset guarantee. Record how reset is asserted and safely released in each clock domain.

Build the bounded register contract for "Constrain the board clock and reset". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Constrain the board clock and reset is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: For a verified 50 MHz source on top-level clk: create_clock -name board_clk -period 20.000 [get_ports {clk}]. This is only the primary-clock constraint, not a complete timing constraint set.

Bounded reference RTL:
// Bounded lesson contract: Constrain the board clock and reset
module lesson(input logic clk, rst_n, enable, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00; else if (enable) led <= data;
end
endmodule

Learner activity: What period corresponds to the verified 50 MHz reference oscillator?

Lab: Build the bounded register contract for "Constrain the board clock and reset". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: RST_N · 0 resets, ENABLE. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, ENABLE, DATA, LED
Interactive inputs: RST_N · 0 resets, ENABLE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Draw the path from physical input through synchronization, any required debounce or event detection, the core, and the output-polarity adapter. Name each clock domain. A two-stage synchronizer is not a mechanical debounce filter and does not guarantee coherent capture of a changing multibit bus. The supplied project adapter uses seven fabric LEDs and synchronized switches; it does not provide a general debounced push-button interface. Verify that your chosen controls exist on the actual board before adding their ports.

Build the bounded shift contract for "Switch, button, and LED top level". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Switch, button, and LED top level is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: External switch -> synchronizer -> stable level control. Mechanical start button -> synchronizer plus debounce -> one-cycle request. These are distinct contracts, not interchangeable controls.

Bounded reference RTL:
// Bounded lesson contract: Switch, button, and LED top level
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw << data[2:0];
endmodule

Learner activity: Which input normally needs synchronization and debounce?

Lab: Build the bounded shift contract for "Switch, button, and LED top level". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[2:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[2:0], DATA, LED
Interactive inputs: SW[7:0], DATA[2:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Simulate the core and the complete wrapper separately. The wrapper test must drive the real top-level ports, establish reset explicitly, account for input synchronization latency and use the documented output polarity. Change inputs away from sampling edges and compare settled results with independent expectations. An accelerated simulation clock-enable divider must preserve the same event logic, and its test-only value must not accidentally enter the board build. A wrapper smoke test checks a limited integration path, not every physical function.

Build the bounded xor contract for "Simulate the complete board top". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Simulate the complete board top is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Assert reset, run enough clock edges to propagate synchronized controls, release reset as specified, apply one known input, then compare the correctly polarized output after its documented latency.

Bounded reference RTL:
// Bounded lesson contract: Simulate the complete board top
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw ^ data;
endmodule

Learner activity: Why simulate the wrapper instead of only the core?

Lab: Build the bounded xor contract for "Simulate the complete board top". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Collect the hierarchy, resource utilization, I/O assignment, clock and timing reports for the exact build. Review missing clocks and unconstrained paths before interpreting slack. Inspect both setup and hold checks and the relevant operating corners; a single positive path is not a complete timing pass. Record each warning with its cause, impact and resolution. Do not hide a real path with a false-path or multicycle exception merely to make the report green. Re-run functional verification after architectural changes.

Build the bounded subtract contract for "Review implementation reports". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Review implementation reports is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Record startpoint, endpoint, clock relation, requirement, arrival time and slack for a reported path. Explain every timing exception and retain the report with its source revision.

Bounded reference RTL:
// Bounded lesson contract: Review implementation reports
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw - data;
endmodule

Learner activity: What makes a warning acceptable?

Lab: Build the bounded subtract contract for "Review implementation reports". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Before programming, identify the target board and device, verify documented power and programmer connections, and disconnect unreviewed external loads. Match the image to the reviewed source and constraints. Record a checksum, tool version and programming log. Use only the manufacturer’s supported programming procedure; do not assume an exported RTL ZIP is a programming image. After programming, perform the documented reset and bring-up sequence. Programming is an external workstation operation in this app revision.

Build the bounded toggle contract for "Programming image and safe handling". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Programming image and safe handling is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Record the programming-image digest, tool version, device, board revision, and result.

Bounded reference RTL:
// Bounded lesson contract: Programming image and safe handling
module lesson(input logic clk, rst_n, enable, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00; else if (enable) led <= ~led;
end
endmodule

Learner activity: What prevents programming the wrong project by mistake?

Lab: Build the bounded toggle contract for "Programming image and safe handling". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: RST_N · 0 resets, ENABLE. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, ENABLE, DATA, LED
Interactive inputs: RST_N · 0 resets, ENABLE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Use one row per experiment: source/image identity, board revision, reset state, exact input values, applied clock events or wait time, predicted output, observed output and pass/fail explanation. Include boundary and repeated-start cases, not only a convenient photograph. Label captures with their test row and measurement setup. If observation differs, retain the failure before changing the design so the result can be reproduced. Self-reported evidence is not automatically graded or certified by this mobile revision.

Build the bounded identity contract for "Collect repeatable board evidence". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Collect repeatable board evidence is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Test row: reset completed; input vector recorded; required synchronization cycles elapsed; expected result from the specification; actual result observed; discrepancy and follow-up recorded.

Bounded reference RTL:
// Bounded lesson contract: Collect repeatable board evidence
module lesson(input logic [7:0] sw, output logic [7:0] led);
assign led = sw;
endmodule

Learner activity: What makes a photograph useful evidence?

Lab: Build the bounded identity contract for "Collect repeatable board evidence". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], LED
Interactive inputs: SW[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Bring up the smallest reviewed design first. Confirm power and programmer detection, verify the selected clock/reset scheme, and establish one known input-to-output path. Then add the intended core, repeat reset and boundary tests, and compare observations with simulation. A heartbeat shows activity but does not prove its frequency, all timing paths or datapath correctness. Archive source, constraints, tool versions, simulation transcripts, implementation reports, programming identity and board test results together. Unresolved mismatches remain failures, not completed lessons.

Build the bounded multiply contract for "PolarFire board bring-up capstone". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

PolarFire board bring-up capstone is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Acceptance package: reproducible source and constraints + passing specified simulation + reviewed implementation/timing + identified programming image + repeatable board observations. None is replaced by an animated phone display.

Bounded reference RTL:
// Bounded lesson contract: PolarFire board bring-up capstone
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw * data;
endmodule

Learner activity: What should be tested first on an unknown board state?

Lab: Build the bounded multiply contract for "PolarFire board bring-up capstone". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A vector groups ordered bits; slicing chooses a fixed subset without arithmetic or storage. This formatter takes the low nibble of DATA for the high result nibble and the high nibble of SW for the low result nibble. Each source bit has one named destination. Unused nibbles are deliberately ignored; vary them to prove that they cannot leak into the result. Start by writing the eight connections on paper before replacing the placeholder. All-zero patterns alone cannot distinguish swapped slices. The mobile model checks supported two-state SystemVerilog behavior, not propagation delays or physical resource placement. Compile checks supported syntax and connectivity; RUN observes your current inputs; VERIFY compares the edited design with independent expected values. A compiling design can still be wrong. After repair, vary inputs without recompiling, predict the complete output byte, and explain discrepancies before attempting the assessment. Export the source and testbench for external verification; real board deployment additionally requires a reviewed pin adapter and constraints.

Worked example: logic [7:0] data; assign low = data[3:0];

Learner activity: Which expression selects the upper nibble?

Lab: Implement vectors and slices, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A combinational block must define its result on every possible path. The enabled limiter has three regions: disabled, enabled and within range, and enabled above the limit. The starter covers only two regions and therefore cannot describe the intended complete combinational function. Write the missing normal-data branch. The comparisons are unsigned because DATA is an unsigned vector. Boundary testing is essential: 199, 200 and 201 exercise both sides of the threshold and equality. Changing enable must immediately suppress the output without waiting for a clock. The mobile model checks supported two-state SystemVerilog behavior, not propagation delays or physical resource placement. Compile checks supported syntax and connectivity; RUN observes your current inputs; VERIFY compares the edited design with independent expected values. A compiling design can still be wrong. After repair, vary inputs without recompiling, predict the complete output byte, and explain discrepancies before attempting the assessment. Export the source and testbench for external verification; real board deployment additionally requires a reviewed pin adapter and constraints.

Worked example: always_comb begin y = 0; if (en) y = a; end

Learner activity: Why is y assigned before the if?

Lab: Implement always_comb blocks, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A case statement compares one selection value with distinct alternatives. These modes are mutually exclusive by their two-bit encodings; this exercise does not require a priority encoder. List all four encodings before editing. The default branch gives mode three its specified constant instead of leaving an output unassigned. Every branch drives the entire eight-bit output. Higher SW bits are outside the selector and must have no effect. Test each mode with a nontrivial DATA pattern, then repeat with a different pattern to distinguish constant modes from data-dependent modes. The mobile model checks supported two-state SystemVerilog behavior, not propagation delays or physical resource placement. Compile checks supported syntax and connectivity; RUN observes your current inputs; VERIFY compares the edited design with independent expected values. A compiling design can still be wrong. After repair, vary inputs without recompiling, predict the complete output byte, and explain discrepancies before attempting the assessment. Export the source and testbench for external verification; real board deployment additionally requires a reviewed pin adapter and constraints.

Worked example: case (sel) 2'b00:y=a; 2'b01:y=b; default:y=0; endcase

Learner activity: What prevents an uncovered selection?

Lab: Implement case and priority, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A parameter configures a hardware instance before runtime; it is not a switch that changes the circuit width while operating. The reusable XOR child has parameter W and is instantiated at W=4. Both input slices are four bits and the child result is four bits. The parent explicitly zero-extends that result to the eight-bit monitor. Edit the child's OR operator to XOR and keep the named connections. Equal asserted bits distinguish the two operations: OR returns one there, while XOR returns zero. External tools must elaborate the same configuration used by the test. The mobile model checks supported two-state SystemVerilog behavior, not propagation delays or physical resource placement. Compile checks supported syntax and connectivity; RUN observes your current inputs; VERIFY compares the edited design with independent expected values. A compiling design can still be wrong. After repair, vary inputs without recompiling, predict the complete output byte, and explain discrepancies before attempting the assessment. Export the source and testbench for external verification; real board deployment additionally requires a reviewed pin adapter and constraints.

Worked example: module add #(parameter W=8)(input logic [W-1:0] a,b);

Learner activity: What does W control?

Lab: Implement parameters and widths, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Hierarchy lets a parent combine smaller blocks through explicit interfaces. Here two distinct children operate in parallel: a mask forms the low result nibble and an XOR forms the high nibble. Instance names identify placements in the design hierarchy, not execution order. A named connection binds a child port to the written parent expression. The broken high-nibble connection uses the wrong DATA slice; the source can compile yet compute the wrong result. Trace each child independently before checking the combined byte. Distinct nibble patterns expose crossed connections that uniform values can conceal. The mobile model checks supported two-state SystemVerilog behavior, not propagation delays or physical resource placement. Compile checks supported syntax and connectivity; RUN observes your current inputs; VERIFY compares the edited design with independent expected values. A compiling design can still be wrong. After repair, vary inputs without recompiling, predict the complete output byte, and explain discrepancies before attempting the assessment. Export the source and testbench for external verification; real board deployment additionally requires a reviewed pin adapter and constraints.

Worked example: adder u_add(.a(a), .b(b), .y(sum));

Learner activity: What is u_add?

Lab: Implement module hierarchy, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An encoder reports the index of an asserted request. A priority encoder additionally defines which request wins when several are asserted. The highest-numbered SW bit wins here. LED7 is valid, LED2:0 is the index, and every other bit is zero. Request zero and no request both encode index zero, so the valid bit is necessary to distinguish them. Inspect the nested conditions in descending order and correct the top branch. Tests should cover every single request, simultaneous requests, and no request; testing one-hot inputs alone cannot establish priority behavior. The mobile model checks supported two-state SystemVerilog behavior, not propagation delays or physical resource placement. Compile checks supported syntax and connectivity; RUN observes your current inputs; VERIFY compares the edited design with independent expected values. A compiling design can still be wrong. After repair, vary inputs without recompiling, predict the complete output byte, and explain discrepancies before attempting the assessment. Export the source and testbench for external verification; real board deployment additionally requires a reviewed pin adapter and constraints.

Worked example: module lesson(input logic [7:0] sw, output logic [7:0] led);
assign led = sw[7] ? 8'd135 : sw[6] ? 8'd134 : sw[5] ? 8'd133 : sw[4] ? 8'd132 : sw[3] ? 8'd131 : sw[2] ? 8'd130 : sw[1] ? 8'd129 : sw[0] ? 8'd128 : 8'd0;
endmodule

Learner activity: What must the RTL define for simultaneous requests?

Lab: Write an eight-request highest-index priority encoder. SW7 wins over SW6 through SW0. LED7 indicates any request; LED2:0 gives the winning index; LED6:3 are zero. No request produces zero. Repair the top branch so SW7 wins. Compile your edited SystemVerilog, predict an output, apply inputs without a clock, and pass VERIFY DESIGN before the assessment. This verifies logic, not physical board timing or pin assignments.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A range check combines two comparisons, but the boundary convention must be explicit. Both ends are inclusive here: DATA must be greater than or equal to LOW and less than or equal to HIGH. Bounds come from SW nibbles multiplied by sixteen through concatenation with four zero bits. The three flags describe separate predicates rather than a priority decision. If the bounds are reversed, no value is inside and some values can be both below LOW and above HIGH. This is defined behavior in this lesson, not an automatically corrected input error. The mobile model checks supported two-state SystemVerilog behavior, not propagation delays or physical resource placement. Compile checks supported syntax and connectivity; RUN observes your current inputs; VERIFY compares the edited design with independent expected values. A compiling design can still be wrong. After repair, vary inputs without recompiling, predict the complete output byte, and explain discrepancies before attempting the assessment. Export the source and testbench for external verification; real board deployment additionally requires a reviewed pin adapter and constraints.

Worked example: module lesson(input logic [7:0] sw, data, output logic [7:0] led);
logic [7:0] low,high; assign low={sw[3:0],4'b0}; assign high={sw[7:4],4'b0}; assign led={5'b0,(data>high),(data<low),((data>=low)&&(data<=high))};
endmodule

Learner activity: What can change a magnitude comparison result?

Lab: Compare unsigned DATA with LOW=16*SW3:0 and HIGH=16*SW7:4. LED0 means inside the inclusive range, LED1 below LOW, LED2 above HIGH; other bits zero. Repair the missing equality on the upper boundary. If LOW>HIGH, inside is false and below/above may both assert. Compile your edited SystemVerilog, predict an output, apply inputs without a clock, and pass VERIFY DESIGN before the assessment. This verifies logic, not physical board timing or pin assignments.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A decoder converts a binary index into a one-hot pattern. A multiplexer selects data from one source. This lab places both functions behind a mode bit so their different purposes can be compared directly. Decoder mode sets one of four low LED bits based only on the two-bit selector. Mux mode selects a two-bit DATA lane, with the least-significant lane numbered zero. Multiplying the selector by two gives the lane's shift amount; masking with three retains only that lane. Keep every higher result bit defined as zero in both modes. The mobile model checks supported two-state SystemVerilog behavior, not propagation delays or physical resource placement. Compile checks supported syntax and connectivity; RUN observes your current inputs; VERIFY compares the edited design with independent expected values. A compiling design can still be wrong. After repair, vary inputs without recompiling, predict the complete output byte, and explain discrepancies before attempting the assessment. Export the source and testbench for external verification; real board deployment additionally requires a reviewed pin adapter and constraints.

Worked example: module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led=sw[2] ? (8'd1 << sw[1:0]) : ((data >> {sw[1:0],1'b0}) & 8'd3);
endmodule

Learner activity: Why include a default output?

Lab: Build a two-mode selector. SW2=1 outputs a four-bit one-hot decoder of SW1:0. SW2=0 selects one two-bit lane of DATA using SW1:0, with lane0=DATA1:0. All upper LED bits zero. Repair the decoder shift; test both modes. Compile your edited SystemVerilog, predict an output, apply inputs without a clock, and pass VERIFY DESIGN before the assessment. This verifies logic, not physical board timing or pin assignments.

Controls: SELECT0 · sw[0], SELECT1 · sw[1], DECODE · sw[2]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SELECT0 · sw[0], SELECT1 · sw[1], DECODE · sw[2], DATA, LED
Interactive inputs: SELECT0 · sw[0], SELECT1 · sw[1], DECODE · sw[2]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Adding two W-bit unsigned values can require W+1 bits. The child explicitly extends both operands with a leading zero before addition, so the intended width is visible in the expression. The parent instantiates W=4 and retains all five result bits rather than discarding the carry. Upper SW and DATA nibbles are intentionally unused. Repair the arithmetic operation in the child, then choose boundary cases that exercise the fifth bit. This arithmetic does not prove a particular carry-chain mapping; inspect synthesis reports separately after exporting the source. The mobile model checks supported two-state SystemVerilog behavior, not propagation delays or physical resource placement. Compile checks supported syntax and connectivity; RUN observes your current inputs; VERIFY compares the edited design with independent expected values. A compiling design can still be wrong. After repair, vary inputs without recompiling, predict the complete output byte, and explain discrepancies before attempting the assessment. Export the source and testbench for external verification; real board deployment additionally requires a reviewed pin adapter and constraints.

Worked example: module add_carry #(parameter W=4)(input logic [W-1:0] a,b,output logic [W:0] y);
assign y={1'b0,a} + {1'b0,b};
endmodule
module lesson(input logic [7:0] sw,data,output logic [7:0] led);
logic [4:0] sum;
add_carry #(.W(4)) u_add(.a(sw[3:0]),.b(data[3:0]),.y(sum));
assign led={3'b0,sum};
endmodule

Learner activity: How wide is sum_ext for W-bit operands?

Lab: Repair a parameterized W=4 unsigned adder. Explicitly extend both operands to W+1 before addition and preserve the five-bit sum on LED4:0; upper LEDs zero. Inputs use low nibbles only. Replace subtraction and demonstrate 15+1=16 and 15+15=30. Compile your edited SystemVerilog, predict an output, apply inputs without a clock, and pass VERIFY DESIGN before the assessment. This verifies logic, not physical board timing or pin assignments.

Controls: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7, DATA, LED
Interactive inputs: SW0, SW1, SW2, SW3, SW4, SW5, SW6, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A datapath combines operation selection with arithmetic and status generation. DATA supplies two unsigned four-bit operands; the operation code comes from SW1:0. The intermediate value has five bits so addition retains carry. Other operations naturally produce no carry. Zero status is defined from the low result nibble, not from all five intermediate bits. Therefore adding fifteen and one asserts both carry and zero. Keep reserved result bits at zero and cover every opcode with equality, boundary and nonzero patterns. The verification must check the packed status byte, not only the visible low result. The mobile model checks supported two-state SystemVerilog behavior, not propagation delays or physical resource placement. Compile checks supported syntax and connectivity; RUN observes your current inputs; VERIFY compares the edited design with independent expected values. A compiling design can still be wrong. After repair, vary inputs without recompiling, predict the complete output byte, and explain discrepancies before attempting the assessment. Export the source and testbench for external verification; real board deployment additionally requires a reviewed pin adapter and constraints.

Worked example: module lesson(input logic [7:0] sw, data, output logic [7:0] led);
logic [4:0] value;
always_comb begin
case(sw[1:0])
0: value={1'b0,data[3:0]}+{1'b0,data[7:4]};
1: value={1'b0,(data[3:0]&data[7:4])};
2: value={4'b0,(data[3:0]<data[7:4])};
default: value={1'b0,data[3:0]};
endcase
end
assign led={(value[3:0]==0),2'b0,value};
endmodule

Learner activity: What proves no selection case is missing?

Lab: Build a nibble ALU: A=DATA3:0, B=DATA7:4. SW1:0 chooses 0 ADD, 1 AND, 2 unsigned A<B, 3 A pass-through. LED3:0=result nibble, LED4=carry from ADD, LED7=1 when result nibble is zero, LED6:5=0. Repair zero detection; 15+1 must show carry and zero together. Compile your edited SystemVerilog, predict an output, apply inputs without a clock, and pass VERIFY DESIGN before the assessment. This verifies logic, not physical board timing or pin assignments.

Controls: OP0 · sw[0], OP1 · sw[1]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: OP0 · sw[0], OP1 · sw[1], DATA, LED
Interactive inputs: OP0 · sw[0], OP1 · sw[1]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A nonblocking assignment evaluates its right-hand expression using the values that existed before the active edge. Updates then become visible together. In this two-stage pipeline first captures the current input nibble while second captures the previous first. Reading the lines from top to bottom must not turn the second assignment into a copy of the newly updated first. The packed monitor deliberately exposes both stages so the one-edge difference is visible. Reset clears both registers at an edge; changing reset or data between edges does not alter synchronous state. The mobile model starts its storage at zero for teaching, but this is not a hardware power-up guarantee. Begin by applying the specified reset. Compile checks the supported source; changing controls prepares inputs; CLOCK EDGE samples synchronous state; VERIFY checks the ordered acceptance sequence independently. An input edit is not an extra clock event. Exported tests use an external simulator, and real deployment additionally needs a reviewed board interface, clock and reset constraints.

Worked example: always_ff @(posedge clk) q <= d;

Learner activity: Which assignment belongs in clocked RTL?

Lab: Implement nonblocking assignments, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A clock enable conditions state updates without creating a separate clock. The accumulator must retain its previous sum and add the new DATA value only on an enabled edge. Copying DATA is a valid register operation but not accumulation, so a syntax pass alone cannot establish correctness. The eight-bit state discards carry and wraps modulo 256 by specification. Test a held state while changing DATA and then apply an enabled edge using the new input. Reset has higher priority than enable and must clear the entire sum even when enable is asserted. The mobile model starts its storage at zero for teaching, but this is not a hardware power-up guarantee. Begin by applying the specified reset. Compile checks the supported source; changing controls prepares inputs; CLOCK EDGE samples synchronous state; VERIFY checks the ordered acceptance sequence independently. An input edit is not an extra clock event. Exported tests use an external simulator, and real deployment additionally needs a reviewed board interface, clock and reset constraints.

Worked example: if (enable) q <= d;

Learner activity: What happens when enable is 0?

Lab: Implement clock enable, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, D, Q
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A synchronous reset affects storage only at a clock event, while an asynchronous reset can assert independently of that event. This exercise requires asynchronous assertion to a nonzero constant so it cannot be confused with the mobile model's zero initialization. Releasing reset is not a data-capture event; the register waits for a subsequent rising edge. The RTL event control includes the active clock edge and the falling active-low reset. Digital simulation does not model metastability, recovery or removal violations. A real board implementation needs the target device's reviewed reset assertion and release strategy. The mobile model starts its storage at zero for teaching, but this is not a hardware power-up guarantee. Begin by applying the specified reset. Compile checks the supported source; changing controls prepares inputs; CLOCK EDGE samples synchronous state; VERIFY checks the ordered acceptance sequence independently. An input edit is not an extra clock event. Exported tests use an external simulator, and real deployment additionally needs a reviewed board interface, clock and reset constraints.

Worked example: always_ff @(posedge clk or negedge rst_n)

Learner activity: Which signal acts asynchronously here?

Lab: Implement synchronous and asynchronous reset, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, RST, Q
Interactive inputs: RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A four-bit counter can encode zero through fifteen, but its boundary policy is a design choice. This counter saturates: incrementing fifteen keeps fifteen, and decrementing zero keeps zero. A plain arithmetic update would wrap and violate that contract. Load has higher priority than counting, so a user can establish a boundary state directly rather than stepping through every value. Enable controls both directions. Write the priority order before editing: reset, load, enabled count, hold. Verify both endpoints and use a no-edge load change to prove that load is still synchronous. The mobile model starts its storage at zero for teaching, but this is not a hardware power-up guarantee. Begin by applying the specified reset. Compile checks the supported source; changing controls prepares inputs; CLOCK EDGE samples synchronous state; VERIFY checks the ordered acceptance sequence independently. An input edit is not an extra clock event. Exported tests use an external simulator, and real deployment additionally needs a reviewed board interface, clock and reset constraints.

Worked example: logic [3:0] count; count <= count + 1'b1;

Learner activity: What follows 15?

Lab: Implement counters and rollover, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, D, Q
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A finite-state machine stores the progress of a temporal rule. This detector needs two consecutive sampled high inputs. State one remembers the first high; state two reports detection for one cycle; state three waits for a sampled low before rearming. Continuous high input must not produce a fresh detection each edge. The visible state bits let the learner inspect the transition sequence instead of guessing from one LED. An input glitch between sampling edges is not a sampled event in this digital model. The exercise assumes its input is already synchronous to the clock. The mobile model starts its storage at zero for teaching, but this is not a hardware power-up guarantee. Begin by applying the specified reset. Compile checks the supported source; changing controls prepares inputs; CLOCK EDGE samples synchronous state; VERIFY checks the ordered acceptance sequence independently. An input edit is not an extra clock event. Exported tests use an external simulator, and real deployment additionally needs a reviewed board interface, clock and reset constraints.

Worked example: IDLE → LOAD → RUN → DONE

Learner activity: Which block stores the current state?

Lab: Implement finite-state machines, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, INPUT, STATE, OUTPUT
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A shift register moves stored bits one position per enabled edge. Direction defines which old endpoint is discarded and where the serial bit enters. A right shift inserts the serial input at bit seven; a left shift inserts it at bit zero. Parallel load replaces all eight bits in one event and takes priority over shifting. The monitor shows the full stored byte, allowing a learner to follow a marker bit across positions. Setting serial input or direction is preparation, not a state update. The common error is to implement both directions with the same concatenation. The mobile model starts its storage at zero for teaching, but this is not a hardware power-up guarantee. Begin by applying the specified reset. Compile checks the supported source; changing controls prepares inputs; CLOCK EDGE samples synchronous state; VERIFY checks the ordered acceptance sequence independently. An input edit is not an extra clock event. Exported tests use an external simulator, and real deployment additionally needs a reviewed board interface, clock and reset constraints.

Worked example: module lesson(input logic clk, input logic [7:0] sw, data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!sw[0]) led <= 8'd0;
else if(sw[2]) led<=data;else if(sw[1]) begin if(sw[3]) led<={sw[4],led[7:1]};else led<={led[6:0],sw[4]};end
end
endmodule

Learner activity: What determines the output timing?

Lab: Build a bidirectional eight-bit shift register. At an edge SW0 resets, then SW2 parallel-loads DATA, otherwise SW1 enables shifting. SW3=1 shifts right inserting SW4 at bit7; SW3=0 shifts left inserting SW4 at bit0. Repair the right-shift direction. Load must override shift. Compile, apply reset, predict the packed LED byte, run the specified edges and pass independent verification. Logical model state starts at zero; actual hardware needs a reviewed initialization/reset design.

Controls: RESET_N · sw[0], ENABLE · sw[1], LOAD · sw[2], RIGHT · sw[3], SERIAL · sw[4]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], ENABLE · sw[1], LOAD · sw[2], RIGHT · sw[3], SERIAL · sw[4], DATA, LED
Interactive inputs: RESET_N · sw[0], ENABLE · sw[1], LOAD · sw[2], RIGHT · sw[3], SERIAL · sw[4]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A sampled-edge detector compares the current input with the previously stored sample. A rising event is current high and previous low. The count increments for that event while the previous-sample register captures the current input on every nonreset edge. Holding the input high must therefore count once, not repeatedly. The previous sample is displayed at LED4 to make the detector's memory visible. A short external pulse that never reaches a sample edge is not counted. This lab assumes synchronous input; real asynchronous signals require suitable synchronization and a pulse-width or handshake strategy. The mobile model starts its storage at zero for teaching, but this is not a hardware power-up guarantee. Begin by applying the specified reset. Compile checks the supported source; changing controls prepares inputs; CLOCK EDGE samples synchronous state; VERIFY checks the ordered acceptance sequence independently. An input edit is not an extra clock event. Exported tests use an external simulator, and real deployment additionally needs a reviewed board interface, clock and reset constraints.

Worked example: module lesson(input logic clk, input logic [7:0] sw, output logic [7:0] led);
logic previous;logic [3:0] count;
always_ff @(posedge clk) begin
if(!sw[0]) begin previous<=0;count<=0;end
else begin previous<=sw[1];if(sw[1] && !previous) count<=count+4'd1;end
end
assign led={3'b0,previous,count};
endmodule

Learner activity: Why detect an edge instead of counting high cycles?

Lab: Count sampled low-to-high transitions of SW1, not high cycles. At an edge compare SW1 with its previous sampled value, increment a four-bit count once per rise and store the new sample. SW0 resets both synchronously. LED3:0=count, LED4=previous sample. Repair the missing previous-sample condition. SW1 is assumed synchronous here; a real asynchronous input needs reviewed synchronization. Compile, apply reset, predict the packed LED byte, run the specified edges and pass independent verification. Logical model state starts at zero; actual hardware needs a reviewed initialization/reset design.

Controls: RESET_N · sw[0], ENABLE / SAMPLE · sw[1]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], ENABLE / SAMPLE · sw[1], LED
Interactive inputs: RESET_N · sw[0], ENABLE / SAMPLE · sw[1]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Pulse-width modulation compares a repeating phase with a duty threshold. Four phase values provide a compact model that can be stepped manually. Duty zero must never assert PWM, while duty four must assert throughout the four-phase period; the threshold therefore needs three bits even though phase uses two. Values above four are clamped. The strict less-than comparison is essential at the boundary. Phase is stored, but PWM is combinational, so changing DUTY can change LED7 without advancing phase. A production glitch-free PWM commonly latches duty at a period boundary; this lesson deliberately does not claim that behavior. The mobile model starts its storage at zero for teaching, but this is not a hardware power-up guarantee. Begin by applying the specified reset. Compile checks the supported source; changing controls prepares inputs; CLOCK EDGE samples synchronous state; VERIFY checks the ordered acceptance sequence independently. An input edit is not an extra clock event. Exported tests use an external simulator, and real deployment additionally needs a reviewed board interface, clock and reset constraints.

Worked example: module lesson(input logic clk, input logic [7:0] sw, data, output logic [7:0] led);
logic [1:0] phase;logic [2:0] duty;
assign duty=(data[2:0]>4) ? 3'd4 : data[2:0];
always_ff @(posedge clk) begin if(!sw[0]) phase<=0;else if(sw[1]) phase<=phase+2'd1;end
assign led={(sw[0] && (phase < duty)),5'b0,phase};
endmodule

Learner activity: What changes PWM average high time?

Lab: Build a four-phase teaching PWM. SW0 synchronously resets phase and suppresses PWM while low. SW1 enables modulo-4 phase advance. LED1:0 shows phase; LED7=(phase<DUTY) when reset is released. DUTY=DATA2:0 clamped to 4, allowing 0%, 25%, 50%, 75%, 100%. Repair <= to <. Duty changes affect this combinational output immediately; this simple lab is not a glitch-free physical PWM design. Compile, apply reset, predict the packed LED byte, run the specified edges and pass independent verification. Logical model state starts at zero; actual hardware needs a reviewed initialization/reset design.

Controls: RESET_N · sw[0], ENABLE / SAMPLE · sw[1]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], ENABLE / SAMPLE · sw[1], DATA, LED
Interactive inputs: RESET_N · sw[0], ENABLE / SAMPLE · sw[1]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A safe-state policy must define both outputs and a transition for unexpected state encodings. This lab reserves encoding three as illegal and includes an explicit injection control for learning and verification. Injecting state three at an edge makes error visible while keeping busy and done low. With injection released, the next edge recovers to idle. A default assignment that retains the illegal state defeats recovery even though the source compiles. Test injection is a teaching facility, not an assumed production interface or proof against physical faults. Real designs need system-specific hazard and recovery analysis. The mobile model starts its storage at zero for teaching, but this is not a hardware power-up guarantee. Begin by applying the specified reset. Compile checks the supported source; changing controls prepares inputs; CLOCK EDGE samples synchronous state; VERIFY checks the ordered acceptance sequence independently. An input edit is not an extra clock event. Exported tests use an external simulator, and real deployment additionally needs a reviewed board interface, clock and reset constraints.

Worked example: module lesson(input logic clk, input logic [7:0] sw, data, output logic [7:0] led);
logic [1:0] state;
always_ff @(posedge clk) begin
if(!sw[0]) state<=0;
else if(sw[2]) state<=data[1:0];
else begin case(state)
0:if(sw[1]) state<=1;
1:state<=2;
2:if(sw[3]) state<=0;
default:state<=0;
endcase end
end
assign led={(state==3),(state==2),(state==1),3'b0,state};
endmodule

Learner activity: What should an illegal state do?

Lab: Implement an FSM with explicit fault-injection practice. At an edge SW0 resets; SW2 injects DATA1:0 into state for testing. Otherwise idle0 accepts SW1 start -> busy1 -> done2; SW3 acknowledges done -> idle. Illegal3 recovers to idle at the next edge and drives only error status. LED7=error, LED6=done, LED5=busy, LED1:0=state. Repair the default recovery branch. Compile, apply reset, predict the packed LED byte, run the specified edges and pass independent verification. Logical model state starts at zero; actual hardware needs a reviewed initialization/reset design.

Controls: RESET_N · sw[0], START · sw[1], INJECT · sw[2], ACK · sw[3]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], START · sw[1], INJECT · sw[2], ACK · sw[3], DATA, LED
Interactive inputs: RESET_N · sw[0], START · sw[1], INJECT · sw[2], ACK · sw[3]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A transaction controller separates accepting a request, performing work and publishing a valid result. Input data must be captured at acceptance so later edits cannot corrupt an active transaction. Two work edges follow the acceptance edge; at completion the controller publishes twice the captured nibble modulo sixteen. Busy and valid describe different phases and must not assert together. Once done, the result remains stable until acknowledgement; a new start alone is ignored. Reset overrides every state. The example teaches protocol and latency rather than a useful arithmetic accelerator, since a real multiply-by-two can be simple combinational wiring. The mobile model starts its storage at zero for teaching, but this is not a hardware power-up guarantee. Begin by applying the specified reset. Compile checks the supported source; changing controls prepares inputs; CLOCK EDGE samples synchronous state; VERIFY checks the ordered acceptance sequence independently. An input edit is not an extra clock event. Exported tests use an external simulator, and real deployment additionally needs a reviewed board interface, clock and reset constraints.

Worked example: module lesson(input logic clk, input logic [7:0] sw, data, output logic [7:0] led);
logic [1:0] state;logic [3:0] captured,result;
always_ff @(posedge clk) begin
if(!sw[0]) begin state<=0;captured<=0;result<=0;end
else begin case(state)
0:if(sw[1]) begin captured<=data[3:0];state<=1;end
1:state<=2;
2:begin result<=captured+captured;state<=3;end
default:if(sw[2]) begin state<=0;result<=0;end
endcase end
end
assign led={(state==3),((state==1)||(state==2)),2'b0,result};
endmodule

Learner activity: What prevents a new start from corrupting an active transaction?

Lab: Build a transaction controller. Idle accepts SW1 start at an edge and captures DATA3:0. After two further work edges publish twice the CAPTURED nibble modulo16 and assert valid. Ignore later DATA/start while busy or done. SW2 acknowledges done and clears result; SW0 resets synchronously with highest priority. LED7=valid, LED6=busy, LED3:0=result. Repair the starter that uses current DATA at completion. Compile, apply reset, predict the packed LED byte, run the specified edges and pass independent verification. Logical model state starts at zero; actual hardware needs a reviewed initialization/reset design.

Controls: RESET_N · sw[0], START · sw[1], ACK · sw[2]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RESET_N · sw[0], START · sw[1], ACK · sw[2], DATA, LED
Interactive inputs: RESET_N · sw[0], START · sw[1], ACK · sw[2]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A testbench provides repeatable clock and reset stimulus before functional vectors begin.

Clock and reset generation is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: initial clk=0; always #5 clk=~clk;

Learner activity: What period does this clock have?

Lab: Implement clock and reset generation, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, RST, Q
Interactive inputs: RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Tasks package repeated bus operations while keeping timing and protocol rules in one place.

Reusable stimulus tasks is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: task send_byte(input [7:0] value);

Learner activity: Why use a task?

Lab: Implement reusable stimulus tasks, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A scoreboard compares the behavior required by a specification with the behavior observed from a design under test (DUT). Its expected result must be independent of that observed result. Copying the DUT output into both inputs makes every comparison agree, even when the design is wrong.

This exercise isolates the comparison component. The switches set an unsigned EXPECTED byte named sw. The DATA field supplies an unsigned ACTUAL byte named data. Write assign led = data != sw; so LED0 is one for a mismatch and zero for a match. The one-bit comparison result is zero-extended into the eight-bit LED output. There is no clocked storage in this component. Changing either input changes the comparison after settling; no recompilation is needed unless the source changes.

The starter uses equality instead of inequality, reversing the meaning of the flag. Test both matching values and deliberate differences, including a difference in the most significant bit. A correct comparison is necessary but not sufficient for verification: an external scoreboard must also associate each response with the correct transaction and sample after the specified latency. This mobile exercise supports only known zero/one values. In an external four-state testbench, case inequality (!==) can detect X/Z differences according to the chosen checking policy. Do not treat this two-state lesson as an X/Z or temporal assertion simulator.

Worked example: if (actual !== expected) $error;

Learner activity: What does the scoreboard detect?

Lab: Implement scoreboards, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, CHECK
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An assertion states a rule that must hold. In a verification environment, SystemVerilog Assertions (SVA) can describe temporal relationships such as a request being acknowledged within a bounded number of cycles. This app does not execute arbitrary SVA syntax. Instead, this lesson builds a small synthesizable monitor whose output makes one rule observable on the simulated board.

REQ is SW0 and ACK is SW1. At each rising edge, LED0 is one exactly when ACK=1 and REQ=0. That is an acknowledgement without an active request. Legal idle (00), request only (01) and simultaneous request/acknowledge (11) produce zero. The register holds its previous violation result when inputs change without a rising edge. The starter uses OR, which incorrectly flags legal combinations; repair it to an AND of ACK and the inverted REQ.

This monitor checks one sampled cycle and does not remember a request across cycles, enforce an acknowledgement latency range or represent X/Z states. A production assertion suite would add temporal properties, reset/disable conditions, failure messages and coverage. Use an external simulator for those constructs. A passing monitor is evidence about the stated rule, not proof that the surrounding DUT or physical board is correct.

Worked example: assert property (@(posedge clk) req |-> ##[1:3] ack);

Learner activity: What is being bounded?

Lab: Implement assertions, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, CHECK
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Functional coverage records whether selected scenarios happened. It answers a different question from a scoreboard: did we exercise this operation, rather than did the operation produce the correct result? First define the scenarios from the requirements. In this exercise there are four opcodes, encoded by DATA[1:0]. Each has one coverage bit in LED3:0; upper DATA bits are ignored.

The recorder samples only on a rising clock edge while SW1, SAMPLE_ENABLE, is high. Form a one-hot bit with 8'd1 << data[1:0], then OR it into the stored bitmap. OR preserves earlier observations, including when the same opcode is sampled again. The starter incorrectly uses XOR: sampling a bin twice erases its evidence. SW0 is a synchronous active-low reset; when low at an edge it clears all bins, even if enable is high. Changing opcode or reset without an edge does not change the register.

This is an explicit synthesizable teaching recorder, not an implementation of SystemVerilog covergroup syntax. A full verification environment may use simulator-managed coverpoints, crosses and coverage reports. Neither this bitmap nor 100 percent of a chosen coverage model guarantees absence of bugs: the model may omit important conditions, and the DUT results still need independent checking. Real hardware use also requires valid clock/reset and input synchronization assumptions.

Worked example: covergroup inputs; coverpoint opcode; endgroup

Learner activity: What does a coverage hole mean?

Lab: Implement functional coverage, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, CHECK
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Directed cases guarantee critical boundaries; constrained-random cases explore legal combinations not anticipated manually.

Build the bounded xor contract for "Directed and constrained-random stimulus". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Directed and constrained-random stimulus is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Always test reset and overflow directly, then randomize legal transactions with a recorded seed.

Bounded reference RTL:
// Bounded lesson contract: Directed and constrained-random stimulus
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw ^ data;
endmodule

Learner activity: Why use both stimulus styles?

Lab: Build the bounded xor contract for "Directed and constrained-random stimulus". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Immediate assertions check current expressions; temporal assertions check relationships across clock cycles.

Build the bounded compare contract for "Immediate and temporal assertions". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Immediate and temporal assertions is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: req |-> ##[1:3] ack requires acknowledgement one to three cycles later.

Bounded reference RTL:
// Bounded lesson contract: Immediate and temporal assertions
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = (sw <= data) ? 8'h01 : 8'h00;
endmodule

Learner activity: What does the range [1:3] define?

Lab: Build the bounded compare contract for "Immediate and temporal assertions". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Coverage models record required states, transitions, values, and crosses. Closure requires explaining or exercising every meaningful hole.

Build the bounded xor contract for "Coverage models and closure". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Coverage models and closure is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Cross operation with overflow to ensure each operation is tested at the boundary.

Bounded reference RTL:
// Bounded lesson contract: Coverage models and closure
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw ^ data;
endmodule

Learner activity: What is a coverage hole?

Lab: Build the bounded xor contract for "Coverage models and closure". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A reference model independently predicts results. A scoreboard aligns transactions and compares expected with observed output.

Build the bounded xor contract for "Formal reference models and scoreboards". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Formal reference models and scoreboards is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Queue expected ALU responses, then compare each DUT valid response in order.

Bounded reference RTL:
// Bounded lesson contract: Formal reference models and scoreboards
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw ^ data;
endmodule

Learner activity: Why keep the predictor independent from DUT RTL?

Lab: Build the bounded xor contract for "Formal reference models and scoreboards". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A regression capstone runs lint/validation, directed tests, seeded random tests, assertions, coverage, and summarized failures automatically.

Build the bounded shift contract for "Verification regression capstone". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Verification regression capstone is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: One command records tool version, seed, tests, assertion failures, and coverage report.

Bounded reference RTL:
// Bounded lesson contract: Verification regression capstone
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw << data[2:0];
endmodule

Learner activity: What makes the regression trustworthy?

Lab: Build the bounded shift contract for "Verification regression capstone". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[2:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[2:0], DATA, LED
Interactive inputs: SW[7:0], DATA[2:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A pipeline divides a long datapath into stages separated by registers. Each rising edge advances values one stage. The extra registers can shorten the amount of combinational work between edges, which may permit a faster clock, but the result of a newly presented input arrives later.

This exercise has an eight-bit DATA input, an active-low RESET_N on SW0, a stage-1 register and an LED output register. A low RESET_N at a rising edge clears both registers. Otherwise, at an edge, stage captures DATA while LED captures the old stage value because both nonblocking assignments sample the pre-edge state. Therefore an input value appears at LED one edge later. DATA changes without an edge do not alter either register. The starter assigns LED directly from DATA inside the clocked block, bypassing the intended stage and hiding the latency.

This is a two-stage transport example, not a performance benchmark. A practical pipeline also needs valid bits, reset policy, arithmetic-width planning, stall/flush behavior and timing reports. The app models logical edges only; it does not synthesize the design or measure a device-specific clock limit.

Worked example: stage1 <= a*b; stage2 <= stage1+c;

Learner activity: What tradeoff is added?

Lab: Implement pipeline registers, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, D, Q
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A valid/ready interface transfers one payload on a rising edge only when VALID and READY are both high. VALID means the producer is presenting a meaningful item; READY means the consumer can accept it. If either side is low, there is no transfer. A receiver must not capture a payload merely because VALID changed, and a producer must keep a valid payload stable while waiting for READY.

This lesson models a receiver register. SW0 is VALID, SW1 is READY and DATA is the eight-bit payload. On a rising edge with both controls high, LED captures DATA. On an edge without a transfer, LED is cleared to zero. If DATA or the controls change without an edge, the registered LED holds. The starter uses OR, so it incorrectly captures when only one side is ready; repair it to AND.

The small monitor does not implement a FIFO, a skid buffer, a multi-beat packet, or independent source-side stability assertions. In a larger design, the transfer event would feed a queue or processing pipeline, and verification would also check that DATA remains stable while VALID=1 and READY=0. The mobile model uses known two-state values and has no physical timing or CDC analysis.

Worked example: transfer = valid && ready;

Learner activity: When does data move?

Lab: Implement valid and ready handshake, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: VALID, READY, TRANSFER
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A FIFO preserves first-in, first-out ordering while decoupling a producer from a consumer. A full flag prevents a write from overwriting an item that has not been read; an empty flag prevents a read from consuming nonexistent data. This lesson intentionally starts with the smallest useful FIFO: one storage slot and one full bit.

SW0 is active-low RESET_N, SW1 is WRITE and SW2 is READ. On a rising edge, reset clears the slot. If READ is high while the slot is full, the item is consumed and LED clears. Otherwise a WRITE is accepted only when the slot is empty, capturing DATA and setting full. A write while full is ignored. Changing controls or DATA without an edge cannot alter the stored item.

This is not a multi-entry queue. A production FIFO adds read/write pointers, occupancy arithmetic, memory, simultaneous read/write policy, overflow/underflow flags and often separate clock-domain logic. The app demonstrates the contract and failure mode; it does not infer block RAM or prove CDC safety.

Worked example: write pointer, read pointer, memory

Learner activity: Which item leaves first?

Lab: Implement fifo buffering, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, WRITE, READ, LEVEL
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An asynchronous transition near a sampling edge can violate setup or hold and place a flip-flop in a metastable state.

Metastability is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: async input → synchronizer FF1 → FF2

Learner activity: What reduces propagation risk for a single bit?

Lab: Implement metastability, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Multi-bit data requires a handshake, Gray code, or asynchronous FIFO rather than independent bit synchronizers.

Clock-domain crossing protocols is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Gray-coded FIFO pointers cross domains

Learner activity: Why use Gray code for a pointer?

Lab: Implement clock-domain crossing protocols, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, D, Q
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A skid buffer holds one transfer when ready falls late, preserving data and valid without duplication or loss.

Build the bounded invert contract for "Skid buffers under backpressure". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Skid buffers under backpressure is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: If valid=1 and ready changes to 0, the offered data is captured until transfer resumes.

Bounded reference RTL:
// Bounded lesson contract: Skid buffers under backpressure
module lesson(input logic [7:0] sw, output logic [7:0] led);
assign led = ~sw;
endmodule

Learner activity: What must remain stable while valid=1 and ready=0?

Lab: Build the bounded invert contract for "Skid buffers under backpressure". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], LED
Interactive inputs: SW[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A narrow pulse can disappear between unrelated clocks. Pulse stretching, toggles, or handshakes preserve the event until observed.

Build the bounded toggle contract for "Pulse and toggle CDC transfer". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Pulse and toggle CDC transfer is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Source toggles a bit per event; destination synchronizes it and detects a change.

Bounded reference RTL:
// Bounded lesson contract: Pulse and toggle CDC transfer
module lesson(input logic clk, rst_n, enable, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00; else if (enable) led <= ~led;
end
endmodule

Learner activity: Why is a raw one-cycle pulse unsafe across domains?

Lab: Build the bounded toggle contract for "Pulse and toggle CDC transfer". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: RST_N · 0 resets, ENABLE. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, ENABLE, DATA, LED
Interactive inputs: RST_N · 0 resets, ENABLE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Reset assertion and deassertion affect domain state and interfaces. Deassertion is synchronized per clock domain before normal transfers begin.

Build the bounded toggle contract for "Reset-domain crossing". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Reset-domain crossing is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Each domain uses a reset synchronizer and asserts ready only after local release.

Bounded reference RTL:
// Bounded lesson contract: Reset-domain crossing
module lesson(input logic clk, rst_n, enable, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00; else if (enable) led <= ~led;
end
endmodule

Learner activity: What can unsynchronized reset release cause?

Lab: Build the bounded toggle contract for "Reset-domain crossing". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: RST_N · 0 resets, ENABLE. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, ENABLE, DATA, LED
Interactive inputs: RST_N · 0 resets, ENABLE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Latency counts time or cycles from acceptance to response; throughput counts completed transfers per interval after pipeline fill.

Build the bounded xor contract for "Measure latency and throughput". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Measure latency and throughput is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A four-stage pipeline has four-cycle latency but can sustain one result each cycle.

Bounded reference RTL:
// Bounded lesson contract: Measure latency and throughput
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw ^ data;
endmodule

Learner activity: Can high throughput coexist with multi-cycle latency?

Lab: Build the bounded xor contract for "Measure latency and throughput". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A complete streaming design combines pipelined processing, valid/ready, backpressure, buffering, reset, and CDC boundaries with no loss or reordering.

Build the bounded handshake contract for "Streaming pipeline capstone". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Streaming pipeline capstone is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Random stalls exercise a processing pipeline while a scoreboard verifies ordered outputs.

Bounded reference RTL:
// Bounded lesson contract: Streaming pipeline capstone
module lesson(input logic clk, rst_n, enable, sel, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00; else if (enable && sel) led <= data;
end
endmodule

Learner activity: What must be proven during backpressure?

Lab: Build the bounded handshake contract for "Streaming pipeline capstone". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: RST_N · 0 resets, READY / ENABLE, VALID / SEL. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, READY / ENABLE, VALID / SEL, DATA, LED
Interactive inputs: RST_N · 0 resets, READY / ENABLE, VALID / SEL, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A constant lookup table can infer ROM and provides deterministic mapped values.

ROM inference is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: case(address) 0:data=8'h3C; endcase

Learner activity: What selects the stored value?

Lab: Implement rom inference, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: ADDRESS, DATA, VALID
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Synchronous array templates map large storage into dedicated FPGA RAM instead of LUTs.

Block RAM inference is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: always_ff @(posedge clk) if (we) mem[addr] <= din;

Learner activity: When is a write performed?

Lab: Implement block ram inference, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, ADDRESS, DATA, VALID
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Dual-port RAM supports two controlled accesses and requires explicit collision behavior.

Dual-port memory is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: port A writes while port B reads

Learner activity: What must be defined for one-address collisions?

Lab: Implement dual-port memory, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, ADDRESS, DATA, VALID
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A multiply-accumulate (MAC) datapath computes a product and adds it to a stored accumulator. It appears in FIR filters, matrix operations, control loops and neural-network kernels. FPGA families often provide dedicated DSP blocks, but inference depends on widths, signedness, pipeline structure, tool version and device resources; writing `*` alone is not proof of a particular implementation.

SW0 is active-low RESET_N, SW1 is ENABLE, SW[5:2] supplies a four-bit coefficient and DATA[3:0] supplies a four-bit sample. On an enabled rising edge the reference adds coefficient*sample to the eight-bit LED accumulator. Disabled edges and no-edge input changes hold. Reset has priority and clears the accumulator. The eight-bit contract wraps at 256, so 235+30 becomes 9.

The mobile interpreter checks the arithmetic and clock/hold behavior only. After exporting, use the exact PolarFire device configuration in Libero, compare inferred DSP/LUT resources, review signedness and timing, and preserve the report. A functional pass does not establish throughput, numerical precision or physical resource mapping.

Worked example: acc <= acc + a*b;

Learner activity: Which FPGA resource best matches this operation?

Lab: Implement dsp multiply-accumulate, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Fixed-point values assign an implied binary point and require planned width, rounding, saturation, and overflow handling.

Fixed-point arithmetic is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Q1.7 uses one integer/sign region and seven fractional bits

Learner activity: What must remain consistent?

Lab: Implement fixed-point arithmetic, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: ROM contents can be defined by constants or supported initialization files. Address range and read latency are part of the interface.

Build the bounded register contract for "ROM initialization and lookup tables". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

ROM initialization and lookup tables is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A sine table maps phase address to a fixed amplitude sample.

Bounded reference RTL:
// Bounded lesson contract: ROM initialization and lookup tables
module lesson(input logic clk, rst_n, enable, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00; else if (enable) led <= data;
end
endmodule

Learner activity: What must simulation and hardware share?

Lab: Build the bounded register contract for "ROM initialization and lookup tables". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: RST_N · 0 resets, ENABLE. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, ENABLE, DATA, LED
Interactive inputs: RST_N · 0 resets, ENABLE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: True dual-port RAM supports two independent controlled ports. Same-address collisions require a documented device-supported policy.

Build the bounded toggle contract for "True dual-port RAM behavior". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

True dual-port RAM behavior is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Port A writes address 5 while port B reads address 9; a collision test then exercises address 5.

Bounded reference RTL:
// Bounded lesson contract: True dual-port RAM behavior
module lesson(input logic clk, rst_n, enable, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00; else if (enable) led <= ~led;
end
endmodule

Learner activity: What must the testbench check explicitly?

Lab: Build the bounded toggle contract for "True dual-port RAM behavior". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: RST_N · 0 resets, ENABLE. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, ENABLE, DATA, LED
Interactive inputs: RST_N · 0 resets, ENABLE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: FIFO sizing accounts for burst length and rate difference. Full, empty, almost-full, and level flags control safe transfers.

Build the bounded handshake contract for "FIFO depth, flags, and overflow". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

FIFO depth, flags, and overflow is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A producer stops before full; a consumer reads only when not empty.

Bounded reference RTL:
// Bounded lesson contract: FIFO depth, flags, and overflow
module lesson(input logic clk, rst_n, enable, sel, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00; else if (enable && sel) led <= data;
end
endmodule

Learner activity: What happens if a write is accepted while full?

Lab: Build the bounded handshake contract for "FIFO depth, flags, and overflow". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: RST_N · 0 resets, READY / ENABLE, VALID / SEL. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, READY / ENABLE, VALID / SEL, DATA, LED
Interactive inputs: RST_N · 0 resets, READY / ENABLE, VALID / SEL, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Fixed-point arithmetic tracks binary points, growth, rounding, truncation, saturation, and overflow at every operation.

Build the bounded add contract for "Fixed-point rounding and saturation". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Fixed-point rounding and saturation is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A wide accumulator is rounded before returning to an 8-bit saturated output.

Bounded reference RTL:
// Bounded lesson contract: Fixed-point rounding and saturation
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw + data;
endmodule

Learner activity: Why saturate instead of wrap for some signals?

Lab: Build the bounded add contract for "Fixed-point rounding and saturation". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An accelerator streams samples from memory through pipelined DSP, stores results, and verifies numeric error, bandwidth, and overflow.

Build the bounded register contract for "Memory and DSP accelerator capstone". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Memory and DSP accelerator capstone is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A small FIR engine reads coefficients from ROM and samples from RAM, then compares output with a reference model.

Bounded reference RTL:
// Bounded lesson contract: Memory and DSP accelerator capstone
module lesson(input logic clk, rst_n, enable, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00; else if (enable) led <= data;
end
endmodule

Learner activity: What evidence validates numerical behavior?

Lab: Build the bounded register contract for "Memory and DSP accelerator capstone". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: RST_N · 0 resets, ENABLE. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, ENABLE, DATA, LED
Interactive inputs: RST_N · 0 resets, ENABLE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A clock constraint defines the period and waveform used by static timing analysis.

Primary clock constraints is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: create_clock -period 10 [get_ports clk]

Learner activity: What frequency corresponds to 10 ns?

Lab: Implement primary clock constraints, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, D, Q
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Setup analysis checks that data arrives sufficiently before the destination sampling edge.

Setup timing is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: slack = required time - arrival time

Learner activity: What does negative setup slack indicate?

Lab: Implement setup timing, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: SOURCE, DESTINATION, SLACK PASS
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Hold analysis checks that data remains stable long enough after the same sampling edge.

Hold timing is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Minimum-delay paths dominate hold checks

Learner activity: What commonly causes hold risk?

Lab: Implement hold timing, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: SOURCE, DESTINATION, SLACK PASS
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: I/O delays describe timing outside the FPGA relative to the interface clock.

Input and output delays is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: set_input_delay accounts for source device and board delay

Learner activity: Why constrain I/O?

Lab: Implement input and output delays, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: False and multicycle paths are used only when the architecture proves the default timing relationship does not apply.

Timing exceptions is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A two-cycle path gets a justified multicycle constraint

Learner activity: What is unsafe?

Lab: Implement timing exceptions, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: SOURCE, DESTINATION, SLACK PASS
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Derived clocks require constraints describing their source, divide/multiply ratio, phase, and intended relationships.

Build the bounded register contract for "Generated clocks and clock relationships". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Generated clocks and clock relationships is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A divide-by-two supported clock output is constrained as generated from the primary source.

Bounded reference RTL:
// Bounded lesson contract: Generated clocks and clock relationships
module lesson(input logic clk, rst_n, enable, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00; else if (enable) led <= data;
end
endmodule

Learner activity: Why define the source clock relationship?

Lab: Build the bounded register contract for "Generated clocks and clock relationships". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: RST_N · 0 resets, ENABLE. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, ENABLE, DATA, LED
Interactive inputs: RST_N · 0 resets, ENABLE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Unrelated clocks are declared asynchronous only when crossings use approved CDC structures and are verified separately.

Build the bounded toggle contract for "Clock groups and asynchronous domains". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Clock groups and asynchronous domains is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: set_clock_groups separates two independent oscillator domains while an async FIFO protects data.

Bounded reference RTL:
// Bounded lesson contract: Clock groups and asynchronous domains
module lesson(input logic clk, rst_n, enable, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00; else if (enable) led <= ~led;
end
endmodule

Learner activity: What is unsafe about declaring clocks asynchronous without CDC logic?

Lab: Build the bounded toggle contract for "Clock groups and asynchronous domains". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: RST_N · 0 resets, ENABLE. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, ENABLE, DATA, LED
Interactive inputs: RST_N · 0 resets, ENABLE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Input/output delays account for external device timing, board flight time, clock phase, and FPGA requirements.

Build the bounded compare contract for "Board-level input and output timing". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Board-level input and output timing is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A source-synchronous input constraint includes the transmitter clock-to-output and board margin.

Bounded reference RTL:
// Bounded lesson contract: Board-level input and output timing
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = (sw <= data) ? 8'h01 : 8'h00;
endmodule

Learner activity: What does set_input_delay model?

Lab: Build the bounded compare contract for "Board-level input and output timing". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: CDC review identifies every crossing, its protocol, synchronizer attributes, physical placement needs, and any justified timing exception.

Build the bounded register contract for "CDC constraints and synchronizer review". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

CDC constraints and synchronizer review is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A single-bit status uses two flops; a data bus uses a handshake or async FIFO.

Bounded reference RTL:
// Bounded lesson contract: CDC constraints and synchronizer review
module lesson(input logic clk, rst_n, enable, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00; else if (enable) led <= data;
end
endmodule

Learner activity: Why not synchronize every bus bit independently?

Lab: Build the bounded register contract for "CDC constraints and synchronizer review". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: RST_N · 0 resets, ENABLE. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, ENABLE, DATA, LED
Interactive inputs: RST_N · 0 resets, ENABLE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Timing closure validates constraints, isolates true critical paths, improves architecture or implementation, and preserves functional correctness.

Build the bounded compare contract for "Timing closure capstone". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Timing closure capstone is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Pipeline a long datapath, rerun implementation, and compare setup/hold reports and latency tests.

Bounded reference RTL:
// Bounded lesson contract: Timing closure capstone
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = (sw <= data) ? 8'h01 : 8'h00;
endmodule

Learner activity: What is the wrong way to close timing?

Lab: Build the bounded compare contract for "Timing closure capstone". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: UART frames asynchronous serial data with start, data, optional parity, and stop bits.

UART transmitter and receiver is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: start=0, eight data bits, stop=1

Learner activity: How does a receiver locate each bit?

Lab: Implement uart transmitter and receiver, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: TX DATA, SERIAL TX, FRAME OK
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: SPI transfers synchronous serial data using SCLK, chip select, MOSI, and MISO with defined phase and polarity.

SPI controller is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: CPOL and CPHA select sampling edges

Learner activity: What activates one peripheral?

Lab: Implement spi controller, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: SCLK, MOSI, MISO
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: I2C devices pull SDA and SCL low and rely on pull-ups for high, allowing arbitration and acknowledgement.

I2C open-drain bus is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: START is SDA falling while SCL is high

Learner activity: Why must outputs release high?

Lab: Implement i2c open-drain bus, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: SCL, SDA, ACK
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: PWM controls average output using a counter and a programmable duty comparison.

PWM generation is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: pwm = counter < duty;

Learner activity: What increases average high time?

Lab: Implement pwm generation, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, COUNTER, DUTY, PWM
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A memory-mapped register bank accepts addressed reads and writes using independent handshake channels.

AXI-Lite register bank is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Software writes a control register; RTL drives hardware

Learner activity: What maps software to hardware state?

Lab: Implement axi-lite register bank, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, D, Q
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Mechanical inputs require synchronization and debounce before edge detection. Outputs require documented polarity and safe reset values.

Build the bounded shift contract for "Debounced GPIO and edge events". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Debounced GPIO and edge events is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A button must remain stable for N cycles before one pressed event is generated.

Bounded reference RTL:
// Bounded lesson contract: Debounced GPIO and edge events
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw << data[2:0];
endmodule

Learner activity: What does debounce prevent?

Lab: Build the bounded shift contract for "Debounced GPIO and edge events". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[2:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[2:0], DATA, LED
Interactive inputs: SW[7:0], DATA[2:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An SPI engine defines CPOL, CPHA, word length, bit order, chip-select timing, and completion/error behavior.

Build the bounded subtract contract for "SPI mode and transaction engine". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

SPI mode and transaction engine is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Mode 0 samples MISO on rising SCLK and shifts MOSI on the opposite edge.

Bounded reference RTL:
// Bounded lesson contract: SPI mode and transaction engine
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw - data;
endmodule

Learner activity: What must match the peripheral?

Lab: Build the bounded subtract contract for "SPI mode and transaction engine". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: I2C uses open-drain SDA/SCL, START/STOP conditions, address phases, ACK/NACK, clock stretching, and arbitration.

Build the bounded mask contract for "I2C arbitration and acknowledgement". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

I2C arbitration and acknowledgement is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: The master releases SDA for ACK and samples whether the receiver pulls it low.

Bounded reference RTL:
// Bounded lesson contract: I2C arbitration and acknowledgement
module lesson(input logic [7:0] sw, output logic [7:0] led);
assign led = sw & 8'h02;
endmodule

Learner activity: What does NACK indicate?

Lab: Build the bounded mask contract for "I2C arbitration and acknowledgement". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], LED
Interactive inputs: SW[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A UART receiver synchronizes RX, detects start, samples near bit centers, shifts data, and validates stop/parity with error flags.

Build the bounded mask contract for "Robust UART receive path". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Robust UART receive path is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A 16x tick generator samples the start bit and then each data bit near its center.

Bounded reference RTL:
// Bounded lesson contract: Robust UART receive path
module lesson(input logic [7:0] sw, output logic [7:0] led);
assign led = sw & 8'h04;
endmodule

Learner activity: What should a bad stop bit produce?

Lab: Build the bounded mask contract for "Robust UART receive path". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], LED
Interactive inputs: SW[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A complete peripheral subsystem combines addressed control registers, protocol engines, buffering, interrupts, status, reset, and board loopback tests.

Build the bounded identity contract for "Multi-interface peripheral capstone". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Multi-interface peripheral capstone is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Software configures SPI, a FIFO buffers bytes, and UART reports transaction status.

Bounded reference RTL:
// Bounded lesson contract: Multi-interface peripheral capstone
module lesson(input logic [7:0] sw, output logic [7:0] led);
assign led = sw;
endmodule

Learner activity: What keeps software and RTL consistent?

Lab: Build the bounded identity contract for "Multi-interface peripheral capstone". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], LED
Interactive inputs: SW[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: PolarFire fabric combines logic, registers, and programmable routing to implement RTL networks.

Logic elements and routing is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Boolean logic maps into fabric logic elements

Learner activity: Where does combinational RTL map?

Lab: Implement logic elements and routing, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Dedicated clock resources distribute low-skew clocks and provide supported frequency conditioning.

Clock conditioning circuits is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Reference clock → CCC/PLL → global clock

Learner activity: Why avoid fabric-generated clocks?

Lab: Implement clock conditioning circuits, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, D, Q
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: PolarFire provides embedded memory resources with different capacities and configurations.

LSRAM and uSRAM is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Select memory style from required depth, width, and ports

Learner activity: What should guide memory selection?

Lab: Implement lsram and usram, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: ADDRESS, DATA, VALID
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Device variants provide hardened high-speed resources that require reference clocks and protocol-aware constraints.

Transceivers and high-speed I/O is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: SERDES path uses dedicated transceiver resources

Learner activity: What is required beyond ordinary GPIO?

Lab: Implement transceivers and high-speed i/o, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: PolarFire combines nonvolatile fabric configuration with device security features and controlled programming flows.

Security and nonvolatile configuration is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Programming policy protects design assets

Learner activity: What should a project define?

Lab: Implement security and nonvolatile configuration, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Clock sources, CCC/PLL resources, global networks, domain frequencies, reset release, and clock consumers are planned before implementation.

Build the bounded register contract for "PolarFire clock resource planning". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

PolarFire clock resource planning is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: One board oscillator feeds a CCC that produces separately constrained fabric clocks.

Bounded reference RTL:
// Bounded lesson contract: PolarFire clock resource planning
module lesson(input logic clk, rst_n, enable, input logic [7:0] data, output logic [7:0] led);
always_ff @(posedge clk) begin
if (!rst_n) led <= 8'h00; else if (enable) led <= data;
end
endmodule

Learner activity: What should never be assumed from a clock net name?

Lab: Build the bounded register contract for "PolarFire clock resource planning". clocked RTL state path: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: RST_N · 0 resets, ENABLE. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: CLK, RST_N · 0 resets, ENABLE, DATA, LED
Interactive inputs: RST_N · 0 resets, ENABLE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: I/O assignment respects package availability, bank voltage, electrical standard, differential pairing, board nets, and reserved functions.

Build the bounded add contract for "PolarFire I/O bank planning". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

PolarFire I/O bank planning is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Group compatible LVCMOS ports into a bank powered for their required standard.

Bounded reference RTL:
// Bounded lesson contract: PolarFire I/O bank planning
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw + data;
endmodule

Learner activity: What can make a package pin unusable for a chosen port?

Lab: Build the bounded add contract for "PolarFire I/O bank planning". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: PolarFire nonvolatile configuration and security features require deliberate lifecycle, programming, debug, and asset-protection decisions.

Build the bounded shift contract for "Nonvolatile fabric and device security". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Nonvolatile fabric and device security is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A training project records image identity and uses no production secrets.

Bounded reference RTL:
// Bounded lesson contract: Nonvolatile fabric and device security
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw << data[2:0];
endmodule

Learner activity: What belongs in a security plan?

Lab: Build the bounded shift contract for "Nonvolatile fabric and device security". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[2:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[2:0], DATA, LED
Interactive inputs: SW[7:0], DATA[2:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A resource budget allocates logic, registers, memories, DSP, clocks, I/O, and timing margin per subsystem before integration.

Build the bounded compare contract for "PolarFire resource budget". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

PolarFire resource budget is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Reserve memory and DSP for the datapath plus headroom for control and debug.

Bounded reference RTL:
// Bounded lesson contract: PolarFire resource budget
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = (sw <= data) ? 8'h01 : 8'h00;
endmodule

Learner activity: Why keep implementation headroom?

Lab: Build the bounded compare contract for "PolarFire resource budget". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A PolarFire architecture review maps every requirement to fabric, memory, DSP, clocks, I/O, security, and observable board evidence.

Build the bounded shift contract for "Architecture mapping capstone". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Architecture mapping capstone is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Review a streaming controller block diagram against resource, clock, interface, and verification budgets.

Bounded reference RTL:
// Bounded lesson contract: Architecture mapping capstone
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw << data[2:0];
endmodule

Learner activity: What closes the architecture review?

Lab: Build the bounded shift contract for "Architecture mapping capstone". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[2:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[2:0], DATA, LED
Interactive inputs: SW[7:0], DATA[2:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: The Libero project must target the exact family, device, package, and speed grade used by the board.

Project and device setup is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Board documentation identifies the fitted FPGA

Learner activity: Why select the exact part?

Lab: Implement project and device setup, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: SOURCE, DESTINATION, SLACK PASS
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: SmartDesign connects RTL, generated IP, clocks, resets, and interfaces in a reviewable system diagram.

SmartDesign integration is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Instantiate a CCC and connect its locked output to reset logic

Learner activity: What does SmartDesign capture?

Lab: Implement smartdesign integration, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: PDC and SDC constraints connect logical ports to board pins and define required timing.

I/O and timing constraints is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Assign LED port, I/O standard, and primary clock

Learner activity: What must be checked against the board?

Lab: Implement i/o and timing constraints, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: SOURCE, DESTINATION, SLACK PASS
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Reports reveal inferred resources, warnings, utilization, clocking, and timing results.

Synthesis and place-and-route reports is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Review warnings before accepting a green status icon

Learner activity: What requires investigation?

Lab: Implement synthesis and place-and-route reports, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Program the generated image, apply a written test plan, and compare measured hardware with simulation.

Programming and hardware debug is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Use LEDs, UART, or an embedded logic analyzer for evidence

Learner activity: What closes the verification loop?

Lab: Implement programming and hardware debug, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Generated IP is configured with explicit parameters, versions, clocks, resets, interfaces, and generated constraints, then reviewed as part of the design.

Build the bounded shift contract for "SmartDesign IP configuration". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

SmartDesign IP configuration is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Configure a CCC, record its input/output frequencies, and connect lock to reset sequencing.

Bounded reference RTL:
// Bounded lesson contract: SmartDesign IP configuration
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw << data[2:0];
endmodule

Learner activity: What must be version-controlled for generated IP?

Lab: Build the bounded shift contract for "SmartDesign IP configuration". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[2:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[2:0], DATA, LED
Interactive inputs: SW[7:0], DATA[2:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Constraint files are imported in the intended order and audited for exact ports, clocks, I/O standards, exceptions, and unresolved placeholders.

Build the bounded and contract for "Import and audit PDC and SDC". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Import and audit PDC and SDC is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: The build fails if PIN_FROM_CURRENT_BOARD_GUIDE remains in a PDC.

Bounded reference RTL:
// Bounded lesson contract: Import and audit PDC and SDC
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw & data;
endmodule

Learner activity: When may a placeholder pin be accepted?

Lab: Build the bounded and contract for "Import and audit PDC and SDC". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Warnings about latches, width truncation, multiple drivers, unused logic, inferred clocks, and undriven nets are resolved or documented.

Build the bounded xor contract for "Resolve synthesis warnings". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Resolve synthesis warnings is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A width warning leads to explicit extension or a documented intentional truncation.

Bounded reference RTL:
// Bounded lesson contract: Resolve synthesis warnings
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw ^ data;
endmodule

Learner activity: What is a warning disposition?

Lab: Build the bounded xor contract for "Resolve synthesis warnings". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Hardware debug uses observable signals, triggers, status counters, UART logs, and supported tools without changing the intended function invisibly.

Build the bounded xor contract for "SmartDebug and on-board observation". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

SmartDebug and on-board observation is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Trigger on an error flag and capture state, control, and data around the event.

Bounded reference RTL:
// Bounded lesson contract: SmartDebug and on-board observation
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw ^ data;
endmodule

Learner activity: What makes a useful trigger?

Lab: Build the bounded xor contract for "SmartDebug and on-board observation". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A reproducible build records source revision, Libero/device versions, IP configuration, constraints, scripts, warnings, reports, and programming digest.

Build the bounded add contract for "Reproducible Libero build capstone". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Reproducible Libero build capstone is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A clean workspace rebuild produces equivalent reports and the recorded image digest.

Bounded reference RTL:
// Bounded lesson contract: Reproducible Libero build capstone
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw + data;
endmodule

Learner activity: What should another engineer be able to do?

Lab: Build the bounded add contract for "Reproducible Libero build capstone". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A timed FSM coordinates mutually exclusive outputs, reset behavior, and safe transitions.

Traffic-light controller is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: RED → RED_AMBER → GREEN → AMBER

Learner activity: What must verification prove?

Lab: Implement traffic-light controller, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, INPUT, STATE, OUTPUT
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A UART receiver, parser, register bank, and transmitter form a controllable debug interface.

UART command console is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Command writes PWM duty; response returns status

Learner activity: Which block stores settings?

Lab: Implement uart command console, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: TX DATA, SERIAL TX, FRAME OK
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A sampled interface feeds filtering, thresholding, buffering, and timestamp logic with valid flow control.

Sensor acquisition pipeline is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: SPI sample → filter → threshold → FIFO

Learner activity: Why propagate valid?

Lab: Implement sensor acquisition pipeline, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: CLK, STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A pipelined multiply-accumulate architecture maps taps into DSP and memory resources.

FIR filter accelerator is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Each sample advances through coefficient taps

Learner activity: What sets numerical accuracy?

Lab: Implement fir filter accelerator, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: The final project includes requirements, RTL, self-checking simulation, constraints, timing closure, programming, and measured evidence.

PolarFire board final project is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Deliver source, tests, reports, bitstream record, and board checklist

Learner activity: What demonstrates completion?

Lab: Implement polarfire board final project, prove it in host simulation, then prepare the reviewed board wrapper

Controls: Use the named RTL inputs in the editor; for the Discovery Kit map SW8 and the seven fabric LEDs only after reviewing the manifest

Expected evidence: Icarus core/wrapper PASS, edited source and expected-versus-observed record; Libero and physical evidence remain external gates

Teaching aid: Interactive concept diagram and live signal graph

Signals: STIMULUS, EXPECTED, OBSERVED
Interactive inputs: None

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Capstone requirements are measurable and each has an acceptance test, expected result, evidence format, and owner.

Build the bounded subtract contract for "Capstone requirements and acceptance tests". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Capstone requirements and acceptance tests is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Requirement R7: accept one sample per cycle for 1024 cycles without loss; test counts accepted and produced samples.

Bounded reference RTL:
// Bounded lesson contract: Capstone requirements and acceptance tests
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw - data;
endmodule

Learner activity: What makes an acceptance criterion useful?

Lab: Build the bounded subtract contract for "Capstone requirements and acceptance tests". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: The system is partitioned into datapath, control, memories, interfaces, clock/reset domains, software boundary, debug, and verification hooks.

Build the bounded and contract for "Capstone architecture partition". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Capstone architecture partition is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A block diagram labels every interface width, direction, clock domain, and backpressure rule.

Bounded reference RTL:
// Bounded lesson contract: Capstone architecture partition
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw & data;
endmodule

Learner activity: What must be defined at every block boundary?

Lab: Build the bounded and contract for "Capstone architecture partition". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: The plan maps requirements to directed, randomized, assertion, coverage, fault, reset, performance, and board tests.

Build the bounded and contract for "Capstone verification plan". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Capstone verification plan is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Each requirement links to at least one automatic simulation check and one relevant acceptance artifact.

Bounded reference RTL:
// Bounded lesson contract: Capstone verification plan
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = sw & data;
endmodule

Learner activity: How is a verification gap found?

Lab: Build the bounded and contract for "Capstone verification plan". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Before hardware release, reviewers examine constraints, clocks, CDC, setup/hold, utilization, critical paths, power estimate, and headroom.

Build the bounded compare contract for "Capstone timing and resource review". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Capstone timing and resource review is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A documented review rejects unexplained unconstrained paths even when the functional simulation passes.

Bounded reference RTL:
// Bounded lesson contract: Capstone timing and resource review
module lesson(input logic [7:0] sw, data, output logic [7:0] led);
assign led = (sw <= data) ? 8'h01 : 8'h00;
endmodule

Learner activity: What does functional simulation not prove?

Lab: Build the bounded compare contract for "Capstone timing and resource review". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0], DATA[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], DATA[7:0], DATA, LED
Interactive inputs: SW[7:0], DATA[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: The final delivery connects requirements, architecture, RTL, tests, coverage, constraints, reports, programming image, measurements, limitations, and maintenance instructions.

Build the bounded invert contract for "Integrated FPGA delivery review". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Integrated FPGA delivery review is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Demonstrate reset, nominal load, boundary load, backpressure, injected fault, recovery, throughput, and reproducible reprogramming.

Bounded reference RTL:
// Bounded lesson contract: Integrated FPGA delivery review
module lesson(input logic [7:0] sw, output logic [7:0] led);
assign led = ~sw;
endmodule

Learner activity: What distinguishes a professional delivery?

Lab: Build the bounded invert contract for "Integrated FPGA delivery review". combinational RTL datapath: repair the intentionally faulty starter, keep the exact port interface, compile it, set the named controls, predict the LED byte, run the required settle/clock event, and pass all ten independent cases. This mobile contract makes the lesson executable; use Icarus or Libero for the complete construct named by the lesson.

Controls: SW[7:0]. Use the named RTL ports and decimal data entry.

Expected evidence: Repair the source, explain a predicted run, and pass ten independent expected-result cases.

Teaching aid: Source-derived RTL connections, input bits, clocked storage and LED result; full-size console.

Signals: SW[7:0], LED
Interactive inputs: SW[7:0]

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: SystemVerilog logic ports make direction and width explicit. One signal must still have one intended driver.

Typed ports and logic signals is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: module mask(input logic [7:0] sw, output logic [7:0] led); assign led = sw; endmodule

Learner activity: Which declaration carries eight input bits?

Lab: an eight-bit typed pass-through

Controls: SW[7:0] stimulus and declared widths

Expected evidence: LED[7:0] equality and clean compile log

Teaching aid: SW[7:0] ── typed input port ──► LED[7:0]
width=8, direction=input

Signals: SW0, SW1, LED0, LED1
Interactive inputs: SW0, SW1

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Signed operands require deliberate extension so sign, carry, and overflow are not confused.

Signed arithmetic and extension is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: logic signed [7:0] a,b; logic signed [8:0] wide_sum; assign wide_sum = a + b;

Learner activity: Why is wide_sum nine bits?

Lab: a signed add/subtract datapath

Controls: two signed switch operands and operation select

Expected evidence: UART result, sign, carry, and overflow record

Teaching aid: A[7:0] ─┐
├─ signed 9-bit ADD ─► SUM[8:0], OVF
B[7:0] ─┘

Signals: CLK, A7, A0, B7, B0, SUM, OVF
Interactive inputs: A7, A0, B7, B0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An enum gives each legal FSM state a meaningful name and a controlled encoding width.

Enumerated states is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: typedef enum logic [1:0] {IDLE, LOAD, RUN, DONE} state_t;

Learner activity: What benefit does state_t provide?

Lab: a four-state sequencer

Controls: START, READY, and DONE switch events

Expected evidence: state code and transition trace

Teaching aid: IDLE ─start→ LOAD ─ready→ RUN ─done→ DONE
▲ │
└──────────── reset ───────────────┘

Signals: CLK, START, READY, DONE, S0, S1
Interactive inputs: START, READY, DONE, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A packed struct groups related fields into one synthesizable bus while preserving field names.

Packed structs for transactions is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: typedef struct packed {logic valid; logic [3:0] tag; logic [7:0] data;} packet_t;

Learner activity: How many bits does packet_t contain?

Lab: a tagged transaction register

Controls: VALID, TAG, DATA, and capture enable

Expected evidence: captured packet fields reported over UART

Teaching aid: [VALID|TAG 4|DATA 8] = one 13-bit packed transaction

Signals: CLK, VALID, TAG0, DATA0, QVALID, QDATA
Interactive inputs: VALID, TAG0, DATA0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An interface bundles a protocol; modports restrict which side drives each signal.

Interfaces and modports is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: modport source(output valid,data, input ready); modport sink(input valid,data, output ready);

Learner activity: Which side drives ready in this example?

Lab: a typed valid-ready channel

Controls: VALID, READY, and DATA controls

Expected evidence: transfer count with no ownership violation

Teaching aid: SOURCE [valid,data] ─────► SINK
SOURCE ◄──────────── [ready] SINK

Signals: CLK, VALID, READY, DATA, XFER
Interactive inputs: VALID, READY, DATA

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Packages centralize shared types and constants. A synthesizable function expresses reusable combinational calculation.

Packages and pure functions is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: function automatic logic parity8(input logic [7:0] d); return ^d; endfunction

Learner activity: What hardware does ^d describe?

Lab: a reusable parity function

Controls: SW8[7:0] in simulation; map only the documented Discovery Kit pins in the board export

Expected evidence: parity LED and exhaustive simulation pass count

Teaching aid: DATA[7:0] ─► parity8() ─► PARITY
shared package definition

Signals: D0, D1, D2, D3, PARITY
Interactive inputs: D0, D1, D2, D3

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A generate loop elaborates repeated hardware instances; it does not execute repeatedly at run time.

Generate loops and arrays is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: for (genvar i=0; i<8; i++) assign led[i] = sw[i] & enable;

Learner activity: How many AND channels are elaborated?

Lab: an eight-channel generated bank

Controls: ENABLE plus SW[7:0]

Expected evidence: eight independent logical channel results in simulation; the Discovery Kit adapter exposes seven fabric LED outputs

Teaching aid: SW[i] ─┬─ AND ─► LED[i] repeated for i=0..7
ENABLE ─┘

Signals: EN, SW0, SW7, LED0, LED7
Interactive inputs: EN, SW0, SW7

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Reusable modules must reject illegal parameter values and calculate internal widths safely.

Parameter guards and width contracts is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: localparam AW = $clog2(DEPTH); initial assert (DEPTH > 1);

Learner activity: What does $clog2(DEPTH) determine?

Lab: a parameterized depth counter

Controls: DEPTH variants and boundary count values

Expected evidence: compile-time guard and correct rollover

Teaching aid: DEPTH ─► $clog2 ─► ADDRESS WIDTH
│
└─ assertion rejects illegal configuration

Signals: CLK, EN, MAX, COUNT, WRAP
Interactive inputs: EN, MAX

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Every combinational output needs an assignment on every path. Defaults plus overrides make that coverage visible.

Combinational completeness and latch prevention is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: always_comb begin y = 0; if (enable) y = data; end

Learner activity: What happens when enable is zero?

Lab: a latch-free conditional datapath

Controls: ENABLE and DATA boundary cases

Expected evidence: zero latch warnings and immediate LED response

Teaching aid: DEFAULT Y=0 ─► if ENABLE then Y=DATA
Every path assigns Y

Signals: EN, DATA, Y, LATCH_WARN
Interactive inputs: EN, DATA

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Professional RTL IP combines a clear contract, typed ports, parameter rules, reset behavior, assertions, and reproducible tests.

Reusable RTL IP review is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Review checklist: interface, widths, reset, CDC, warnings, tests, constraints, hardware evidence.

Learner activity: Which artifact defines how another module may use the IP?

Lab: a reviewed reusable GPIO processing IP

Controls: parameter, reset, enable, and data cases

Expected evidence: review checklist, regression log, timing report, and board capture

Teaching aid: CONTRACT → RTL → ASSERTIONS → SYNTHESIS → BOARD
trace every requirement end-to-end

Signals: CLK, RST, EN, DATA, VALID, RESULT
Interactive inputs: EN, DATA, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A board oscillator enters a clock-capable pin and reaches sequential logic through dedicated low-skew clock resources.

Board oscillator and global clock network is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: board oscillator → clock input → global buffer → registers

Learner activity: Why use the dedicated global network?

Lab: a global-clock heartbeat counter

Controls: clock constraint and counter division value

Expected evidence: measured LED heartbeat and reported clock period

Teaching aid: OSC ─► CLK IN ─► GLOBAL CLOCK ─┬► FF bank A
└► FF bank B

Signals: CLK, EN, CLK_OK, COUNT, LED
Interactive inputs: EN

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: PolarFire clock conditioning resources generate supported frequencies and expose lock status for controlled release of logic.

CCC and PLL frequency generation is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: reference clock → CCC/PLL → generated clock; LOCK gates startup reset release

Learner activity: When may dependent logic leave reset?

Lab: a conditioned-clock startup controller

Controls: frequency selection and simulated LOCK delay

Expected evidence: LOCK trace, clock measurement, and stable counter

Teaching aid: REFCLK ─► CCC/PLL ─► CLK_OUT
└──────► LOCK ─► reset release

Signals: CLK, SEL, LOCK, CLK_OK, LED
Interactive inputs: SEL, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A synchronous reset changes state only on the active clock edge and must meet timing like other synchronous controls.

Synchronous reset sequencing is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: always_ff @(posedge clk) if (rst) q <= 0; else q <= d;

Learner activity: When does q clear?

Lab: a synchronously reset register bank

Controls: RST, D, and clock-edge sequences

Expected evidence: Q clears only at documented edges

Teaching aid: RST ────────┐
CLK _/‾_/‾_ ├─ sample reset at edge ─► Q=0
D ───────────┘

Signals: CLK, D, RST, Q, VALID
Interactive inputs: D, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A common reset strategy asserts immediately but passes deassertion through synchronizing flip-flops in each clock domain.

Asynchronous assert, synchronous release is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: async reset clears sync_ff; two clock edges shift a safe release high

Learner activity: Why synchronize deassertion?

Lab: a two-stage reset release synchronizer

Controls: asynchronous button timing around clock edges

Expected evidence: immediate assertion and two-edge release trace

Teaching aid: RESET_N ─► async clear [FF1→FF2] ─► DOMAIN_RESET_N
clocked release

Signals: CLK, RESET_N, RST_SYNC, READY
Interactive inputs: RESET_N

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A single asynchronous level is sampled by a destination-domain flip-flop and then a second flip-flop to reduce metastability propagation risk.

Two-flop single-bit synchronizer is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: async_in → sync_ff1 → sync_ff2 → destination logic

Learner activity: Which signal should destination logic consume?

Lab: a single-bit level synchronizer

Controls: asynchronous switch transitions

Expected evidence: source, first-stage, and safe-level traces

Teaching aid: ASYNC_IN ─► FF1 ─► FF2 ─► SAFE_LEVEL
destination clock domain

Signals: CLK, ASYNC, FF1, SAFE
Interactive inputs: ASYNC

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A narrow source pulse can be encoded as a persistent toggle, synchronized, and edge-detected in the destination domain.

Pulse transfer with a toggle synchronizer is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: source pulse toggles bit → 2FF sync → XOR delayed copy creates destination pulse

Learner activity: Why encode the pulse as a toggle?

Lab: a reliable pulse-domain crossing

Controls: source pulse spacing versus destination clock

Expected evidence: one destination pulse for every accepted source event

Teaching aid: SRC_PULSE ─► TOGGLE ─► [FF1→FF2] ─► XOR ─► DST_PULSE

Signals: CLK, PULSE, TOGGLE, SYNC, DST_PULSE
Interactive inputs: PULSE

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Gray encoding changes one bit per adjacent count, reducing ambiguity when a multi-bit pointer is synchronized.

Gray-code counter crossing is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: gray = binary ^ (binary >> 1); 0111 binary → 0100 Gray

Learner activity: How many Gray pointer bits should change per increment?

Lab: a Gray-coded event counter crossing

Controls: increment enable and two independent clock rates

Expected evidence: adjacent one-bit Gray transitions and reconstructed count

Teaching aid: BINARY COUNTER ─► XOR SHIFT ─► GRAY ─► bit synchronizers

Signals: CLK, INC, G0, G1, G2, COUNT_OK
Interactive inputs: INC

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An asynchronous FIFO combines dual-port memory, local binary pointers, synchronized Gray pointers, and full/empty logic.

Asynchronous FIFO architecture is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: write clock/domain → RAM ← read clock/domain; Gray pointers cross between them

Learner activity: Which data structure preserves multi-bit payload coherency?

Lab: a dual-clock asynchronous FIFO

Controls: independent write/read enables and rates

Expected evidence: ordered UART readback with correct full/empty flags

Teaching aid: WR_CLK: DATA→RAM, WR_PTR_GRAY ─────►
FULL/EMPTY
RD_CLK: DATA←RAM, ◄───── RD_PTR_GRAY

Signals: CLK, WR_EN, RD_EN, FULL, EMPTY, DATA_OK
Interactive inputs: WR_EN, RD_EN

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: CDC safety needs both correct RTL structures and constraints that identify asynchronous clocks and synchronizer intent.

CDC constraints and structural review is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Declare unrelated clocks asynchronous; inspect that only approved synchronizers cross the boundary.

Learner activity: What is not sufficient by itself?

Lab: a constrained two-clock crossing report

Controls: clock relationship and crossing classification

Expected evidence: zero unreviewed CDC paths and documented exceptions

Teaching aid: CLOCK GROUPS + CDC STRUCTURE + MTBF REVIEW
All three must agree

Signals: CLK, SRC_EVENT, DST_EVENT, CDC_OK
Interactive inputs: SRC_EVENT

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A complete multi-clock system combines conditioned clocks, reset release, a safe control synchronizer, and an asynchronous data FIFO.

Multi-clock acquisition capstone is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: sensor clock → sample FIFO → processing clock → result UART

Learner activity: Which crossing carries the sample bus safely?

Lab: a two-clock sensor acquisition pipeline

Controls: sample enable, rate ratio, reset, and backpressure

Expected evidence: ordered samples, clean CDC report, timing pass, and UART capture

Teaching aid: SENSOR_CLK → ACQUIRE → ASYNC FIFO → PROCESS → UART
resets released per domain

Signals: CLK, SAMPLE, READY, FULL, VALID, RESULT
Interactive inputs: SAMPLE, READY, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A verification plan turns every design requirement into stimulus, checks, coverage, and completion evidence.

Verification plan from requirements is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: REQ-04 FIFO ordering → directed sequence + scoreboard + ordering assertion + coverpoint

Learner activity: What makes a requirement verified?

Lab: a traceable verification plan

Controls: requirement IDs and planned scenarios

Expected evidence: requirements-to-results matrix

Teaching aid: REQUIREMENT ─► TEST ─► CHECK ─► COVERAGE ─► EVIDENCE

Signals: CLK, STIM, CHECK, COVER, PASS
Interactive inputs: STIM

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Constrained stimulus produces legal combinations across a useful range while preserving repeatable random seeds.

Constrained stimulus generation is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Randomize packet length 1..16 and opcode in the supported set; record seed 42017.

Learner activity: Why record the random seed?

Lab: a repeatable transaction generator

Controls: seed, opcode set, length range, and invalid-case injection

Expected evidence: stimulus log and reproducible failure ID

Teaching aid: SEED ─► CONSTRAINTS ─► LEGAL TRANSACTIONS ─► DUT

Signals: CLK, VALID, OP0, LEN0, ACCEPT
Interactive inputs: VALID, OP0, LEN0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A reference model independently predicts results; a scoreboard matches expected and actual transactions despite latency.

Reference models and scoreboards is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: expected_queue.push(model(input)); compare when output_valid arrives;

Learner activity: Why queue expected results?

Lab: a latency-aware scoreboard

Controls: data, valid, ready, and injected pipeline delay

Expected evidence: transaction-by-transaction match log

Teaching aid: INPUT ─┬─► DUT ─────────► ACTUAL ─┐
└─► MODEL ─► EXPECTED QUEUE ─┴─ COMPARE

Signals: CLK, VALID, READY, EXPECTED, ACTUAL, MATCH
Interactive inputs: VALID, READY

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Immediate assertions check a value now; concurrent assertions describe clocked relationships across time.

Immediate and concurrent assertions is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: assert property (@(posedge clk) valid && !ready |=> valid);

Learner activity: What must remain asserted while backpressured?

Lab: a valid-ready protocol assertion set

Controls: backpressure length and data stability

Expected evidence: assertion pass/fail report with first failing cycle

Teaching aid: valid && !ready at cycle N ─► valid at cycle N+1

Signals: CLK, VALID, READY, STABLE, ASSERT_OK
Interactive inputs: VALID, READY

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Safety says a bad event never occurs; liveness says a requested good event eventually occurs under stated assumptions.

Safety and liveness properties is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Safety: never read empty. Liveness: accepted request receives done within 16 cycles.

Learner activity: Which property is liveness?

Lab: bounded request-response properties

Controls: request timing, response latency, and legal assumptions

Expected evidence: proof depth or counterexample trace

Teaching aid: REQUEST ───────────────► DONE within bound
no illegal state at any cycle

Signals: CLK, REQ, BUSY, DONE, PROP_OK
Interactive inputs: REQ

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Functional coverage measures meaningful scenarios and crosses, not merely elapsed simulation time.

Functional coverage design is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Cover opcode, boundary length, backpressure, and opcode×backpressure.

Learner activity: What does a coverage hole identify?

Lab: a protocol coverage model

Controls: opcode, length boundary, backpressure, and reset timing

Expected evidence: coverage table with no unexplained holes

Teaching aid: SCENARIOS ─► COVERPOINTS ─► CROSSES ─► COVERAGE CLOSURE

Signals: CLK, OP0, LEN_MAX, STALL, HIT
Interactive inputs: OP0, LEN_MAX, STALL

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Widths, counters, pointers, and arithmetic must be tested at zero, one, maximum, rollover, and signed extremes.

Boundary-value and overflow testing is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: 8-bit add vectors: 0+0, 1+255, 127+1, -128-1.

Learner activity: Which case exposes unsigned rollover?

Lab: an arithmetic boundary regression

Controls: minimum, maximum, signed edge, and rollover operands

Expected evidence: result/carry/overflow comparison table

Teaching aid: MIN ─ NORMAL ─ MAX ─ ROLLOVER
check result, carry, overflow separately

Signals: CLK, A_MAX, B_ONE, Y_ZERO, CARRY, OVF
Interactive inputs: A_MAX, B_ONE

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Controlled faults prove that checkers detect corruption and that diagnostics point to the failing requirement.

Fault injection and error observability is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Flip one stored bit after write; parity checker must flag the next read.

Learner activity: What validates the checker?

Lab: a parity fault-injection path

Controls: fault enable, bit index, and read timing

Expected evidence: detected fault location and alarm latency

Teaching aid: GOOD DATA ─► FAULT MASK XOR ─► CORRUPTED DATA ─► CHECKER ─► ALARM

Signals: CLK, FAULT, BIT0, PARITY_ERR, ALARM
Interactive inputs: FAULT, BIT0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Formal tools exhaustively explore behavior under assumptions; a counterexample is a concrete trace that violates a property.

Formal counterexamples and assumptions is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Assume legal reset release; assert FIFO count never exceeds DEPTH.

Learner activity: What should be done with an assumption?

Lab: a bounded FIFO safety proof

Controls: legal write/read sequences and reset assumptions

Expected evidence: proof result plus reviewed counterexample when intentionally broken

Teaching aid: ASSUMPTIONS + RTL + PROPERTY ─► PROOF or COUNTEREXAMPLE

Signals: CLK, WRITE, READ, COUNT_OK, PROOF
Interactive inputs: WRITE, READ

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Closure requires stable regressions, met coverage goals, reviewed waivers, clean assertions, and hardware acceptance evidence.

Regression and verification closure is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Run lint, unit tests, integration tests, assertions, coverage, synthesis, timing, then board acceptance.

Learner activity: Which item may be silently ignored?

Lab: an automated verification closure run

Controls: fixed seed set, tool settings, and board acceptance sequence

Expected evidence: signed closure report and archived artifacts

Teaching aid: LINT → SIM → ASSERT → COVER → IMPLEMENT → BOARD
one reproducible regression

Signals: CLK, RUN, SIM_OK, TIMING_OK, BOARD_OK
Interactive inputs: RUN

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A serializer converts a parallel word into timed serial symbols; a deserializer rebuilds aligned parallel words.

Parallel-to-serial data flow is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: 8-bit word 10110010 → serializer → one bit per unit interval → deserializer

Learner activity: What must the receiver recover before presenting words?

Lab: a low-rate serializer loopback

Controls: parallel pattern, bit order, and word-alignment marker

Expected evidence: transmitted/received word comparison and error count

Teaching aid: WORD[7:0] ─► SER ─► differential lane ─► DES ─► WORD[7:0]

Signals: CLK, START, TX_BIT, RX_BIT, WORD_OK
Interactive inputs: START

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: High-speed differential links use a voltage difference between a pair and require compatible standards, pin pairs, and termination.

Differential signaling and termination is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: TX_P/TX_N drive a matched differential pair; RX compares P against N.

Learner activity: Why must P and N use a defined differential pair?

Lab: a constrained differential test output

Controls: I/O standard, legal pin pair, and toggle rate

Expected evidence: clean implementation report and measured complementary pair

Teaching aid: TX_P ═════════════ RX_P
TX_N ═════════════ RX_N
matched pair + termination

Signals: CLK, ENABLE, TX_P, TX_N, PAIR_OK
Interactive inputs: ENABLE

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A transceiver reference clock must meet supported frequency and jitter limits because it anchors transmit and receive timing.

Reference clocks and jitter budget is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: reference oscillator → transceiver PLL → serial line rate clocks

Learner activity: What can excess reference-clock jitter reduce?

Lab: a reference-clock qualification check

Controls: selected reference source, divider, and lock timeout

Expected evidence: frequency, lock status, and jitter-budget worksheet

Teaching aid: REFCLK ─► PLL ─► TX CLOCK
└► RX/CDR support
frequency + jitter budget

Signals: CLK, REFSEL, PLL_LOCK, CLK_OK
Interactive inputs: REFSEL

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: The receiver CDR follows transition timing in the incoming serial stream and produces a recovered clock and data.

Clock and data recovery is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: transition-rich serial data → CDR → recovered bits; long runs may require line coding or scrambling.

Learner activity: Why are transitions important?

Lab: a CDR lock and loss monitor

Controls: transition pattern and signal-present control

Expected evidence: lock acquisition time and loss-of-lock indication

Teaching aid: SERIAL DATA ─► CDR ─┬► RECOVERED CLOCK
└► RECOVERED DATA

Signals: CLK, SIGNAL, CDR_LOCK, RX_VALID
Interactive inputs: SIGNAL

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A line code can limit run length, provide control symbols, and manage DC disparity at the cost of encoding overhead.

Line coding and disparity control is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: 8b/10b maps each data byte or control character to a ten-bit transmission symbol.

Learner activity: What is the payload efficiency of 8b/10b?

Lab: an encoder/decoder symbol checker

Controls: data byte, control/data selection, and error injection

Expected evidence: decoded byte, code error, and disparity error

Teaching aid: 8 DATA BITS ─► ENCODER ─► 10 LINE BITS
control symbols + transition density

Signals: CLK, KCHAR, DATA0, CODE_ERR, DISP_ERR, DECODE_OK
Interactive inputs: KCHAR, DATA0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A receiver searches the serial bit stream for a defined alignment symbol, then fixes parallel word boundaries.

Word alignment and comma detection is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Detect comma → slip gearbox if needed → assert aligned → deliver words.

Learner activity: When may payload checking begin?

Lab: a word-alignment controller

Controls: comma insertion, bit offset, and reacquisition request

Expected evidence: alignment latency and correct payload words

Teaching aid: BITS ─► COMMA DETECT ─► BIT SLIP ─► ALIGNED WORDS

Signals: CLK, COMMA, SLIP, ALIGNED, WORD_OK
Interactive inputs: COMMA, SLIP

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Parallel serial lanes may arrive with different delay; deskew buffers align marked blocks before combining them.

Multi-lane deskew and bonding is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: lane markers enter elastic buffers; bonded output releases only when all lanes align.

Learner activity: What absorbs lane-to-lane delay?

Lab: a lane-bonding deskew model

Controls: lane delay offsets and alignment markers

Expected evidence: deskew depth, bonded-valid, and ordered data

Teaching aid: LANE0 ─► BUFFER ─┐
LANE1 ─► BUFFER ─┼─► BONDED DATA
LANE2 ─► BUFFER ─┘

Signals: CLK, MARK0, MARK1, DESKEW, BONDED
Interactive inputs: MARK0, MARK1

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A pseudo-random binary sequence stresses a link; the receiver compares the expected sequence and counts bit errors over time.

PRBS generation and BER measurement is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: PRBS generator → link → PRBS checker; BER = error bits / observed bits.

Learner activity: What does a zero error count prove?

Lab: a PRBS link quality monitor

Controls: pattern select, run duration, and error injection

Expected evidence: observed bits, errors, and calculated BER bound

Teaching aid: PRBS GEN ─► LINK ─► PRBS CHECK
├► BITS
└► ERRORS

Signals: CLK, RUN, INJECT, LOCK, ERROR
Interactive inputs: RUN, INJECT

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An eye diagram summarizes sampling margin. Equalization compensates channel loss but must be tuned using measured results.

Eye margin and equalization concepts is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Sweep sampling phase and threshold; mark passing region; choose center margin.

Learner activity: Where is the preferred sample point?

Lab: an eye-margin sweep exercise

Controls: sampling phase, threshold, and equalization setting

Expected evidence: pass/fail eye map and chosen operating point

Teaching aid: voltage ▲ ______
│ / EYE \
└──/_________\──► time
sample center

Signals: CLK, SWEEP, EQSEL, MARGIN_OK, LINK_OK
Interactive inputs: SWEEP, EQSEL

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Disciplined bring-up checks power, reference clock, reset order, PLL/CDR lock, alignment, PRBS, payload, and recovery separately.

Transceiver bring-up capstone is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Bring up one loopback lane; prove locks; run PRBS; send framed payload; force and recover one fault.

Learner activity: What should be checked before payload errors?

Lab: a measured serial-link loopback

Controls: line rate, loopback mode, pattern, and forced loss-of-lock

Expected evidence: bring-up checklist, BER run, payload match, and recovery time

Teaching aid: REFCLK → RESET → LOCK → ALIGN → PRBS → PAYLOAD → RECOVERY

Signals: CLK, RESET, PLL_LOCK, ALIGNED, DATA_OK, ERROR
Interactive inputs: RESET, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A memory controller sequences address, write data, byte enables, and read-valid timing around the memory interface contract.

Synchronous SRAM controller is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: WRITE: present address/data + WE at edge. READ: present address, then capture data when valid.

Learner activity: Why is read-valid required?

Lab: a synchronous memory transaction controller

Controls: read/write, address, data, and byte enable

Expected evidence: transaction log with expected readback

Teaching aid: REQUEST ─► ADDRESS/CONTROL ─► MEMORY
RESPONSE ◄──── DATA/VALID ◄───────┘

Signals: CLK, WRITE, ADDR0, WDATA0, RVALID, MATCH
Interactive inputs: WRITE, ADDR0, WDATA0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Double-data-rate memory transfers on both clock edges and organizes commands, addresses, banks, strobes, and data buses.

DDR signaling concepts is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: One clock cycle contains a rising-edge transfer and a falling-edge transfer.

Learner activity: How many transfer opportunities occur per clock cycle?

Lab: a DDR edge-transfer teaching model

Controls: edge select, burst enable, and data pattern

Expected evidence: edge-by-edge word sequence and strobe relationship

Teaching aid: CLK _/‾_/‾_
DQ A B C D transfers at both edges

Signals: CLK, ENABLE, DQS, DQ0, EDGE_OK
Interactive inputs: ENABLE

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: External DDR cannot serve traffic until reset, initialization, calibration, and training complete successfully.

Memory controller initialization and training is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: power stable → reset sequence → initialization → training → READY

Learner activity: When may application requests begin?

Lab: a memory-startup state machine

Controls: reset, simulated training delay, and injected training failure

Expected evidence: state trace, READY time, and failure code

Teaching aid: POWER → RESET → INIT → TRAIN → READY → TRAFFIC

Signals: CLK, START, FAIL, READY, ERROR
Interactive inputs: START, FAIL, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Burst traffic amortizes command overhead by moving consecutive beats from an aligned starting address.

Burst transfers and address alignment is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Burst length 4 from aligned address 0x20 transfers 0x20, 0x24, 0x28, 0x2C for 32-bit beats.

Learner activity: What follows address 0x24 in this burst?

Lab: an aligned burst address generator

Controls: base address, beat size, burst length, and backpressure

Expected evidence: address sequence, beat count, and completion response

Teaching aid: CMD [ADDR,LEN] ─► BEAT0 → BEAT1 → BEAT2 → BEAT3

Signals: CLK, START, READY, LAST, ALIGN_OK
Interactive inputs: START, READY

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An arbiter grants one requester at a time according to a documented fairness and priority policy.

Multi-master arbitration is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Round-robin rotates priority after each accepted transaction.

Learner activity: What should a fair arbiter prevent?

Lab: a three-requester round-robin arbiter

Controls: request combinations and downstream ready

Expected evidence: grant order, wait cycles, and starvation bound

Teaching aid: REQ0 ─┐
REQ1 ─┼─► ARBITER ─► GRANT + MEMORY PORT
REQ2 ─┘

Signals: CLK, REQ0, REQ1, READY, GNT0, GNT1
Interactive inputs: REQ0, REQ1, READY

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A DMA engine moves blocks without per-word processor intervention using source, destination, length, and status descriptors.

DMA descriptor engine is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: descriptor {src=0x1000, dst=0x2000, len=256}; DMA copies and interrupts on completion.

Learner activity: What terminates the transfer?

Lab: a small descriptor-driven DMA

Controls: start, length, source pattern, and destination backpressure

Expected evidence: byte count, checksum, completion, and error status

Teaching aid: DESCRIPTOR ─► READ ENGINE ─► FIFO ─► WRITE ENGINE ─► DONE

Signals: CLK, START, READY, LAST, DONE, ERROR
Interactive inputs: START, READY

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: An elastic FIFO separates producer and consumer timing while occupancy thresholds drive backpressure before overflow.

Elastic buffering and rate matching is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Producer writes every cycle; consumer stalls for four cycles; FIFO level rises then drains.

Learner activity: When should the producer stop?

Lab: a rate-matching elastic buffer

Controls: producer rate, consumer stalls, and threshold

Expected evidence: occupancy waveform with no overflow or underflow

Teaching aid: PRODUCER ─► ELASTIC FIFO ─► CONSUMER
level → almost_full → backpressure

Signals: CLK, WRITE, READ, ALMOST_FULL, EMPTY, LEVEL_OK
Interactive inputs: WRITE, READ

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Error-correcting codes detect and correct supported bit faults; scrubbing periodically reads, corrects, and rewrites memory.

ECC and memory scrubbing is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Inject one data-bit error → ECC corrects read → scrubber rewrites corrected word.

Learner activity: What should happen after a correctable error?

Lab: an SEC-DED fault and scrub model

Controls: fault enable, bit location, scrub interval, and read address

Expected evidence: corrected count, uncorrectable alarm, and data match

Teaching aid: MEMORY ─► ECC CHECK ─┬► CORRECTED DATA
└► SCRUB WRITEBACK + LOG

Signals: CLK, INJECT, SCRUB, CORRECTED, UNCORR, DATA_OK
Interactive inputs: INJECT, SCRUB

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Measured memory performance separates first-response latency, sustained bandwidth, protocol overhead, and idle cycles.

Bandwidth, latency, and efficiency is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Efficiency = transferred data beats / available beat slots during the measurement window.

Learner activity: What improves burst efficiency?

Lab: a hardware performance counter set

Controls: burst length, outstanding requests, and backpressure

Expected evidence: cycles, bytes, latency, bandwidth, and utilization

Teaching aid: REQUEST ─ latency ─► FIRST DATA ─ sustained beats ─► DONE
measure cycles, bytes, and stalls

Signals: CLK, RUN, VALID, READY, LAST, PERF_OK
Interactive inputs: RUN, READY

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A complete data mover reads burst data, buffers it, applies backpressure, transforms each word, and writes results with end-to-end checks.

Memory-to-streaming capstone is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: DDR source → read DMA → FIFO → XOR transform → write DMA → DDR destination.

Learner activity: Where should backpressure be absorbed?

Lab: an end-to-end DDR data mover

Controls: buffer addresses, length, transform key, and forced stalls

Expected evidence: matching destination buffer, throughput, timing, and utilization reports

Teaching aid: DDR READ → DMA → FIFO → TRANSFORM → DMA → DDR WRITE
scoreboard checks every word

Signals: CLK, START, STALL, VALID, LAST, DONE, ERROR
Interactive inputs: START, STALL, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: PolarFire SoC combines a hardened RISC-V microprocessor subsystem with programmable FPGA fabric; partition by latency, parallelism, flexibility, and software needs.

MSS and FPGA fabric partitioning is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Linux configures thresholds; fabric samples inputs and evaluates them every cycle.

Learner activity: Which work best fits fabric?

Lab: a hardware/software partition diagram

Controls: software command, fabric input, and status response

Expected evidence: partition rationale and measured response latency

Teaching aid: RISC-V MSS ⇄ memory-mapped bridge ⇄ FPGA FABRIC
software control parallel hardware

Signals: CLK, CMD, INPUT, STATUS, IRQ
Interactive inputs: CMD, INPUT

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A memory map assigns non-overlapping address ranges to control, status, memory, and peripheral blocks.

Memory maps and address decoding is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: 0x6000_0000 CONTROL; 0x6000_0004 STATUS; low address bits select registers.

Learner activity: What must two peripheral ranges avoid?

Lab: a fabric register address decoder

Controls: address, read/write, write data, and invalid address

Expected evidence: readback table and decode-error response

Teaching aid: CPU ADDRESS ─► RANGE DECODE ─┬► CONTROL REG
└► STATUS REG

Signals: CLK, WRITE, ADDR0, WDATA0, RDATA0, ERROR
Interactive inputs: WRITE, ADDR0, WDATA0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: APB provides a simple setup/access transfer for low-bandwidth control and status peripherals.

APB control-register peripheral is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Setup selects address; access asserts PENABLE; peripheral returns PREADY and optional PSLVERR.

Learner activity: When does an APB transfer complete?

Lab: an APB LED and switch peripheral

Controls: PSEL, PENABLE, write/read, address, and wait state

Expected evidence: protocol assertion log and register readback

Teaching aid: SETUP: PSEL + address
ACCESS: PENABLE + PREADY ─► complete

Signals: CLK, PSEL, PENABLE, PWRITE, PREADY, PSLVERR
Interactive inputs: PSEL, PENABLE, PWRITE

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: AXI channels transfer only when VALID and READY meet; payload must remain stable while stalled.

AXI-style ready-valid channels is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Master holds address and VALID until slave raises READY.

Learner activity: What must remain stable during backpressure?

Lab: a backpressure-safe streaming bridge

Controls: VALID, READY, payload, and random stalls

Expected evidence: no lost/duplicated transfers and stable-payload assertions

Teaching aid: VALID + PAYLOAD ─────►
◄──── READY
transfer at VALID && READY

Signals: CLK, VALID, READY, DATA, LAST, ERROR
Interactive inputs: VALID, READY, DATA

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A fabric interrupt records an event, asserts a request, and remains observable until software acknowledges or clears it.

Interrupt generation and service is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: event sets pending; IRQ rises; handler reads cause and writes clear; IRQ falls.

Learner activity: Why latch the pending event?

Lab: a latched fabric interrupt source

Controls: event pulse, mask, clear, and repeated event timing

Expected evidence: interrupt count, cause, latency, and clear behavior

Teaching aid: EVENT ─► PENDING ─► IRQ ─► RISC-V HANDLER ─► CLEAR

Signals: CLK, EVENT, MASK, IRQ, CLEAR, PENDING
Interactive inputs: EVENT, MASK, CLEAR

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: DMA moves bulk data between fabric and memory while software manages descriptors, ownership, and completion.

Fabric DMA and shared buffers is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: software fills descriptor → fabric DMA runs → completion interrupt → software verifies checksum.

Learner activity: What prevents simultaneous ownership?

Lab: a shared-buffer DMA transaction

Controls: descriptor start, length, ownership, and stalls

Expected evidence: checksum, byte count, completion IRQ, and ownership trace

Teaching aid: SOFTWARE BUFFER ⇄ DMA ⇄ FABRIC STREAM
ownership flag + completion interrupt

Signals: CLK, START, OWNED, VALID, DONE, IRQ
Interactive inputs: START, OWNED

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: MSS and fabric peripherals may use different clocks and reset sequences; bridges must not transfer until both sides are ready.

Clock and reset boundaries in an SoC is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: MSS reset release + fabric PLL lock + bridge reset synchronizers → bridge_ready.

Learner activity: When may the bridge accept traffic?

Lab: a cross-domain bridge startup controller

Controls: MSS ready, fabric lock, reset, and early request

Expected evidence: no transfer before ready and deterministic restart

Teaching aid: MSS_READY ─┐
FABRIC_READY ─┼─► BRIDGE_READY ─► transactions
PLL_LOCK ─────┘

Signals: CLK, MSS_OK, PLL_LOCK, BRIDGE_OK, REQUEST, ERROR
Interactive inputs: MSS_OK, REQUEST, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A bare-metal driver defines register offsets, masks, ordering, timeouts, and error returns for one hardware peripheral.

Bare-metal driver development is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: write CONTROL.START; poll STATUS.DONE with timeout; read RESULT; clear DONE.

Learner activity: Why include a timeout?

Lab: a C driver for a fabric arithmetic engine

Controls: operation, operands, start, timeout, and error injection

Expected evidence: driver test transcript and correct hardware result

Teaching aid: DRIVER API → CONTROL REG → HARDWARE → STATUS/RESULT → DRIVER

Signals: CLK, START, OP0, DONE, TIMEOUT, RESULT
Interactive inputs: START, OP0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Linux needs a device-tree description and a suitable driver or controlled userspace interface to locate fabric peripherals.

Linux device-tree and userspace access is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Device-tree node declares compatible string, register range, and interrupt.

Learner activity: What does the reg property describe?

Lab: a Linux-visible fabric status peripheral

Controls: device-tree base address, range, interrupt, and access permissions

Expected evidence: boot binding message and controlled read/write transcript

Teaching aid: DEVICE TREE ─► DRIVER/BINDING ─► /dev or sysfs ─► APPLICATION

Signals: CLK, ENABLE, STATUS, IRQ, ACCESS_OK
Interactive inputs: ENABLE

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: A useful accelerator has a measured baseline, explicit data movement, correct control/status, interrupts, verification, and board performance evidence.

Hardware-software acceleration capstone is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Software CRC baseline → DMA buffer to fabric CRC → completion IRQ → compare result and execution time.

Learner activity: What determines real acceleration benefit?

Lab: a fabric CRC or checksum accelerator

Controls: buffer size, seed, DMA mode, and injected mismatch

Expected evidence: matching result, latency, throughput, CPU use, and timing report

Teaching aid: SOFTWARE → BUFFER/DMA → FABRIC ACCELERATOR → IRQ/RESULT
compare correctness + end-to-end time

Signals: CLK, START, VALID, LAST, DONE, MATCH
Interactive inputs: START, VALID, RST

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Total device power includes static leakage and dynamic switching power from clocks, logic, memories, I/O, and transceivers.

Static and dynamic power is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Dynamic power rises with activity, capacitance, voltage squared, and frequency.

Learner activity: Which change usually lowers dynamic power?

Lab: an activity-controlled toggle bank

Controls: enable, toggle density, and clock rate

Expected evidence: power-estimator comparison and measured current trend

Teaching aid: TOTAL POWER = STATIC + CLOCK + LOGIC + RAM + I/O + XCVR

Signals: CLK, ENABLE, ACTIVITY, CLOCK_ON, POWER_OK
Interactive inputs: ENABLE, ACTIVITY

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Use synchronous clock enables for ordinary state control so dedicated clock resources remain intact and timing stays analyzable.

Clock enable instead of fabric gating is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: always_ff @(posedge clk) if (enable) count <= count + 1;

Learner activity: What happens while enable is zero?

Lab: an enabled counter bank

Controls: clock enable duty cycle and counter load

Expected evidence: correct hold behavior and lower activity estimate

Teaching aid: GLOBAL CLK ─► FF
ENABLE ──────► CE input; state holds when CE=0

Signals: CLK, ENABLE, COUNT0, HOLD_OK, ACTIVITY
Interactive inputs: ENABLE

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Operand isolation holds or masks inputs to an inactive combinational block so internal nodes do not toggle uselessly.

Operand isolation is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this contract is combinational, changing an input changes the output after the model settles and no clock edge is required.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: mult_a = active ? a : 0; mult_b = active ? b : 0;

Learner activity: What is preserved when active is zero?

Lab: an isolated arithmetic datapath

Controls: active duty cycle and changing operands

Expected evidence: identical active results and reduced toggle count while idle

Teaching aid: A,B ─► ISOLATION ─► DSP BLOCK ─► RESULT
ACTIVE controls switching

Signals: CLK, ACTIVE, A0, B0, RESULT, TOGGLE
Interactive inputs: ACTIVE, A0, B0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: Dedicated RAM and math blocks usually provide better density, performance, and power than equivalent distributed logic when templates match.

Efficient memory and DSP mapping is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: A pipelined multiply-accumulate maps to a math block; a deep synchronous array maps to LSRAM.

Learner activity: What confirms the intended mapping?

Lab: a RAM-fed multiply-accumulate kernel

Controls: memory depth, coefficient, enable, and pipeline rate

Expected evidence: resource mapping, timing, result, and activity reports

Teaching aid: RTL TEMPLATE ─► SYNTHESIS ─┬► MATH BLOCK
└► LSRAM

Signals: CLK, ENABLE, DATA0, COEF0, VALID, RESULT
Interactive inputs: ENABLE, DATA0, COEF0

Assessment: 10 guided activities; 10 checks per attempt drawn from 50 generated question variants

Focus: I/O standards, toggle rates, termination, and transceiver power states can dominate interface power and must follow device guidance.

I/O and transceiver power states is taught as a focused hardware contract. The named inputs drive an eight-bit LED monitor; the starter is intentionally wrong so a compiling design can still be rejected by an independent expected-result model. Because this topic involves state or a timing boundary, values change only at the modeled rising clock edge and reset/enable behavior must be traced.

The mobile model is a teaching instrument, not a synthesis engine: it does not prove FPGA resource inference, timing closure, voltage compatibility, or board behavior. Use the exported testbench with Icarus and the exact-device project in Libero when those claims matter.

Worked example: Disable or place an unused lane into its supported low-power state instead of transmitting idle noise.

Learner activity: What should guide an I/O power choice?

Lab: an interface activity and sleep controller

Controls: enable, idle timeout, wake request, and link lock

Expected evidence: state transitions, wake latency, and power comparison