§2.1 Combinational requirements and gate mapping

Unit 2, Lesson 1: Combinational requirements and gate mapping

Learning focus: Start from the full truth table, including priority, default values and ignored codes. Map to primitives only after the specified behavior is unambiguous.

1. The idea in engineering context

Start from the full truth table, including priority, default values and ignored codes. Map to primitives only after the specified behavior is unambiguous. This principle belongs within combinational logic design. To reason correctly, decide what kind of object each symbol represents: a Boolean truth value, a signed integer, a sample of a waveform, a device threshold, a state bit, or a timed event. An equation may be mathematically valid yet describe the wrong physical or temporal quantity. In a circuit drawing, label all inputs, outputs and control signals with direction and active polarity. If a signal can be unknown, undefined or invalid, describe what the receiving block must do rather than silently treating the signal as zero.

A useful preliminary step is to state the behavior without naming any particular component. For the topic combinational requirements and gate mapping, write an input-output contract in plain language and translate it to a truth table, transition table, numerical equation or timing diagram as appropriate. The same contract should survive translation into a schematic, a behavioral simulation and an HDL module. If an implementation changes the contract, the change must be documented as a new requirement rather than hidden as a convenience.

2. A checkable example

A two-input enable E applied to data D gives Y=E·D. When E=0 the data is suppressed regardless of D. Reproduce this calculation or Boolean reasoning from the definitions, showing intermediate bit patterns and units where relevant. When the example uses an idealized value, state explicitly that the numerical values are illustrative teaching inputs, not component specifications. If it refers to a word length, compute the representable range; if it refers to timing, identify the relevant clock domain, edge and uncertainty terms; and if it refers to a voltage, distinguish absolute maximum ratings from guaranteed digital logic levels.

Alternate check. Explain the expected result qualitatively before computing it. A binary carry chain, parity function, or state transition often has an intuitive conserved property: changing one input can affect a particular output but not every unrelated output. Compare the intuitive expectation with the mathematical answer and resolve discrepancies by writing a smaller exhaustive example. This is especially important when signed interpretation, bit ordering or active-low conventions may reverse an apparently obvious answer.

3. Design method and derivation

Representation and mathematical check. Begin with a bit-level representation before calculating the decimal result. Annotate the position of the most significant bit and whether negative values use two's complement. Perform the same operation by at least two independent methods: for example Boolean algebra versus exhaustive enumeration, or direct binary arithmetic versus a modular decimal calculation. When testing fixed-width operations, include all zeros, all ones, one-hot patterns, alternating bits, and values adjacent to overflow.

The next step is to make the dependence of output on input explicit. Start with the simplest special case: zero data, inactive enable, reset asserted, or minimum address as appropriate. Then test the opposite boundary, including all-one words, maximum carry, saturated load, or final counter state. For combinational requirements and gate mapping, list which of these tests are informative and which are irrelevant. Do not automatically assign meaning to a don't-care or illegal combination. If a simplification assumes certain input codes never occur, describe how the enclosing system enforces that assumption.

Compositional design. Identify what the component guarantees when supplied with valid inputs and what it demands from connected blocks. A decoder's one-hot property, a mux's selector function or an adder's carry semantics can be written as an invariant. Connect blocks only after all signal widths and active polarities are clear. A source with 'active-low valid' cannot be connected to an active-high enable without changing its meaning.

4. Failure modes and limits

Topic-specific pitfall: A simulation may hide an unspecified branch by treating an unknown output as harmless. A reliable engineering write-up names the condition that triggers the failure, the observable symptom and the quickest discriminating test. For a functional bug, compare expected and actual truth-table rows; for a timing bug, inspect waveform edges and clock assumptions; for a numeric bug, inspect sign extension and intermediate widths; and for an interface bug, check whether validity and acknowledgement share the same interpretation at each endpoint.

Unit-level model boundary: A minimized expression might create glitches. Combinational correctness must be paired with a settling-time requirement. Avoid extrapolating an ideal gate model into a claim about any particular commercial part. Robustness also requires considering reset entry, temperature-dependent device performance and asynchronous external disturbances whenever they are relevant. If a measured device disagrees with a model, first verify the input stimulus, measurement bandwidth and grounding before declaring the underlying logic theory incorrect.

5. Worked design workflow

1. Specify: write a sentence that defines each input, output and its width; resolve any ambiguous invalid or simultaneous input behavior.

2. Model: select a Boolean expression, transition relation or time equation that captures the defined behavior and state all assumptions.

3. Derive: compute the result for the particular illustrative case above. If there is arithmetic, keep bit widths explicit through every intermediate operation.

4. Cross-check: compare against an independently enumerated case or a direct formula. Document discrepancies rather than adjusting the expected answer to match the implementation.

