From Hardware to Chips: Exploring the Underlying Logic of Hardware Engineering

A Counterintuitive Starting Point

Hardware engineers often say that analog electronics and digital electronics are separate disciplines that should not interfere with each other.

Chip designers say that hardware belongs to the board level, while chips belong to the silicon level, so they are fundamentally different.

Software engineers may see hardware and software as entirely separate worlds.

Yet three counterintuitive conclusions emerge:

1. There is no absolute separation between analog and digital electronics.
2. There is no absolute separation between hardware and chips.
3. There is no absolute separation between hardware and software.

These are not motivational slogans. They are conclusions reached by an engineer who has worked in hardware for many years and followed the technology from fundamental physical laws to the highest application layers.

Starting with the abstraction layers of basic electronic circuits and moving upward, we can see how the hardware world is constructed—and why complex engineering ultimately relies on the same chain of fundamental technologies.

Once the layers of abstraction are peeled back, the underlying principles become surprisingly similar.

1. The Abstraction of Electronic Circuits

From Natural Phenomena to Applications

The electronic world spans 11 layers of abstraction between natural phenomena and real-world applications. These layers decompose familiar "hardware" into a sequence that begins with the physical world and ends with applications.

Viewed from the bottom upward, the layers are as follows:

Layer 1: Natural phenomena. At the lowest level is the physical world itself: how electrons move, how electric fields are distributed, and how materials conduct electricity. These properties are determined by nature, and every circuit is built on them.

Layer 2: Zeros and ones. The first major abstraction is to convert the continuous physical world into 0 and 1. A higher voltage can represent 1, while a lower voltage represents 0. This simple abstraction is the starting point of the digital world.

Layer 3: Physical laws to lumped-parameter models. Representing signals as 0 and 1 is not enough. Engineers also need to simplify complex electromagnetic behavior into models that can be calculated using lumped parameters such as resistance, capacitance, and inductance. This means engineers do not have to begin every circuit analysis with Maxwell's equations.

Layer 4: Amplifier models. The next level is the core of analog electronics: the amplifier. Operational amplifiers, filters, oscillators, power supplies, mixers, and RF circuits all process continuous signals at their core.

Layer 5: Digital circuits. The transition from analog to digital is a critical step. Combinational logic and sequential logic use zeros and ones to create circuits that can perform calculations and retain state.

Layer 6: ADCs. An analog-to-digital converter forms a bridge between analog and digital electronics. It converts continuous analog signals into discrete digital data. Sounds, temperatures, light levels, and other real-world signals can enter the digital domain only after this conversion.

Layer 7: Processors. As digital circuits become more complex, processors emerge. A processor is the "brain" of the digital world, capable of executing instructions and processing data.

Layer 8: Instruction sets. How does a processor operate? Through an instruction set. RISC, or reduced instruction set computing, and CISC, or complex instruction set computing, represent an important interface between hardware and software. Code written by a developer must eventually be translated into instructions that the processor can understand.

Layer 9: Operating systems. Above the instruction set is the operating system. μC/OS, FreeRTOS, Contiki, RTEMS, Linux, and Windows all hide hardware complexity and provide application software with a consistent interface.

Layer 10: Applications. At the highest level are the applications used every day, including mobile games, launch vehicles, and software applications.

From natural phenomena at the bottom to a game running on a smartphone, there are many layers of abstraction in between. Each layer encapsulates the complexity of the layer beneath it and exposes only a relatively simple interface.

Interfaces are therefore the key to understanding the entire hardware world.

2. Interfaces: The Common Language of Complex Systems

What Is an Interface?

An interface is an abstraction that an entity exposes to the outside world. It separates internal implementation from external communication, allowing the internal implementation to change without affecting how other entities interact with it.

In simpler terms, an interface is an agreement between two entities. As long as the agreement remains unchanged, the internal implementation can be modified without affecting the outside world.

This concept is fundamental because every complex system—software, hardware, or even human society—is constructed layer by layer through interfaces.

Software Interfaces

