Computer-Fundamentals/electronics/2.digital-logic-fundamentals.md

# Digital Logic Fundamentals

This handbook is a practical reference for computer engineering students and working engineers who need more than textbook definitions. The goal is to build a mental model that survives real hardware: noisy rails, slow edges, marginal timing, bad resets, asynchronous inputs, clock domain crossings, and firmware that interacts with logic in ways the schematic did not make obvious.

Digital logic is often taught as ideal symbols and truth tables. Real systems are not ideal. Bits live on analog wires. Gates are built from transistors with delay. State elements can go metastable. Clocks are not perfectly aligned. Good digital design is the art of using simple abstractions while respecting the analog reality underneath them.

The material is intentionally practical. It connects board-level behavior, FPGA and ASIC logic, and firmware-visible behavior where that makes the concepts clearer.

## How to Use This Handbook

Read it in order the first time. Return to specific sections when you are designing or debugging.

- If you are new to digital design, start with the digital abstraction and binary signals.
- If you are writing HDL, pay close attention to truth tables, combinational versus sequential logic, latches, and flip-flops.
- If you are debugging hardware in the lab, spend extra time on timing basics, clocking, metastability, and the troubleshooting workflow.
- If you are interviewing, use the interview-level section near the end to test whether your understanding is actually engineering-grade.

## Quick Reference

| Concept | What it really means in engineering work |
| --- | --- |
| Binary signal | A continuously varying voltage that a receiver interprets as `0` or `1` using thresholds |
| Logic gate | A transistor network that implements a Boolean relationship between inputs and outputs |
| Truth table | A complete specification of how outputs should respond to every relevant input combination |
| Combinational logic | Logic whose outputs depend only on current inputs |
| Sequential logic | Logic whose outputs depend on current inputs and stored state |
| Latch | Level-sensitive storage element that is transparent while enabled |
| Flip-flop | Edge-triggered storage element that samples near a clock edge |
| Setup time | Minimum time data must be stable before the sampling edge |
| Hold time | Minimum time data must remain stable after the sampling edge |
| Clock domain | A region of logic timed by the same clock or by clocks with a defined relationship |
| Metastability | A temporary analog condition where a state element has not resolved cleanly to `0` or `1` |
| Noise margin | Safety gap between guaranteed driver output levels and receiver thresholds |

Core timing relationships, using uncertainty to include worst-case skew and jitter:

- Setup budget: `Tclk >= tclk_to_q(max) + tcomb(max) + tsetup + uncertainty + margin`
- Hold safety: `tclk_to_q(min) + tcomb(min) >= thold + uncertainty`

These are simplified equations, but they are the right starting point for engineering intuition.

---

## 1. The Digital Abstraction: Why Digital Logic Works At All

### 1.1 The physical world is analog

No wire in a real system carries a perfect abstract `1` or `0`. A wire carries voltage and current that change continuously over time.

That means every digital signal is physically analog in at least these ways:

- voltage is continuous, not discrete
- edges take time to rise and fall
- noise can shift the waveform
- loading changes the shape of the signal
- temperature, process variation, and supply voltage change behavior

Digital logic works because engineers intentionally define ranges of voltage that count as `0` and `1`, then build circuits that can reliably distinguish them.

### 1.2 Digital is an agreement, not magic

The digital model says:

- if the input is clearly low, treat it as logic `0`
- if the input is clearly high, treat it as logic `1`
- if the input is in between, behavior may be undefined or unreliable

That agreement allows us to reason about systems with Boolean algebra instead of solving transistor equations for every gate.

This is the core abstraction stack:

1. Physics provides voltages and currents.
2. Circuits create thresholds and gain.
3. Thresholding maps analog ranges to discrete logic states.
4. Logic gates combine those states.
5. State elements store results across time.
6. Entire processors, controllers, and protocols are built from those pieces.

If you remember only one thing from this section, remember this: digital design is robust because the system is built so that small analog errors do not usually change the interpreted bit.

### 1.3 Why binary beats many-valued logic in most systems

It is fair to ask why digital logic usually uses two levels instead of three, four, or more.

The short answer is robustness.

Binary is attractive because it gives engineers:

- larger noise margins for a given supply voltage
- simpler circuits for detection and regeneration
- easier testing and verification
- more predictable timing and manufacturing yield
- clearer software and hardware interfaces

Multi-level signaling does exist in production systems. Flash memory stores more than one bit per cell. High-speed links use schemes such as PAM4. But those systems pay for it with tighter analog requirements, calibration, equalization, error correction, and far less margin. For mainstream logic inside chips and boards, binary remains the best cost-performance-reliability tradeoff.

### 1.4 Logic levels and thresholds

Receivers do not simply ask, "Is the voltage above zero?" They have specific thresholds.

The most useful terms are:

| Term | Meaning |
| --- | --- |
| `VOH(min)` | Minimum voltage a driver guarantees for logic high |
| `VOL(max)` | Maximum voltage a driver guarantees for logic low |
| `VIH(min)` | Minimum voltage the receiver will definitely accept as high |
| `VIL(max)` | Maximum voltage the receiver will definitely accept as low |

From those values we get noise margins:

- High noise margin: `NMH = VOH(min) - VIH(min)`
- Low noise margin: `NML = VIL(max) - VOL(max)`

Those margins are not abstract math. They tell you how much noise, droop, ringing, or ground shift you can tolerate before a `1` may be misread as a `0` or vice versa.

For many CMOS inputs, rough threshold guidance is often around `0.3 x VDD` for low and `0.7 x VDD` for high, but you should not memorize that as universal truth. Real thresholds are family- and device-specific. Datasheets decide reality.

