Name: Maven Silicon
Brand: Maven Silicon
Rating: 4.7 (1481 reviews)

<h3><img class="alignnone size-medium wp-image-18556" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/Blog-Banners-Rectangle-3-1024x576.png" alt="" width="1024" height="576" />Introduction</h3>
In the world of modern SoC design, the race is no longer just about functionality-it’s about achieving the best possible balance of Power, Performance, and Area (PPA). What makes the challenge interesting is that these three metrics constantly conflict with each other. Improving performance may require deeper pipelines, which increases area; reducing power consumption could mean slower operations; optimising area might compromise throughput.PPA optimization is often associated with synthesis and physical design.
This blog presents a practical, engineer-friendly overview of how micro-architectural decisions, RTL coding style, and design awareness directly influence PPA outcomes. Each section is structured to guide both new and experienced designers toward writing smarter, more efficient RTL.
<h3>Understanding PPA at the RTL Stage</h3>
PPA begins long before the design hits the synthesis tool. RTL is the foundation upon which the entire backend flow depends. Poor structuring here can create timing violations, excessive area usage, or unnecessary power leakage later.

Power
Dynamic power dominates switching activities. The more signals toggled, the more energy the chip burns. Clock networks, wide data paths, and large buffers are the biggest contributors.
Example - Reducing unnecessary toggling with operand isolation:
<img class="wp-image-18526 alignnone" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/1-blog.png" alt="" width="162" height="100" />
Here, the adder only toggles when enable is high, reducing dynamic power.

Performance
This reflects how quickly a design completes its tasks. Factors such as pipeline depth, parallelism, and critical path length directly determine achievable frequency.
Example - Pipelining to improve frequency:
<img class="alignnone wp-image-18525" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/2-blog.png" alt="" width="154" height="97" />
Breaking a long combinational path into pipeline stages helps meet higher clock frequency targets.

Area
Gate count, flip-flop usage, mux complexity, buffer sizes, and replicated logic all contribute. A smarter RTL design can often reduce area without sacrificing functionality.
Example - Resource sharing to save area:
<img class="alignnone wp-image-18524" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/3-blog.png" alt="" width="168" height="225" />
A single adder is shared via a multiplexer rather than two separate adders.
Balancing these three is at the heart of RTL microarchitecture.
<h3>Microarchitecture Choices That Shape PPA</h3>
Pipeline Depth and Timing Budget
Deeper pipelines help a design meet tough frequency targets, but they also increase the number of flip-flops - and with that, power and area. Finding the correct number of stages involves identifying real bottlenecks instead of inserting registers everywhere.
A well-balanced pipeline can rescue timing issues without unnecessary overhead.
Balanced pipeline example:
<img class="alignnone wp-image-18523" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/4-blog.png" alt="" width="189" height="156" />
Only critical paths are pipelined, not every internal signal.

Clock Gating: The Cornerstone of Power Optimization
Clock gating ensures that only active logic receives clock edges. Gating large blocks (instead of sprinkling tiny gates everywhere) provides the best results.
Good practices include:
<ul>
 	<li>Using simple enable conditions</li>
 	<li>Grouping logic to maximize fan-out of gated clocks</li>
 	<li>Avoiding glitch combinational gating signals</li>
</ul>
Effective clock gating can drastically reduce dynamic power.
Example - Simple clock gating structure:
<img class="alignnone wp-image-18528" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/unnamed-19.png" alt="" width="169" height="121" />
Note: In real flows, integrated clock-gating cells (ICGs) are used instead of AND gates.

Register vs. Logic Complexity
Designers are often tempted to “fix timing” by inserting a register. But every register adds area and consumes power through the clock tree. Sometimes, reducing combinational depth-such as breaking a large multiplexer (mux) into smaller hierarchical structures, achieves the same timing improvement with less overhead.
Example - Hierarchical MUX for better timing:
<img class="alignnone wp-image-18529" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/unnamed-20.png" alt="" width="206" height="67" />
This is better than a flat 4:1 mux.

FIFO Depth and Width Optimization
FIFO memory consumes a significant area. Over-provisioning wastes silicon; under-provisioning hurts performance. The right approach is to size FIFOs based on:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Latency requirements</li>
 	<li style="font-weight: 400;" aria-level="1">Expected traffic volume</li>
 	<li style="font-weight: 400;" aria-level="1">Burst behaviour</li>
</ul>
Avoid using arbitrarily large "safe depth" values.
Parameterised FIFO example:
<img class="alignnone wp-image-18530" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/unnamed-21.png" alt="" width="216" height="50" />


Adjusting DEPTH directly controls area usage.
<h3>RTL Coding Styles That Improve PPA</h3>
Good coding style isn’t just about neatness-it directly impacts synthesis quality.

Modular Always Blocks
Breaking big logic blocks into smaller, function-based always blocks helps synthesis identify gating opportunities and reduce fan-out.