In software, an interface is the access method exposed to external users or programs.

• Network interfaces: A URL can be exposed so that a remote terminal can perform operations on a database.
• Local interfaces: Memory, files, or command-line interfaces can be exposed so that other programs can interact with a system.

The software world is essentially a collection of interfaces that invoke one another. Network protocols such as TCP/IP enable systems to communicate across networks, while web browsers and web standards make those services accessible to users.

Human Interfaces

The interface between humans and computers is the user interface, or UI. A mouse, keyboard, and touchscreen are all interfaces between a person and a machine.

Communication between people is also based on interfaces. When one person says "hello" and another responds with "hello," both sides are following an agreed communication protocol. As long as the protocol is understood, the participants can communicate regardless of the specific devices or internal processes involved.

Circuit Interfaces

There are many types of circuit interfaces:

Data interfaces: UART, parallel interfaces, I2C, CAN, USB, PS/2, LPC, PCI, PCIe, SATA, SAS, RapidIO, Ethernet, optical fiber, E1, T1, FXO, and FXS.

Audio interfaces: 2.5 mm and 3.5 mm interfaces.

Video interfaces: VGA, HDMI, DP, and DPI.

Wireless interfaces: RFID, Bluetooth, Wi-Fi, Zigbee, two-way radio, 433 MHz systems, LoRa, GSM, WCDMA, TD, LTE, 5G, Sigfox, and NB-IoT.

These names may appear overwhelming, but the underlying concept is the same. Each interface defines how signals are transmitted, how data is encoded, what data rate is supported, and what voltage levels are used.

When two devices implement the same interface standard, equipment from different manufacturers can communicate. That is the power of an interface.

Three Special Interfaces

Three interfaces are especially important because they connect the digital domain with the real world.

1. GPIO. A general-purpose input/output is one of the simplest interfaces. Its state is generally represented by a high or low logic level. A GPIO can control whether an LED is on or off, or detect whether a button has been pressed.

2. PWM. Pulse-width modulation uses a digital signal to approximate an analog output. By changing the ratio between the high and low portions of a waveform, a system can control motor speed, LED brightness, or servo position. In effect, a digital signal produces a continuously variable result.

3. ADC. An analog-to-digital converter is the entry point from the real world into the digital world. Temperature, voltage, sound, and light are continuous analog quantities that must be converted into digital data before a processor can handle them.

From software to hardware and from humans to machines, the logic of interfaces is the same: define an agreement, isolate implementation changes, and allow complex systems to cooperate in layers.

Interfaces are the common language of complex systems.

3. Clocks: The Heartbeat of the Digital World

If an interface is the language of the digital world, the clock is its heartbeat.

Digital circuits rely on clocks for operation. Each clock transition advances the circuit by one step. Without a clock, a synchronous digital circuit cannot operate in an orderly way.

Clock design is one of the most important and failure-prone aspects of digital design.

Global Clocks: The Most Robust Option

The simplest and most reliable clocking scheme is a global clock. The entire system uses one clock, and all flip-flops are driven by the same clock signal.

The clock is usually supplied through a dedicated input and processed by a PLL or DLL for frequency division, frequency multiplication, or phase shifting. This approach minimizes additional skew and jitter.

The preferred clocking method is to use global clocks throughout the design and, where possible, keep the logic within a single clock domain. This makes data synchronization easier to maintain.

Real systems, however, are often too complex for one clock to serve every function.

Gated Clocks: A Power-Saving Risk

A gated clock uses an enable signal to turn a clock on or off. When the clock is disabled, the associated circuitry stops operating, reducing power consumption.

Clock gating can be dangerous because it can easily generate glitches that cause unintended logic transitions. If logic gates are used to control a clock and the timing is not handled correctly, a short pulse may appear on the clock signal. A flip-flop may interpret that pulse as a valid clock edge, causing a system error.

A gated clock should be used only when strict conditions are met:

1. The clock-driving logic should contain only a single AND gate or OR gate. Adding extra logic can create race conditions and glitches in certain operating states.
2. One input of the logic gate must be the actual clock, and all other inputs must satisfy the required setup and hold timing relative to that clock.

Although these conditions sound simple, they are easy to violate in practice. Therefore, clock gating should generally be avoided when it is not necessary.

A safer alternative for power management is a synchronous circuit with an enable input. The clock continues to run, but the enable signal determines whether a flip-flop updates its data. This avoids clock glitches and improves stability, although power consumption may be higher than with true clock gating.

Derived Clocks: Attractive in Theory, Risky in Practice

A derived clock, also called a ripple clock, uses the output of one register as the clock input of another register. In other words, the output of one stage becomes the clock for the next stage.

In principle, this type of clock can be glitch-free and, if designed correctly, may appear as reliable as a global clock. The problem is that clock delay accumulates as the signal passes through multiple registers. Each stage adds a small time offset, and the accumulated offset can eventually cause setup or hold timing violations.

Once setup or hold time is violated, the design may fail.

When possible, a derived clock should be replaced with an enable signal while the main clock continues to drive the synchronous circuit. If a derived clock cannot be avoided, it must be constrained carefully. When it cannot be constrained relative to the global clock, an appropriate hold margin must be established to ensure reliable operation.

Setup and Hold Time: The "Schrodinger's Cat" of Digital Circuits

Clock design cannot be discussed without setup and hold time.

There is a small timing window around each active clock edge during which the data input must remain stable. If the data changes during this window, the value captured by the flip-flop becomes uncertain. It may be interpreted as either 0 or 1, resembling Schrodinger's cat in a superposition of states.

Setup time is the minimum time that data must remain stable before the active clock edge.

Hold time is the minimum time that data must remain stable after the active clock edge.

These two parameters are the lifeline of sequential circuits. A significant part of digital design consists of ensuring that every timing path satisfies its setup and hold requirements.

This is also why synchronous systems are generally easier to control than asynchronous systems. In a synchronous design, devices are referenced to a common clock, making their timing relationships easier to analyze and constrain.

From global clocks to gated clocks, derived clocks, setup time, and hold time, the essence of clock design is finding a balance between performance, power consumption, and reliability.

4. From Sequential Logic to Processors

Once a design has clocks and flip-flops, it can implement sequential logic.

As sequential logic becomes more sophisticated, it forms a processor. A processor is essentially a large collection of sequential and combinational logic that has been organized to execute instructions.

Instructions include addition, subtraction, multiplication, division, memory reads, memory writes, and branches. The complete set of supported instructions is called the instruction set.

RISC vs. CISC

Instruction-set design is commonly associated with two approaches: RISC and CISC.

CISC, or complex instruction set computing, uses instructions that can perform multiple operations. A single instruction may read data from memory, perform a calculation, and write the result back to memory. CISC architectures generally have larger and more complex instruction sets, and instruction lengths may vary.

x86 is a familiar example of a CISC architecture. Other examples include the CDC 6600, System/360, VAX, PDP-11, and the Motorola 68000 family.

RISC, or reduced instruction set computing, takes the opposite approach. Instructions are kept relatively simple, and each instruction performs a limited operation. Execution behavior is more regular, which simplifies implementation and can improve instruction-level parallelism and compiler efficiency.

ARM is a well-known RISC architecture used extensively in mobile systems. Other examples include DEC Alpha, ARC, AVR, MIPS, PA-RISC, Power Architecture, PowerPC, PowerXCell, and SPARC.

The debate between RISC and CISC has continued for decades. CISC was once dominant, while RISC later became highly influential. Today, ARM is particularly strong in mobile computing, while x86 remains important in desktop and server systems.

The two approaches have also borrowed ideas from each other. Modern x86 processors internally translate complex CISC instructions into simpler micro-operations that can be executed in parallel.

This reflects a broader pattern in engineering: there is rarely an absolute right or wrong approach. The important question is whether a design is suitable for its intended application.

Buses: Highways Between Processors and Peripherals

Once a processor exists, it must communicate with memory and peripherals. This communication takes place over buses.

