How Project Slice Submission Works
What a project slice actually checks, and a process for designing a new sequence detector from a written spec instead of a fill-in-the-blank scaffold.
Updated 2026-07-21
A project slice is the same Run and Check Work contract every code lesson uses, plus two more pieces the checker cannot verify by itself: a documented state table, and a short written explanation of a real design choice. All three parts are required before a submission is accepted — passing code alone is not enough.
The checker only cares whether your circuit's inputs and outputs behave correctly against the hidden tests. It never looks at how many states you used, what you named them, or how you encoded them internally — any internal design that produces the correct input/output behavior passes. That is genuinely a design decision you make, not a hidden requirement to guess.
A steady process for a new pattern, without a fill-in-the-blank scaffold to lean on:
- List the states. One state per length of the pattern matched so far by the most recent bits, plus the reset state. A pattern of length four needs four states.
- Draw or list every transition. For each state and each input value, ask: if this bit arrives now, what is the longest prefix of the target pattern that still matches the bits just seen? That answer is the next state — and it is often the reset state, not a partial-credit state.
- Write the state register first. It is the same clocked pattern used since Module 3, regardless of the specific pattern being detected.
- Write next-state logic straight from the table. Each row becomes one condition inside the matching case item.
- Decide the output's timing. With the four-state partial-match encoding used here, a state-only output is one bit too early; reading the current input directly inside the output expression lets it react the instant the deciding bit arrives. A Moore design can instead add a full-match state and assert one cycle later.
- Decide overlapping versus non-overlapping, and be ready to explain it. An overlap-capable design keeps a matched suffix reusable as the start of the next match. A non-overlapping design deliberately forces a full reset after every detection instead, even when some of the just-matched bits could have started a new match. Neither choice is graded as more "correct" by the checker — the explanation is where you show you understand the tradeoff you made.
Once the checks pass, write the state table as plain rows — current state, input, next state — and a 50-to-100-word explanation of your overlapping choice. Both are checked for completeness, not for a specific "correct" answer.