Simulation-Synthesis Mismatch

In the world of digital design, every line of Hardware Description Language (HDL) code exists in two parallel universes: the abstract, rule-based world of simulation and the physical, tangible world of synthesized hardware. A successful design is one where these two universes are in perfect alignment. However, when the simulated behavior fails to predict the hardware's reality, designers face a critical and often costly problem known as a ​​simulation-synthesis mismatch​​. This discrepancy is a ghost in the machine, capable of turning a logically sound design into a non-functional piece of silicon.

This article addresses the fundamental knowledge gap that leads to such mismatches. It demystifies the distinct roles of the simulator and the synthesis tool and provides a clear guide to writing HDL code that both can interpret consistently. By mastering these principles, designers can bridge the gap between abstract code and physical reality, ensuring their circuits work as intended from the very first simulation.

In the following chapters, we will first explore the "Principles and Mechanisms" behind simulation-synthesis mismatch, uncovering the "golden rules" of assignments and the dangers of unintended memory and logical contradictions. Then, in "Applications and Interdisciplinary Connections," we will see how these rules are applied to build robust systems and how the core concepts of causality and state management extend far beyond the realm of chip design.

To understand the art and science of a digital design, we must first appreciate that every line of code we write lives a double life. It exists simultaneously in two very different worlds: the abstract world of ​​simulation​​ and the physical world of ​​synthesis​​. The journey from a brilliant idea to a working microchip is a journey between these two realms, and the path is fraught with subtle dangers. When the behavior in one world does not match the other, we have a ​​simulation-synthesis mismatch​​—a ghost in the machine that can render an otherwise perfect design utterly useless.

Imagine the ​​simulator​​ as a meticulous, rule-obsessed bureaucrat. It executes our code line by line, following the language specification with perfect, logical precision. Its world is one of discrete events and infinitesimally small time steps called ​​delta cycles​​. It knows nothing of voltage, current, or the messy physics of electrons. It only knows the rules.

The ​​synthesis tool​​, on the other hand, is a master architect and engineer. It takes our abstract code and translates it into a tangible blueprint for a physical circuit—a specific arrangement of transistors, gates, and wires. Its world is governed by the laws of physics. Signals are not just ones and zeros; they are voltages propagating through silicon with real, finite delays.

The entire practice of modern hardware design is built on the hope that the bureaucrat's prediction will match the architect's final building. A mismatch means our simulation, our only window into the circuit's behavior before we build it, has lied to us. To avoid this, we must learn to speak a language that both worlds understand, starting with the most fundamental commands of all.

In Verilog and SystemVerilog, we have two primary ways to tell a variable to take on a new value: the blocking assignment (=) and the non-blocking assignment (<=). The choice is not a matter of style; it is a declaration of intent with profound consequences.

Think of it this way:

• A ​​blocking assignment (=)​​ is like making a direct, sequential command. "Calculate this value, and assign it right now. Do not proceed to the next instruction until this one is complete." It enforces a strict order.

• A ​​non-blocking assignment (<=)​​ is like sending a text message. "Please calculate this value. At the end of the current flurry of activity, update the variable to this new value." The calculation happens now, but the final update is scheduled to occur concurrently with all other "text message" updates.

From this simple difference, two "golden rules" emerge that form the bedrock of reliable digital design:

1. ​​For Combinational Logic (logic without memory), use blocking assignments (=).​​
2. ​​For Sequential Logic (logic with memory, like flip-flops), use non-blocking assignments (<=).​​

Let's look at the first rule. Combinational logic, like a simple multiplexer, should have outputs that depend only on the current state of the inputs. In a always @(*) block meant to describe such logic, using blocking assignments (=) ensures that the flow of data within the block mimics the flow through real gates. For a simple circuit, like a 4-to-1 multiplexer, you might get away with using non-blocking assignments—the synthesis tool is often smart enough to figure out your intent. But this is like using a screwdriver as a hammer; it’s not the right tool for the job, and when the design gets more complex, it will cause problems.

So, what exactly are these problems? Let's see what happens when we ignore Rule 1 in a slightly more complex piece of logic. Suppose we want to build a circuit for the function $y = ((a \land b) \lor c)$. We can describe this using an intermediate signal, tmp:

The synthesis tool looks at this, understands the logical relationship, and builds the correct chain of gates. In the physical world, a change on input a will ripple through the AND gate, then the OR gate, and appear at output y after a tiny propagation delay.

But the simulator sees something very different. Remember, it's a meticulous bureaucrat. When input a changes, the always_comb block triggers.