Prefer case Over Nested if-else.
If-else chains create priority encoders that are deep and slow.
Case statements produce balanced logic and lead to much cleaner timing.
Example:
<img class="alignnone wp-image-18531" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/unnamed-22.png" alt="" width="129" height="118" />
Use Enumerated FSM States
Enumerated states give synthesis freedom to choose binary, grey, or one-hot encoding depending on the optimal PPA strategy.
Example:
<img class="alignnone wp-image-18532" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/unnamed-23.png" alt="" width="376" height="47" />
Thoughtful Parameterization
Parameters make designs flexible, but uncontrolled parameter growth can generate massive, unused logic. Use generate-if blocks to include only what’s needed.
<h3>Micro-architectural Strategies for Different PPA Goals</h3>
For Higher Performance
<ul>
 	<li style="font-weight: 400;" aria-level="1">Wider data paths</li>
 	<li style="font-weight: 400;" aria-level="1">Parallel computation units</li>
 	<li style="font-weight: 400;" aria-level="1">Deeper (but balanced) pipelines</li>
 	<li style="font-weight: 400;" aria-level="1">Multi-bank or multi-port memories</li>
</ul>
These provide throughput but increase power and area.
Example:
<img class="alignnone wp-image-18533" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/unnamed-24.png" alt="" width="146" height="65" />
Parallel computation improves throughput but increases area.

For Smaller Area
<ul>
 	<li style="font-weight: 400;" aria-level="1">Sharing computation resources</li>
 	<li style="font-weight: 400;" aria-level="1">Using multi-cycle functionality</li>
 	<li style="font-weight: 400;" aria-level="1">Reducing precision where acceptable</li>
 	<li style="font-weight: 400;" aria-level="1">Minimizing FIFO sizes</li>
</ul>
Area-efficient designs often trade latency for size.
Example:
<img class="alignnone wp-image-18534" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/unnamed-25.png" alt="" width="239" height="139" />
Reuse one ALU for multiple operations.

For Lower Power
<ul>
 	<li style="font-weight: 400;" aria-level="1">Operand isolation</li>
 	<li style="font-weight: 400;" aria-level="1">Fine-grained clock gating</li>
 	<li style="font-weight: 400;" aria-level="1">Sleep states for idle FSMs</li>
 	<li style="font-weight: 400;" aria-level="1">Multi-cycle slower paths for low-power modes</li>
 	<li style="font-weight: 400;" aria-level="1">Grey-coded counters to reduce switching</li>
</ul>
Power optimization requires awareness of activity patterns across the design.
Example: Grey-coded counter (reduces switching):
<img class="alignnone wp-image-18535" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/unnamed-26.png" alt="" width="185" height="31" />
<h3>Designing for Multiple Modes</h3>
Modern SoCs operate in many modes-turbo, high-performance, low-power, eco, etc. RTL should support dynamic mode switching using features like:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Variable pipeline latency</li>
 	<li style="font-weight: 400;" aria-level="1">Scalable throttling on buses</li>
 	<li style="font-weight: 400;" aria-level="1">Reconfigurable multipliers</li>
 	<li style="font-weight: 400;" aria-level="1">Flexible clock gating levels</li>
</ul>
A single design serving multiple modes saves area and silicon cost while allowing high performance when needed.
<h3>Common RTL Anti-Patterns That Hurt PPA</h3>
Avoid the following whenever possible:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Deeply nested mux trees</li>
 	<li style="font-weight: 400;" aria-level="1">Large cascaded priority logic</li>
 	<li style="font-weight: 400;" aria-level="1">Blind use of 1-hot FSM encoding</li>
 	<li style="font-weight: 400;" aria-level="1">Over-use of registers for “clean code”</li>
 	<li style="font-weight: 400;" aria-level="1">Too many tiny FIFOs</li>
 	<li style="font-weight: 400;" aria-level="1">Fully combinational giant datapaths</li>
 	<li style="font-weight: 400;" aria-level="1">Copy-paste logic instead of resource sharing</li>
</ul>
Recognising these early prevents expensive redesigns.
Example:
<img class="alignnone wp-image-18536" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/Screenshot-2025-12-06-110159.png" alt="" width="270" height="179" />

<h3>A Practical PPA Checklist for RTL Engineers</h3>
Power Checks
<ul>
 	<li style="font-weight: 400;" aria-level="1">Are idle parts toggling unnecessarily?</li>
 	<li style="font-weight: 400;" aria-level="1">Can any logic be clock-gated?</li>
 	<li style="font-weight: 400;" aria-level="1">Are wide buses switching every cycle?</li>
</ul>
Performance Checks
<ul>
 	<li style="font-weight: 400;" aria-level="1">Is the critical path predictable?</li>
 	<li style="font-weight: 400;" aria-level="1">Are pipeline stages balanced?</li>
 	<li style="font-weight: 400;" aria-level="1">Any unwanted combinational feedback loops?</li>
