Every signoff starts the same way: a specification, a picture of the clock domains, and an inventory of what crosses between them. This lesson gives you all three for the capstone peripheral, plus the first version of its RTL. The code below is complete and honest about what it is — a starting point with problems still in it, the way real block RTL arrives at the signoff desk. Your job across the next three lessons is to do what the methodology sections describe: classify its report, fix what is broken, waive what is safe, and close the gate.

The specification

The peripheral has two clock domains. The configuration domain (clk_cfg, about 37 MHz, 27 ns period) owns a simple register interface: a write strobe cfg_wr with 4-bit write data cfg_wdata programs a threshold register. The engine domain (clk_eng, 100 MHz, 10 ns period) runs a free-running 4-bit counter and raises a one-cycle event pulse eng_event whenever the counter equals the programmed threshold. Two results travel back to the configuration domain: the 4-bit counter value as a status word, and the event as an interrupt-style pulse. A single asynchronous reset input rst_n_async (active-low) must release cleanly in both domains.

The crossing inventory

Before any report is read, the inventory lists every crossing the design intends: source, destination, what kind of signal it is, what structure carries it, and who owns it. This table is the map the later lessons work against. Read it as a statement of what is there, not as a verdict on whether it is right — deciding that is the next lesson's exercise.

The first version

The full design is below, 55 lines including the reset synchroniser. The module names peri_top and rst_sync stay the same in every later lesson, so findings and fixes always point at blocks you can already name. It is marked as the first version: it compiles and it simulates, and — as the report will show — that proves less than it seems.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

// bad-example: capstone peripheral, first version (signoff pending).
// It compiles and simulates cleanly: the three planted defects are
// structural, so a passing simulation says nothing about CDC safety.
module rst_sync (
  input wire clk, input wire rst_n_async, output wire rst_n_sync
);
  reg [1:0] sh;
  always @(posedge clk or negedge rst_n_async) begin
    if (!rst_n_async) sh <= 2'b00;
    else sh <= {sh[0], 1'b1};
  end
  assign rst_n_sync = sh[1];
endmodule

module peri_top (
  input wire clk_cfg, input wire clk_eng, input wire rst_n_async,
  input wire cfg_wr, input wire [3:0] cfg_wdata,
  output wire [3:0] status_cfg, output wire event_cfg
);
  wire rst_n_eng;
  rst_sync u_rst_eng (.clk(clk_eng), .rst_n_async(rst_n_async), .rst_n_sync(rst_n_eng));

  reg [3:0] cfg_thresh_q;
  reg [3:0] eng_count, eng_thresh;
  reg eng_event;
  reg ev_a, ev_b;
  reg [3:0] st_a, st_b;

  always @(posedge clk_eng or negedge rst_n_eng) begin
    if (!rst_n_eng) begin
      eng_count <= 4'h0; eng_thresh <= 4'h0; eng_event <= 1'b0;
    end else begin
      eng_count <= (eng_count == 4'hF) ? 4'h0 : eng_count + 4'h1;
      eng_thresh <= cfg_thresh_q;
      eng_event <= (eng_count == eng_thresh);
    end
  end

  always @(posedge clk_cfg or negedge rst_n_async) begin
    if (!rst_n_async) cfg_thresh_q <= 4'h0;
    else if (cfg_wr) cfg_thresh_q <= cfg_wdata;
  end

  always @(posedge clk_cfg or negedge rst_n_async) begin
    if (!rst_n_async) begin ev_a <= 1'b0; ev_b <= 1'b0; end
    else begin ev_a <= eng_event; ev_b <= ev_a; end
  end
  assign event_cfg = ev_b;

  always @(posedge clk_cfg or negedge rst_n_async) begin
    if (!rst_n_async) begin st_a <= 4'h0; st_b <= 4'h0; end
    else begin st_a <= eng_count; st_b <= st_a; end
  end
  assign status_cfg = st_b;
endmodule

What the checks look for

A structural analysis of this design asks one question per inventory row: does the carrying structure match the signal type? A pulse needs a pulse qualifier, a multi-bit value needs a protocol, a reset release needs a synchroniser, and a direct capture needs a written stability argument. The inventory gives the reviewer the rows; the report in the next lesson gives the findings; the classification is yours. The violation classes lesson lists the categories those findings will fall into.

How to work this capstone

Follow the signoff loop in lesson order. First classify each finding in the report lesson as fix, waive, or accept — without peeking at the fixes. Then repair the defects in the fix lesson and check each repair three ways. Finally write the single waiver and close the gate in the signoff lesson. Each lesson's output is the next lesson's input, exactly like a real signoff thread.

Exercise

Extend it: draw the same inventory for a peripheral you know (a UART, a timer, a sensor front end) with real clock names, and mark for each row which structure carries it today. Bring that table to the report lesson and classify its rows the same way you classify C1 to C5.

Related topics

• Next: Classify the Report

• Crossing Inventory

• Violation Classes

• RTL: Metastability and Synchronisation