1. ​​First pass (Delta Cycle 1):​​ The simulator sees tmp <= a & b;. It calculates the new value for tmp but, because this is a non-blocking assignment, it only schedules this update. For the rest of this pass, tmp still holds its old value. It then sees y <= tmp | c;. It uses the old value of tmp to calculate a new value for y, which it also schedules. At the end of this pass, the new tmp is updated, but y is still wrong.

2. ​​Second pass (Delta Cycle 2):​​ Because tmp changed value at the end of the last pass, the always_comb block is triggered again, all within the same simulation time. This time, when it evaluates y <= tmp | c;, it uses the new value of tmp. It calculates the correct final value for y and schedules the update.

The simulation eventually gets the right answer, but it takes two "computational steps" (delta cycles) to get there. It models the logic as a two-stage pipeline, while the hardware is a single, instantaneous (from a logical perspective) ripple. This transient mismatch might seem harmless, but if other parts of your design are listening to the intermediate, incorrect value of y, catastrophic failures can occur.

If we had followed the rule and used blocking assignments:

The simulator would execute the first line, immediately updating tmp. Then it would execute the second line, using the brand-new value of tmp to calculate y. The correct final result appears in a single pass. The simulation now perfectly mirrors the logical dataflow of the hardware.

Combinational logic is memoryless. For any given set of inputs, the output is always the same. This implies that we must specify what the output should be for every possible condition. What happens if we don't?

Consider a priority encoder written in VHDL. The code might have a series of if-then-elsif statements to define the output based on which input has the highest priority. But what if the code doesn't include a final else clause? What should the circuit do if none of the inputs are active?

The simulator might simply assign an X (unknown) value. But the synthesis tool can't build a circuit that produces an "unknown". It has to build something. So, it reasons: "The designer didn't tell me what to do in this case. The only safe thing to do is to hold the output at whatever its last value was."

This behavior—"hold the last value"—is the very definition of memory. Without meaning to, the designer has forced the synthesis tool to infer a ​​latch​​, a simple memory element, right in the middle of what was supposed to be memoryless combinational logic. The hardware now has state, while the designer's mental model does not. This is a severe mismatch, born from an incomplete specification. The same thing happens if a signal is read inside a process but is missing from its sensitivity list; the circuit won't know to update when that signal changes, effectively "remembering" its old state until something else triggers an update.

We've seen the danger of using the wrong assignment in combinational logic. Now, let's witness the chaos that ensues when we break Rule 2 and mix assignment types in sequential logic.

Imagine a register q with a synchronous reset. At the rising edge of a clock, if an enable en is high, q should increment. If a reset rst is high, q should be cleared to 0. A naive designer might write:

Let's say q is 10, and at a clock edge, both en and rst are high.

• ​​The Simulation World:​​ The rule-obsessed simulator follows its script.

  1. It sees q <= q + 1;. It calculates 10 + 1 = 11 and schedules an update for q to become 11 at the end of the time step.
  2. It sees q = 0;. This is a blocking assignment. It executes immediately. The variable q is now 0.
  3. The main part of the time step is over. The simulator now processes its scheduled non-blocking updates. It sees the scheduled update for q to become 11. So, it sets q to 11. The final value in the simulation is 11. The reset appears to have been ignored!

• ​​The Synthesis World:​​ The architect sees this code and must build a physical circuit. It has no concept of "scheduling updates". It sees two drivers for the same flip-flop. It interprets the immediate, blocking assignment (=) as having priority over the scheduled, non-blocking one (<=). It builds a flip-flop where the reset signal has ultimate authority. If rst is high, the input to the flip-flop will be 0, period. The final value in the hardware will be 0.

The simulation reports 11, the hardware produces 0. A complete and catastrophic mismatch. The bug would be invisible until the chip came back from the foundry. This is why the golden rules are not mere suggestions; they are pacts we make to keep the two worlds in sync.

Finally, let's look at a case so strange it pushes the very limits of what simulation can mean. What if we try to model the fundamental building block of memory, an SR latch, using combinational logic with feedback? The classic textbook circuit is two cross-coupled NAND gates. In Verilog, this might look seductively simple:

This seems perfectly analogous to the hardware schematic. But what happens in the simulator's world when we try to exit an illegal state, like when both s_n and r_n go from 0 to 1? Let's assume the outputs q and q_bar were both 1.

1. ​​Delta Cycle 1:​​ With s_n=1 and r_n=1, the simulator calculates q <= ~q_bar (which is ~1=0) and q_bar <= ~q (which is ~1=0). At the end of the cycle, (q, q_bar) becomes (0, 0).