5. Implement: map the model to gates or synthesizable RTL, leaving enough information to identify clocking, reset and active polarities.

6. Verify: test boundaries and one deliberate fault injection, then record whether the result is logical, simulated, measured or formally proven.

This workflow is intentionally stricter than drawing a plausible diagram. An executable calculator can confirm arithmetic while missing an incorrect interpretation of its inputs. Conversely, a timing waveform can look convincing even if the specification omitted a simultaneous request. A successful solution must connect intent, derivation and independent observation.

6. Laboratory and simulation protocol

Investigation: Create a testbench for enable plus two mutually exclusive interlock requests. Construct a small input matrix containing at least one nominal case, a lower boundary, an upper boundary and a deliberately ambiguous or invalid stimulus. Before running a browser model, write your predicted output and the rule that supports it. Run the experiment, record the output and compare. If the model disagrees with your prediction, determine whether the error is in your rule, your convention, or the model. Explicitly distinguish calculated values from observed electrical measurements; the provided browser apps are not instruments connected to hardware.

Extensions. Repeat the test with an input changed by one bit or one clock cycle. If the result is unchanged, explain which invariance made that possible. If the result changes, identify the exact dependency path. Next ask whether this exercise would still work with a real gate driving several receivers, a different supply voltage, or a clock with uncertainty. That question may require a data sheet, timing analysis or physical measurement beyond the ideal simulation.

7. Guided exercises

1. Derive and explain. Starting from the definition behind combinational requirements and gate mapping, construct the smallest nontrivial truth table, bit pattern, timing diagram or state-transition example. Label all relevant conventions. Provide an independent cross-check.

2. Boundary case. Modify the worked example so that one parameter is at its legal minimum and another at its legal maximum. Recompute the expected result and explain whether the nominal assumption still holds.

3. Find the error. Analyze this claim: “A simulation may hide an unspecified branch by treating an unknown output as harmless.” Identify a concrete input condition that reveals the problem, describe the output symptom and propose a correction or safety guard.

4. Design choice. Compare two implementations of the lesson's function: a direct gate-level representation and a modular block with explicit interface signals. State their likely advantages in clarity, area, timing or testability without assuming a universal winner.

5. Verification. Write five test vectors (including a boundary and invalid input), expected results and a single assertion or invariant that should hold across the set. Explain how a false-positive test could occur.

8. Reflection and further study

The central question of Combinational requirements and gate mapping is not whether an expression looks familiar, but whether a particular result follows from a complete set of stated assumptions. Recheck the significance of each bit and event, the boundary conditions and the consequences of implementing the abstraction in physical hardware. In design reviews, a clearly documented failed assumption is more valuable than a visually polished schematic with hidden undefined behavior. Before moving on, write a three-sentence summary: what this mechanism guarantees, what it does not guarantee, and the simplest independent test that would reveal a mistake.

§2.2 Multiplexers and Shannon expansion

Unit 2, Lesson 2: Multiplexers and Shannon expansion

Learning focus: A 2:1 mux implements Y=(NOT S)·D0 + S·D1. A Boolean function can be recursively expanded around any chosen selector variable.

1. The idea in engineering context

A 2:1 mux implements Y=(NOT S)·D0 + S·D1. A Boolean function can be recursively expanded around any chosen selector variable. This principle belongs within combinational logic design. To reason correctly, decide what kind of object each symbol represents: a Boolean truth value, a signed integer, a sample of a waveform, a device threshold, a state bit, or a timed event. An equation may be mathematically valid yet describe the wrong physical or temporal quantity. In a circuit drawing, label all inputs, outputs and control signals with direction and active polarity. If a signal can be unknown, undefined or invalid, describe what the receiving block must do rather than silently treating the signal as zero.

A useful preliminary step is to state the behavior without naming any particular component. For the topic multiplexers and shannon expansion, write an input-output contract in plain language and translate it to a truth table, transition table, numerical equation or timing diagram as appropriate. The same contract should survive translation into a schematic, a behavioral simulation and an HDL module. If an implementation changes the contract, the change must be documented as a new requirement rather than hidden as a convenience.

2. A checkable example

With S=1, D0=0, D1=1 the mux outputs 1. A two-level mux tree selects one of four sources using two address bits. Reproduce this calculation or Boolean reasoning from the definitions, showing intermediate bit patterns and units where relevant. When the example uses an idealized value, state explicitly that the numerical values are illustrative teaching inputs, not component specifications. If it refers to a word length, compute the representable range; if it refers to timing, identify the relevant clock domain, edge and uncertainty terms; and if it refers to a voltage, distinguish absolute maximum ratings from guaranteed digital logic levels.