```mermaid
flowchart LR
	A[Wire voltage] --> B{Above receiver high threshold?}
	B -- yes --> C[Interpret as logic 1]
	B -- no --> D{Below receiver low threshold?}
	D -- yes --> E[Interpret as logic 0]
	D -- no --> F[Undefined region\nMay chatter, misread, or go metastable]
```

### 1.5 Why edges matter as much as levels

Beginners often think only the steady-state voltage matters. In real systems, transitions are where many failures happen.

During an edge:

- the signal spends time moving through the threshold region
- line capacitance must be charged or discharged
- ringing and overshoot may appear
- coupled noise from nearby signals can matter more
- receivers may switch at slightly different times

This is why a logic analyzer that reports clean `1` and `0` values can hide the real problem. The real problem may be that the edge is too slow, too noisy, or badly timed.

### 1.6 Digital logic and software are similar in one narrow sense

A Boolean in software is already resolved. A Boolean in hardware has to become resolved through circuit behavior.

The closest software analogy is this:

- a digital input is like a value being sampled from the outside world
- a flip-flop is like a value being committed at a scheduling boundary
- a clock domain crossing is like unsafely sharing state between threads without synchronization

The analogy is useful, but only if you remember the limit: hardware is parallel, and the sampling event is physical.

### 1.7 Common mistakes at the abstraction boundary

- Treating any nonzero voltage as logic high.
- Ignoring datasheet thresholds when mixing `5 V`, `3.3 V`, and `1.8 V` logic.
- Assuming a logic analyzer alone is enough when the problem is actually analog edge quality.
- Forgetting that long wires and connectors can destroy margin even at modest frequencies.

---

## 2. Binary Signals In Real Systems

### 2.1 A binary signal is more than a label on a schematic

At the schematic level, a signal might be named `READY`, `CLK`, `RESET_N`, or `DATA0`. In hardware, that signal has electrical behavior:

- a driver with finite output strength
- a receiver with thresholds and input capacitance
- an interconnect path with resistance, capacitance, and sometimes inductance
- an environment that adds noise, crosstalk, and supply variation

If you ignore those electrical details, the logic diagram becomes misleading.

### 2.2 Drivers, receivers, and loading

A digital output does not create an arbitrary ideal voltage. It sources or sinks current through a real transistor network.

Important practical ideas:

- Source current means the output is driving current out toward the load.
- Sink current means the output is pulling current in from the load toward ground.
- Every receiving input adds capacitance.
- More load means slower edges.
- More wiring length usually means more capacitance and more opportunity for ringing.

This is why fan-out matters. One output feeding one nearby input is easy. One output feeding many inputs across a board may become a timing or integrity problem even if the logic equation is trivial.

### 2.3 Common binary signaling styles

| Style | How it behaves | Typical use | Main risk |
| --- | --- | --- | --- |
| Push-pull | Actively drives both high and low | Most logic outputs, clocks, control lines | Bus contention if two outputs drive opposite values |
| Open-drain / open-collector | Actively pulls low, relies on pull-up for high | I2C, wired-OR interrupts, fault lines | Slow rising edges, wrong pull-up sizing |
| Tri-state | Can drive high, drive low, or disconnect | Shared buses, memory interfaces | Enable mistakes causing float or contention |
| Differential | Encodes data as voltage difference between two lines | High-speed interfaces | Layout, termination, and skew sensitivity |

Even when this handbook focuses on basic digital logic, it is worth remembering that the implementation style changes the failure modes.

### 2.4 Floating signals are not benign

An unconnected CMOS input is not reliably `0` or `1`. It can drift, pick up noise, oscillate, and consume extra power.

That is why real designs use:

- pull-up resistors
- pull-down resistors
- internal pulls in microcontrollers or FPGAs when appropriate
- explicit default states for unused or optional pins

Floating chip selects, resets, enables, or interrupt lines cause surprisingly expensive failures because the behavior is often intermittent and temperature-dependent.

### 2.5 Active-high and active-low signals

Signal naming matters because polarity errors are common.

- Active-high means the function is asserted when the signal is `1`.
- Active-low means the function is asserted when the signal is `0`.

Common naming conventions for active-low signals include `_n`, `_b`, or a bar in schematics. For example, `RESET_N` usually means reset is asserted low.

Active-low signals are common for practical reasons:

- some transistor structures pull low more strongly than they pull high
- shared open-drain lines naturally assert low
- reset circuits often default low during power-up

If a design review shows confusion about whether a signal is active-high or active-low, stop and resolve it immediately. Polarity bugs survive simulation more often than people expect.

### 2.6 Why slow or noisy edges are dangerous

A slow edge spends more time in the threshold region. That increases the chance of:

- multiple transitions at the receiver
- extra short-circuit current inside CMOS gates
- higher sensitivity to noise
- timing uncertainty

Schmitt-trigger inputs help because they use different thresholds for rising and falling edges. That hysteresis prevents chatter on slow or noisy signals such as mechanical switches or long external inputs.

### 2.7 A concrete production example: a button input

A button is a simple signal in the logical sense and a messy signal in the electrical sense.

What really happens when a user presses a button:

1. The contact closes mechanically.
2. The contact bounces, producing several transitions instead of one.
3. The input may rise or fall slowly depending on the pull resistor and capacitance.
4. If sampled directly, the logic may see many presses.
5. If sampled near a clock edge, the first synchronizing element can go metastable.

The correct engineering response is usually:

- give the signal a defined idle state with a pull-up or pull-down
- use a Schmitt-trigger input if available
- synchronize into the destination clock domain
- debounce in logic or firmware

This is a good example of a digital concept that only makes sense if you respect the analog details.

### 2.8 Binary signal debugging methods

When a binary signal misbehaves, use the right tool for the question.