One of the simplest bus structures is a LocalBus interface, in which address lines and data lines are separate. NOR Flash and SSRAM devices commonly use this type of interface.

More complex buses may multiplex address and data signals. This reduces pin count, but it also makes the timing relationship more complicated.

The development of peripheral interfaces generally addresses three problems:

1. Availability: First, an interface must exist and provide basic functionality.
2. Scalability: One device may not be enough, so the interface must support multiple devices.
3. Arbitration: When several devices require access to the bus at the same time, the system must determine which device gets priority.

These challenges resemble the evolution of many complex systems: first establishing basic functionality, then increasing capacity, and finally managing conflicts and order.

DDR: Signal-Integrity Challenges on High-Speed Buses

DDR, or double data rate synchronous dynamic random-access memory, is widely used in computers and mobile devices. Its design is challenging because of the high operating speed.

One important issue is that the signal and clock do not necessarily have identical spectral and timing behavior. On a high-speed bus, even a small difference in propagation delay can affect the sampling result. If the signal delay does not match the clock delay, the receiver may sample incorrect data.

DDR topologies have evolved to address this problem.

Early DDR designs used a T-branch topology. The clock and data signals left the controller and split into two branches leading to memory devices on both sides. This topology could work at lower speeds, but signal quality degraded as the data rate increased.

Later generations adopted a fly-by topology. The clock and data signals leave the controller and pass sequentially through the memory devices, similar to beads on a string. This topology significantly improves signal quality, which is why DDR3 and later standards use fly-by routing.

The transition from T-branch to fly-by may appear to be only a routing change, but it reflects the deeper challenge of high-speed signal integrity.

This is a normal part of hardware engineering: every increase in speed creates a new negotiation with the laws of physics.

5. A PCIe Debugging Case Study

PCIe, or PCI Express, is one of the most widely used high-speed buses in modern computers. Graphics cards, solid-state drives, network adapters, and many other high-speed devices connect to the CPU through PCIe.

PCIe debugging is difficult because of the high signaling speed. A PCIe 4.0 x16 link can provide a bandwidth of 64 GB/s. At such speeds, a small issue can make the link unstable or cause it to go down completely.

In this case, the CPU connected to storage devices through the platform controller hub using an x8 PCIe link, but the link repeatedly went down and the drive could not connect.

Step 1: Investigate Multiple Dimensions

When a PCIe link fails, the investigation should not focus only on the PCIe differential pairs. Several related dimensions must be checked:

• Is the power-on sequence correct?
• Is the reset sequence correct?
• Do the combined timing requirements for the clock, reset, and power rails meet the required conditions?
• Are the clock levels correct?
• Is there a problem with spread-spectrum clocking?
• Does the firmware need to be upgraded?

Hardware debugging is not a matter of treating only the most visible symptom. It requires a systematic review of the complete system.

Step 2: Clock-Matching Problems

One of the problems identified in this case was incorrect clock matching.

The PCIe requirements specified that the clock-signal crossing point should be between 250 mV and 500 mV. Measurements showed that the swing of the single-ended clock signal was insufficient and that its crossing point was too low.

The problem was traced to an unsuitable PCIe clock matching circuit recommended by the manufacturer.

Removing the matching circuit raised the crossing point to approximately 400 mV and increased the signal swing. Signal quality improved and the required conditions were met.

This illustrates why a recommended reference circuit should not be accepted without verification. Hardware engineers must evaluate the actual electrical behavior of the design rather than rely blindly on a reference design.

Step 3: The Trade-Off of Spread-Spectrum Clocking

Another finding involved spread-spectrum clocking, or SSC.

Spread-spectrum clocking slowly varies the clock frequency within a small range. Its purpose is to distribute electromagnetic energy over a wider frequency range and reduce EMI.

However, a larger spread-spectrum deviation is not always better. If it is too small, the expected EMI reduction may not be achieved. If it is too large, the resulting timing variation may violate bus timing requirements and cause data errors.