Alternate check. Explain the expected result qualitatively before computing it. A binary carry chain, parity function, or state transition often has an intuitive conserved property: changing one input can affect a particular output but not every unrelated output. Compare the intuitive expectation with the mathematical answer and resolve discrepancies by writing a smaller exhaustive example. This is especially important when signed interpretation, bit ordering or active-low conventions may reverse an apparently obvious answer.

3. Design method and derivation

Representation and mathematical check. Begin with a bit-level representation before calculating the decimal result. Annotate the position of the most significant bit and whether negative values use two's complement. Perform the same operation by at least two independent methods: for example Boolean algebra versus exhaustive enumeration, or direct binary arithmetic versus a modular decimal calculation. When testing fixed-width operations, include all zeros, all ones, one-hot patterns, alternating bits, and values adjacent to overflow.

The next step is to make the dependence of output on input explicit. Start with the simplest special case: zero data, inactive enable, reset asserted, or minimum address as appropriate. Then test the opposite boundary, including all-one words, maximum carry, saturated load, or final counter state. For multiplexers and shannon expansion, list which of these tests are informative and which are irrelevant. Do not automatically assign meaning to a don't-care or illegal combination. If a simplification assumes certain input codes never occur, describe how the enclosing system enforces that assumption.

Compositional design. Identify what the component guarantees when supplied with valid inputs and what it demands from connected blocks. A decoder's one-hot property, a mux's selector function or an adder's carry semantics can be written as an invariant. Connect blocks only after all signal widths and active polarities are clear. A source with 'active-low valid' cannot be connected to an active-high enable without changing its meaning.

4. Failure modes and limits

Topic-specific pitfall: If select lines change at different instants, momentary selection of the wrong source is possible. A reliable engineering write-up names the condition that triggers the failure, the observable symptom and the quickest discriminating test. For a functional bug, compare expected and actual truth-table rows; for a timing bug, inspect waveform edges and clock assumptions; for a numeric bug, inspect sign extension and intermediate widths; and for an interface bug, check whether validity and acknowledgement share the same interpretation at each endpoint.

Unit-level model boundary: A minimized expression might create glitches. Combinational correctness must be paired with a settling-time requirement. Avoid extrapolating an ideal gate model into a claim about any particular commercial part. Robustness also requires considering reset entry, temperature-dependent device performance and asynchronous external disturbances whenever they are relevant. If a measured device disagrees with a model, first verify the input stimulus, measurement bandwidth and grounding before declaring the underlying logic theory incorrect.

5. Worked design workflow

1. Specify: write a sentence that defines each input, output and its width; resolve any ambiguous invalid or simultaneous input behavior.

2. Model: select a Boolean expression, transition relation or time equation that captures the defined behavior and state all assumptions.

3. Derive: compute the result for the particular illustrative case above. If there is arithmetic, keep bit widths explicit through every intermediate operation.

4. Cross-check: compare against an independently enumerated case or a direct formula. Document discrepancies rather than adjusting the expected answer to match the implementation.

5. Implement: map the model to gates or synthesizable RTL, leaving enough information to identify clocking, reset and active polarities.

6. Verify: test boundaries and one deliberate fault injection, then record whether the result is logical, simulated, measured or formally proven.

This workflow is intentionally stricter than drawing a plausible diagram. An executable calculator can confirm arithmetic while missing an incorrect interpretation of its inputs. Conversely, a timing waveform can look convincing even if the specification omitted a simultaneous request. A successful solution must connect intent, derivation and independent observation.

6. Laboratory and simulation protocol

Investigation: Map a majority-of-three function onto muxes and verify transitions. Construct a small input matrix containing at least one nominal case, a lower boundary, an upper boundary and a deliberately ambiguous or invalid stimulus. Before running a browser model, write your predicted output and the rule that supports it. Run the experiment, record the output and compare. If the model disagrees with your prediction, determine whether the error is in your rule, your convention, or the model. Explicitly distinguish calculated values from observed electrical measurements; the provided browser apps are not instruments connected to hardware.

Extensions. Repeat the test with an input changed by one bit or one clock cycle. If the result is unchanged, explain which invariance made that possible. If the result changes, identify the exact dependency path. Next ask whether this exercise would still work with a real gate driving several receivers, a different supply voltage, or a clock with uncertainty. That question may require a data sheet, timing analysis or physical measurement beyond the ideal simulation.

7. Guided exercises

1. Derive and explain. Starting from the definition behind multiplexers and shannon expansion, construct the smallest nontrivial truth table, bit pattern, timing diagram or state-transition example. Label all relevant conventions. Provide an independent cross-check.

2. Boundary case. Modify the worked example so that one parameter is at its legal minimum and another at its legal maximum. Recompute the expected result and explain whether the nominal assumption still holds.