</ul>
Area Checks
<ul>
 	<li style="font-weight: 400;" aria-level="1">Is any logic duplicated?</li>
 	<li style="font-weight: 400;" aria-level="1">Are buffer/FIFO sizes justified?</li>
 	<li style="font-weight: 400;" aria-level="1">Are muxes minimised and well-structured?</li>
</ul>
A quick review using this checklist during development helps avoid surprises in synthesis and STA.
<h3>Conclusion</h3>
PPA is not something to “optimise later”-it begins the moment the RTL is written. The most successful RTL designers are those who think about PPA implications while planning architecture, coding modules, and reviewing design decisions.
Better pipelines, smarter gating, careful resource sharing, and mindful coding styles transform ordinary RTL into silicon-friendly, efficient hardware. When performance, area, and power are balanced intelligently, the design becomes not only functional but competitive.

Designing for Power, Performance, Area (PPA) Trade-offs at RTL Level

<img class="alignnone size-medium wp-image-18557" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/Blog-Banners-Rectangle-4-1024x576.png" alt="" width="1024" height="576" />When you first learn Verilog, you quickly get comfortable with parameter. It’s the go-to feature for defining things like bus widths, counter limits, or any constant that makes your RTL more reusable.

But if you ever peeked inside a standard cell model (say, a flip-flop or a simple gate from a library), you might have noticed something different: instead of just parameter, there’s this odd keyword called specparam.

So what’s the deal with specparam? Why do we need a separate keyword when we already have parameter? Let’s dig in.
<h3>What exactly is specparam?</h3>
specparam is simply a special type of parameter used inside a specify block. Its job is to hold timing numbers: path delays, setup/hold times, clk-to-q delays, etc and unlike parameter, you cannot override it from outside the module.
<h3>parameter vs specparam — the real difference</h3>
parameter is part of your design logic. You can override it when instantiating modules, which makes designs configurable. Parameters are synthesizable.

specparam is tied to timing. It can’t be changed from outside, because you don’t want random instances of a flip-flop having arbitrary setup/hold times. It is meant for timing simulation, not hardware synthesis.
<h3>An example of D Flip Flop</h3>
<img class=" wp-image-18520 aligncenter" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/unnamed-18.png" alt="" width="422" height="168" />The functional part is just the always @(posedge clk) block.
The timing part uses specparam to describe setup time, hold time and clk-to-q delay.

(q:+d) means Q follows D with the specified delay.

So what does the line (posedge clk =&gt; (q:+d)) = t_clkq; mean?
<ul>
 	<li style="font-weight: 400;" aria-level="1">On a posedge of clk,</li>
 	<li style="font-weight: 400;" aria-level="1">Q will take the value of D (positive unate),</li>
 	<li style="font-weight: 400;" aria-level="1">after a delay of t_clkq. </li>
</ul>
<h3>Is it needed?</h3>
Yes — if you want timing-accurate simulation.
Without it: your flip-flop model will change Q instantly on the posedge of clk (zero delay). That’s fine for pure RTL simulation, but inaccurate for gate-level simulation.
With it: the simulator accounts for the real clk→q delay, which is critical when checking setup/hold timing in back-annotated simulations.
<h3>Closing Thoughts</h3>
<ul>
 	<li style="font-weight: 400;" aria-level="1">So the next time you bump into specparam, remember: it’s not the same as that as a parameter. It’s there to keep timing constraints separate from logic design.</li>
 	<li style="font-weight: 400;" aria-level="1">Use parameter when you’re building reusable RTL.</li>
 	<li style="font-weight: 400;" aria-level="1">Use specparam when you’re describing timing inside library models.</li>
</ul>
&nbsp;

A Practical Look at specparam in Verilog

<h2><img class="aligncenter size-medium wp-image-17925" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/05/RTL-Design-Explained-Like-Online-Delivery-2-min-1024x576.png" alt="rtl design like online delivery" width="1024" height="576" /></h2>
<h2>Introduction: What Is RTL Design in VLSI?</h2>
If you’re starting your journey in VLSI (Very Large Scale Integration) design, one of the core concepts you’ll learn is RTL design. Though it sounds highly technical, you can understand RTL easily when you compare it to something you already use every day, like tracking your online orders.

In this blog, we’ll explain RTL design step-by-step by drawing parallels with the modern product delivery system. By the end, you’ll see how data flows inside a chip just as packages move through a delivery network — quickly, efficiently, and with precise logic.
<h2>What Is RTL (Register Transfer Level) Design?</h2>
RTL is a method for describing how digital circuits behave at a logical level. It focuses on:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Registers: Temporary storage locations for data.</li>
 	<li style="font-weight: 400;" aria-level="1">Transfer: The movement of data between registers.</li>
 	<li style="font-weight: 400;" aria-level="1">Logic: Operations performed on data during its movement.</li>