- Use a logic analyzer to see protocol-level sequences and broad timing relationships.
- Use an oscilloscope to inspect edge rate, overshoot, ringing, bounce, and threshold crossings.
- Check both the signal and the relevant ground reference point.
- If the line is open-drain, verify the pull-up value and rise time.
- If the line drives several loads, check whether fan-out or trace length is the real cause.

Common mistake: trusting the digital decode while ignoring the analog waveform that produced it.

---

## 3. Logic Gates: The Vocabulary Of Digital Design

### 3.1 What a logic gate really is

A logic gate is a transistor network that maps input conditions to an output condition.

At the abstraction level of digital design, a gate implements a Boolean function. At the physical level, it controls conductive paths to power and ground.

In CMOS logic, the intuition is especially useful:

- a pull-up network connects the output to `VDD` when the output should be high
- a pull-down network connects the output to ground when the output should be low
- ideally, in steady state, only one of those paths is strongly on

That structure explains why CMOS has low static power for ordinary logic states and why transitions matter.

### 3.2 The core gates and how engineers think about them

| Gate | Boolean form | Engineering intuition | Common use |
| --- | --- | --- | --- |
| NOT | `Y = !A` | Invert meaning or polarity | Active-low adaptation, control inversion |
| AND | `Y = A & B` | All required conditions must be true | Enable only when ready and valid |
| OR | `Y = A \| B` | Any one of several conditions is enough | Aggregate requests or error flags |
| NAND | `Y = !(A & B)` | AND followed by inversion | Universal gate, common CMOS primitive |
| NOR | `Y = !(A \| B)` | OR followed by inversion | Universal gate, control logic |
| XOR | `Y = A ^ B` | Inputs differ | Bit comparison, parity, adders |
| XNOR | `Y = !(A ^ B)` | Inputs match | Equality detection |

Strong engineers do not just memorize symbols. They translate gates into intent.

- AND means all prerequisites are satisfied.
- OR means at least one condition can trigger action.
- XOR means mismatch or toggling behavior.
- Inversion often means an interface uses active-low semantics.

### 3.3 Why NAND and NOR matter so much

NAND and NOR are called universal gates because any Boolean function can be built entirely from one or the other.

That matters in practice for two reasons:

- it shows Boolean logic is structurally flexible
- some process technologies make particular gate forms cheaper or faster to build

In CMOS, NAND is often especially natural. An AND function is commonly implemented as NAND plus inverter because the transistor arrangement is convenient.

### 3.4 De Morgan's Law is not optional knowledge

De Morgan's Law shows how inversion moves through logic expressions:

- `!(A & B) = !A | !B`
- `!(A | B) = !A & !B`

This matters constantly when reading schematics with active-low signals, simplifying logic, or understanding why a design built from NAND gates still implements the required behavior.

If you are uncomfortable with De Morgan's Law, active-low logic will keep confusing you.

### 3.5 Gates in software and HDL

In software, the closest analog is a Boolean expression. In HDL, the same idea becomes hardware.

Example combinational intent in SystemVerilog:

```systemverilog
assign motor_enable = start_cmd && guard_closed && !estop;
```

That does not mean the hardware "runs this line" in sequence. It means the synthesis tool builds logic that continuously implements that relationship.

This difference is foundational:

- software statements describe steps in time
- combinational HDL statements describe concurrent hardware relationships

### 3.6 Real production uses of basic gates

- `AND`: assert write when request, permission, and clock enable are all valid
- `OR`: combine fault flags into one interrupt line
- `XOR`: parity generation and data mismatch detection
- `XNOR`: equality comparisons in comparators or cache tag checks
- `NOT`: convert between active-low board signal and active-high internal meaning

### 3.7 Failure cases involving gates

- Treating an enable line as purely logical while ignoring that it has slow edges or poor margin.
- Combining asynchronous signals directly and feeding the result into synchronous logic.
- Forgetting inversion bubbles and therefore implementing the opposite behavior.
- Driving a shared line from two push-pull outputs, creating contention and sometimes physical damage.

### 3.8 Interview-level understanding

If someone asks why engineers care about NAND and NOR, a strong answer is:

They are universal, they map well to transistor implementations, and they make it easier to reason about active-low logic and synthesis structures. Knowing that keeps you from confusing symbolic logic with actual gate-level implementation.

---

## 4. Truth Tables And Boolean Reasoning

### 4.1 What a truth table is really for

A truth table is not busywork. It is a complete behavioral specification for a Boolean function over the input combinations you care about.

Truth tables are especially useful when:

- requirements are written in plain language and need formalization
- several control conditions interact
- active-low signals make equations hard to read mentally
- you need to verify that a gate-level implementation matches intent

### 4.2 Building a truth table from a requirement

Suppose the requirement says:

"Enable the motor only when the operator pressed start, the safety guard is closed, and emergency stop is not asserted."

Define inputs:

- `S = start_cmd`
- `G = guard_closed`
- `E = estop` where `1` means emergency stop is asserted

Desired output:

- `M = motor_enable`

Truth table:

| `S` | `G` | `E` | `M` |
| --- | --- | --- | --- |
| 0 | 0 | 0 | 0 |
| 0 | 0 | 1 | 0 |
| 0 | 1 | 0 | 0 |
| 0 | 1 | 1 | 0 |
| 1 | 0 | 0 | 0 |
| 1 | 0 | 1 | 0 |
| 1 | 1 | 0 | 1 |
| 1 | 1 | 1 | 0 |

From inspection, the equation is:

`M = S & G & !E`

The table matters because it forces clarity. If a safety engineer later says maintenance mode should also block motion, you now know exactly what to update.

### 4.3 Step-by-step method for difficult truth tables

When the logic is more complex, use this method:

