How do you grade your own work honestly?
The build is green and the mutants are dead. It feels done, and that feeling is exactly when self-deception moves in. You wrote the tests, so passing them feels like passing. The rubric below replaces that feeling with arithmetic: twenty points, five rows, each one asking for evidence you can point at.
The rubric scores the project the way a reviewer would: the spec first, then the design, then the tests, then the machinery around them. Read the table row by row and notice where the weight sits. Mutant kills earn the largest share, because a test that cannot fail is the most expensive lie in a project.
Category | Points | What earns them |
|---|---|---|
Specification and acceptance criteria | 4 | Every input, output and priority named; each of the 7 criteria has a directed test |
Design correct and lint clean | 4 | The RTL matches the spec on every criterion; make lint reports no warnings |
Tests that kill mutants | 5 | One point per real-bug mutant you wrote and the testbench kills, up to five. The project requires three; two more are the stretch. An equivalent mutant earns no point and costs none, so replace it with another |
Automation | 4 | make all runs lint, simulation and synthesis; failure fails the build; one verdict line |
Reproducibility | 3 | Versions recorded; the README explains the run |
The figure below draws the same five rows as bars, so the weight is visible at a glance. The longest bar belongs to mutant kills: five of the twenty points. When you are short on time, that bar tells you where the next hour goes.
Grade cold, at least a day after you finish, with the rubric and the files open side by side. Score each row from the evidence, never from the memory of writing it.
For each row, write one sentence naming the evidence: a file, a test name, a mutant you killed.
A row earns full points only when the evidence exists and you can open it. A sentence like [the random phase covers it] is not evidence; the directed test name is.
Any row below full points gets a fix before the project counts as done. A 19 is a task list, not a grade.
Ask one specific question a reviewer could answer. The sentence [does the saturation case reach 255] beats the sentence [does this look right].
Beginners lose points in the same places. The table below names the usual ones, so you can check yourself before a reviewer does.
If you | You lose | Fix |
|---|---|---|
Tested saturation with 200 pulses instead of 256 | 1 from tests | Drive the full climb past 255 |
Wrote the checks by reading the RTL | 2 from spec and tests | Rewrite one directed case per criterion from the table |
Recorded versions from memory | 1 from reproducibility | Run make check-tools and copy its output |
Left two verdict lines in the log | 1 from automation | Remove the extra print; keep exactly one verdict line |
Wrote and killed only the three required mutants | Up to 2 from tests | Write and kill two more, up to five |
When your own score is written down, compare against the reference solution in start-here-pulse-counter-solution.zip: its design, its testbench and its seven mutants, with the one equivalent mutant marked. Unpack it, run make all in its folder, and see how its tests differ from yours.
The scores below are an illustration worked from the rubric, not a report of a measured run. They show how the arithmetic treats the course running example, a 4-bit counter you already know, so you can calibrate your own grading.
Specification and acceptance criteria, 4 of 4. The spec names every input and the priority, and each of its criteria has directed tests.
Design correct and lint clean, 4 of 4. The RTL matches the table on every row and lint reports no warnings.
Tests that kill mutants, 5 of 5. The strong testbench kills all seven real-bug mutants, more than the five the rubric counts.
Automation, 4 of 4. make all runs lint, simulation and synthesis, a failing test fails the build, and success is marked by exactly one verdict line.
Reproducibility, 2 of 3. Versions and the README exist, but the CI workflow is present yet untested on a runner, so one point stays unearned.
Total 19 of 20. The missing point names the next task: prove the CI workflow on a real runner.
Two of five: each kill earns one point, and surviving mutants earn nothing. You write directed cases for the rows the survivors break, until the kills reach five or the survivors prove equivalent.
Grading the effort instead of the evidence. A week of work earns nothing by itself; an open directed test for every criterion earns the spec row. Score what a stranger can open, not what you remember doing.
Awarding mutant points for equivalent mutants. A change no input sequence can distinguish, such as swapping reset and clear when both assign zero, earns no point, because the testbench is right to pass it, and it costs no point either. Document the equivalence, then write a different mutant to take its place in the count.
Rounding 19 up to done. The missing point is a task with a name, like the untested CI workflow in the illustration above. Fix the row instead of forgiving it.
Rule: grade the evidence, not the effort.
Not full marks. Every criterion needs at least one directed test, so one untested row costs at least one point. Add the missing case to the testbench before claiming the row.
That mutant earns no point and costs none: it is equivalent, like swapping two branches that both assign zero, and a test is right to pass it. Write down why no input distinguishes it so the reviewer sees the reasoning, then write a different mutant so you still reach the five that count.
Reproducibility. The recorded versions may describe the wrong machine, and the README steps may assume files only you have. Rerun the check script where you claim it runs and confirm the README steps on a clean copy.
A rubric turns done from a feeling into arithmetic: twenty points, five rows, evidence for each.
Weight follows risk: the largest share belongs to tests that can fail.
A score below full marks is a task list; fix the row before you call the project done.