Short, step-by-step lessons that teach a concept from scratch — not a reference to look something up in, and not a Q&A to test yourself with.
Looking for something else? Guides go deeper on one topic as a reference. Examples are pure code with no teaching prose. Interview Questions test what you already know.
Every chip you've ever used — your phone, laptop, car — is built using VLSI: Very Large Scale Integration. It's the process of packing millions (sometimes billions) of transistors onto a single piece of silicon. Before VLSI, engineers built circuits from individual components wired together by hand. That worked for simple circuits, but modern processors have billions of transistors — wiring those by hand isn't possible. VLSI solves this with a layered design process: you describe what the circuit should do (RTL), tools convert that into a network of logic gates (synthesis), and more tools figure out where to physically place and connect millions of these gates on a few square millimeters of silicon (physical design). Each of those three stages — RTL, synthesis, and physical design — is itself a specialization within VLSI, which is why a "VLSI engineer" role can look very different depending on which stage you work in.
Verilog is a Hardware Description Language — you're not writing instructions for a processor to execute, you're describing hardware that will physically exist. This is the single biggest mental shift for anyone coming from software. A Verilog "module" is like a black box with inputs and outputs, describing a chunk of hardware. Every line inside it doesn't run once, top to bottom, the way a Python script does — it describes a piece of circuitry that always exists, always connected, always reacting to its inputs. Two constructs trip up almost every beginner: wire vs. reg, and blocking (=) vs. non-blocking (<=) assignment. Get comfortable with a simple combinational module (like a multiplexer) before moving to sequential logic with clocked always blocks — trying to learn both at once is where most confusion starts.
An ASIC (Application-Specific Integrated Circuit) goes through a long pipeline before it becomes real silicon: specification, RTL design, functional verification, synthesis (RTL → gates), physical design (floorplanning → placement → clock tree → routing), and sign-off (timing, power, DRC/LVS checks) before tape-out. What makes this flow tricky to learn is that decisions made early — like floorplan shape or clock architecture — constrain what's possible later. A common beginner mistake is treating each stage as fully independent; in practice, experienced engineers think a few stages ahead even while working on the current one.
FPGAs (Field-Programmable Gate Arrays) are reconfigurable — you can reprogram the same chip with a completely different design in minutes. ASICs are custom-fabricated for one specific design and can't be changed after manufacturing. The trade-off: FPGAs are fast to iterate on and have no upfront fabrication cost, but are slower, less power-efficient, and more expensive per unit at high volumes. ASICs cost millions in non-recurring engineering (NRE) and take months to fabricate, but are far more efficient at scale. This is why FPGAs dominate prototyping, low-volume products, and applications needing field updates, while ASICs dominate high-volume consumer electronics. As a career choice, FPGA and ASIC roles overlap heavily in RTL skills but diverge sharply in physical design and DFT.
RTL (Register Transfer Level) design describes how data moves between registers on each clock cycle, and what logic transforms it along the way. Writing good RTL isn't just about getting the logic correct — it's about writing code that synthesis tools can turn into efficient, working hardware. A design that behaves correctly in simulation but wasn't written with synthesis in mind can fail timing, waste area, or behave unpredictably on real silicon. The best way to build this skill is to start with small, complete designs — a counter, then an FSM, then a simple FIFO — and study how each maps to real hardware, rather than jumping straight into a large project.
UVM (Universal Verification Methodology) can feel overwhelming at first because of how much infrastructure exists before you write your first real test. The key insight: UVM is just a standardized way to organize the same components a hand-written testbench would need anyway — something to generate stimulus (sequence), something to drive it onto the DUT (driver), something to observe outputs (monitor), and something to check correctness (scoreboard). Once you can name what each component in a UVM environment is doing in plain English, the class hierarchy and factory pattern make a lot more sense — they're solving the problem of making those components reusable and swappable, not adding complexity for its own sake.
Move from tutorials to our free interview question banks.
Browse questions