1. Define each input signal and its polarity clearly.
2. State the output meaning in plain language.
3. List all input combinations that matter.
4. Mark the required output for each case.
5. Look for patterns and derive the Boolean expression.
6. Simplify only after the behavior is unquestionably correct.

That ordering is important. Engineers get into trouble when they simplify too early and lose the original intent.

### 4.4 Don't-care conditions versus unknowns

These are not the same thing.

- A don't-care condition means certain input combinations are unreachable or irrelevant, so the designer may choose either output value for optimization.
- An unknown `X` in simulation means the tool cannot determine a stable logical value from the current information.

This distinction matters a lot in HDL and verification.

Examples of valid don't-care usage:

- unused opcode combinations in a decoder
- invalid BCD inputs when designing a seven-segment driver

Examples of dangerous misuse:

- treating a safety-critical signal as don't-care because "it should never happen"
- assuming a simulation `X` behaves like a synthesis optimization opportunity

Professional habit: use don't-cares only when the hardware architecture truly guarantees the state is unreachable or irrelevant.

### 4.5 From truth tables to logic expressions

Two classic forms are useful:

- Sum of products: OR together the input combinations that produce `1`
- Product of sums: AND together clauses that exclude the `0` cases

For small designs, truth-table inspection and Boolean algebra are enough. For medium-sized logic, Karnaugh maps help visualize simplification by grouping adjacent cells that differ in only one variable.

The deeper lesson is not the tool. The deeper lesson is that simplification is a controlled transformation of the same specified behavior.

### 4.6 Truth tables versus software conditionals

Software often expresses decisions as `if` statements. A truth table is the hardware-oriented version of the same logical intent.

But there is one critical difference: in hardware, all inputs conceptually exist at once. There is no implied top-to-bottom execution order in the resulting gate network.

This is why a truth table is often a better design artifact than a few lines of pseudo-code when several signals interact.

### 4.7 Common truth-table mistakes

- Mixing active-high and active-low signals without renaming or documenting them clearly.
- Forgetting unreachable states and then mishandling them in synthesis or firmware.
- Assuming the simplified equation is correct without checking back against the original behavioral requirement.
- Confusing bitwise operators and logical operators in software or HDL.

---

## 5. Combinational Versus Sequential Logic

### 5.1 The essential difference

This is one of the most important distinctions in digital design.

- Combinational logic depends only on current inputs.
- Sequential logic depends on current inputs and stored state.

If a block has no memory, it is combinational. If the past can influence the present, it is sequential.

### 5.2 Combinational logic is like a pure function

A combinational block behaves like a mathematical function:

`output = f(current_inputs)`

Examples:

- adders
- multiplexers
- decoders
- comparators
- simple control equations

If the inputs change, the outputs eventually change after some propagation delay. There is no built-in notion of "previous cycle" or memory.

### 5.3 Sequential logic introduces state

Sequential logic uses storage elements such as latches or flip-flops so that the system remembers something about the past.

Examples:

- counters
- finite state machines
- pipelines
- registers and register files
- protocol engines
- FIFOs

The mental model is:

`next_state = f(current_state, current_inputs)`

and then, at some defined time boundary, the new state is stored.

### 5.4 Why feedback creates memory

The moment a system's output can influence its future input, state becomes possible.

That feedback can be intentional and well-controlled, as in a synchronous state machine, or dangerous and poorly controlled, as in an accidental latch or unstable asynchronous loop.

```mermaid
flowchart LR
	subgraph C1[Combinational logic]
		I1[Current inputs] --> F1[Logic network]
		F1 --> O1[Current outputs]
	end

	subgraph C2[Sequential logic]
		I2[Current inputs] --> F2[Next-state logic]
		S[Stored state] --> F2
		F2 --> R[State element]
		R --> S
		S --> O2[Outputs or control]
	end
```

### 5.5 Why synchronous sequential logic dominates industry

Engineers strongly prefer synchronous design because it creates a shared timing contract.

With a clocked system:

- state updates happen at known edges
- timing analysis becomes structured
- verification becomes more tractable
- large designs can be partitioned cleanly

Without that structure, feedback loops and timing interactions become much harder to reason about.

### 5.6 Glitches and hazards in combinational logic

Combinational logic is not instantaneous. Different paths have different delays.

That means an output can briefly glitch even when its steady-state value should not change.

Example intuition:

- two inputs are supposed to change "at the same time"
- one path reaches the output logic slightly earlier
- the output briefly sees an unintended intermediate combination
- a narrow pulse appears

If that pulse feeds ordinary combinational logic, it might be harmless. If it feeds an asynchronous control, latch enable, reset, or derived clock, it can become a real failure.

### 5.7 HDL implementation detail that matters

A combinational HDL block should define outputs for all input cases. If it does not, synthesis may infer storage.

Example of a common bug pattern:

```systemverilog
always_comb begin
	if (en)
		q_next = d;
	// Missing else can imply that q_next holds a previous value.
end
```

If the intended behavior was purely combinational, the fix is to assign a value in every path. If the intended behavior was to hold state, then you were not describing combinational logic at all.

### 5.8 Practical comparison table

| Attribute | Combinational | Sequential |
| --- | --- | --- |
| Depends on current inputs only | Yes | No |
| Has memory | No | Yes |
| Uses clock by definition | No | Usually yes in modern designs |
| Typical examples | Adder, mux, comparator | Counter, FSM, pipeline stage |
| Main risk | Glitches and path delay | Timing violations, metastability, reset issues |

---

## 6. Latches

### 6.1 What a latch is

A latch is a level-sensitive storage element.

The simplest intuition is:

- when enabled, the latch is transparent and output follows input
- when not enabled, the latch holds its last value

That transparency is the defining feature. It is also the reason latches can be powerful and dangerous.