</ul>
RTL is typically written using hardware description languages like Verilog or VHDL - languages that convert design intent into real hardware.
<h2>Package Delivery Steps vs. RTL Design</h2>
Let’s look at a typical online order and delivery process and map it to RTL design stages.
<table>
<tbody>
<tr>
<td>
<h6>Package Delivery Process Step</h6>
</td>
<td>
<h6>RTL Design Step</h6>
</td>
<td>
<h6>What It Means (Simple Explanation)</h6>
</td>
</tr>
<tr>
<td>1. You place an online order</td>
<td>Input signal is received</td>
<td>The chip gets a command or signal to begin a task</td>
</tr>
<tr>
<td>2. Product is picked from the warehouse</td>
<td>Data fetched from a register</td>
<td>A value is read from stored memory</td>
</tr>
<tr>
<td>3. Item is packed and labeled for delivery</td>
<td>Data processed using logic</td>
<td>The data is modified or computed (e.g., added, compared, etc.)</td>
</tr>
<tr>
<td>4. Package moves to a regional distribution hub</td>
<td>Data transferred to another register</td>
<td>The processed data is stored for the next step</td>
</tr>
<tr>
<td>5. Delivery center decides final destination</td>
<td>Control logic determines next path</td>
<td>Logic determines where the data goes next</td>
</tr>
<tr>
<td>6. Package delivered to your doorstep</td>
<td>Final output stored or sent out</td>
<td>The result is ready and sent to its final destination</td>
</tr>
</tbody>
</table>
<h2>Why Use This Analogy?</h2>
<ul>
 	<li style="font-weight: 400;" aria-level="1"> Familiarity: Everyone has tracked an order online — it’s something we all understand.</li>
 	<li style="font-weight: 400;" aria-level="1"> Visualization: Helps you imagine how data flows through a chip like a package through delivery checkpoints.</li>
 	<li style="font-weight: 400;" aria-level="1"> Simplifies Coding: Makes RTL code easier to grasp, especially when starting out.</li>
 	<li style="font-weight: 400;" aria-level="1"> Great for Beginners: Connects abstract chip logic with real-world examples you see every day.
</li>
</ul>
<h2>Where Does RTL Fit in the VLSI Design Process?</h2>
Understanding where RTL design comes into play in the <a href="https://www.maven-silicon.com/blog/essential-verilog-coding-guidelines-for-writing-robust-rtl/">VLSI workflow is key:</a>
<ol>
 	<li style="font-weight: 400;" aria-level="1">Specification – What the chip must do</li>
 	<li style="font-weight: 400;" aria-level="1">RTL Design – Writing code that describes the chip’s behavior</li>
 	<li style="font-weight: 400;" aria-level="1">Verification – Ensuring the RTL works as intended</li>
 	<li style="font-weight: 400;" aria-level="1">Synthesis – Converting RTL into gate-level logic</li>
 	<li style="font-weight: 400;" aria-level="1">Physical Design – Defining the physical layout of the chip</li>
 	<li style="font-weight: 400;" aria-level="1">Fabrication &amp; Testing – Building and validating the chip
</li>
</ol>
<h2>Conclusion</h2>
RTL design might seem tough at first, but when you think of data like a package and registers like delivery hubs, everything starts to make sense. Every data bit follows a clear path, guided by logic, just like your online orders moving through a delivery system.
<h2>Does learning VLSI feel difficult?</h2>
<a href="https://l.linklyhq.com/l/27dcN">Maven Silicon is here to help you learn easily</a>. With real-world analogies, hands-on labs, and expert mentorship, we simplify even the most advanced VLSI concepts for beginners like you.

RTL Design Explained Like Online Delivery

<img class="aligncenter size-medium wp-image-17932" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/05/4-1-min-1024x576.png" alt="verilog" width="1024" height="576" />Verilog is a powerful hardware description language, but it comes with its own set of quirks, especially when it comes to simulation vs. synthesis. Writing correct and reliable RTL (Register Transfer Level) code isn’t just about getting your design to "work", it’s about making sure it behaves consistently across tools. That's where coding guidelines come in.

In this blog post, we’ll go through 6 essential Verilog coding guidelines that help avoid common mistakes like race conditions, unintended latches, and simulation-synthesis mismatches. These aren’t just arbitrary rules—they're based on years of real-world design experience and are widely followed in both academia and industry.

By following these guidelines, Verilog RTL will be:
<ul>
 	<li style="font-weight: 400;" aria-level="1">More predictable in simulation,</li>
 	<li style="font-weight: 400;" aria-level="1">More synthesizable for real hardware,</li>
 	<li style="font-weight: 400;" aria-level="1">And easier to maintain and debug.</li>