2. ​​Delta Cycle 2:​​ The outputs have changed, so the always @(*) block runs again. Now, it calculates q <= ~q_bar (which is ~0=1) and q_bar <= ~q (which is ~0=1). At the end of the cycle, (q, q_bar) becomes (1, 1).

3. ​​Delta Cycle 3:​​ The outputs have changed again, so the block runs again. The state reverts to (0, 0).

The simulation has become trapped in an infinite loop, flipping between (1, 1) and (0, 0) with every delta cycle, all without advancing a single picosecond in simulation time. This is a ​​zero-time oscillation​​. The simulator is stuck, chasing its own tail forever.

Of course, a real physical circuit doesn't do this. In the real world, tiny, unavoidable differences in gate delays and transistor characteristics would cause one side to "win" the race, and the latch would fall into one of its two stable states ((0, 1) or (1, 0)). This uncertain but eventual resolution is called ​​metastability​​.

Here, the simulation model, in its perfect, idealized adherence to its rules, fails completely to capture the messy reality of the physical world. It produces a logical artifact that has no physical counterpart. This is the ultimate lesson: our tools are powerful, but they are models, not reality. True mastery lies not just in knowing the rules, but in understanding their limits, and in appreciating the deep and beautiful correspondence between the abstract world of code and the physical universe of the circuits we strive to create.

We have journeyed through the abstract world of the Hardware Description Language (HDL) simulation scheduler, a realm of active regions and non-blocking assignment queues. It might seem like a set of arcane rules for a digital priesthood. But nothing could be further from the truth. These rules are not arbitrary constraints; they are the very grammar we use to describe the physics of computation, to command fleets of billions of transistors to act in perfect unison. By understanding how to speak this language correctly, we graduate from merely writing code to truly designing physical reality. The distinction between a simulation that works and hardware that works—the dreaded simulation-synthesis mismatch—is bridged not by hope, but by discipline. Let us now explore where this discipline bears fruit, moving from simple logic to complex systems, and see how these principles echo in fields far beyond a silicon chip.

Much of a digital circuit's work is thoughtless and immediate. It is pure combinational logic—a cascade of gates where a change at the input ripples through to the output as fast as electricity allows. There is no memory, no waiting for a clock. Our language must capture this sense of immediate consequence. This is the world of the blocking assignment (=).

Consider the task of building a priority encoder, a fundamental circuit that, for instance, might decide which of several alarms is the most urgent. If alarm 3 rings, it takes precedence over all others; if not, we check alarm 2, and so on. We can describe this with a simple if-else chain. When we use blocking assignments, we are telling the simulator a story in a clear, sequential order: "Look at input d[3]. Is it active? If so, the output is y_3. End of story. If not, then look at d[2]." This models the exact behavior of a chain of logic gates. Using the wrong tool here, like a non-blocking assignment, would be like telling a committee to decide on a course of action, where each member makes their decision without waiting to hear the decision of the higher-priority member. The result is chaos and a machine that fails to correctly prioritize its tasks in simulation, even if the synthesis tool manages to guess our intent.

This same principle applies when we construct Finite State Machines (FSMs), the "brains" of many digital systems. A well-designed FSM separates its "thinking" from its "acting." The thinking part—deciding what state to go to next—is sequential, paced by the system clock. But the acting part—determining the machine's outputs based on its current state—is often purely combinational. For a Moore FSM, the outputs depend only on the state registers. To model this, we use a separate block of code sensitive to any change in the state. Inside this block, we use blocking assignments. This ensures that the moment the machine enters a new state, its outputs reflect that new reality instantly, just as the lights on a control panel should immediately reflect the machine's status. This clean separation of concerns is a cornerstone of robust design.

Perhaps the most intuitive application is in debugging. Imagine you are building a complex pipeline and you want a "spy-glass" to peer inside and see the value of an internal register in real-time. This debug probe must be a perfect, non-invasive window. It shouldn't have any memory or delay of its own; it must simply mirror the internal signal. We achieve this with a combinational connection. In HDL, a simple always @(*) probe_out = internal_reg; does the trick. The blocking assignment (=) creates a direct, immediate link. Any flicker in internal_reg is instantly reflected on probe_out. It is the purest form of "what you see is what you get," an indispensable tool for understanding the inner life of a complex machine.