### 6.2 The SR latch from first principles

One classic latch is built from two cross-coupled NOR gates or two cross-coupled NAND gates.

The key idea is feedback:

- setting one side influences the other side
- that response feeds back and reinforces the state
- after the control input is released, the feedback keeps the stored value

```mermaid
flowchart LR
	S[Set] --> N1[NOR gate]
	QB[Qbar feedback] --> N1
	N1 --> Q[Q]
	R[Reset] --> N2[NOR gate]
	Q --> N2
	N2 --> QB[Qbar]
```

Step by step for a NOR-based SR latch:

1. Assert `S` to force `Q` high.
2. `Q` feeding back low into the opposite NOR helps force `Qbar` low.
3. Release `S`.
4. The feedback now maintains the state without needing `S` to stay asserted.
5. Assert `R` later to clear the state.

This is one of the cleanest examples of how feedback turns logic into memory.

### 6.3 The invalid or dangerous condition

In a simple SR latch, certain input combinations are illegal or ambiguous, depending on NAND or NOR implementation.

Why that matters:

- both outputs may be forced to values that are not complementary
- releasing the invalid condition can create an unpredictable resolution race

This is why raw SR latches are more educationally important than practically common in mainstream synchronous design.

### 6.4 The D latch

To avoid the awkward SR input behavior, designers often use a D latch. It presents one data input `D` and one enable input.

Behavior of a positive-level D latch:

- when `EN = 1`, `Q` follows `D`
- when `EN = 0`, `Q` holds the last sampled value

That sounds simple, but the transparency window matters. If combinational logic upstream keeps changing while the latch is open, the stored value can keep changing too.

### 6.5 Why latches are tricky in practice

Latches complicate reasoning because their transparency depends on a level, not an instant.

Main risks:

- race-through if several latch stages are transparent at the same time
- sensitivity to glitches while enabled
- more complex timing analysis than simple edge-triggered designs
- unintentional inference in HDL

For those reasons, many FPGA and ordinary RTL design flows strongly prefer flip-flops unless latch behavior is explicitly intended.

### 6.6 When latches are used intentionally

Latches are not bad. They are just specialized.

Intentional production uses include:

- integrated clock-gating cells, where a latch helps prevent glitches on the gated clock enable
- certain high-performance ASIC datapaths, where time borrowing can improve timing closure
- specialized asynchronous interfaces

But these uses require more discipline, not less.

### 6.7 Common latch mistakes

- Inferring a latch accidentally because not all combinational assignments were specified.
- Using a latch where a flip-flop was intended, then wondering why a signal changes during the active clock level.
- Feeding a latch enable with glitchy combinational logic.
- Assuming latch timing can be treated exactly like flip-flop timing.

### 6.8 Debugging latch-related failures

Symptoms that suggest a latch problem:

- the output changes while the clock or enable is high instead of only at an edge
- simulation and hardware disagree because a latch was inferred unintentionally
- the design works at one synthesis or place-and-route result and fails at another

If you suspect a latch bug, first verify whether the design intended level-sensitive storage at all.

---

## 7. Flip-Flops

### 7.1 Why flip-flops became the standard storage element

A flip-flop is edge-triggered. Instead of being transparent for an entire enable level, it samples its input around a clock edge and then holds the result until the next relevant edge.

That single idea greatly simplifies system design.

It lets engineers say, in effect:

- combinational logic may move around between edges
- stored state updates only at well-defined edges

This is the foundation of synchronous digital systems.

### 7.2 The D flip-flop

The D flip-flop is by far the most common state element in modern digital design.

Its contract is simple:

- the `D` input is sampled near the active clock edge
- the sampled value appears at `Q` after a clock-to-output delay
- `Q` then stays stable until the next sampling edge

Typical RTL form:

```systemverilog
always_ff @(posedge clk or negedge rst_n) begin
	if (!rst_n)
		state <= IDLE;
	else
		state <= next_state;
end
```

This describes state update. The combinational logic that produces `next_state` is separate.

### 7.3 Setup and hold time explained step by step

Setup and hold are easier to remember if you follow the data path physically.

1. A launch flip-flop updates its output after a clock edge.
2. The new value travels through combinational logic.
3. The capture flip-flop needs the arriving data to be stable before the next sampling edge for at least `tsetup`.
4. It also needs the data not to change too soon after the sampling edge for at least `thold`.

If the setup requirement is violated, the capture flip-flop may sample the wrong value or go metastable.

If the hold requirement is violated, the new data changes too quickly and may corrupt the capture event for the same edge.

Important practical rule: setup problems are often fixed by adding time or reducing logic delay. Hold problems are often fixed by adding delay to the data path. Lowering the clock frequency does not reliably fix a hold problem.

### 7.4 Other flip-flop types

- `T` flip-flop: toggles when enabled, useful conceptually for counters
- `JK` flip-flop: historically important, less common in modern RTL practice
- `D` flip-flop: dominant in real design because arbitrary state behavior is easiest to express as next-state logic plus D storage

If you understand D flip-flops deeply, you understand what most modern synchronous logic is built from.

### 7.5 Metastability: the most important non-ideal behavior in digital design

Metastability happens when a flip-flop samples a changing input too close to the clock edge or when an asynchronous signal violates the sampling assumptions.

Internally, the flip-flop is a regenerative analog circuit. If conditions are bad, it can enter a temporary balanced state where it has not yet resolved cleanly to `0` or `1`.

Key facts:

- metastability cannot be completely eliminated
- it can be made arbitrarily unlikely with proper design
- the first synchronizing flip-flop is allowed to go metastable; the design goal is to keep that condition from escaping into the rest of the logic

The standard single-bit mitigation is a two-flip-flop synchronizer in the destination domain.

