Digital Logic Design: Turn Requirements into Gates and State Machines

Digital logic design converts a behavioral requirement into a circuit that produces specified outputs. Use combinational logic when current inputs contain everything needed for the decision. Add stored state when the output must distinguish different histories, such as whether a request has already started a transaction.

Begin with input meanings and expected behavior. This tutorial develops a Boolean condition and a controller; physical voltage thresholds and PCB implementation require a separate review.

Start with a complete input-output requirement

A truth table describes the output for each allowed input combination. With three binary inputs, there are eight combinations to consider. MIT's introductory combinational-logic lecture explains this relationship between a functional specification and its truth table.

For an illustrative request-acceptance circuit, define three inputs:

request: a transaction has been requested.
ready: the processing block can accept it.
inhibit: acceptance must be blocked.

Specify accept = request AND ready AND NOT inhibit. Only input combination request=1, ready=1, inhibit=0 produces 1; the other seven produce 0. That statement completely defines the function without an eight-row table.

Test the requirement with counterexamples. If ready is 1 but request is 0, acceptance must stay 0. If request and ready are both 1 but inhibit becomes 1, acceptance must also be 0. These checks test the intended behavior, rather than merely repeating the expression.

Translate the expression into useful logic blocks

The expression maps to an inverter on inhibit followed by an AND operation. A synthesis tool may implement an equivalent network of different cells. The logical function is the contract; the particular gate arrangement is an implementation choice.

A multiplexer chooses an input; an adder combines binary quantities; a decoder translates a code into selection signals. Verify any simplified expression against every required input combination.

Do not equate an arbitrary network of gates with combinational logic. Feedback can create storage. What matters is whether the specified output depends solely on present inputs or requires retained information.

When does the circuit need state?

State is needed when identical current inputs must produce different behavior because earlier events differed. Suppose a processing request lasts only one cycle, but the processing block must remain active until completion. The request-acceptance expression alone cannot remember that work is underway.

A finite state machine, or FSM, separates a state register, next-state logic, and output logic. These are the three elements identified in AMD's Vivado FSM description. Moore outputs depend on state; Mealy outputs also depend directly on current inputs.

For this example, assume all event inputs are synchronous to one clock and stable for sampling. Use three states, a synchronous reset, and a Moore output called done.

Build and trace a three-state controller

The controller accepts start in IDLE, waits for complete in RUN, and holds DONE until acknowledge arrives. Reset takes priority over all other conditions and selects IDLE at the next active clock edge.

Present state	Condition at active edge	Next state	done in present state
Any state	reset = 1	IDLE	Determined by present state
IDLE	start = 1, reset = 0	RUN	0
RUN	complete = 1, reset = 0	DONE	0
DONE	acknowledge = 1, reset = 0	IDLE	1
IDLE / RUN / DONE	No applicable transition, reset = 0	Hold present state	0 / 0 / 1

The illustration omits hold-state arrows for clarity. In this example, reset is synchronous and done is asserted only in DONE.

Trace a concrete sequence. After a reset edge, state is IDLE and done is 0. A sampled start selects RUN. Two cycles without complete leave it in RUN. Sampling complete selects DONE, making done 1 after the state update. Acknowledge then returns it to IDLE.

Three states need at least two binary state bits. Choose recovery to IDLE for the unused encoding. This is a functional design choice, not a safety certification.

Verify the corner cases before implementation

Check events in the wrong state: complete in IDLE must not produce done, and start during RUN must not restart the transaction. If complete and acknowledge arrive together in RUN, the controller enters DONE; acknowledgement is evaluated only while already in DONE.

A start held high through completion can initiate another transaction after the controller returns to IDLE. If that is unwanted, change the interface contract or add request-edge detection. Also test reset during RUN and DONE. Because reset here is synchronous, it does not change state until the active edge.

FAQ

Are all flip-flop outputs restricted to clock-edge changes?

No. Some devices have asynchronous set or reset controls. For example, TI's SN74HC74 datasheet specifies asynchronous preset and clear. Match the circuit or RTL behavior to the intended reset contract.

Does a correct truth table prove the finished circuit will work?

It proves only the specified logical mapping when properly implemented. A complete design also needs sequential verification where applicable, timing analysis, and electrical-interface checks.

Carry the behavior into the schematic

Keep the input definitions, Boolean expressions, state transitions, and reset priority together. They provide concrete checks for simulation and help distinguish a logic error from an implementation problem.