</ul>
<h2>Guideline 1: When modelling combinational logic with an always block, use blocking assignments</h2>
The blocking assignment operator is an equal sign ("="). <a href="https://www.maven-silicon.com/blog/what-is-systemverilog-used-for/">A blocking assignment</a> gets its name because a blocking assignment must evaluate the RHS arguments and complete the assignment without interruption from any other Verilog statement. The assignment is said to "block" other assignments until the current assignment has been completed.Execution of blocking assignments can be viewed as a one-step process that is evaluating the RHS (right-hand side equation) and update the LHS (left-hand side expression) of the blocking assignment without interruption from any other Verilog statement. A blocking assignment "blocks" trailing assignments in the same always block from occurring until after the current assignment has been completed. 

<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXcs7GeCTNUGMZvtlyumeZrrdwB1gOiava7tubWyhn89uaY9-vX8LetZgYifXbBLzbWghi4ZQcLfGqnMyUVQ0Qmn6pq_jwvNmoo_u9grNvQq6dVIcJC_YlVZ0GYZGbXKMu7lEYcXHm8hfPnSWYSC0w=w1366-h599?key=kpavi2j053PwRoEvWlegqg&amp;auditContext=forDisplay" alt="Displaying " />  
<h4>Bad combinational logic coding style using non-blocking assignments </h4>
If only a single assignment is made in the always block, using either blocking or nonblocking assignments will work, but in the interest of developing good coding habits, one should always use blocking assignments to code combinational logic. For coding simple combinational always blocks this would work, but if multiple assignments are included in the always block, 

such as in the one in the above example, using nonblocking assignments with no delays will either simulate incorrectly, or require additional sensitivity list entries and multiple passes through the always block to simulate correctly. The code shown in example  builds the y-output from three sequentially executed statements. Since nonblocking assignments evaluate the RHS expressions before updating the LHS variables, the values of tmp1 and tmp2 were the original values of these two variables upon entry to this always block and not the values that will be updated at the end of the simulation time step. The y-output will reflect the old values of tmp1 and tmp2, not the values calculated in the current pass of the always block. 
<h4><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXedmlbWPxqaKZluJdtqzjN9Ooi5ucpb72_FErxCauJz0urG3dBoFz69paJQhU2VvH8kdRwisbZiBoW6JDzkNBgcCaIhfv4bxFOL484trK7tBzv-8a2iy6sLmlQoGOsPLDAvTIcc8Sf2p3Wo7n8eFHA=w1366-h599?key=kpavi2j053PwRoEvWlegqg" alt="Displaying " />
Inefficient multi-pass combinational logic coding style with nonblocking assignments </h4>
In the above example  tmp1 and tmp2 have been added to the sensitivity list. As described  when the nonblocking assignments update the LHS variables in the nonblocking assign update events queue, the always block will self-trigger and update the y-outputs with the newly calculated tmp1 and tmp2 values. The y-output value will now be correct after taking two passes through the always block. Multiple passes through an always block equates to degraded simulation performance and should be avoided if a reasonable alternative exists. 

<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfItfikQmC8ERBRwLwn57ut3uQqhZcmOxYYyDm70tZdl6KvWya1tGg_KJWCeE8SZ1dhooOYDRnnT9-zah6bsHhLKEZ-rqbM6iXXQ3rDKIKn5HCXgyxQAosU_XwbYji2SxfQ-tdwbUBk4dSKWVoYojM=w1366-h599?key=kpavi2j053PwRoEvWlegqg" alt="Displaying " />
<h4> Efficient combinational logic coding style using blocking assignments </h4>
<h2>Guideline 2: When modeling sequential logic with an always block, use Non-blocking assignments</h2>
<h2><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXcpB5nCB3XltOYm-LZJin_m55AC4oH4RB5U3Ubtm1JvbP1GRNManL72kNqLPYiHgiaw_kSkCHmbdPYjLvFgYOTBZeUrx7e0TLnrNz4lo128X9TAdmHKY28TDk32wq4INeEcFj3zXq_OAgnF4n_Ttw=w1366-h599?key=kpavi2j053PwRoEvWlegqg" alt="Displaying " /></h2>
In the above code-segment, at the positive edge of clk, both the always blocks get triggered. So, b is being written into (through the first always block), while it is being read also (through the second always block).

 Assume that the first always block gets triggered before the second one. b gets updated. Then, the second always block gets triggered. ‘a’ sees the updated value of b. Thus, in effect, the value of c percolates all the way to a through b.

 Consider another scenario. The second always block gets triggered before the first one. In this case, a sees the old value of b, and, then, b gets updated. So, depending on the sequence chosen by the simulator, the value of ‘a’ could be either c (i.e. the new value of b) or the old value of b.

<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXe9YrNNS8GFe0rR7-gqoiGt1zGT2TzdYxXZBpPK3cuxXxgcLcWTiyDWTMiwKHXYbb8miumr7wFuV_y5Q6Q1KTOVSU6dFOyZztJhVc8ZVxnU06sKbR79HoQv4pcVf0H9JcDylXeD47IkZsFLtHWwqrU=w1366-h599?key=kpavi2j053PwRoEvWlegqg" alt="Displaying " />