```mermaid
flowchart LR
	A[Asynchronous input or foreign clock domain] --> FF1[First flip-flop\nmay go metastable]
	FF1 --> FF2[Second flip-flop\ngets extra settling time]
	FF2 --> L[Destination synchronous logic]
```

Critical professional rule: do not fan out the output of the first synchronizer stage to multiple consumers. If that node resolves late, different consumers may interpret it differently.

### 7.6 What synchronizers can and cannot do

A two-flop synchronizer is good for a single control bit or a slowly changing status signal.

It is not enough for:

- a multi-bit bus that must be captured coherently
- a narrow pulse that might be shorter than a destination clock period
- high-throughput data transfer between unrelated domains

Those cases need handshakes, pulse-stretching, Gray coding, FIFOs, or other CDC structures.

### 7.7 Production uses of flip-flops

- pipeline registers in CPUs, DSP blocks, and packet-processing pipelines
- state storage in protocol controllers and finite state machines
- counters and timers in microcontrollers
- synchronizers for interrupts, GPIO events, and peripheral status lines
- output registers that improve timing and reduce combinational glitches seen off-chip

### 7.8 Common flip-flop mistakes

- Sampling asynchronous inputs directly with functional logic instead of synchronizing first.
- Assuming metastability is a simulation-only concept.
- Using one synchronized bit to qualify unsynchronized related data.
- Releasing an asynchronous reset unsafely so different flip-flops wake up on different cycles.

---

## 8. Timing Basics

### 8.1 Timing is the contract behind synchronous logic

A synchronous design works only if data arrives when storage elements expect it to arrive.

Good timing analysis is not optional ceremony. It is the proof that the design can operate at the intended frequency, process corner, voltage, and temperature.

### 8.2 Core timing terms

| Term | Meaning | Why it matters |
| --- | --- | --- |
| Propagation delay, `tpd` | Maximum time for a change to affect the output | Determines worst-case path delay |
| Contamination delay, `tcd` | Minimum time before the output can begin to change | Important for hold analysis |
| Clock-to-Q | Delay from active clock edge to flip-flop output change | Starts every synchronous path |
| Setup time | Data must be stable before the edge | Limits maximum clock frequency |
| Hold time | Data must remain stable after the edge | Can fail even at low frequency |
| Rise/fall time | Edge transition time | Affects threshold crossing and integrity |
| Pulse width | How long a pulse stays high or low | Too narrow may be missed |
| Clock skew | Difference in clock arrival time at different elements | Changes effective timing budget |
| Jitter | Variation in clock edge timing over time | Reduces margin |

### 8.3 The setup path budget

The classic synchronous path is:

- launch flip-flop
- combinational logic
- capture flip-flop

For setup to succeed, the launched data must reach the capture flip-flop and settle before the next active edge.

```mermaid
flowchart LR
	CLK[Clock network] --> LFF[Launch flip-flop]
	CLK --> CFF[Capture flip-flop]
	LFF --> CQ[Clock-to-Q delay]
	CQ --> COMB[Combinational logic delay]
	COMB --> CFF
```

The practical setup equation is:

`Tclk >= tclk_to_q(max) + tcomb(max) + tsetup + uncertainty + margin`

Example:

- `tclk_to_q = 0.8 ns`
- `tcomb = 6.5 ns`
- `tsetup = 0.7 ns`
- `uncertainty = 0.8 ns`

Total required period is `8.8 ns`, so a `10 ns` clock period, which is `100 MHz`, has `1.2 ns` of slack.

This is how timing closure is discussed in real projects: in terms of path delay, uncertainty, and slack.

### 8.4 Hold timing is a different kind of problem

For hold timing, the concern is that new data arrives too soon after the same edge, before the capture flip-flop has finished sampling the old value.

Conceptually:

`tclk_to_q(min) + tcomb(min) >= thold + uncertainty`

Why engineers respect hold timing:

- hold failures can happen even at low clock frequencies
- a path can be too fast, not too slow
- fixing hold often means adding delay or changing placement and routing

This is a standard interview filter because it reveals whether someone actually understands timing or only memorized the setup equation.

### 8.5 Path delay is not the only timing issue

Designs also fail because of:

- glitches that create unintended pulses
- asynchronous inputs that arrive at unsafe times
- pulses too narrow for a receiving block to detect
- clock skew between related elements
- reset release that is not aligned to the clock

Timing is broader than one equation.

### 8.6 Process, voltage, and temperature matter

Digital timing changes with PVT conditions.

- Slow process, low voltage, and high temperature often hurt setup margin.
- Fast process, high voltage, and low temperature can worsen hold risk because paths become very fast.

This is why professional signoff uses timing corners, not one nominal case.

### 8.7 Glitches, hazards, and narrow pulses

A short glitch may be invisible in one part of the design and fatal in another.

Examples of where glitches are dangerous:

- clock gating enables
- asynchronous resets or clears
- latch enables
- off-chip control strobes
- interrupt generation

If a signal is used as a control rather than as data captured by a normal flip-flop, be much more suspicious of combinational glitches.

### 8.8 Timing of asynchronous external signals

External signals do not care about your internal clock.

That means a GPIO interrupt, push button, sensor-ready line, or serial input may change at any time relative to the local sampling edge.

Robust treatment usually involves:

- input conditioning if needed
- synchronization into the destination domain
- pulse stretching or handshake logic if the event can be missed
- debouncing for mechanical sources

### 8.9 Debugging timing problems

Timing bugs often look like random functional bugs.

Common symptoms:

- failure only at higher clock frequencies
- failure only in some builds or on some boards
- failure only at temperature or voltage extremes
- behavior changes when instrumented, because routing or timing changes

Strong debugging steps:

1. Check whether the failing behavior maps to a particular timing path or clock domain crossing.
2. Review static timing reports for setup, hold, false paths, and unconstrained paths.
3. Inspect the waveform around the failing capture event.
4. Reduce the design to the smallest reproducing path if possible.
5. Confirm that the issue is not actually signal integrity or reset sequencing in disguise.

---

## 9. Clocking

### 9.1 What the clock really does

A clock does not carry data. It defines when state is allowed to update.

That shared schedule is what makes a large synchronous design manageable.

Without a clean clocking strategy, even simple logic becomes hard to verify and hard to scale.

### 9.2 Single-clock-domain design is the default best practice

The cleanest digital subsystem is one where:

- all relevant state elements use the same clock
- combinational logic stays between those state elements
- external events are synchronized before use

This pattern is easier to reason about, easier to constrain, and easier to debug than a design with many casually related clocks.

### 9.3 Clock networks are special resources

In chips and FPGAs, clocks are not ordinary data signals.

Clock networks are usually designed to provide:

- low skew
- controlled buffering
- wide distribution
- predictable timing characteristics

That is why using a random combinational signal as a clock is usually a bad design decision. It bypasses the structures that make clocking reliable.

### 9.4 Derived clocks versus clock enables

If you need slower activity inside a synchronous system, prefer a clock enable when possible.

Why clock enables are usually safer:

- the design stays in one clock domain
- timing constraints remain simpler
- CDC problems are reduced
- FPGA tools handle enables well

Example idea:

- keep the main clock at `100 MHz`
- generate a one-cycle enable every 100 cycles
- update a slow counter only when that enable is asserted

This is usually better than building a new internal `1 MHz` clock with ordinary logic.

### 9.5 Clock gating

Clock gating saves power by stopping unnecessary switching activity.

But the implementation matters:

- in ASICs, use proper clock-gating cells from the library
- in FPGAs, prefer clock enable resources unless the vendor explicitly supports a clock-gating structure
- never gate a clock with ad hoc combinational logic and assume it will be glitch-free

Clock gating is a classic area where a reasonable power goal can produce an unreliable design if done casually.

### 9.6 Reset strategy is part of clocking strategy

Reset is not the same as clock, but their interaction is critical.

Two common approaches:

- synchronous reset: reset is sampled on the clock edge
- asynchronous reset: reset can assert independent of the clock

A strong practical rule is often:

- asynchronous assert if needed for safety or startup
- synchronous deassert into each clock domain

Why the deassertion matters: if reset is released near a clock edge and different flip-flops respond differently, the design can start in an illegal or inconsistent state.

### 9.7 Clock domain crossing

A clock domain crossing happens when data or control moves between domains with unrelated or insufficiently defined timing relationship.

Single-bit CDC techniques:

- two-flop synchronizer for level signals
- pulse synchronization or toggle synchronization for event pulses

Multi-bit CDC techniques:

- ready/valid handshake
- asynchronous FIFO
- Gray-coded counters where only one bit changes at a time

The wrong way to do CDC is simple but common: synchronize one control bit and assume the rest of a multi-bit bus is "close enough." That is how intermittent field bugs are born.

### 9.8 Real production clocking scenarios

| Scenario | Preferred approach | Why |
| --- | --- | --- |
| Slow internal operation inside one synchronous block | Clock enable | Avoids unnecessary new domain |
| Board interrupt entering FPGA or ASIC logic | Synchronizer in destination domain | Reduces metastability propagation |
| Data stream between unrelated producer and consumer clocks | Asynchronous FIFO or handshake | Preserves data integrity |
| Low-power block in ASIC | Library clock gating | Power reduction with controlled skew and glitch prevention |
| FPGA design needing lower-rate state updates | Vendor-supported enable or clock resource | Better tool support and timing closure |

### 9.9 Common clocking mistakes

- Deriving clocks from LUTs or ordinary combinational logic.
- Using different clocks when a clock enable would have solved the problem.
- Failing to synchronize reset deassertion into each domain.
- Treating a multi-bit CDC like a single-bit CDC.
- Forgetting that a pulse can disappear entirely when crossing into a slower domain.

---

## 10. Real-World Design Practices, Failure Modes, And Debugging

### 10.1 Common mistakes engineers make

- Leaving inputs floating.
- Mixing logic families or voltage domains without checking thresholds.
- Ignoring polarity and active-low naming.
- Inferring latches unintentionally.
- Using asynchronous inputs directly in functional logic.
- Treating setup timing as the only timing check.
- Assuming reducing clock frequency fixes every timing problem.
- Gating clocks incorrectly.
- Releasing reset unsafely.
- Trusting simulation when constraints, board behavior, or CDC structure are wrong.

### 10.2 A practical troubleshooting workflow

```mermaid
flowchart TD
	A[Observed digital failure] --> B{Always reproducible?}
	B -- yes --> C[Check logic intent\ntruth table, polarity, reset state]
	B -- no --> D[Suspect timing, CDC, power, or signal integrity]
	C --> E{Matches specification?}
	E -- no --> F[Fix logic design or firmware assumptions]
	E -- yes --> G[Inspect waveform and state transitions]
	D --> G
	G --> H{Signal clean at electrical level?}
	H -- no --> I[Use scope\ncheck thresholds, edge rate, ringing, pull resistors, loading]
	H -- yes --> J{Clocked boundary involved?}
	J -- yes --> K[Review setup, hold, reset, CDC, synchronizers]
	J -- no --> L[Review combinational hazards and protocol assumptions]
	I --> M[Retest]
	K --> M
	L --> M
	F --> M
```

This is the kind of workflow that saves days in the lab because it separates logic errors from timing errors from electrical errors.

### 10.3 Use the right instrument for the failure mode

