Digital System Design Process and Engineering Decisions

Introduction

Digital logic is often introduced through gates, Boolean algebra, combinational circuits, and sequential machines. In professional practice, however, a successful digital system is not defined only by whether its logic equations are correct. It must also satisfy requirements, communicate through well-defined interfaces, operate within timing and power limits, be affordable to manufacture, remain maintainable, and continue to be supportable throughout its expected life.

Digital system design is therefore an engineering decision process. Designers translate an informal need into measurable requirements, partition the problem into modules, select an implementation technology, define interfaces, verify behavior, and evaluate trade-offs. A technically elegant design may still fail if it is too expensive, consumes excessive power, cannot be tested, or depends on components that are becoming obsolete.

This chapter presents a practical design method suitable for small and medium-scale digital systems. The method applies to FPGA projects, microcontroller-based products, programmable-logic controllers, embedded instruments, and custom digital hardware.

Learning Objectives

By the end of this chapter, you should be able to:

1. Translate stakeholder needs into measurable functional and nonfunctional requirements.
2. Partition a digital system into modules and represent it with a block diagram.
3. Specify interfaces, timing assumptions, data formats, and error behavior.
4. Develop a verification and test plan linked to requirements.
5. Evaluate performance, power, area, cost, reliability, maintainability, and lifecycle risk.
6. Compare build-versus-buy alternatives using explicit engineering criteria.
7. Make and justify design decisions in a practical digital-system project.

1. From Need to Engineering Requirements

A design begins with a problem rather than a circuit. Stakeholders may state a need such as “monitor room temperature and activate a warning when the room becomes unsafe.” This statement is useful but incomplete. It does not define the temperature range, measurement accuracy, response time, warning behavior, power source, environmental conditions, or maintenance procedure.

Requirements engineering converts needs into statements that are specific, testable, and traceable. A good requirement normally identifies:

• the required function;
• the operating conditions;
• the performance level;
• the interface or user-visible behavior;
• acceptance criteria; and
• constraints such as cost, size, safety, or regulatory compliance.

Functional and nonfunctional requirements

A functional requirement describes what the system does. For example: “The controller shall sample the temperature sensor every 1 s and activate the alarm when the measured temperature exceeds 35 °C.”

A nonfunctional requirement describes a quality or constraint. Examples include:

• response time shall not exceed 100 ms;
• supply voltage shall be 3.3 V ± 5%;
• average power shall be below 500 mW;
• the enclosure shall fit within 100 mm × 70 mm × 25 mm;
• the system shall retain configuration after power loss; and
• the design shall use components available from at least two approved suppliers.

Requirements should avoid vague terms such as “fast,” “low cost,” or “user-friendly” unless these terms are defined by measurable limits.

Requirements traceability

Traceability links each requirement to architecture, implementation, and verification evidence. A traceability matrix may contain the following fields:

Traceability prevents an important requirement from being forgotten and helps identify unnecessary features. It also supports controlled change: if a sensor is replaced, the designer can identify affected interfaces and tests.

2. Architecture and Modular Decomposition

Architecture describes the major parts of a system and the relationships among them. A modular architecture divides the design into units with clear responsibilities. Typical digital modules include:

• input conditioning or sensor interface;
• clock and reset generation;
• data acquisition;
• storage or buffering;
• processing and decision logic;
• communication interface;
• user interface or display driver;
• power management; and
• diagnostics and fault handling.

A module should have high cohesion: its internal elements should contribute to one clear responsibility. Modules should also have low coupling: changes inside one module should require minimal changes elsewhere.

Functional partitioning

A useful first step is to describe the system as a data path and a control path. The data path transports and transforms values. The control path determines when operations occur and which mode the system is in.

For example, a monitoring device may have the following data path:

Sensor → input interface → digital filter → threshold comparator → display/communication output.

Its control path may include a finite-state machine with states such as IDLE, SAMPLE, PROCESS, REPORT, and FAULT.

Figure: A modular architecture connecting inputs, interfaces, processing, outputs, and verification activities.

The block diagram is not merely an illustration. It establishes boundaries, identifies information flows, and provides a basis for assigning responsibilities to people or teams.

Architectural styles

A centralized architecture places most decision-making in one controller. It can be simple and inexpensive, but a large controller may become difficult to test and modify.

