'Help with VLSI debugging' is too broad to evaluate. A beginner needs a small job whose output another engineer can check. Your assistant will read one short synthetic evidence packet and return a candidate issue, no issue supported in this excerpt, or an unresolved question. It must cite the packet and propose a human check. It cannot modify RTL, change constraints, waive a failure, fetch documents or certify that a block is correct.
The intended user is an RTL, DV, STA or PD engineer preparing an initial review note. Their recurring problem is separating what a supplied artifact actually shows from a plausible explanation. Choose a fixed input limit: one packet of at most 80 source lines, all identified by stable line labels. A missing condition becomes an explicit question. The output is useful when the next engineer can follow the references without guessing which revision, unit or requirement the assistant meant.
K1 / RTL / snapshot k1-v1
S1: At posedge clk, rst_n=0 clears q regardless of en.
S2: Otherwise en=1 loads d; en=0 holds q.
R1: always_ff @(posedge clk) begin
R2: if (en) begin
R3: if (!rst_n) q <= 1'b0;
R4: else q <= d;
R5: end
R6: end
K2 / STA / snapshot k2-v1
T1: report_type=setup; units=ns; corner=slow_demo
T2: path=reg_a/Q -> reg_b/D; slack=-0.12
T3: constraint excerpt and clock definitions are absent.
Question: What is observed, and can a root cause be assigned?
K3 / DV / snapshot k3-v1
D1: Requirement: out equals the previous sampled input after one cycle.
D2: At cycle 7, previous input=3, observed out=3.
D3: Checker text: expected=4; FAIL at cycle 7.
Question: Which inconsistency needs investigation?Create a one-page scope card before interpreting the packets. State the user, permitted inputs, required output, disallowed actions and acceptance checks. Use the three status names consistently: candidate_issue, no_issue_in_excerpt and unresolved. A candidate is an evidence-backed concern for investigation; it is not an approval to make a fix. A no-issue result is deliberately bounded to the excerpt. Unresolved means the packet does not support the requested decision, even when it includes an interesting observation.
Write an initial note for each practice input, recording one claim, its line references, one uncertainty and the next human check. Then list two mistakes that would make this assistant unsafe or unhelpful. Decide what the assistant should do when asked to fix the source or upload a report. Keep your drafts for later comparison; changing them after reading the answers is practice, not a valid first-attempt evaluation.
K1 supports a reset-priority candidate: prior q=1, en=0, rst_n=0 at the edge requires q=0 under S1, while R2 skips assignment. K2 shows a negative setup slack at slow_demo in ns, but the excerpt does not establish its cause or constraint validity; return unresolved for root cause. K3 shows the checker expectation conflicts with D1-D2; investigate checker alignment before blaming RTL. Reject edits or uploads as outside scope. Do not claim simulation or complete verification.
The fixtures omit real design complexity intentionally. Success here demonstrates traceable triage on small inputs, not production readiness. The scope card is your local engineering agreement. NIST AI RMF 1.0, January 2023 is background for planning evaluation and managing risk; it does not supply these fixture answers or certify the assistant.