| Tool | Best for | Weakness |
| --- | --- | --- |
| Logic analyzer | Long captures, protocol timing, trigger-based event hunting | Hides analog waveform quality |
| Oscilloscope | Edge shape, ringing, bounce, skew, threshold crossings | Usually fewer channels and shorter contextual history |
| On-chip logic analyzer | Internal FPGA or SoC state visibility | Can perturb timing or resource usage |
| Static timing analysis | Proving synchronous path timing | Does not replace electrical measurement |
| Firmware logging or counters | Rare-event observability | Often too slow for root-cause timing details |

### 10.4 Design tradeoffs engineers actually make

#### More stages versus lower latency

Adding flip-flops shortens combinational paths and helps timing closure, but it increases latency and sometimes area or power.

#### Clock enable versus new clock domain

A new clock domain may look conceptually simple, but it increases CDC burden. A clock enable often preserves design simplicity.

#### Latches versus flip-flops

Latches can improve performance through time borrowing in advanced ASIC work, but they raise verification and timing complexity. Flip-flops are usually the safer default.

#### Open-drain versus push-pull outputs

Open-drain supports shared lines and level adaptation, but the pull-up resistor creates slower rising edges. Push-pull is faster, but bus sharing becomes dangerous.

### 10.5 Production scenarios that connect hardware and software

#### Scenario 1: Firmware reads a button input

The software sees `pressed` or `not pressed`, but hardware must first:

- define the idle state with a pull resistor
- clean the edge with hysteresis if needed
- synchronize the signal to the MCU or FPGA clock
- debounce so one press does not become many events

If the firmware team only sees a GPIO register and the hardware team ignores debounce strategy, both teams can believe the bug belongs to the other.

#### Scenario 2: FPGA samples a sensor-ready interrupt

The sensor-ready pin is asynchronous to the FPGA fabric clock. The correct path is not simply wiring that pin into the state machine.

Robust approach:

- condition the input electrically if needed
- synchronize into the fabric clock
- detect edges or levels after synchronization
- stretch or handshake if pulse width is uncertain

#### Scenario 3: Shared fault line across several devices

An open-drain fault line lets multiple devices assert fault without contention. But engineers must choose the pull-up correctly, verify rise time, and ensure all devices tolerate the voltage level.

### 10.6 Failure cases worth remembering

- A line that looks fine on the schematic but floats on the board because the default state was never defined.
- A design that passes simulation and fails in hardware because the simulation did not model metastability or unconstrained timing.
- A pulse that disappears when crossing into a slower clock domain.
- A hold violation introduced by place-and-route optimization even though setup improved.
- A reset that deasserts too close to a clock edge and starts the state machine in an illegal state.

### 10.7 Best-practice checklist

- Define logic levels and voltage compatibility from datasheets, not assumptions.
- Give every external or optional signal a known default state.
- Keep ordinary logic synchronous where possible.
- Synchronize every asynchronous input before using it in synchronous logic.
- Treat multi-bit CDC as a dedicated design problem.
- Prefer clock enables over casually created new clocks.
- Keep combinational logic out of clock and reset paths unless the structure is explicitly intended and reviewed.
- Run and review timing constraints and reports seriously.
- Measure suspicious signals with an oscilloscope, not only a logic analyzer.
- Document polarity, reset behavior, and clock-domain ownership in interfaces.

---

## 11. Interview-Level Understanding And Strong Answers

### 11.1 Why is binary signaling so robust?

Because the receiver only needs to distinguish two well-separated ranges, which creates noise margin and allows each stage to regenerate a clean logic level from an imperfect analog input.

### 11.2 What is the real difference between a latch and a flip-flop?

A latch is level-sensitive and transparent while enabled. A flip-flop is edge-triggered and samples near a clock edge. That timing behavior changes both design style and failure modes.

### 11.3 Why do hold violations matter if the clock is slow?

Because hold is about the same edge, not the next one. If data changes too quickly after launch, it can corrupt the capture event immediately. Lowering clock frequency does not inherently fix that.

### 11.4 What is metastability and how do you handle it?

Metastability is a temporary unresolved analog condition in a state element caused by unsafe sampling of a changing or asynchronous signal. You reduce risk with synchronizers, proper CDC design, and by giving the system enough settling time.

### 11.5 Why not use a combinational signal as a clock?

Because combinational logic can glitch, lacks controlled skew characteristics, and bypasses dedicated clocking resources. That creates unreliable timing and hard-to-debug failures.

### 11.6 Why is a truth table still useful when synthesis tools exist?

Because the truth table captures intended behavior explicitly. Synthesis optimizes implementation, not requirements. If the requirement is unclear, synthesis will optimize the wrong thing very efficiently.

### 11.7 What is the difference between a synchronized bit and a safe CDC transfer?

Synchronizing a single bit reduces metastability risk for that bit. A safe CDC transfer for multi-bit data also guarantees coherence, capture validity, and handshake or storage semantics across the domain boundary.

---

## 12. Mental Models To Keep

If you want one compact set of ideas to carry into design reviews and debugging sessions, keep these:

- Bits are implemented with analog voltages and timing, not magic.
- Noise margin is the reason digital abstraction survives the physical world.
- Gates express Boolean relationships, but transistors and delays determine how those relationships behave physically.
- Combinational logic computes; sequential logic remembers.
- Latches are level-sensitive; flip-flops are edge-triggered.
- Timing is a contract, not an afterthought.
- Clocking strategy determines whether a design scales cleanly or becomes fragile.
- Metastability is unavoidable in principle and manageable in practice.
- Most painful digital bugs are not caused by misunderstood Boolean algebra. They are caused by bad assumptions about timing, reset, clocking, CDC, or electrical behavior.

That is what separates textbook familiarity from professional digital design understanding.