Execution records and continuing into DDS practice

Deliver a reproducible experiment

A practice result should let another learner reconstruct the same design and comparisons. Include the source files, top module, parameter values, input schedule, expected values, tool version, exact commands and outcome. Preserve the first failing case as well as the restored passing run.

For the integrated lab, a compact project layout is:

rtl/modulo_tick.sv
rtl/periodic_accumulator.sv
test/tb.sv
evidence/expected.csv
evidence/run.txt

Keep the circuit under rtl and simulation-only stimulus under test. Use hashes or an immutable source revision to tie a log to its source. A screenshot of PASS without the tested input or source identity is difficult to reproduce.

Write acceptance conditions before pressing Run

The periodic accumulator accepts a sample only when enable=1, emits a pulse for every Nth accepted sample and consumes that saved sample one edge later. Reset discards a pending event. Total arithmetic wraps modulo 256.

Acceptance requires the edge-by-edge pulse and total to match an independent model for N=1 and N=3, enable gaps, changed external data during consumption, pending reset and wraparound. The checker must also detect consuming current data instead of saved data and incorrectly gating consumption with enable.

Continue through the actual DDS product path

The lessons are free to read. An actual DDS experiment additionally depends on the current product’s supported syntax, execution adapter and the signed-in account’s execution access. Use Digital Design Studio and the installation and first-run documentation to reach the intended product environment.

Choose the supported execution mode shown in that environment. If it expects input rows for a restricted single-clock RTL model, provide the synthesizable DUT and those rows; do not upload a general-purpose #delay testbench and assume it will run. If a construct or mode is unsupported, record the rejection and narrow the claim accordingly.

After executing, inspect the actual preflight result, simulator outcome, output waveform or values and saved artifact. A course completion mark, an imported project, successful local compilation or a displayed Run button is not evidence that a free account finished the experiment.

Keep the evidence boundaries explicit

Report “local functional comparisons passed” for a local simulator run. Report “DDS free-account practice passed” only after that account follows the product path and saves the expected results. Generic synthesis is separate from device implementation. Neither establishes physical timing, a programmed FPGA or manufacturing qualification.

This course provides circuit sources and verification methods. Verify the actual free DDS practice path separately before declaring product acceptance. Finish this lesson by submitting a reproducible result and a short list of unresolved product or tool limitations, if any.