The solution to deal with this kind of ambiguity is also very simple. For a sequential element, we should use a Non-Blocking Assignment (NBA). With an NBA, the Right-Hand-Side is read immediately, but the updating of the Left-Hand-Side happens after all the reads scheduled for the current time have already taken place

So, irrespective of what sequence is used for triggering the blocks, the events will occur in the following sequence:

(i) b and a will decide what values they should go to, but they will not actually get updated. The relative sequence of the two always blocks is still undeterminable, but that does not make any difference.

(ii) Subsequently, b and a will get updated. This updating happens after all read of Right-Hand-Side have already taken place. Since ‘a’ has already decided what value to go to (in the first step itself), so any change in value of b is not going to impact the value of a.
<h2>Guideline 3: When modeling both sequential and combinational logic within the same always block, use nonblocking assignments. </h2>
It is sometimes convenient to group simple combinational equations with sequential logic equations. When combining combinational and sequential code into a single always block, code the always block as a sequential always block with nonblocking assignments as shown in the below example.
<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfU22LtZ_aYePx_8sGTuECltq1ltnLXQxgWnrs70uWwg8FSaBSXt0aYLFY-BHJNz8aybTmc90CbJMQGlSzObWsQG4ohtvV0IKUBL5yx14s6xNN0QlpgQIkl1FpBOuKm7ifgXyzsmUOY-jaXhXdagKY=w1366-h599?key=kpavi2j053PwRoEvWlegqg" alt="Displaying " />

The same  could also be implemented as two separate always blocks, one with purely combinational logic coded with blocking assignments and one with purely sequential logic coded with nonblocking assignments, as shown in the below example

<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXf3uOmdt-8ljXq0PqRc971ElwEjOVuEF58LXXQjIXHrrLBcZrBWKjejXeTvfSsQEf39VqoB7Rlw4apnoNJqdXXFwUG8Zl3tIUiDn0Wb4thCYLCM75Attld-2C2dkozDpFk6sU66VZK1FVYNAHtwiTY=w1366-h599?key=kpavi2j053PwRoEvWlegqg" alt="Displaying " />
<h2>Guideline 4: Do not mix blocking and nonblocking assignments in the same always block.</h2>
<h2><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdklIZOC3HCET7Rf-Yqih7SpLcwh692CCTqVVvF1or-Wd63fwgWF0DUEe61XK71-fxxiQmTA3wXmSk2vFm1iKHJN-ZLGfH7jC91di1R-ty1-1oqjZKgRy1GG3Xu-m8BsI99nFM7ICJwL5L1iyDN17E=w1366-h599?key=kpavi2j053PwRoEvWlegqg" alt="Displaying " /></h2>
Verilog permits blocking and nonblocking assignments to be freely mixed inside  an always block. In general, mixing blocking and nonblocking assignments in the same always block is a poor coding style, even if Verilog permits it.

The above example simulates correctly, but Synopsys tools will report a syntax error because the blocking assignment is made inside a inferred a sequential block.
<h2>Guideline 5: Do not make assignments to the same variable from more than one always block. </h2>
Making multiple assignments to the same variable from more than one always block is a Verilog race condition, even when using blocking and nonblocking assignments.Write-Write race occurs when multiple values are being written into a signal at the same time.

<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXeEhJ8CgQmKDE1tPEmL3nLWI6XHvqppAuiddV00Q6VFqj0xFyi_XamfYRmYViq-M--qsqba-BkSUKRfgKOJN0-EDSs0JNgB0bvcKPfkzDbXAdEzpDiv8bJAtrNsU64fivyvq6PWBuW6Og_x3qSL1Q=w1366-h599?key=kpavi2j053PwRoEvWlegqg" alt="Displaying " />

When b changes, both the always blocks get triggered. It is possible that in one of the always blocks, err_flag is supposed to take the value of 1, while, in the other, it’s supposed to take the value of 0. The value that err_flag finally takes will depend on the sequence in which these always blocks get triggered. The one that triggers later – will determine the final value.The race is being created because of the assignments in the two always blocks being made to

the same signal.

The simplest solution to this ambiguity is to avoid updating a signal in more than one concurrent block. A signal should be updated in only one concurrent statement.
<h2>Guideline 6: Use $strobe to display values that have been assigned using nonblocking assignments. </h2>
<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdDjH9MSlM4AD42Afz-yl9z0tXPCb9ci2RpstpwKV-3EIR7LAAorUhzFFpBOfK3V8_I76MlZRoy3c8dtyGSD42216fgw5VGI0wRxHcA-DnqWGpzaDRa6-Bl7fCv33Mds73KIDHGqcSwDOuXEwulQTY=w1366-h599?key=kpavi2j053PwRoEvWlegqg" alt="Displaying " />

Nonblocking assignments are updated after all $display commands. The below output from the above simulation shows that the $display command was executed in the active events queue, before the nonblocking assign update events were executed

$display: a = 0 

$monitor: a = 1 

