55:10
RTL Synthesis- Part I
NPTEL-NOC IITM
Overview
This video introduces RTL synthesis, the initial stage of logic synthesis in VLSI design. It explains how RTL code, typically written in Verilog, is translated into a netlist of generic logic gates. The process involves parsing the code to create a hierarchical data structure, followed by elaboration to establish connections between modules and instances. The video also details how various Verilog constructs like 'assign' statements, 'if-else', 'case', and 'always' blocks are synthesized into combinational logic or sequential elements like flip-flops and latches, while also highlighting constructs that are not synthesizable.
How was this?
Save this permanently with flashcards, quizzes, and AI chat
Chapters
- RTL synthesis is the first step in logic synthesis, translating Verilog code into a netlist of generic logic gates.
- It involves parsing, elaboration, and translation of Verilog constructs into logic.
- Parsing breaks down code into tokens and builds a hierarchical syntax tree.
- Elaboration links instances to their master modules and checks for connection errors.
Understanding RTL synthesis is crucial because it bridges the gap between a functional description of a circuit in Verilog and its actual hardware implementation.
A Verilog module 'mid' containing an 'always' block, which is then represented as a hierarchical tree with 'mid' as a child of the root and the 'always' block as a child of 'mid'.
- Lexical analysis breaks RTL code into tokens (keywords, identifiers, operators).
- Syntax analysis checks if the code follows Verilog grammar, reporting errors if not.
- A syntax tree (or parse tree) is built as a hierarchical data structure representing the code's structure.
- Parent-child relationships in the tree mirror containment in the RTL code (e.g., a module contains statements).
The syntax tree provides a structured representation of the code that the synthesis tool can easily process and analyze, forming the foundation for subsequent steps.
A Verilog code snippet with modules 'top' and 'mid', where 'mid' has an 'always' block with two non-blocking and one blocking statement, resulting in a tree structure with 'top' and 'mid' as children of the root, and statements as children of the 'always' block.
- Elaboration connects instantiated modules (instances) to their master module definitions.
- It verifies the legitimacy of connections, checking port names and bus widths.
- During elaboration, the tool infers port directions if not explicitly defined, sometimes making simplistic assumptions (e.g., all ports as inputs).
- Errors like missing master module definitions (leading to black boxes) or incorrect port connections are reported.
Elaboration ensures that the design's hierarchy is correctly formed and that all components are properly connected, preventing errors before synthesis.
A design with instances I1, I2 (of module 'leaf') and I3 (of module 'middle') within module 'Top'. Elaboration links these instances to their respective master modules and checks if ports like 'd', 'clk', and 'q' are connected correctly, flagging an error if 'd' was mistakenly named 'd1'.
- Elaboration handles parameterized modules by creating specialized versions for each unique set of parameter values.
- A parameterized module (e.g., 'counter' with parameter 'WIDTH') can have different interface sizes based on the parameter's value.
- For each instance with a different parameter value, the tool may internally generate a new module with a name reflecting the parameter and its value (e.g., 'counter_WIDTH_8').
This allows for flexible and reusable module designs that can be adapted to specific needs without rewriting the entire code.
A parameterized 'counter' module with a 'WIDTH' parameter. Instance C1 uses the default WIDTH=4, C2 uses WIDTH=8, and C3 uses WIDTH=16, leading the tool to internally create distinct modules for each width.
- Not all Verilog constructs are synthesizable; some are intended only for simulation/verification.
- Synthesizability is tool-dependent; designers must know which constructs their tool supports.
- Non-synthesizable constructs include delay specifications (`#delay`), `initial` blocks, `fork-join`, `force-release`, `real`/`time` data types, and system tasks like `$display`.
- Delay specifications are ignored during synthesis, treating the assignment as immediate.
Understanding synthesizable constructs is essential to write RTL code that can be correctly translated into hardware, avoiding unexpected behavior or synthesis failures.
A Verilog statement like `assign out1 = #12 a;` will have the `#12` delay ignored by the synthesis tool, effectively becoming `assign out1 = a;`.
- Continuous `assign` statements synthesize into combinational logic gates based on the right-hand side (RHS) expression.
- Operators like AND, OR, and ternary operators map directly to AND gates, OR gates, and multiplexers, respectively.
- `if-else` statements synthesize into multiplexers, where the condition determines the select line.
- `case` statements also synthesize into multiplexers or select logic, with the case expression forming the select lines.
This shows how procedural and continuous assignments are directly translated into the fundamental building blocks of digital circuits.
An `assign out3 = s ? q : p;` statement synthesizes into a multiplexer where 's' is the select line, and 'q' and 'p' are the data inputs.
- Edge-sensitive `always` blocks (e.g., triggered by `posedge clk`) synthesize into sequential elements like flip-flops.
- Asynchronous resets in `always` blocks lead to flip-flops with asynchronous reset pins.
- Synchronous resets are implemented within the clock edge logic, often using multiplexers.
- The synthesis tool aims for functional equivalence, potentially using different gate implementations than shown.
This explains how state-holding elements, essential for memory and sequential operations, are created from RTL descriptions.
An `always @(posedge clk)` block with `q <= d;` synthesizes into a D flip-flop where 'd' is the input and 'q' is the output.
- Blocking assignments (`=`) in `always` blocks execute sequentially and can lead to simplified logic (e.g., a single flip-flop).
- Non-blocking assignments (`<=`) evaluate RHS first and schedule LHS updates, typically synthesizing into shift registers or multiple flip-flops.
- Level-sensitive `always` blocks infer combinational logic if all paths assign a value, or latches if a variable retains its old value in some paths.
- Latches can be inferred unintentionally due to incomplete case statements or missing assignments in conditional branches.
The choice between blocking and non-blocking assignments, and careful coding of `always` blocks, directly impacts whether combinational logic, flip-flops, or unintended latches are generated.
An `always @(posedge clk)` block using blocking assignments `reg1 = in1; reg2 = reg1;` synthesizes to one flip-flop passing `in1` to `out1`, while using non-blocking assignments `reg1 <= in1; reg2 <= reg1;` synthesizes to a shift register (multiple flip-flops).
- Latches are often inferred unintentionally when combinational logic is intended.
- Missing assignments in conditional branches (like `case` or `if-else`) cause variables to retain their old values, leading to latch inference.
- Using a `default` clause in `case` statements ensures all possibilities are covered, preventing latches.
- Assigning default values to signals at the beginning of an `always` block can also help avoid latches.
Unintended latches can cause timing issues and incorrect circuit behavior, so understanding how to prevent them is critical for robust design.
In a `case` statement, if the condition `11` is missed and doesn't assign a value to `out1`, a latch will be inferred. Adding a `default: out1 = 1'b0;` clause prevents this by ensuring `out1` always gets a value.
Key takeaways
- RTL synthesis translates human-readable Verilog code into a hardware-understandable netlist of logic gates.
- Parsing and elaboration are foundational steps that structure the code and verify its connectivity.
- Synthesizable Verilog constructs map directly to hardware elements like gates, flip-flops, and multiplexers.
- Non-synthesizable constructs, like delays and system tasks, are ignored or cause errors during synthesis.
- The distinction between blocking and non-blocking assignments significantly impacts the synthesized sequential logic.
- Careful coding, especially in `always` blocks and `case` statements, is essential to avoid inferring unintended latches.
- Understanding tool-specific behavior is important, as synthesizability and implementation details can vary.
Key terms
RTL SynthesisVerilogLogic SynthesisNetlistParsingLexical AnalysisSyntax TreeElaborationInstanceMaster ModuleBlack BoxParameterized ModuleSynthesizableNon-SynthesizableCombinational LogicSequential LogicFlip-FlopLatchBlocking AssignmentNon-blocking AssignmentAlways BlockCase StatementIf-Else StatementAssign Statement
Test your understanding
- What is the primary goal of RTL synthesis in the VLSI design flow?
- How does the process of parsing contribute to the RTL synthesis workflow?
- What is the role of elaboration, and what types of errors can it detect?
- Why is it important to distinguish between synthesizable and non-synthesizable Verilog constructs?
- How do `if-else` and `case` statements typically translate into hardware during synthesis?
- What is the functional difference between blocking and non-blocking assignments in an `always` block, and how does it affect synthesis?
- What conditions can lead to the unintentional inference of latches during RTL synthesis, and how can this be prevented?