3. Find the error. Analyze this claim: “If select lines change at different instants, momentary selection of the wrong source is possible.” Identify a concrete input condition that reveals the problem, describe the output symptom and propose a correction or safety guard.

4. Design choice. Compare two implementations of the lesson's function: a direct gate-level representation and a modular block with explicit interface signals. State their likely advantages in clarity, area, timing or testability without assuming a universal winner.

5. Verification. Write five test vectors (including a boundary and invalid input), expected results and a single assertion or invariant that should hold across the set. Explain how a false-positive test could occur.

8. Reflection and further study

The central question of Multiplexers and Shannon expansion is not whether an expression looks familiar, but whether a particular result follows from a complete set of stated assumptions. Recheck the significance of each bit and event, the boundary conditions and the consequences of implementing the abstraction in physical hardware. In design reviews, a clearly documented failed assumption is more valuable than a visually polished schematic with hidden undefined behavior. Before moving on, write a three-sentence summary: what this mechanism guarantees, what it does not guarantee, and the simplest independent test that would reveal a mistake.

§2.3 Decoders, encoders and priority

Unit 2, Lesson 3: Decoders, encoders and priority

Learning focus: A decoder activates a selected output code; a priority encoder converts simultaneous active requests into one deterministic winning code.

1. The idea in engineering context

A decoder activates a selected output code; a priority encoder converts simultaneous active requests into one deterministic winning code. This principle belongs within combinational logic design. To reason correctly, decide what kind of object each symbol represents: a Boolean truth value, a signed integer, a sample of a waveform, a device threshold, a state bit, or a timed event. An equation may be mathematically valid yet describe the wrong physical or temporal quantity. In a circuit drawing, label all inputs, outputs and control signals with direction and active polarity. If a signal can be unknown, undefined or invalid, describe what the receiving block must do rather than silently treating the signal as zero.

A useful preliminary step is to state the behavior without naming any particular component. For the topic decoders, encoders and priority, write an input-output contract in plain language and translate it to a truth table, transition table, numerical equation or timing diagram as appropriate. The same contract should survive translation into a schematic, a behavioral simulation and an HDL module. If an implementation changes the contract, the change must be documented as a new requirement rather than hidden as a convenience.

2. A checkable example

A 3-to-8 active-high decoder selects output 5 for binary input 101, provided enable is asserted. Reproduce this calculation or Boolean reasoning from the definitions, showing intermediate bit patterns and units where relevant. When the example uses an idealized value, state explicitly that the numerical values are illustrative teaching inputs, not component specifications. If it refers to a word length, compute the representable range; if it refers to timing, identify the relevant clock domain, edge and uncertainty terms; and if it refers to a voltage, distinguish absolute maximum ratings from guaranteed digital logic levels.

Alternate check. Explain the expected result qualitatively before computing it. A binary carry chain, parity function, or state transition often has an intuitive conserved property: changing one input can affect a particular output but not every unrelated output. Compare the intuitive expectation with the mathematical answer and resolve discrepancies by writing a smaller exhaustive example. This is especially important when signed interpretation, bit ordering or active-low conventions may reverse an apparently obvious answer.

3. Design method and derivation

Representation and mathematical check. Begin with a bit-level representation before calculating the decimal result. Annotate the position of the most significant bit and whether negative values use two's complement. Perform the same operation by at least two independent methods: for example Boolean algebra versus exhaustive enumeration, or direct binary arithmetic versus a modular decimal calculation. When testing fixed-width operations, include all zeros, all ones, one-hot patterns, alternating bits, and values adjacent to overflow.

The next step is to make the dependence of output on input explicit. Start with the simplest special case: zero data, inactive enable, reset asserted, or minimum address as appropriate. Then test the opposite boundary, including all-one words, maximum carry, saturated load, or final counter state. For decoders, encoders and priority, list which of these tests are informative and which are irrelevant. Do not automatically assign meaning to a don't-care or illegal combination. If a simplification assumes certain input codes never occur, describe how the enclosing system enforces that assumption.

Compositional design. Identify what the component guarantees when supplied with valid inputs and what it demands from connected blocks. A decoder's one-hot property, a mux's selector function or an adder's carry semantics can be written as an invariant. Connect blocks only after all signal widths and active polarities are clear. A source with 'active-low valid' cannot be connected to an active-high enable without changing its meaning.

4. Failure modes and limits

Topic-specific pitfall: An ordinary encoder is ambiguous when two requests are simultaneously high; priority must be specified. A reliable engineering write-up names the condition that triggers the failure, the observable symptom and the quickest discriminating test. For a functional bug, compare expected and actual truth-table rows; for a timing bug, inspect waveform edges and clock assumptions; for a numeric bug, inspect sign extension and intermediate widths; and for an interface bug, check whether validity and acknowledgement share the same interpretation at each endpoint.