$strobe :  a = 1

Essential Verilog Guidelines for Writing Robust RTL

<h2></h2>
<img class="aligncenter size-medium wp-image-17985" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/05/3-min-1024x576.png" alt="rtl design " width="1024" height="576" />
<h2>Introduction:</h2>
In digital circuit design, engineers often begin by describing the intended behavior of a system using a high-level language like Verilog or VHDL. This abstraction, known as RTL, focuses on how data flows between registers and how operations are performed on each clock cycle. However, this description must eventually be transformed into a gate-level netlist that represents physical logic gates and the flip-flops. RTL synthesis automates this transformation, ensuring functional accuracy while optimizing for performance, power, and area.
<h2>What is RTL Design?</h2>
RTL is an abstraction level in digital design that describes the flow of data between registers and the logical operations performed on that data. At this level, designers focus on clocked sequential behavior and combinational logic. 

Designs at the RTL level are typically written in hardware description languages (HDLs) such as Verilog or VHDL.
<h4>Example: </h4>
&nbsp;

This describes a 4_bit up counter behavior using Verilog, which is synthesized to actual flip-flop gates during RTL synthesis.
<h2>What is Synthesis?</h2>
Synthesis is the automated process of converting RTL code into a gate-level netlist. This netlist consists of logic gates and interconnections derived from a technology library.
<h4>RTL Design Synthesis Flow</h4>
The synthesis process typically involves several stages:
<h4>1.RTL Design</h4>
Engineers write the functional description of the circuit using HDL like (VHDL/Verilog). This code includes modules, finite state machines, arithmetic logic, and register definitions. Good design practices and proper coding style are crucial for efficient synthesis.
<h4>2. Functional Simulation</h4>
Before synthesis, the RTL code is simulated to verify correctness. Testbenches apply stimulus to the design, and simulators (e.g., ModelSim, VCS) are used to observe outputs and debug any logical errors.
<h4>3.Design Constraints</h4>
The synthesis tool requires timing, area, and power constraints, typically defined in a Synopsys Design Constraints (SDC) file. These constraints include:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Clock definitions</li>
 	<li style="font-weight: 400;" aria-level="1">Input/output delays</li>
 	<li style="font-weight: 400;" aria-level="1">Maximum area or power budgets</li>
 	<li style="font-weight: 400;" aria-level="1">False or multicycle paths</li>
</ul>
<h4>4.RTL Synthesis</h4>
Using tools like Synopsys Design Compiler or Cadence Genus, the RTL is converted into a gate-level netlist. This includes:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Elaboration: HDL code is parsed and expanded into a hierarchical design.</li>
 	<li style="font-weight: 400;" aria-level="1">Technology Mapping: Logic is mapped onto gates from the target library.</li>
 	<li style="font-weight: 400;" aria-level="1">Optimization: The design is optimized for area, speed, and power.</li>
</ul>
<h4>5. Gate-Level Netlist Generation</h4>
<ul>
 	<li style="font-weight: 400;" aria-level="1">Output is a netlist comprising logic gates like AND, OR, NOT, flip-flops, etc.</li>
 	<li style="font-weight: 400;" aria-level="1">Mapped to a specific process technology or FPGA architecture.</li>
</ul>
<h4>6. Formal Equivalence Checking (FEC)</h4>
Optional but recommended, formal tools compare the synthesized netlist with the original RTL to ensure no functional discrepancies exist after synthesis.
<h4>7.Static Timing Analysis (STA)</h4>
This step checks if all timing paths in the netlist meet the constraints. STA tools like Synopsis(PrimeTime) analyze the worst-case propagation delays, setup/hold violations, and provide slack reports.
<h4>Challenges in RTL Synthesis:</h4>
<ul>
 	<li style="font-weight: 400;" aria-level="1">Clock Domain Crossing (CDC) issues</li>
 	<li style="font-weight: 400;" aria-level="1">Timing closure</li>
 	<li style="font-weight: 400;" aria-level="1">Power optimization</li>
 	<li style="font-weight: 400;" aria-level="1">RTL coding quality</li>
</ul>
All these aspects must be addressed early to ensure a successful synthesis outcome.
<h2>Conclusion:         </h2>
<a href="https://www.maven-silicon.com/blog/rtl-coding-synthesis/">RTL Design Synthesis</a> is the cornerstone of digital hardware implementation, linking abstract design with physical realization. A solid understanding of the flow, tools, and best practices is essential for producing efficient, high-performance chips that meet timing and resource requirements. As designs grow more complex, synthesis continues to evolve, incorporating features like power-aware synthesis, machine learning-based optimization, and improved debugging capabilities.

RTL Design and Synthesis in VLSI Design Flow

<img class="aligncenter size-medium wp-image-17992" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/04/1-min-1024x576.png" alt="why verilog
" width="1024" height="576" />
If you’ve ever jumped into someone else’s Verilog code and thought, “What on earth is going on here?” — you’re not alone.