A distributed architecture assigns processing to several local modules or devices. It can improve scalability and fault isolation, but communication and synchronization become more important.

A hardware-software architecture divides functions between dedicated logic and programmable software. Dedicated logic can provide deterministic timing and parallelism; software usually provides flexibility and easier updates. The division should be based on timing, computational complexity, development skill, power, and lifecycle requirements rather than habit.

3. Interfaces and Contracts

An interface specifies how modules interact. It includes signal names, direction, width, encoding, timing, electrical levels, and error behavior. An interface is a contract: each module must know what it may assume and what it must guarantee.

For a synchronous data interface, a simple transaction may use:

• data: the value being transferred;
• valid: asserted when data is meaningful;
• ready: asserted when the receiver can accept data; and
• clock: the reference timing signal.

A transfer occurs on a clock edge when both valid and ready are asserted. This handshake prevents data loss when the receiver temporarily cannot keep up.

Interface specifications should also address:

• reset polarity and reset timing;
• idle values;
• maximum transaction rate;
• byte order and bit significance;
• signed or unsigned interpretation;
• overflow and underflow behavior;
• illegal commands; and
• timeout and retry behavior.

Timing and synchronization

Synchronous logic normally changes state on a designated clock edge. A simplified timing requirement is that data must remain stable for the setup interval before the active edge and for the hold interval after it. If a signal crosses between unrelated clock domains, direct sampling can cause metastability. Designers commonly use synchronizer flip-flops for single-bit control signals and asynchronous FIFO structures for multi-bit data streams.

The maximum clock frequency is constrained by the longest combinational path. A simplified setup relationship is:

Here, T_clock is the clock period in seconds, t_clk-to-Q is the launching flip-flop delay, t_comb is the combinational-path delay, t_setup is the receiving flip-flop setup time, and t_skew represents clock skew and related timing margin. The relationship applies to a synchronous path under the stated clocking assumptions; it is not a complete timing model for every technology.

For example, if these terms are 0.4 ns, 3.8 ns, 0.6 ns, and 0.2 ns, respectively:

T_clock ≥ 0.4 + 3.8 + 0.6 + 0.2 = 5.0 ns

Thus the theoretical frequency limit from this path is:

Actual designs normally use margin for variation, clock uncertainty, routing, and aging.

4. Design Constraints and Trade-offs

Constraints convert system goals into boundaries within which the design must operate. Important constraints include timing, power, area, cost, reliability, safety, manufacturability, environmental conditions, and availability.

Performance

Performance may mean throughput, latency, response time, clock frequency, or capacity. These are different measures. A pipeline can increase throughput while adding latency. A larger buffer can absorb bursts but consumes area and may delay fault detection.

For a stream of words, throughput can be expressed as:

where N_data is the number of successfully transferred data items and T is the measurement interval. Units may be items/s or bits/s. The formula assumes that the measurement interval and counted transfers are clearly defined.

Power

A digital system has dynamic and static power. A commonly used first-order estimate for CMOS switching power is:

where α is the activity factor, C is effective switched capacitance in farads, V is supply voltage in volts, and f is switching frequency in hertz. This estimate assumes capacitive switching dominates and does not include short-circuit, leakage, regulator, or peripheral power. It shows why reducing voltage can be especially effective, although lowering voltage may reduce speed or noise margin.

Energy per operation is:

when f_operation represents the operation rate and the average power is measured under comparable conditions. Battery systems must also consider sleep current, conversion efficiency, duty cycle, and peak current.

Area and cost

Area affects package choice, board size, thermal behavior, and manufacturing yield. Cost includes more than component price. A useful lifecycle view includes nonrecurring engineering cost, tooling, software, certification, assembly, testing, field service, and end-of-life redesign.

A simple total-cost model is:

where N is production quantity. This simplified model assumes costs are known and linear with quantity; real costs may include fixed tooling, volume discounts, scrap, warranty, and inflation.

Reliability and availability

Reliability is the probability that a system performs its required function for a specified time under stated conditions. Availability concerns the proportion of time the system is operational. Redundancy, error detection, watchdogs, safe states, and diagnostic information can improve dependability but add hardware and verification effort.

Maintainability and lifecycle

