Paste the interface before the internals. The module header, parameters, clock and reset, and neighboring connections define what the block can do.
Internals without the boundary invite guessing. The boundary turns guesses into checkable statements.
Paste this | Why it matters |
|---|---|
Module header and parameters | Sets widths, counts, and configurability before any logic is read. |
Clock, reset, and enables | Decides what is synchronous and what can change when. |
Neighbor connections | Shows where inputs come from and where outputs go. |
Constraints and coding rules | States what the original authors were and were not allowed to do. |
Start with the module under discussion and the dependencies that determine its behavior. Shorter is not automatically better: removing a parameter override, reset definition, or caller can make the answer wrong. Expand the evidence bundle when a claim depends on code outside it.
SYNTHETIC context exercise:
Requirement: done is high exactly when count is 9.
Question A: What value makes this comparator assert done?
Include comparator source and port widths.
Question B: Does done pulse once per counter period?
Also include counter update/hold behavior and parameter overrides.
Expected distinction: a comparison alone does not establish pulse duration.Ask for a signal table and a list of assumptions, not a story. Tables can be checked line by line against the code.
Separate what a line computes from what the surrounding system guarantees. A comparator can establish done=(count==9); a one-cycle pulse additionally requires evidence that count advances past 9 instead of holding there.
schematic exchange (not real output from any system):
ask: "here is the header, parameters, and reset behavior. list each output,
the condition that drives it, and your assumptions."
reply: a table of outputs and conditions, then "assumptions: (1) reset is
synchronous, (2) count covers 0 to 9, (3) done pulses for one cycle."
verdict: verify items 1 and 2 in the counter source; it is absent below.
The comparator example checks the compare value, not pulse duration.The module below is an illustrative example written for this course, never real assistant output. Assume the exercise requirement is done=(count==9). The buggy comparator uses 8. The testbench enumerates count values; it contains no clocked counter and cannot establish that done lasts one cycle.
// Illustrative example written for this course, never real model output.
module gen_tick_buggy (
input logic [3:0] count,
output logic done
);
always_comb done = (count == 4'd8); // BUG: asserts at the wrong count
endmodule
module gen_tick_fixed (
input logic [3:0] count,
output logic done
);
always_comb done = (count == 4'd9);
endmodule
module tb_tick;
logic [3:0] count;
logic done_b, done_f;
int errors = 0;
int buggy_pulses = 0;
gen_tick_buggy bb (.count(count), .done(done_b));
gen_tick_fixed ff (.count(count), .done(done_f));
initial begin
for (int c = 0; c < 16; c++) begin
count = c[3:0]; #1;
if (done_f !== (c == 9 ? 1'b1 : 1'b0)) errors++;
if (done_b) buggy_pulses++;
end
if (buggy_pulses != 1) errors++;
count = 4'd8; #1;
if (done_b !== 1'b1) errors++;
count = 4'd9; #1;
if (done_b !== 1'b0) errors++;
if (errors == 0) $display("PASS: fixed compare selects 9, buggy compare selects 8");
$finish;
end
endmoduleBegin with the counter, header, parameters, clock/reset, and relevant connections. Include overrides and upstream enables if they affect the question. Retain a pointer to the complete source and expand when dependencies are missing.
Inspect the actual compare and confirm the requirement says 9. Checked source evidence establishes the local mismatch without a new run. Boundary tests can check the correction, but do not decide what the requirement should be.