When it comes to writing Verilog, we often focus on whether it works. But in professional environments, how you write your code can make just as much difference as what it does.

Whether you're building an FPGA prototype, ASIC RTL, or a clean testbench — good coding style is key. Here's why it matters, with a few real-world examples
<ol>
 	<li>
<h2> Readable Code = Maintainable Code</h2>
</li>
</ol>
Unreadable RTL leads to headaches, confusion, and bugs. Clarity helps everyone — especially future you. 

&nbsp;
<h4>Before:</h4>
<img class="aligncenter size-full wp-image-17815" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/04/unnamed-8.png" alt="verilog code before " width="567" height="44" />
<h4>After:</h4>
<img class="aligncenter size-full wp-image-17816" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/04/unnamed-9.png" alt="after verilog code" width="266" height="135" />

Just a few tabs and line breaks, and suddenly the logic is crystal clear.
<ol start="2">
 	<li>
<h2> Consistent Naming Helps Everyone</h2>
</li>
</ol>
Stick to naming conventions. Avoid mixing styles like DataBus, databus, and data_bus in the same module. Pick one and be consistent.

<img class="aligncenter size-full wp-image-17817" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/04/unnamed-10.png" alt="Consistent Naming Helps Everyone" width="187" height="93" />
<ol start="3">
 	<li>
<h4> Modularization = Reuse + Testability</h4>
</li>
</ol>
Think of each module like a building block. The cleaner it is, the easier it is to plug into larger systems — or reuse later.

<img class="aligncenter size-full wp-image-17818" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/04/unnamed-11.png" alt="Modularization = Reuse + Testability" width="211" height="136" />

Reusing the adder module in a top block called system.

<img class="aligncenter size-full wp-image-17819" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/04/unnamed-12.png" alt="Code 1" width="355" height="188" />
<ol start="4">
 	<li>
<h4> Good Style Reduces Bugs</h4>
</li>
</ol>
One of the most common mistakes in Verilog is mixing blocking (=) and non-blocking (&lt;=) assignments.
<h4>Bug prone code:</h4>
<img class="aligncenter size-full wp-image-17820" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/04/unnamed-13.png" alt="incorrect verilog code " width="218" height="87" />
<h4>Correct code:</h4>
<img class="aligncenter size-full wp-image-17829" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/04/unnamed-7-1.png" alt="" width="218" height="87" />

&nbsp;
<ol start="5">
 	<li>
<h4> Write cleaner testbenches using tasks</h4>
</li>
</ol>
The testbenches help us to analyze if the response from the design is matching with the expected results. It is very important to write cleaner and organized code for even testbenches to make them more readable and understandable. Below are two code snippets showcasing how important it is to write a readable testbench.
<h4>Testbench 1:</h4>
<img class="aligncenter size-full wp-image-17822" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/04/unnamed-15.png" alt="Testbench 1" width="126" height="232" />
<h4>Testbench 2:</h4>
<img class="aligncenter size-full wp-image-17823" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/04/unnamed-16.png" alt="testbench 2 " width="216" height="166" />

Looking at both the code snippets. You can notice Testbench 2 written using tasks appears more readable and clean than Testbench 1. The Testbench 2 is written using tasks in Verilog. Tasks have been written to initialize the inputs, reset the system and drive the stimulus.
<h4>Final Takeaway: </h4>
Writing <a href="https://www.maven-silicon.com/blog/which-software-is-used-for-systemverilog/">Verilog</a> is not just about functionality. It’s about writing RTL that’s understandable, readable, and reliable — especially when working with larger teams or long-term projects.

Following good coding practices is like future-proofing your design process. It saves time, reduces errors, and makes you a better engineer overall whether it is about writing RTL or the testbenches that verify your design.

All Posts

Designing for Power, Performance, Area (PPA) Trade-offs at RTL Level

A Practical Look at specparam in Verilog

RTL Design Explained Like Online Delivery

Essential Verilog Guidelines for Writing Robust RTL

RTL Design and Synthesis in VLSI Design Flow

Why clean Verilog code is crucial?

SUBSCRIBERS

Subscribe to our Blog

Maven Learning App

Get trained online as a VLSI Professional

40%^OFF

SUBSCRIBERS

Subscribe to our Blog

Have Doubts?
Read Our FAQs

All Posts

Designing for Power, Performance, Area (PPA) Trade-offs at RTL Level

A Practical Look at specparam in Verilog

RTL Design Explained Like Online Delivery

Essential Verilog Guidelines for Writing Robust RTL

RTL Design and Synthesis in VLSI Design Flow

Why clean Verilog code is crucial?

SUBSCRIBERS

Subscribe to our Blog

Maven Learning App

Get trained online as a VLSI Professional

40%OFF

SUBSCRIBERS

Subscribe to our Blog

Have Doubts?Read Our FAQs

40%^OFF

Have Doubts?
Read Our FAQs