Unit-level model boundary: A minimized expression might create glitches. Combinational correctness must be paired with a settling-time requirement. Avoid extrapolating an ideal gate model into a claim about any particular commercial part. Robustness also requires considering reset entry, temperature-dependent device performance and asynchronous external disturbances whenever they are relevant. If a measured device disagrees with a model, first verify the input stimulus, measurement bandwidth and grounding before declaring the underlying logic theory incorrect.

5. Worked design workflow

1. Specify: write a sentence that defines each input, output and its width; resolve any ambiguous invalid or simultaneous input behavior.

2. Model: select a Boolean expression, transition relation or time equation that captures the defined behavior and state all assumptions.

3. Derive: compute the result for the particular illustrative case above. If there is arithmetic, keep bit widths explicit through every intermediate operation.

4. Cross-check: compare against an independently enumerated case or a direct formula. Document discrepancies rather than adjusting the expected answer to match the implementation.

5. Implement: map the model to gates or synthesizable RTL, leaving enough information to identify clocking, reset and active polarities.

6. Verify: test boundaries and one deliberate fault injection, then record whether the result is logical, simulated, measured or formally proven.

This workflow is intentionally stricter than drawing a plausible diagram. An executable calculator can confirm arithmetic while missing an incorrect interpretation of its inputs. Conversely, a timing waveform can look convincing even if the specification omitted a simultaneous request. A successful solution must connect intent, derivation and independent observation.

6. Laboratory and simulation protocol

Investigation: Write a priority table for four interrupt sources and test every conflicting combination. Construct a small input matrix containing at least one nominal case, a lower boundary, an upper boundary and a deliberately ambiguous or invalid stimulus. Before running a browser model, write your predicted output and the rule that supports it. Run the experiment, record the output and compare. If the model disagrees with your prediction, determine whether the error is in your rule, your convention, or the model. Explicitly distinguish calculated values from observed electrical measurements; the provided browser apps are not instruments connected to hardware.

Extensions. Repeat the test with an input changed by one bit or one clock cycle. If the result is unchanged, explain which invariance made that possible. If the result changes, identify the exact dependency path. Next ask whether this exercise would still work with a real gate driving several receivers, a different supply voltage, or a clock with uncertainty. That question may require a data sheet, timing analysis or physical measurement beyond the ideal simulation.

7. Guided exercises

1. Derive and explain. Starting from the definition behind decoders, encoders and priority, construct the smallest nontrivial truth table, bit pattern, timing diagram or state-transition example. Label all relevant conventions. Provide an independent cross-check.

2. Boundary case. Modify the worked example so that one parameter is at its legal minimum and another at its legal maximum. Recompute the expected result and explain whether the nominal assumption still holds.

3. Find the error. Analyze this claim: “An ordinary encoder is ambiguous when two requests are simultaneously high; priority must be specified.” Identify a concrete input condition that reveals the problem, describe the output symptom and propose a correction or safety guard.

4. Design choice. Compare two implementations of the lesson's function: a direct gate-level representation and a modular block with explicit interface signals. State their likely advantages in clarity, area, timing or testability without assuming a universal winner.

5. Verification. Write five test vectors (including a boundary and invalid input), expected results and a single assertion or invariant that should hold across the set. Explain how a false-positive test could occur.

8. Reflection and further study

The central question of Decoders, encoders and priority is not whether an expression looks familiar, but whether a particular result follows from a complete set of stated assumptions. Recheck the significance of each bit and event, the boundary conditions and the consequences of implementing the abstraction in physical hardware. In design reviews, a clearly documented failed assumption is more valuable than a visually polished schematic with hidden undefined behavior. Before moving on, write a three-sentence summary: what this mechanism guarantees, what it does not guarantee, and the simplest independent test that would reveal a mistake.

§2.4 Half adders, full adders and carry

Unit 2, Lesson 4: Half adders, full adders and carry

Learning focus: One-bit addition yields sum A XOR B XOR Cin and carry majority(A,B,Cin). Cascading full adders is simple but can create a long carry chain.

1. The idea in engineering context

One-bit addition yields sum A XOR B XOR Cin and carry majority(A,B,Cin). Cascading full adders is simple but can create a long carry chain. This principle belongs within combinational logic design. To reason correctly, decide what kind of object each symbol represents: a Boolean truth value, a signed integer, a sample of a waveform, a device threshold, a state bit, or a timed event. An equation may be mathematically valid yet describe the wrong physical or temporal quantity. In a circuit drawing, label all inputs, outputs and control signals with direction and active polarity. If a signal can be unknown, undefined or invalid, describe what the receiving block must do rather than silently treating the signal as zero.

