Verilog, VLSI, and ASIC Design - From RTL to RISC-V, CISC, and ARM
This note is adapted from course materials for EE4802 VLSI Circuit Design at City University of Hong Kong. Instructor: course teaching staff.
1. Why These Topics Belong Together
Students often meet these terms in isolation:
- Verilog in a digital design class,
- VLSI in a chip design or fabrication course,
- ASIC in industry discussions about custom silicon,
- RISC-V, ARM, and CISC in computer architecture.
That separation is convenient for teaching, but it hides how real digital systems are built.
If we decide to build a processor, accelerator, or hardware controller, we usually begin with an architectural idea: what instructions should exist, what performance is needed, what power budget is allowed, and what software must run. That architectural decision leads to a microarchitecture: pipelines, control logic, datapaths, caches, buses, and interfaces. The microarchitecture is then expressed as RTL, often in Verilog. RTL is synthesized into gates, placed and routed on silicon, checked for timing and manufacturability, and finally fabricated as an ASIC or mapped to programmable hardware.
So these topics are not separate islands. They are layers of one engineering stack:
- choose the computational model,
- choose an instruction architecture or hardware function,
- design the microarchitecture,
- describe it in RTL,
- implement it physically as a chip.
That is the practical reason to study them together. Each becomes clearer when seen as part of the path from idea to silicon.
2. What Verilog Actually Describes
Verilog is a hardware description language, not a sequential programming language in disguise. The important mental shift is that Verilog describes circuits that exist simultaneously, not instructions that run one after another on a hidden processor.
When we write synthesizable Verilog, the default model is structure and time:
- combinational logic responds to input changes,
- sequential logic updates state on a clock edge,
- many blocks operate concurrently.
That is why a Verilog design is usually understood in terms of:
- signals: wires and registers carrying values,
- combinational logic: logic functions with no stored state,
- sequential logic: flip-flops or latches that store state,
- modules: reusable hardware blocks with ports.
The core RTL habit is to separate the design into:
- a block that computes next values combinationally,
- a block that updates current state sequentially.
Here is a compact synthesizable example:
module counter4 (
input wire clk,
input wire rst_n,
input wire en,
output reg [3:0] count
);
reg [3:0] next_count;
always @(*) begin
if (en)
next_count = count + 4'd1;
else
next_count = count;
end
always @(posedge clk or negedge rst_n) begin
if (!rst_n)
count <= 4'd0;
else
count <= next_count;
end
endmodule
This module is small, but it already illustrates several important points:
- the
always @(*)block describes combinational next-state logic, - the
always @(posedge clk ...)block describes state updates in flip-flops, countdoes not change continuously; it changes on clock edges,- the hardware implied by the code exists all at once.
In practice, Verilog is valuable because it sits at the level where designers can still reason about behavior while synthesis tools can still map the description to hardware. It is abstract enough for a CPU pipeline or DMA engine, but concrete enough to imply registers, multiplexers, adders, and finite-state machines.
This is also why “writing Verilog” is not the same as “programming a chip.” Good RTL design still requires thinking about reset, clocking, latency, resource sharing, and timing closure.
3. What VLSI Means Beyond the Acronym
VLSI originally means Very Large Scale Integration: integrating huge numbers of transistors on one chip. Today, the useful meaning is broader. It refers to the design and implementation of integrated circuits at scale, where success depends on managing abstraction layers correctly.
Those layers are easy to confuse, so it helps to separate them clearly:
- ISA: the machine-level contract visible to software.
- Microarchitecture: the internal organization that implements that contract.
- RTL: a cycle-accurate hardware description of registers and logic transfers.
- Gate level: Boolean logic cells and timing arcs after synthesis.
- Physical design: floorplanning, placement, clock trees, routing, power grids, and layout.
- Silicon process: the fabrication technology that turns layout into transistors and wires.
The key lesson is that the same ISA can be implemented by very different microarchitectures, and the same microarchitecture can be expressed in different RTL styles, but every layer constrains the next.
This is where VLSI becomes more than “small transistors.” It is the discipline of keeping each abstraction honest:
- architecture must be implementable,
- RTL must be synthesizable,
- gate count must fit area and power budgets,
- layout must be routable and manufacturable,
- timing must close at the required frequency.
If any layer is treated casually, the chip fails somewhere downstream. VLSI work is therefore not only invention; it is disciplined translation across abstraction boundaries.
4. The ASIC Design Flow
An ASIC is an Application-Specific Integrated Circuit: a chip built for a particular class of functions rather than for general reprogrammability.
The ASIC flow is usually presented as a pipeline, and that is a good first approximation. In reality it is iterative, because timing, power, verification, and physical constraints often force architecture or RTL changes.
4.1 Specification and architecture
Everything begins with a specification:
- what the chip must do,
- required throughput and latency,
- power target,
- area target,
- clock frequency,
- interfaces,
- reliability and test requirements.
From there, designers choose the architecture and microarchitecture. This is where major tradeoffs appear:
- deeper pipelines can improve frequency but increase control complexity,
- more parallelism can improve throughput but increase area and power,
- wider datapaths improve precision or bandwidth but expand routing and storage costs.
Good ASIC design starts by making these tradeoffs explicit instead of hoping synthesis will fix them later.
4.2 RTL design and functional verification
Once the architecture is stable enough, designers write RTL, often in Verilog or SystemVerilog. The goal is not only to express function, but to express it in a way that is:
- synthesizable,
- testable,
- maintainable,
- robust to timing and reset assumptions.
At the same time, verification engineers build testbenches, directed tests, constrained-random tests, assertions, and reference models. This phase is critical because fixing a bug in RTL is far cheaper than discovering it after tape-out. Verification must still ask harder questions:
- what happens after reset,
- what happens on stalls or backpressure,
- what happens on rare control interactions,
- what happens at corner-case widths, latencies, or protocol timings.
4.3 Synthesis and implementation tradeoffs
After functional confidence is high enough, the RTL is synthesized into a gate-level netlist using a standard-cell library. At this point, abstract constructs become real hardware costs.
Synthesis answers questions such as:
- how many gates are required,
- what logic depth exists on critical paths,
- how much area is consumed,
- how much switching activity may drive dynamic power,
- whether the design can plausibly meet the target clock.
This is where timing, area, and power become inseparable. For example:
- aggressive clock targets may require pipeline registers,
- area minimization may increase logic sharing and slow paths,
- power reduction may require clock gating or lower activity structures.
There is no single “best” implementation, only one that best satisfies the design constraints.
4.4 Place-and-route and signoff
After synthesis, physical design begins:
- floorplan the major blocks,
- place standard cells and macros,
- build the clock tree,
- route signals and power,
- extract parasitics,
- run signoff checks.
At this stage, distance becomes real. A path that looked fine in RTL may fail when wire delays, clock skew, congestion, and coupling are included.
Signoff typically includes checks such as:
- static timing analysis,
- power integrity and IR-drop review,
- design rule checking,
- layout-versus-schematic consistency,
- testability support such as scan insertion.
Only after these checks pass with adequate margin is the design ready for tape-out.
4.5 Fabrication, packaging, and silicon validation
Tape-out sends the final layout data to the fabrication flow. Wafers are manufactured, diced, packaged, and then the first silicon returns for bring-up and validation.
Post-silicon work must confirm:
- boot and reset behavior,
- frequency targets,
- power consumption,
- interface correctness,
- production test coverage,
- corner-case stability across voltage and temperature.
If the chip works, the ASIC flow looks elegant in hindsight. If it does not, the lesson is usually that one abstraction layer hid a problem from another.
5. RISC-V vs CISC vs ARM
This comparison needs one clarification first: RISC-V, ARM, and CISC are not perfectly parallel categories.
- RISC-V is an open instruction set architecture.
- ARM is a licensed ISA family and ecosystem with strong RISC heritage.
- CISC is a design style, most commonly discussed through x86 in modern computing.
So the question is not really “which label wins?” The better question is: what kind of instruction interface, ecosystem, and implementation freedom does a design need?
| Dimension | RISC-V | ARM | CISC / x86 |
|---|---|---|---|
| What it is | Open ISA standard | Proprietary licensed ISA family | Instruction-style category, usually represented by x86 |
| Licensing model | Open specification, implementers can build compatible cores | ISA and core access depend on licensing terms | Controlled by vendors with long legacy ecosystems |
| Instruction philosophy | Modular and relatively clean base plus extensions | Generally load-store RISC style with mature profiles | Rich, historically complex instruction set with variable-length encodings |
| Ecosystem maturity | Growing rapidly in academia, startups, and embedded systems | Extremely mature across mobile, embedded, and many SoCs | Dominant in desktop/server software compatibility |
| Implementation flexibility | High freedom for custom cores and custom extensions | Strong ecosystem but less open for ISA-level experimentation | Limited freedom for new implementers due to compatibility and control constraints |
| Typical use cases | Research, embedded, accelerators, domain-specific processors | MCUs, mobile SoCs, application processors, embedded systems | PCs, laptops, servers, compatibility-driven platforms |
The appeal of RISC-V is openness and modularity. A designer can implement a small embedded core, a Linux-capable processor, or a domain-specific accelerator-friendly core while staying within a published ISA framework.
The appeal of ARM is ecosystem strength. Toolchains, software support, verification IP, partner networks, and deployment history are all major advantages. For many companies, this reduces risk more than openness would.
The appeal of modern CISC/x86 systems is software continuity and platform depth. The instruction set is complex, but commercial implementations often translate those instructions internally into simpler micro-operations. This is an important reminder that ISA appearance and internal implementation are not the same thing.
So the practical engineering comparison is:
- choose RISC-V when openness, extensibility, or architectural experimentation is important,
- choose ARM when ecosystem maturity and deployability are more valuable,
- study CISC/x86 mainly as the case where instruction-set compatibility and historical continuity dominate the design space.
From a VLSI perspective, all three still lead to the same downstream work: microarchitecture, RTL, verification, timing closure, and physical implementation.
6. How the Layers Connect in Practice
Digital chip design becomes clearer if each layer is treated as a different question: what behavior software should see, how hardware should implement it, how that behavior should be described cycle by cycle, and how it will finally meet timing, area, power, and manufacturability constraints.
This is where Verilog fits. Verilog is usually the bridge between the architectural idea and the realizable circuit.
Suppose we want a simple RISC-V core for an embedded application. The ISA tells us what instructions software expects. The microarchitecture decides whether to use a tiny in-order pipeline, how many stages to include, and how loads, branches, and interrupts are handled. Verilog captures the register file, decoder, ALU control, pipeline registers, hazard handling, and bus interface. Synthesis then turns that into gates, and backend tools determine whether the chosen design actually fits the clock, area, and power budget.
The same story applies to non-CPU hardware. An ASIC for image processing, motor control, networking, or neural inference may expose no general-purpose ISA at all. Even then, the design still follows the same path:
- define function and interfaces,
- choose architecture,
- write RTL,
- verify,
- implement in silicon.
This also explains the usual distinction between FPGA and ASIC work. Both often begin with similar RTL, but the implementation targets differ:
- FPGA prioritizes programmability and faster iteration,
- ASIC prioritizes performance, power efficiency, density, and unit-volume optimization.
An FPGA is often the right place to prototype a design, validate architecture decisions, or ship lower-volume systems. An ASIC becomes attractive when the function is stable enough and the expected performance, power, or production scale justify the cost and risk of custom silicon.
In that sense, Verilog is the language of structural intent, VLSI is the discipline of abstraction and physical realization, and ASIC design is the industrial process that turns verified intent into a manufactured chip. RISC-V, ARM, and CISC/x86 sit above that stack as different ways of defining the computational contract.
The unifying idea is simple:
chip design is not one decision, but a chain of linked decisions from architecture to physical implementation.
Once that is clear, these topics stop feeling like scattered buzzwords and start looking like parts of one coherent engineering workflow.