Maintainability includes the ease of diagnosing, repairing, updating, and documenting a system. Component lifecycle risk must be assessed early. A low-cost integrated circuit that is already scheduled for discontinuation may be a poor choice. Designers should examine supplier qualification, second sources, minimum order quantities, lead time, firmware support, package longevity, and last-time-buy policies.

5. Verification, Validation, and Test Planning

Verification asks, “Did we build the system according to its specification?” Validation asks, “Does the system solve the intended user problem?” Both are necessary.

A test plan should identify:

1. the requirement under test;
2. test stimuli and initial conditions;
3. equipment or simulation environment;
4. expected result;
5. pass/fail limits;
6. data to record; and
7. responsible person and test status.

Common verification methods are inspection, analysis, simulation, formal property checking, laboratory measurement, and system-level demonstration.

Testing should proceed at several levels:

• Unit test: verifies an individual module.
• Integration test: verifies interactions between modules.
• System test: evaluates complete behavior against requirements.
• Stress test: applies boundary, overload, timing, thermal, or power conditions.
• Regression test: repeats an established test set after changes.
• Acceptance test: confirms that the delivered system meets stakeholder criteria.

Boundary-value testing is particularly valuable. If an alarm must activate above 35 °C, tests should include values below 35 °C, exactly 35 °C, just above 35 °C, sensor faults, and rapid transitions. If the requirement does not specify behavior at exactly 35 °C, the specification is incomplete and must be clarified.

Assertions and self-checking testbenches can detect illegal states and protocol violations early. Measurement equipment must also be suitable: an oscilloscope with insufficient bandwidth or a power meter that averages away short current peaks may produce misleading evidence.

6. Build-versus-Buy Decisions

Build-versus-buy analysis compares developing a function internally with acquiring a component, intellectual-property block, module, or complete subsystem. The decision should not be based on purchase price alone.

Build is attractive when the function is strategically differentiating, requirements are unusual, long-term control is essential, or volume justifies development cost. Buy is attractive when the function is standardized, specialist expertise is scarce, time to market is critical, or certification evidence is already available.

A weighted decision matrix can make assumptions visible. Let w_i be the weight for criterion i, and r_i be a normalized score. A weighted score is:

The weights should satisfy ∑w_i = 1 and scores should use a defined scale, such as 1 to 5. The matrix supports discussion; it does not replace technical due diligence.

7. Illustrative Case: Environmental Monitoring Controller

Background

A university laboratory needs a small controller that monitors temperature and humidity in a storage cabinet. It must display current readings, activate an alarm for unsafe conditions, record recent measurements, and communicate status to a computer.

Problem definition

The initial stakeholder request is converted into the following illustrative requirements:

• sample both sensors once per second;
• display temperature and relative humidity;
• activate a warning when temperature exceeds 35 °C or humidity exceeds 70%;
• detect a disconnected sensor within 5 s;
• retain at least 24 h of readings at one-minute resolution;
• communicate status through a serial interface;
• operate from a regulated 5 V supply;
• consume less than 2 W average power; and
• provide a test connector for production diagnosis.

These requirements include functional behavior, timing, storage, interface, power, and maintainability considerations.

Analysis and architecture

The proposed architecture contains a sensor interface, timer, controller, memory buffer, display driver, alarm output, serial interface, and diagnostic logic. The controller is implemented as a finite-state machine. A one-second timer initiates acquisition. The sensor interface validates a response and produces a status flag. The processing module converts raw values into engineering units and compares them with thresholds.

The storage calculation illustrates how requirements affect resources. One day at one-minute resolution requires:

24 × 60 = 1,440 samples per channel. If each temperature and humidity record uses 16 bits per channel, the data storage is:

1,440 × (16 + 16) = 46,080 bits

or 5,760 bytes, excluding timestamps, headers, and error codes. Adding timestamps or redundancy increases the required capacity, so a design margin should be included.

Interface and fault behavior

The sensor interface uses a request/response handshake. If a valid response is not received within the specified interval, the interface reports a fault rather than reusing an apparently current value. During a sensor fault, the alarm enters a defined safe behavior and the display shows a diagnostic code. The serial protocol includes a message type, payload length, data, and checksum.

Verification plan