A useful preliminary step is to state the behavior without naming any particular component. For the topic half adders, full adders and carry, write an input-output contract in plain language and translate it to a truth table, transition table, numerical equation or timing diagram as appropriate. The same contract should survive translation into a schematic, a behavioral simulation and an HDL module. If an implementation changes the contract, the change must be documented as a new requirement rather than hidden as a convenience.

2. A checkable example

Adding 0111 and 0001 in four bits yields 1000; unsigned result is 8, signed result is −8 and the signed overflow flag must assert. Reproduce this calculation or Boolean reasoning from the definitions, showing intermediate bit patterns and units where relevant. When the example uses an idealized value, state explicitly that the numerical values are illustrative teaching inputs, not component specifications. If it refers to a word length, compute the representable range; if it refers to timing, identify the relevant clock domain, edge and uncertainty terms; and if it refers to a voltage, distinguish absolute maximum ratings from guaranteed digital logic levels.

Alternate check. Explain the expected result qualitatively before computing it. A binary carry chain, parity function, or state transition often has an intuitive conserved property: changing one input can affect a particular output but not every unrelated output. Compare the intuitive expectation with the mathematical answer and resolve discrepancies by writing a smaller exhaustive example. This is especially important when signed interpretation, bit ordering or active-low conventions may reverse an apparently obvious answer.

3. Design method and derivation

Representation and mathematical check. Begin with a bit-level representation before calculating the decimal result. Annotate the position of the most significant bit and whether negative values use two's complement. Perform the same operation by at least two independent methods: for example Boolean algebra versus exhaustive enumeration, or direct binary arithmetic versus a modular decimal calculation. When testing fixed-width operations, include all zeros, all ones, one-hot patterns, alternating bits, and values adjacent to overflow.

The next step is to make the dependence of output on input explicit. Start with the simplest special case: zero data, inactive enable, reset asserted, or minimum address as appropriate. Then test the opposite boundary, including all-one words, maximum carry, saturated load, or final counter state. For half adders, full adders and carry, list which of these tests are informative and which are irrelevant. Do not automatically assign meaning to a don't-care or illegal combination. If a simplification assumes certain input codes never occur, describe how the enclosing system enforces that assumption.

Compositional design. Identify what the component guarantees when supplied with valid inputs and what it demands from connected blocks. A decoder's one-hot property, a mux's selector function or an adder's carry semantics can be written as an invariant. Connect blocks only after all signal widths and active polarities are clear. A source with 'active-low valid' cannot be connected to an active-high enable without changing its meaning.

4. Failure modes and limits

Topic-specific pitfall: A carry-out flag is not equivalent to signed overflow. A reliable engineering write-up names the condition that triggers the failure, the observable symptom and the quickest discriminating test. For a functional bug, compare expected and actual truth-table rows; for a timing bug, inspect waveform edges and clock assumptions; for a numeric bug, inspect sign extension and intermediate widths; and for an interface bug, check whether validity and acknowledgement share the same interpretation at each endpoint.

Unit-level model boundary: A minimized expression might create glitches. Combinational correctness must be paired with a settling-time requirement. Avoid extrapolating an ideal gate model into a claim about any particular commercial part. Robustness also requires considering reset entry, temperature-dependent device performance and asynchronous external disturbances whenever they are relevant. If a measured device disagrees with a model, first verify the input stimulus, measurement bandwidth and grounding before declaring the underlying logic theory incorrect.

5. Worked design workflow

1. Specify: write a sentence that defines each input, output and its width; resolve any ambiguous invalid or simultaneous input behavior.

2. Model: select a Boolean expression, transition relation or time equation that captures the defined behavior and state all assumptions.

3. Derive: compute the result for the particular illustrative case above. If there is arithmetic, keep bit widths explicit through every intermediate operation.

4. Cross-check: compare against an independently enumerated case or a direct formula. Document discrepancies rather than adjusting the expected answer to match the implementation.

5. Implement: map the model to gates or synthesizable RTL, leaving enough information to identify clocking, reset and active polarities.

6. Verify: test boundaries and one deliberate fault injection, then record whether the result is logical, simulated, measured or formally proven.

This workflow is intentionally stricter than drawing a plausible diagram. An executable calculator can confirm arithmetic while missing an incorrect interpretation of its inputs. Conversely, a timing waveform can look convincing even if the specification omitted a simultaneous request. A successful solution must connect intent, derivation and independent observation.

6. Laboratory and simulation protocol

Investigation: Build a four-bit adder and tabulate zero, carry, sign and overflow flags. Construct a small input matrix containing at least one nominal case, a lower boundary, an upper boundary and a deliberately ambiguous or invalid stimulus. Before running a browser model, write your predicted output and the rule that supports it. Run the experiment, record the output and compare. If the model disagrees with your prediction, determine whether the error is in your rule, your convention, or the model. Explicitly distinguish calculated values from observed electrical measurements; the provided browser apps are not instruments connected to hardware.

