Skip to content
VLSI Mentor

VLSI MentorByAZVYA Education Private Limited

The engineering path
from logic to silicon

Learn RTL design, verification, SystemVerilog, UVM, protocols, and debugging through one structured engineering system.

Start learning

Free tutorials. No paywall.

  1. Digital Electronics
  2. Verilog
  3. RTL Design
  4. VHDL
  5. SystemVerilog
  6. ProtocolsAMBA · PCIe · DDR and more
  7. VerificationIP · Subsystem · SoC
  8. UVM
  9. UVM-RAL
  10. C / C++
  11. Synthesis · Lint / CDC
  12. GLS
  13. DFT
  14. STA & Physical DesignComing soon
See how we teach

Understand what the RTL means, not just how to write it

VLSI Mentor connects code to timing, behavior, failure modes, and the reasoning engineers use to debug real designs.

Blocking vs non-blocking assignments are a recurring source of RTL design bugs, simulation/synthesis mismatches, and interview questions. That’s why VLSI Mentor teaches the topic in both Verilog and SystemVerilog—with emphasis on timing behavior, scheduling, races, and debugging.

Inside always_ff @(posedge clk)

<=Non-blocking

stage1 <= d;stage2 <= stage1;

stage2 keeps its one-cycle latency

=Blocking

stage1 = d;stage2 = stage1;

stage2 collapses onto stage1

With non-blocking assignment stage2 lags stage1 by one cycle, preserving the two-stage pipeline. With blocking assignment in the same clocked block stage2 is identical to stage1, so the pipeline collapses to a single stage.clkstage1XABCDEEstage2 <=XXABCDEstage2 =XABCDEEt0t1t2t3t4t5t6

stage2 <= +1 cycle behind stage1stage2 = same cycle as stage1

Engineering insight — with <= both registers sample pre-edge values, preserving the pipeline. With = in this clocked example, stage2 reads the newly assigned stage1 and the simulated stages collapse.

Verilog tutorialSystemVerilog tutorial
Engineering reasoning

From RTL intent to debug decision

A good engineer does not stop at “the waveform looks wrong.” The real skill is tracing behavior back to the architectural cause and choosing the correct fix.

RTL Design PatternsTwo-Flop Synchronizer
Two-flop synchroniser: a single-bit control level leaves the source clock domain, crosses the domain boundary, and is re-sampled by two flops clocked by the destination clock before any logic reads it.SOURCE CLOCK DOMAINSOURCE CLOCK DOMAINDESTINATION CLOCK DOMAINDESTINATION CLOCK DOMAINFFsrc_qsrc_qddclk_srcclk_srcSYNC 1q1q1clk_dstclk_dstSYNC 2q2q2clk_dstclk_dstsync_qsync_qdomain boundarydomain boundary
One bit of control, one boundary, two destination-domain flops — the structure every step on the right refers to.

  1. Intent

    A single-bit control level has to cross between two unrelated clocks. Metastability cannot be designed out — it has to be contained.

  2. RTL

    Two flops in the destination domain. sync_ff1 absorbs the async edge; sync_ff2 re-samples a full period later, with nothing but wire between them.

  3. Observation

    Intermittent, unreproducible incoherence — one consumer reads 1, another reads 0, a state machine takes an illegal transition, a word is written twice or not at all.

  4. Root cause

    sync_ff1 was fanned out to a second load. A node that is still settling now drives logic that resolves it at a different threshold, so the metastability the chain was built to contain is spread instead.

  5. Engineering decision

    sync_ff1 drives exactly one thing — sync_ff2 — and every consumer reads sync_out. And the fix is not always textual: a multi-bit bus does not get this pattern at all, it needs gray coding or a handshake with a data hold. That is a different structure, and a different lesson.

Practice

Turn understanding into engineering practice

Test your reasoning against questions written around real failure modes, then apply the same concepts in labs with a provided testbench and waveform guidance.

MCQ practice

Sim/Synth Mismatch

Why do simulation and synthesis disagree for this block?

always @(a)  y = a & b;
  • Synthesis silently inserts a hidden clock that the RTL simulation does not model at all
  • The list omits b, so sim misses b-only changes while synthesis builds full AND
  • y must be a wire; the mismatch is a type error
  • Blocking = is illegal in combinational logic

Synthesis reads the intent and builds the full AND, but simulation only re-evaluates when a changes — so a b-only change is missed and the RTL waveform diverges from the gates. The fix is always @(*), or always_comb.

Hands-on labs

Advanced · 150 min

Project — Synchronous FIFO Verification Environment

Verify a parameterised FIFO end to end: an interface with a clocking block, assertions for the full/empty contract, a class-based environment, randomised traffic and a coverage model that proves both boundaries were hit.

Interface + assertionsScoreboardCoverage closure

  1. Assemble the environment
  2. Run the clean regression
  3. Inject two bugs — one still passes
  4. Debug to the first divergence
Practice MCQsSystemVerilog labs

Free MCQ papers are open to everyone; lab exercises are part of the paid packs.

Learning philosophy

VLSI learning should not be a collection of disconnected answers

Real understanding comes from the order ideas arrive in — intuition before formalism, hardware behaviour before syntax, and failure analysis before a rule is treated as understood.

Fragmented learning

how a concept is often picked up

  1. Search a single termyou land on one idea with no sense of what comes before or after it
  2. Read a definitionthe wording can be correct while the mental model is still missing
  3. Copy an examplethe code runs, but why it behaves that way is never made explicit
  4. Move to another topicthe link to timing, verification and the rest of the system is dropped
  5. Keep the keyword, lose the conceptthe terminology stays familiar; the reasoning under it stays fragile

VLSI Mentor

the order lessons are written in

  1. Intuitionthe mental picture of what the hardware is doing, before any syntax appears
  2. Formal definitionthe precise wording, introduced only once that picture is in place
  3. Real engineering usewhere a designer or verification engineer actually meets it in a real system
  4. Failure caseswhat breaks, how the symptom shows up, and why it happens at all
  5. Examplecode, a waveform or a diagram — whichever makes the behaviour observable
  6. How to remember itthe durable rule that still holds once the tutorial is closed
  7. Connect the next conceptplaced back into the learning graph, so the next topic has something to stand on
The sequence is part of the teaching — build the mental model, make it precise, study what fails, then carry the reasoning into the next problem.
Engineering Journal

Keep learning beyond the tutorial

Longer notes that carry an idea past the lesson it started in — each one linking back into the tutorials it draws on.

View all journal

Build your engineering foundation

One structured path — from digital fundamentals through RTL design, verification and the protocol stack.

Start learning

Need help?

Have a technical question, interested in premium training, or found an issue in a tutorial? We're happy to help.

Contact us