Tests include normal measurements, threshold boundaries, disconnected sensors, invalid checksums, power cycling, memory wraparound, maximum display values, serial communication errors, and operation at the power limit. A traceability matrix links each test to one or more requirements.

Outcome

The modular design allows the display to be replaced without changing sensor acquisition. The interface contract makes it possible to substitute a different humidity sensor. The test connector reduces production diagnosis time. The main engineering trade-off is between local storage capacity, timestamp detail, and component cost.

Learning points

The case demonstrates that architecture follows requirements. Storage, timing, fault behavior, and testability must be decided before detailed logic is written. It also shows why interfaces and lifecycle considerations are part of digital design rather than administrative afterthoughts.

8. Ethical, Safety, and Governance Considerations

Digital systems can influence physical safety, privacy, access, and economic decisions. Designers must identify foreseeable misuse and failure consequences. A monitoring system should not silently report stale data as current. A medical, industrial, or transportation controller requires more rigorous hazard analysis and documented verification than a classroom indicator.

Security is also an engineering concern. Unauthenticated firmware updates, exposed debug ports, predictable credentials, and unvalidated input can allow unauthorized control. Designs should apply least privilege, secure update procedures, logging, access control, and appropriate encryption where sensitive data is transmitted.

Environmental responsibility includes energy consumption, repairability, material selection, e-waste, and component sourcing. Accessibility may require readable displays, clear alarms, and alternative user interfaces. Compliance obligations vary by application and jurisdiction; engineers must consult applicable standards rather than assuming that a general-purpose prototype is suitable for safety-critical deployment.

9. Contemporary Development Practices

Modern digital design increasingly combines hardware description languages, automated synthesis, simulation, version control, continuous integration, and hardware-in-the-loop testing. Reusable intellectual-property blocks can accelerate development, but their interfaces, licenses, timing assumptions, and security properties must be reviewed.

Artificial intelligence can assist with test generation, log classification, documentation, and design-space exploration. It should not be treated as an authority on correctness. AI-generated hardware or verification code requires review, simulation, linting, formal checks where suitable, licensing assessment, and independent testing. Responsibility for the final design remains with the engineering team.

Best practices include:

• freeze and review requirements before implementation;
• define interfaces before assigning detailed modules;
• separate functional correctness from performance optimization;
• use version control and peer review;
• maintain traceability from requirement to test evidence;
• measure power and timing on realistic workloads;
• design for observable faults and diagnosability;
• assess component lifecycle at project start; and
• document assumptions, unresolved risks, and change decisions.

Chapter Summary

Digital system design is a structured process that begins with stakeholder needs and produces a verified, maintainable implementation. Requirements must be measurable and traceable. Modular architectures divide responsibilities, reduce coupling, and clarify interfaces. Timing, synchronization, data formats, reset behavior, and fault responses must be explicitly specified.

Engineering decisions require simultaneous consideration of performance, power, area, cost, reliability, maintainability, lifecycle, and time to market. Verification and validation use complementary methods, from unit simulation to system-level testing. Build-versus-buy decisions should consider strategic value, total lifecycle cost, supplier dependence, customization, and risk. The environmental-monitoring case illustrates how requirements drive architecture, storage selection, interface design, and test planning.

Key Terms

Requirement: A documented condition or capability that a system must satisfy.

Functional requirement: A statement of what a system must do.

Nonfunctional requirement: A constraint or quality attribute such as power, timing, or reliability.

Traceability: The ability to link requirements to design elements and verification evidence.

Architecture: The high-level organization of system components and their relationships.

Module: A bounded design unit with a defined responsibility and interface.

Interface: A contract specifying how modules exchange signals, data, and control.

Handshake: A protocol in which communicating parties coordinate transfer readiness.

Clock domain crossing: Transfer of signals or data between unrelated clocks.

Throughput: The rate at which useful data or operations are completed.

Latency: The time between an input event and its corresponding output or response.

Activity factor: The fraction or probability of switching used in a power estimate.

Verification: Evaluation of whether implementation satisfies its specification.

Validation: Evaluation of whether the system meets its intended purpose.

Regression test: A repeated test used to detect unintended effects of changes.

Maintainability: Ease of diagnosing, repairing, modifying, or updating a system.