Many high-speed chips use an SSC modulation rate of approximately 0.5%, representing a balance between EMI performance and timing requirements.

In this case, disabling spread-spectrum clocking improved the situation. This shows that although SSC can reduce EMI, it can also increase timing pressure on a high-speed link.

Step 4: The Eye Diagram as a Signal-Quality Report

An eye diagram is a practical way to assess high-speed signal quality. It is created by superimposing many signal periods so that the resulting pattern resembles an eye.

A larger and clearer eye opening generally indicates better signal quality. A small or blurry opening indicates greater distortion, timing uncertainty, or noise. If the eye closes completely, the link may no longer operate reliably.

Before optimization, the PCIe eye diagram in this case had a small opening. After optimization, the eye opened significantly, indicating a substantial improvement in signal quality.

Every stable high-speed interface represents many rounds of debugging, measurement, and optimization.

6. The Underlying Unity of Engineering

After considering abstraction layers, interfaces, clocks, processors, buses, and PCIe, we can return to the three conclusions introduced at the beginning.

There Is No Absolute Separation Between Analog and Digital Electronics

Many engineers regard analog and digital electronics as completely different fields. Digital designers may find analog design mysterious, while analog designers may consider digital design overly simple.

At a deeper level, however, they are part of the same physical system.

The 0 and 1 states in digital electronics are ultimately represented by analog voltages. Signal-integrity problems in high-speed digital circuits are fundamentally analog problems. Clock jitter, signal reflection, and crosstalk all belong to the physical behavior of electrical signals.

ADCs and DACs directly connect the two domains: one side represents the continuous analog world, while the other represents discrete digital data.

Analog and digital electronics are therefore not isolated disciplines. They are two abstraction methods applied to the same physical world.

There Is No Absolute Separation Between Board-Level Hardware and Chips

Board-level hardware design and chip design may appear unrelated. One engineer operates PCB design while another writes RTL, but the underlying engineering problems are closely related.

• Both must manage clocks, including global clocks, gated clocks, and derived clocks.
• Both must manage timing, including setup time and hold time.
• Both must manage signal integrity, although one operates on a PCB and the other within silicon.
• Both must balance power consumption and performance, although the physical scale is different.

Moving from the board level to the chip level changes the abstraction layer, but the underlying principles and methodology remain connected.

There Is No Absolute Separation Between Hardware and Software

This may be the most counterintuitive conclusion. Hardware and software clearly have different implementations, but their engineering logic is highly similar.

• Interfaces: Hardware and software both rely on agreements that isolate one module from another.
• Abstraction: Hardware uses abstraction layers, while software uses layered architectures. Both approaches manage complexity.
• Timing: Hardware uses timing constraints, while software uses concurrency and synchronization controls. Both deal with time and ordering.
• Debugging: Hardware engineers use oscilloscopes and logic analyzers, while software engineers use breakpoints and logs. Both are searching for faults in a complex system.

Even optimization follows similar patterns. Designers may add caching, increase parallelism, or make trade-offs among performance, power, cost, and reliability.

Complex engineering is governed by the same common technical chain:

• Abstraction: Divide complex problems into layers so that each layer focuses on its own responsibilities.
• Interfaces: Define clear agreements so that different modules can cooperate.
• Timing: Control time and ordering so that the system operates reliably.
• Trade-offs: Find a balance among performance, power consumption, cost, and reliability.

These principles do not belong exclusively to analog electronics, digital electronics, board-level hardware, chip design, hardware, or software. They are the underlying logic of complex engineering systems.

Electronic systems may begin with natural physical phenomena and end with high-level applications, separated by many layers of abstraction. Each layer appears different, but the underlying principles remain connected.

Interfaces may take different forms in software, hardware, and human interaction, but they all define agreements and isolate internal changes. Clock systems may use global, gated, or derived clocks, but they all deal with the same fundamental dimension: time.

When the same underlying logic becomes visible across different technical fields, hardware engineering becomes more than the design of circuits or chips. It becomes a way of understanding complex systems.