Extensions. Repeat the test with an input changed by one bit or one clock cycle. If the result is unchanged, explain which invariance made that possible. If the result changes, identify the exact dependency path. Next ask whether this exercise would still work with a real gate driving several receivers, a different supply voltage, or a clock with uncertainty. That question may require a data sheet, timing analysis or physical measurement beyond the ideal simulation.

7. Guided exercises

1. Derive and explain. Starting from the definition behind half adders, full adders and carry, construct the smallest nontrivial truth table, bit pattern, timing diagram or state-transition example. Label all relevant conventions. Provide an independent cross-check.

2. Boundary case. Modify the worked example so that one parameter is at its legal minimum and another at its legal maximum. Recompute the expected result and explain whether the nominal assumption still holds.

3. Find the error. Analyze this claim: “A carry-out flag is not equivalent to signed overflow.” Identify a concrete input condition that reveals the problem, describe the output symptom and propose a correction or safety guard.

4. Design choice. Compare two implementations of the lesson's function: a direct gate-level representation and a modular block with explicit interface signals. State their likely advantages in clarity, area, timing or testability without assuming a universal winner.

5. Verification. Write five test vectors (including a boundary and invalid input), expected results and a single assertion or invariant that should hold across the set. Explain how a false-positive test could occur.

8. Reflection and further study

The central question of Half adders, full adders and carry is not whether an expression looks familiar, but whether a particular result follows from a complete set of stated assumptions. Recheck the significance of each bit and event, the boundary conditions and the consequences of implementing the abstraction in physical hardware. In design reviews, a clearly documented failed assumption is more valuable than a visually polished schematic with hidden undefined behavior. Before moving on, write a three-sentence summary: what this mechanism guarantees, what it does not guarantee, and the simplest independent test that would reveal a mistake.

§2.5 Comparators, parity and error indication

Unit 2, Lesson 5: Comparators, parity and error indication

Learning focus: Magnitude comparators operate on a defined numeric representation. XOR reduction computes parity, which detects any odd count of bit flips but misses even counts.

1. The idea in engineering context

Magnitude comparators operate on a defined numeric representation. XOR reduction computes parity, which detects any odd count of bit flips but misses even counts. This principle belongs within combinational logic design. To reason correctly, decide what kind of object each symbol represents: a Boolean truth value, a signed integer, a sample of a waveform, a device threshold, a state bit, or a timed event. An equation may be mathematically valid yet describe the wrong physical or temporal quantity. In a circuit drawing, label all inputs, outputs and control signals with direction and active polarity. If a signal can be unknown, undefined or invalid, describe what the receiving block must do rather than silently treating the signal as zero.

A useful preliminary step is to state the behavior without naming any particular component. For the topic comparators, parity and error indication, write an input-output contract in plain language and translate it to a truth table, transition table, numerical equation or timing diagram as appropriate. The same contract should survive translation into a schematic, a behavioral simulation and an HDL module. If an implementation changes the contract, the change must be documented as a new requirement rather than hidden as a convenience.

2. A checkable example

For data 1011011 there are five ones, so an even-parity bit must be 1, making six ones total. Reproduce this calculation or Boolean reasoning from the definitions, showing intermediate bit patterns and units where relevant. When the example uses an idealized value, state explicitly that the numerical values are illustrative teaching inputs, not component specifications. If it refers to a word length, compute the representable range; if it refers to timing, identify the relevant clock domain, edge and uncertainty terms; and if it refers to a voltage, distinguish absolute maximum ratings from guaranteed digital logic levels.

Alternate check. Explain the expected result qualitatively before computing it. A binary carry chain, parity function, or state transition often has an intuitive conserved property: changing one input can affect a particular output but not every unrelated output. Compare the intuitive expectation with the mathematical answer and resolve discrepancies by writing a smaller exhaustive example. This is especially important when signed interpretation, bit ordering or active-low conventions may reverse an apparently obvious answer.

3. Design method and derivation

Representation and mathematical check. Begin with a bit-level representation before calculating the decimal result. Annotate the position of the most significant bit and whether negative values use two's complement. Perform the same operation by at least two independent methods: for example Boolean algebra versus exhaustive enumeration, or direct binary arithmetic versus a modular decimal calculation. When testing fixed-width operations, include all zeros, all ones, one-hot patterns, alternating bits, and values adjacent to overflow.

The next step is to make the dependence of output on input explicit. Start with the simplest special case: zero data, inactive enable, reset asserted, or minimum address as appropriate. Then test the opposite boundary, including all-one words, maximum carry, saturated load, or final counter state. For comparators, parity and error indication, list which of these tests are informative and which are irrelevant. Do not automatically assign meaning to a don't-care or illegal combination. If a simplification assumes certain input codes never occur, describe how the enclosing system enforces that assumption.