Lifecycle risk: Risk arising from component availability, support, obsolescence, or suppliers.

Build-versus-buy: A structured decision between internal development and external acquisition.

Weighted decision matrix: A comparison method using criterion weights and normalized scores.

Review Questions

Short Answer Questions

1. Why should requirements be measurable and testable?
2. Distinguish functional requirements from nonfunctional requirements.
3. What information should an interface specification contain?
4. Why is traceability useful during design changes?
5. Distinguish verification from validation.

Long Answer Questions

1. Explain how a digital system can be partitioned into data-path and control-path modules.
2. Discuss the principal trade-offs among performance, power, area, and cost.
3. Explain why clock-domain crossings require special design techniques.
4. Describe a complete test strategy for a modular digital controller.
5. Compare the advantages and risks of building a subsystem internally with buying it from a supplier.

Analytical / Application Questions

1. Design a block-level architecture for a digital access-control system. Identify at least six modules and define the principal interfaces between them.
2. A synchronous path has t_clk-to-Q=0.5 ns, t_comb=4.2 ns, t_setup=0.7 ns, and t_skew=0.1 ns. Calculate the minimum clock period and corresponding maximum frequency before adding design margin.
3. For a battery-powered sensor, propose a decision matrix comparing a microcontroller solution with an FPGA solution. Select at least five criteria, assign defensible weights, and explain the assumptions behind your preferred choice.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a nonfunctional requirement?

A. The controller shall sample the sensor once per second.

B. The alarm shall activate when the threshold is exceeded.

C. The system shall consume less than 500 mW.

D. The display shall show the measured temperature.

Correct Answer: C. The system shall consume less than 500 mW.

Question 2

In a valid-ready handshake, when does a data transfer normally occur?

A. Whenever valid is asserted, regardless of ready.

B. Whenever ready is asserted, regardless of valid.

C. On a clock edge when both valid and ready are asserted.

D. Only when both signals are deasserted.

Correct Answer: C. On a clock edge when both valid and ready are asserted.

Question 3

Which design property generally reduces the effect of changes inside one module on other modules?

A. High coupling

B. Low coupling

C. Higher clock frequency

D. More undocumented signals

Correct Answer: B. Low coupling

Question 4

A synchronous path has delays of 0.5 ns, 3.0 ns, 0.4 ns, and 0.1 ns for clock-to-Q, combinational logic, setup, and skew. What minimum clock period is indicated by the simplified timing relationship?

A. 3.0 ns

B. 3.5 ns

C. 4.0 ns

D. 4.5 ns

Correct Answer: C. 4.0 ns

Question 5

In the estimate P_dynamic ≈ αCV²f, which change has the strongest direct quadratic effect on estimated dynamic power?

A. Reducing voltage

B. Reducing activity factor

C. Reducing capacitance

D. Reducing frequency

Correct Answer: A. Reducing voltage

Question 6

What is the primary purpose of a requirements traceability matrix?

A. To replace all laboratory testing

B. To link requirements to design elements and verification evidence

C. To calculate transistor dimensions

D. To select a programming language

Correct Answer: B. To link requirements to design elements and verification evidence

Question 7

Which situation most strongly favors buying an external subsystem?

A. The function is the product's unique competitive feature.

B. The requirements are highly unusual and frequently changing.

C. A certified standard subsystem is available and time to market is critical.

D. The organization must retain complete implementation control.

Correct Answer: C. A certified standard subsystem is available and time to market is critical.

Question 8

Which test is specifically intended to detect unintended effects after a design modification?

A. Regression test

B. Acceptance test

C. Inspection only

D. Initial requirements interview

Correct Answer: A. Regression test

Question 9

A system records 1,440 samples, with 32 bits per sample. How many bytes are required before adding metadata?

A. 1,440 bytes

B. 2,880 bytes

C. 5,760 bytes

D. 46,080 bytes

Correct Answer: C. 5,760 bytes

Question 10

Why is a component scheduled for discontinuation a lifecycle concern?

A. It necessarily has excessive clock skew.

B. Future procurement, maintenance, and redesign may become difficult.

C. It cannot be verified using simulation.

D. It always consumes more dynamic power than newer components.

Correct Answer: B. Future procurement, maintenance, and redesign may become difficult.