How Project Slice Submission Works

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 simulation only checks 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 — those are genuinely design decisions you make, not hidden requirements to guess. Beside the simulation, three source checks confirm the structure the project asks for: the next-state logic sits in its own always @(*) block, reads the current state and assigns with =, and the state register sits in an always @(posedge clk) block that loads that next state with <=. Names are still yours. A detector built another way, such as a shift register, or one clocked block that updates the state directly, can produce the right outputs and still fail these checks.

A steady process for a new pattern, without a fill-in-the-blank scaffold to lean on:

1. List the states. One method that works: one state for each length of the pattern the latest bits can match, from nothing (the reset state) up to one bit short of the whole pattern. For a pattern of length four that is four states. Another design is allowed, as long as the ports behave as the spec says.
2. Draw or list every transition. For each state and each input value, ask: if this bit arrives now, what is the longest run of the latest bits, shorter than the whole pattern, that still matches the start of the target pattern? The state that remembers that run is the next state — and it is often the reset state, not a partial-credit state.
3. Write the state register first. It is the same clocked pattern used since Module 3 — updated on the rising edge, with a synchronous reset tested inside the clocked block — regardless of the specific pattern being detected.
4. Write next-state logic straight from the table. Each row becomes one condition inside the matching case item.
5. Check the output's timing against the spec. The spec asks for the output to be 1 in the cycle the final bit arrives, before the rising edge that samples it. With the partial-match states above, a state-only output would be 1 after only three matched bits, whatever the fourth bit is, so the output also reads the current input. A Moore design with an extra full-match state is a valid detector in general, but it reports one cycle later than this spec allows, so the checks reject it.
6. Decide overlapping versus non-overlapping, and be ready to explain it. An overlapping design lets the last bits of one match begin the next, so the detecting transition goes to a partial-match state. A non-overlapping design deliberately returns to the start state 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.