While combinational logic is immediate, the true power of digital systems comes from synchronicity—actions orchestrated by the metronomic tick of a clock. This is where we choreograph the future. We are no longer describing what is, but what will be at the next clock edge. This is the domain of the non-blocking assignment (<=). It is our tool for conducting an orchestra of flip-flops. When we write a <= b, we are not saying a becomes b right now. We are saying, "At the moment the clock ticks, everyone look at the current state of the world. Based on that snapshot, calculate your next value. Then, all at once, update yourselves."

This allows for a beautiful and seemingly impossible feat: swapping the values of two registers without a temporary third register. The code is simply:

At the clock edge, the right-hand side of a <= b reads the old value of b, and the right-hand side of b <= a reads the old value of a. Then, simultaneously, a gets the old b and b gets the old a. The magic is in the scheduling—all plans are made based on the same moment in time, before any changes occur.

This principle scales to far more complex and powerful operations. Consider a high-performance memory controller that needs to perform a ​​read-modify-write​​ operation in a single clock cycle. This is common in processors and network routers, where we might need to increment a counter in memory. The task is to read the current value, add one to it, and write the result back to the same location, all between one clock tick and the next. A naive approach using blocking assignments would create a race condition—do you read the old value or the new one you just wrote? The simulation becomes a mess.

But with non-blocking assignments, the solution is elegant. We can write code that effectively says: "On the next clock edge, two things will happen. The memory's output port will receive the value currently at address_X. And the memory location address_X itself will receive the value of (currently at address_X + 1)." Both operations are scheduled based on the same, pristine, pre-clock-tick state of the memory. The result is that the old value is correctly read out while the new value is simultaneously written in, a perfect execution of a complex, atomic operation. This is not just a coding trick; it's a profound way to describe and build hardware that achieves maximum performance through precise temporal control.

What happens if we lose this discipline? What if, in a single clocked process, we try to mix the "now" of blocking assignments with the "next" of non-blocking assignments? We create a monster: a piece of code that behaves one way in simulation and another way in silicon. This is the very heart of simulation-synthesis mismatch.

Imagine a block of code meant to describe the behavior of a single register, p. If we update one bit of p with a blocking assignment and another bit with a non-blocking assignment, we are creating a logical contradiction. In the fantasyland of the simulator's event queue, a bizarre sequence unfolds. The blocking assignment executes immediately, changing a piece of the register. Then, a subsequent non-blocking assignment within the same block reads this newly changed value to schedule its own update for the end of the time step. The simulation produces a result, but it's based on a sequence of events that has no physical counterpart.

A synthesis tool, faced with this confusing description, will throw up its hands. It cannot build a flip-flop that is partially updated "now" and partially "later." It will likely ignore the artificial sequential dependency created in the simulation and build what it thinks you meant: a set of flip-flops that are all clocked together. The result? The physical hardware behaves completely differently from the simulation. You have a ghost in your machine, a bug that was invisible until the moment you fabricated the chip, and it was born from mixing the language of the present with the language of the future in a single, confused thought. The rule is simple and absolute: in a sequential, clocked block, use only non-blocking assignments.

This rigorous distinction between immediate and scheduled events is not just an esoteric quirk of digital design. It is a fundamental lesson in managing causality and state in any complex system.

In ​​software engineering​​, the race conditions that plague multi-threaded applications arise from the same ambiguity. When two threads access a shared variable, and at least one is a write, the outcome depends on the non-deterministic scheduling of the threads. The discipline of using mutexes, semaphores, or transactional memory is analogous to the HDL designer's discipline of using non-blocking assignments for shared state (registers) to ensure predictable, synchronous updates.

In ​​distributed systems and databases​​, ensuring consistency across multiple nodes requires a deep understanding of state changes over time. Concepts like snapshot isolation, where transactions operate on a consistent view of the database as it existed at a certain point in time, directly mirror the principle of non-blocking assignments, where all right-hand sides are evaluated on a consistent, pre-clock-tick "snapshot" of the circuit.

Even in ​​project management​​, we face similar challenges. If one team's output is another's input, a "blocking" dependency means one team must wait for the other to finish completely. A "non-blocking" approach might involve teams working in parallel based on a shared, agreed-upon specification from the project's start, with their results integrated at a later milestone. Confusing the two leads to delays and integration nightmares.

The rules of HDL are not just rules; they are a distilled wisdom for orchestrating complexity. Learning to separate the immediate from the scheduled, the combinational from the sequential, is to learn the language of dynamic systems. It teaches us to think with exacting clarity about cause and effect, about time and state. And in doing so, it allows us to build machines of staggering complexity that work with the beautiful, predictable certainty of a law of physics.