Compositional design. Identify what the component guarantees when supplied with valid inputs and what it demands from connected blocks. A decoder's one-hot property, a mux's selector function or an adder's carry semantics can be written as an invariant. Connect blocks only after all signal widths and active polarities are clear. A source with 'active-low valid' cannot be connected to an active-high enable without changing its meaning.

4. Failure modes and limits

Topic-specific pitfall: Parity detects errors but cannot correct them and cannot detect all multi-bit errors. A reliable engineering write-up names the condition that triggers the failure, the observable symptom and the quickest discriminating test. For a functional bug, compare expected and actual truth-table rows; for a timing bug, inspect waveform edges and clock assumptions; for a numeric bug, inspect sign extension and intermediate widths; and for an interface bug, check whether validity and acknowledgement share the same interpretation at each endpoint.

Unit-level model boundary: A minimized expression might create glitches. Combinational correctness must be paired with a settling-time requirement. Avoid extrapolating an ideal gate model into a claim about any particular commercial part. Robustness also requires considering reset entry, temperature-dependent device performance and asynchronous external disturbances whenever they are relevant. If a measured device disagrees with a model, first verify the input stimulus, measurement bandwidth and grounding before declaring the underlying logic theory incorrect.

5. Worked design workflow

1. Specify: write a sentence that defines each input, output and its width; resolve any ambiguous invalid or simultaneous input behavior.

2. Model: select a Boolean expression, transition relation or time equation that captures the defined behavior and state all assumptions.

3. Derive: compute the result for the particular illustrative case above. If there is arithmetic, keep bit widths explicit through every intermediate operation.

4. Cross-check: compare against an independently enumerated case or a direct formula. Document discrepancies rather than adjusting the expected answer to match the implementation.

5. Implement: map the model to gates or synthesizable RTL, leaving enough information to identify clocking, reset and active polarities.

6. Verify: test boundaries and one deliberate fault injection, then record whether the result is logical, simulated, measured or formally proven.

This workflow is intentionally stricter than drawing a plausible diagram. An executable calculator can confirm arithmetic while missing an incorrect interpretation of its inputs. Conversely, a timing waveform can look convincing even if the specification omitted a simultaneous request. A successful solution must connect intent, derivation and independent observation.

6. Laboratory and simulation protocol

Investigation: Test all single-bit flips of a payload and find an undetected double-bit flip. Construct a small input matrix containing at least one nominal case, a lower boundary, an upper boundary and a deliberately ambiguous or invalid stimulus. Before running a browser model, write your predicted output and the rule that supports it. Run the experiment, record the output and compare. If the model disagrees with your prediction, determine whether the error is in your rule, your convention, or the model. Explicitly distinguish calculated values from observed electrical measurements; the provided browser apps are not instruments connected to hardware.

Extensions. Repeat the test with an input changed by one bit or one clock cycle. If the result is unchanged, explain which invariance made that possible. If the result changes, identify the exact dependency path. Next ask whether this exercise would still work with a real gate driving several receivers, a different supply voltage, or a clock with uncertainty. That question may require a data sheet, timing analysis or physical measurement beyond the ideal simulation.

7. Guided exercises

1. Derive and explain. Starting from the definition behind comparators, parity and error indication, construct the smallest nontrivial truth table, bit pattern, timing diagram or state-transition example. Label all relevant conventions. Provide an independent cross-check.

2. Boundary case. Modify the worked example so that one parameter is at its legal minimum and another at its legal maximum. Recompute the expected result and explain whether the nominal assumption still holds.

3. Find the error. Analyze this claim: “Parity detects errors but cannot correct them and cannot detect all multi-bit errors.” Identify a concrete input condition that reveals the problem, describe the output symptom and propose a correction or safety guard.

4. Design choice. Compare two implementations of the lesson's function: a direct gate-level representation and a modular block with explicit interface signals. State their likely advantages in clarity, area, timing or testability without assuming a universal winner.

5. Verification. Write five test vectors (including a boundary and invalid input), expected results and a single assertion or invariant that should hold across the set. Explain how a false-positive test could occur.

8. Reflection and further study

The central question of Comparators, parity and error indication is not whether an expression looks familiar, but whether a particular result follows from a complete set of stated assumptions. Recheck the significance of each bit and event, the boundary conditions and the consequences of implementing the abstraction in physical hardware. In design reviews, a clearly documented failed assumption is more valuable than a visually polished schematic with hidden undefined behavior. Before moving on, write a three-sentence summary: what this mechanism guarantees, what it does not guarantee, and the simplest independent test that would reveal a mistake.