In this article , we delve into several key topics. First, we provide an introduction to both NetlistSVG and GraphViz, outlining their features and uses. We then demonstrate how to create a JSON file for NetlistSVG and render the output, offering step-by-step guidance through the process. Similarly, we explain how to generate a DOT file for GraphViz and render its output, ensuring a clear understanding of the procedures involved. Finally, we conduct a detailed side-by-side comparison of the outputs from NetlistSVG and GraphViz, highlighting their differences and similarities to give you a comprehensive view of both tools.
In the previous episodes, we explored how to install and run Yosys. In today’s episode, we’ll delve into generating graphical representations of synthesized netlists using Graphviz and netlist SVG. These visual outputs can help in post-synthesis verification, debugging, and even professional presentations, such as in thesis documents or PowerPoint slides. Let’s break down the process step by step.
Overview of Graphical Outputs
We will create two types of visual outputs:
1. Netlist SVG: A digital circuit-style representation, generated from a JSON (JavaScript Object Notation) file.
2. Graphviz Output: A graph-style visualization from a DOT file.
Both formats offer unique insights into the synthesized netlist, making them invaluable for documentation and debugging.
Getting Started:
First, ensure you’re working in your project directory and launch the Yosys tool from the terminal. Begin by loading the test case files and following the synthesis process:
Synthesis Steps:
1. Read the Verilog file: read_verilog counter.v
2. Run the hierarchy command: hierarchy -check
3. Load the library and synthesize:
read_liberty -lib my_lib.lib
synth -top top_module
4. Write the synthesized netlist: write_verilog synth.v
Once synthesis is complete, we proceed to generate the graphical outputs.
Generating Graphical O/P:
Step 1: Generating the JSON File
To create a JSON representation of the netlist:
1. Use the write_json command: write_json synth.json
2. Open the JSON file to verify its structure. It includes details such as modules, ports, cells, and interconnections. This standardized format is essential for converting the netlist into a visual format.
help write_json#JSON Format write_json synth.json#JSON File Creation for Netlist-SVGhelp show# open synth.json & copy+paste data in the website (https://neilturley.dev/netlistsvg/)
Step 2: Visualizing JSON:
- Copy the JSON content and paste it into a Netlist SVG web interface (URL provided in the description).
- Choose the default settings and click "Render" to generate the visual.
- Save the output as an SVG file for use in documentation or presentations.
Step 3: Generating the Graphviz DOT File
For a graph-style visualization:
1. Use the show command with specific switches:
show -prefix graph -format dot
2. The command generates a `graph.dot` file. This file can be opened using the xdot viewer:
xdot graph.dot &
The graphical output will display the netlist in a connected graph format, complete with nodes and directed edges.
4. Comparing Outputs
The two outputs serve distinct purposes:
- Netlist SVG provides a more circuit-like representation, ideal for digital circuit diagrams.
- Graphviz Graph offers a broader network-style visualization, useful for analyzing connections and dependencies.
Applications of Visual Outputs:
1. Debugging: Identify connections, ports, and interconnects visually to spot issues quickly.
2. Documentation: Enhance the quality of your thesis, reports, or presentations with professional visuals.
3. Verification: Confirm synthesized netlists by visually comparing the outputs with your design expectations.
Conclusion:
Visualizing synthesized netlists using JSON and Graphviz outputs is a powerful way to validate and present your work. Whether for debugging or professional documentation, these tools streamline the process and make your designs more accessible.
Watch the Video lecture Here:
This article comprehensively covers several key points relating to Yosys and GH-Clone. First, it provides a thorough introduction to GH-Clone, elucidating its functionality and guiding viewers through the installation process. Following this, it demonstrates the practical application of GH-Clone by showcasing how to copy Yosys CMOS test cases using this tool. Moreover, the article highlights the execution of Synthesis flow test cases, showcasing a hands-on approach by running and comparing these test cases side by side in two distinct terminals. Finally, it delves into a detailed comparison between the outputs of the two different test cases, providing insights into the nuances and variations between them. Through these discussions and demonstrations, viewers gain a comprehensive understanding of utilizing GH-Clone, executing test cases, and analyzing their outputs within the context of Yosys synthesis.
In the previous episode, we covered the installation of Yosys. Today, we’ll dive into downloading a test case directly from the Yosys GitHub repository using a command-line tool called `gh clone`. Additionally, we’ll demonstrate two approaches to synthesis—using a command macro and performing step-by-step synthesis—before comparing the results to determine the better method.
Revisiting the Test Case with a New Approach :
We’ll start with the same test case used in the last episode but access it differently this time. Using the `gh clone` tool, we’ll download the test case directly from the GitHub repository. If you haven’t installed `gh clone` yet, don’t worry—we’ve got you covered.
After downloading the test case, we’ll create two directories: tc1 and tc2. In each directory, we’ll execute different synthesis methods on the same test case:
1. tc1: Use a high-level synthesis macro (`synth`) to automate the process.
2. tc2: Perform synthesis using detailed step-by-step commands.
Step-by-Step Synthesis vs. High-Level Macro:
Here’s how the synthesis process unfolds:
1. Downloading the Test Case:
Using `gh clone`, we’ll clone the required test case into both directories.
bash gh clone "GitHub-URL-to-test-case"
This creates a directory with the necessary files, ready for synthesis.
2. Launching Yosys:
In each directory, we’ll start Yosys and begin the synthesis process.
3. tc1: Using the Macro Command:
A single `synth` command executes multiple synthesis steps:
- Reading Verilog files.
- Optimizing hierarchical structures.
- Mapping RTL and cell libraries.
- Performing logic synthesis.
4. tc2: Using Baby Steps:
Instead of a single macro, we execute each step manually:
read_verilog: Parses the design into an internal format.
proc: Converts behavioral Verilog into muxes and flip-flops.
opt: Optimizes and cleans up intermediate files.
fsm: Analyzes and optimizes state machines.
techmap: Maps coarse-grained cells to fine-grained logic cells.
- Additional steps for optimization and mapping to library cells.
Each step mirrors the functionality bundled within the `synth` macro, providing deeper insight into the synthesis process.
Comparing Results:
Once synthesis is complete, we generate and compare the output netlists using tkdiff. This allows us to examine:
- Behavioral Verilog vs. synthesized netlist differences.
- Netlist consistency between macro-based and stepwise synthesis methods.
Conclusion: Which Method is Better?
Both methods yield identical synthesized netlists, confirming that the synth macro internally performs the same steps as manual synthesis. However, using the macro is more efficient for most scenarios, while the step-by-step approach is ideal for learning and debugging.
Stay tuned for more deep dives into Yosys workflows! 🚀
In this comprehensive article, we delve into a thorough exploration of several key aspects. Initially, we embark on a website tour of Yosys, where we meticulously navigate through its features, functionalities, and interface, ensuring a nuanced understanding. Following this, we extend our exploration to GraphViz, another integral tool, conducting a detailed website tour to grasp its utility and intricacies effectively. Subsequently, we shift our focus to the practical realm, delving into the Yosys GitHub Repository and Documentation, elucidating its significance in facilitating seamless usage and understanding. Moving forward, we embark on a step-by-step guide to installing Yosys on the Ubuntu Linux platform, ensuring accessibility and ease of implementation for viewers. Similarly, we proceed with the installation of GraphViz on Ubuntu Linux, providing clear instructions to enable smooth integration into the operating system. Moreover, we delve into the practical application of Yosys by executing a CMOS behavioral testcase and effectively converting it into an RTL netlist, demonstrating the practical utility of the software. Lastly, we emphasize the importance of post-synthesis analysis by guiding viewers through the installation of TKDIFF and illustrating its application in comparing pre and post-synthesis Verilog netlists, facilitating a comprehensive understanding of the synthesis process.
Install Yosys on Ubuntu Linux:
In the last four episodes, we covered all theories of synthesis in front-end VLSI design. Now we will-
1. install Yosys on Ubuntu Linux,
2. download a test case from Yosys' GitHub repository,
3. execute it with the installed version.
This is the homepage of Yosys, an open-source synthesis suite. As discussed in previous episodes, Yosys offers extensive documentation, FAQs, and example usage guides. Key resources like papers, slides, and a manual can be downloaded directly from the website.
We’ll also briefly look at Graphviz, a visualization tool often used alongside Yosys. While we won’t cover Graphviz usage in this article , we’ll ensure it’s installed for later parts. Installation process for both Yosys and Graphviz will be demonstrated step-by-step using terminal commands.
Additionally, we’ll explore GitHub to download a sample test case for synthesis. You’ll learn how to parse Verilog files, elaborate design hierarchies, map libraries, and generate the synthesized netlist using Yosys. Finally, we’ll compare the original Verilog code with the synthesized output to understand the transformation.
This article focuses on installation and verification steps; future episodes will delve into detailed synthesis workflows.
In this article, we delve into several advanced topics related to synthesis and optimization using Yosys. We start by discussing the internal methodology of synthesis tools, providing a detailed look at how they function. Next, we explore optimization macros in Yosys, focusing on their role in enhancing the efficiency of the synthesis process. We introduce FSM (Finite State Machine) optimization, explaining its importance and the specific handling macros used in Yosys for this purpose. We also cover the methodology for detecting FSMs in Yosys and the subsequent steps for extracting and optimizing these state machines. Additionally, we discuss technology mapping, which involves substituting cells, gates, and subcircuits to achieve the desired design specifications. Finally, we provide a comprehensive synthesis summary, encapsulating all the key points discussed in the article to give a complete understanding of the synthesis and optimization process.
Synthesis Tool Internal Methodology :
We’ll review the above infographic that explains the key engines in a synthesis tool, using YoSys as a reference. These engines work in sequence to process and optimize your design from HDL to an optimized, technology-specific netlist.
Key Engines in Synthesis:
1. Translation Engine
- Converts the Verilog description (written in any abstraction) into an un-optimized intermediate representation (IR).
- This step happens once and is essential for the subsequent stages.
2. Optimization Engine
- Receives the unoptimized IR and performs multiple iterations of logic optimizations.
- These optimizations aim to improve power, performance, and area (PPA).
- Runs both one-time and iterative optimizations until a predefined goal is achieved.
3. Mapping Engine
- Combines the optimized gate-level netlist with technology-specific data (from standard cell libraries and PDKs).
- Outputs an optimized tech gate-level netlist, embedding technology-specific information.
This flow highlights how each engine plays a distinct role, with the translation engine used once, the optimization engine iterating multiple times, and the mapping engine finalizing the process.
More On Yosys Optimization Macros:
opt_muxtree:
- Optimizes multiplexer cell trees by analyzing select inputs.
- Replaces inner multiplexers with constants to simplify logic where contradictions exist.
opt_reduce:
- Consolidates identical input bits for $reduce_and and $reduce_or cells
- Sorts input bits for easier identification of shareable cells.
- Consolidates identical inputs to multiplexer cells using $reduce_or.
opt_rmdff:
- Replaces single-bit d-type flip-flops with constant drivers if they have constant data inputs.
opt_clean:
- Identifies and removes unused signals and cells.
- Adds "unused_bits" attribute for debugging and other optimizations.
opt_merge:
- Performs resource sharing by replacing cells with identical inputs with a single instance.
- Option "-nomux" disables resource sharing for multiplexer cells ($mux and $pmux) to preserve multiplexer trees for later optimizations
FSM Optimization : Introduction
Extracting the FSM Logic:
This means finding, taking out, and changing the part of a computer program that acts like a decision-maker into a special format. Think of it like finding and organizing the rules that a computer follows to make decisions.
Optimizing the State Table:
Making the decision-making part more efficient. This involves making the rules simpler and using as few resources as possible. It's like making a car run better by using less fuel and having less traffic.
FSM Handeling Macros in Yosys:
The fsm pass performs finite-state-machine (FSM) extraction and re-coding. The fsm pass simply executes the following other passes:
Identify and extract FSMs: fsm_detect, fsm_extract
Basic optimizations:fsm_opt, opt_clean , fsm_opt
Expanding to nearby gate-logic (along with -expand): fsm_expand, opt_clean, fsm_opt
Re-code FSM states (unless called with -norecode): fsm_recode
Print information about FSMs: fsm_info,
Export FSMs in KISS2 file format (along with -export): fsm_export
Map FSMs to RTL cells (unless called with -nomap): fsm_map
FSM Detection Methodology In Yosys :
Identifying FSM State Registers:
- There's a process called "fsm_detect" that looks for special memory-like parts in a computer program.
- It marks these parts as important by giving them a label called "\fsm_encoding = "auto"" under certain conditions.
- It only does this for parts that meet specific criteria, like not already having the label and being connected in a certain way.
Why This Matters:
This helps make the program run better and faster.
But, it's essential to be careful because wrongly labeling these parts can cause problems.
Steps in the Process:
First, the "fsm_detect" process finds and labels these special parts.
Then, another process called "fsm_extract" takes these labeled parts and replaces them with something more efficient.
After that, there are more processes that work with these special parts.
Finally, there's a step called "fsm_map" that turns them back into regular parts.
N.B: All of these processes happen to a list of instructions, like a recipe. They should be done in the right order, and only after certain other things have been done to the instructions.
FSM Extraction and Optimization :
What fsm_extract Does:
- It works on specific signals marked as important (not labeled "none").
- For each of these important signals, it figures out:
- Which are the special memory-like parts.
If these parts have a special reset condition.
All the different situations these parts can be in.
What results come from these situations.
A list of all the changes that can happen and the reasons why.
How It Works:
To find the special memory-like parts, it follows the path that controls them. It also looks at the values these parts compare to and how they affect other things. It makes a table that shows all the possible changes in these special parts.
FSM Extraction and Optimization :
Creating the Table:
To make the table, it uses a special tool called "ConstEval." It goes through each situation and tries to figure out what happens next. If it can't, it tries again with different conditions. Once it knows all the possible changes, it makes a table. After all this, it makes a special part in the program and connects it to the important signals. It disconnects any old connections that are not needed anymore.
Optimizing with fsm_opt:
Later, there's another process called "fsm_opt" that makes this special part run even better. It does things like removing unnecessary parts, combining similar parts, and making sure everything works efficiently.
Technology Mapping : Cell Substitution
Phase 1 - RTL to Internal Cells: In the first phase, RTL cells are mapped to an internal library of single-bit cells. This phase helps in converting high-level RTL descriptions into a more abstract internal representation.
Phase 2 - Internal Cells to Target Technology Gates: In the second phase, the netlist composed of internal gate types is transformed into a netlist of gates from the target technology library. This phase adapts the design to the specific hardware technology being used.
Mapping Coarse-Grain Cells: When the target architecture includes coarse-grain cells like block RAM or ALUs, these must be directly mapped to the RTL netlist. This is necessary because information about the coarse-grain structure is lost when mapping to bit-width gate types.
Cell Substitution (Techmap Pass): The simplest form of technology mapping involves cell substitution, which is performed by the techmap pass. It replaces RTL cells with a provided implementation using simpler cells.
Mapping without a Map File: If no specific map file is provided, techmap uses a built-in map file that translates Yosys RTL cell types into the internal gate library used by Yosys. This map file can be found in the Yosys source tree.
Conditional Mapping: Additional features in techmap allow for conditional mapping of cells. This is useful when the target architecture supports certain hardware features for specific bit-widths but not for others. Conditional mapping allows for flexibility in choosing the appropriate cell types based on the design requirements.
Typical Synthesis Flow: In a typical synthesis flow, the techmap pass is used first to directly map some RTL cells to coarse-grain cells provided by the target architecture (if available). Then, techmap with the built-in default map file is used to map the remaining RTL cells to gate logic in the target technology library. This two-phase approach ensures efficient technology-specific synthesis of the design.
Technology Mapping : SubCkt Substitution
In VLSI synthesis, sometimes the target architecture offers more powerful cells than those available in RTL descriptions used by Yosys. For instance, a target architecture may have cells capable of performing complex operations like calculating the absolute difference of two numbers, which cannot be directly matched with single RTL cell types but require combinations of cells.
To address this, Yosys provides the "extract" pass, which serves several purposes:
Identifying Isomorphic Subcircuits: The extract pass can match a given set of modules against a design and identify portions of the design that are structurally identical (isomorphic subcircuits) to any of the provided modules. These matched subcircuits can then be replaced by instances of the specified modules.
Handling Basic Variations: The extract pass can also recognize basic variations of the given modules, such as cases with swapped inputs on commutative cell types.
Frequent Subcircuit Mining: The extract pass has limited support for frequent subcircuit mining, which involves finding recurring subcircuits within the design. This capability has applications in designing new coarse-grain architectures.
The algorithmic work performed by the extract pass, including solving the isomorphic subcircuit problem and conducting frequent subcircuit mining, is accomplished using the SubCircuit library. This library can be used independently of Yosys and provides the necessary functionality for these tasks.
Technology Mapping : Gate Level
Liberty File: Target architectures at the gate-level are described using a "Liberty file," an industry-standard format that details the behavior and properties of standard library cells.
Mapping Phases: Mapping a design to the Yosys internal gate library is a two-phase process:
Register Cell Mapping: Initially, register cells in the design need to be mapped to the registers available in the target architecture. The target architecture may not provide all variations of flip-flops, so additional logic like inverters may be added. It's crucial to map register cells first. The "dfflibmap" pass, using a Liberty file as an argument, performs this mapping.
Combinational Logic Mapping: The second phase involves mapping the combinational logic to the target architecture. This is achieved using the external program ABC via the "abc" pass, with the -liberty option specifying the Liberty file. Only the combinational cells from the library are used in this case.
Sensitive Information: Some Liberty files may contain sensitive trade secrets, such as timing data, making it challenging to share or report issues with the tools. To address this, the "yosys-filterlib" tool can be employed to remove sensitive information from the Liberty file, ensuring that non-sensitive data can still be used for synthesis without revealing proprietary details.
Synthesis Summary:
Don't-Care Conditions: Assignments to 'x' in a case or an if statement are treated as don't-care conditions during synthesis.
Casex and Casez Statements: Synthesis tools treat 'casex' and 'casez' statements as regular 'case' statements.
Conditional Operator and Three-State Device: When a conditional operator assigns 'z' to the right-hand side expression in a continuous assignment within a level-sensitive block, it will be synthesized into a three-state device driven by combinational logic.
Operator Grouping with Parentheses: Using parentheses helps control operator grouping and reduce circuit size.
Feedback-Free Netlist: Combinational primitives in a feedback-free netlist will be synthesized into latch-free combinational logic.
Continuous Assignments: Feedback-free continuous assignments are synthesized into latch-free combinational logic, but those with feedback are synthesized into latches.
Completeness in Combinational Logic: A Verilog description of combinational logic must ensure that outputs are assigned values for all possible input combinations.
If Statements and Latches: If an if statement in a level-sensitive block assigns a value to a register variable in some branches but not all, it will be synthesized into a latch.
Edge-Sensitive Blocks: Variables referenced within an edge-sensitive block before being assigned a value will be synthesized as flip-flop outputs (e.g., nonblocking assignment).
Elimination of Unused Variables: Variables assigned within a block but not referenced outside it will be eliminated during synthesis (e.g., iteration constants).
Edge-Sensitive Block Outputs: Variables assigned within an edge-sensitive block and referenced outside will be synthesized as flip-flop outputs (e.g., declared as output ports).
State Machine Design: To describe an explicit state machine, use two cyclic blocks: a level-sensitive block for combinational logic and outputs in the next state, and an edge- sensitive block to synchronize state transitions.
Procedural and Nonblocking Assignments: In level-sensitive cyclic blocks describing combinational logic, use the procedural assignment operator ('='). In edge-sensitive cyclic blocks describing state transitions and register transfers, use the non-blocking assignment operator ('<=').
In this article, we delve into several critical topics related to the synthesis process and verification in VLSI design. We begin by discussing pre-synthesis checks and the standard verification methodology, emphasizing the importance of these steps in ensuring a robust design. Next, we explore synthesizable HDL constructs, highlighting the specific coding practices that enable efficient synthesis. We then examine the role of the standard cell library in synthesis, explaining how these pre-characterized cells facilitate the design process. We provide an overview of the generic internal process steps of synthesis, detailing what happens during synthesis and illustrating these stages with informative infographics that depict both the initial and final stages of logic synthesis. Additionally, we discuss two types of optimizations in Yosys, a popular open-source synthesis tool, and explain the constant folding algorithm, which is crucial for optimizing the design by evaluating constant expressions at compile time.
Pre-Synthesis Checks :
1. Functional Design Verification:
-Confirm the design's functional accuracy
- Follow a verification methodology.
2. Verification Approach:
- Create a verification plan based on the design spec
- Develop test-benches for simulation.
3. Verification Steps:
-Instantiate the Design Under Test (DUT) to test.
- Apply input stimuli to the DUT.
- Verify the DUT's output against expected results.
4. Testbench Execution:
-Utilize HDL simulators for testbench execution
- For Verilog: Choose from icarus verilog or verilator
- For VHDL: Opt for GHDL for simulation.
Standard Verification Methodology :
1. Directed Tests:
- Prepare input stimuli (test vectors) manually.
- Detects bugs based on known issues.
2. Constrained Random Verification:
- Randomize input stimuli with specific constraints.
- Uncertainty about which functions are tested.
3. Coverage:
- Measures testing comprehensiveness.
- Includes code coverage and functional coverage.
4. Universal Verification Methodology (UVM):
- SystemVerilog-based class library.
- Highly powerful but intricate.
- Contains over 300 classes.
- Limited familiarity for graduate students new to SystemVerilog.
5. Open Source VHDL Verification Methodology (OSVVM):
- VHDL-based library - Resembles UVM in concept
Synthesizable HDL Constructs :
Synthesizable Verilog/VHDL:
- Designed for hardware description and synthesis to physical circuits.
- Uses hardware constructs like flip-flops, logic gates, and multiplexers.
- Focuses on sequential and combinational logic.
- Timing is critical; designs must meet setup and hold time requirements.
- Typically follows specific coding guidelines for synthesis compatibility.
- Emphasizes efficient resource utilization and timing closure.
- Suitable for implementing designs on FPGA or ASIC hardware.
Non-Synthesizable Verilog/VHDL:
- Used for modeling behavior and simulation purposes.
- Can include constructs that don't directly map to hardware, like delays and tasks.
- Focuses on functionality and ease of simulation.
- Timing considerations might be less critical or not relevant.
- Offers more flexibility in coding style and language features.
- Used for test benches, simulation of functional behavior, and algorithmic modeling.
- Not guaranteed to produce functional hardware when directly synthesized.
Standard Cell Library & Synthesis:
Synthesis requires attaching a technology library, making it essential to understand the standard cell library. Here are key episodes to enhance your knowledge:
- A crucial episode from the STA series that explains timing library contents, electrically characterized data, and how to retrieve cell-specific information.
Synthesis Internal Process Steps :
This flowchart outlines the internal process of any synthesis tool, starting with the HDL description (e.g., Verilog or VHDL) and progressing through key steps. Note that this is not the full VLSI design flow but rather a generic representation of synthesis. While the process may vary between EDA tools, the core steps are similar.
1. HDL Translation:
- The HDL description is translated into an unoptimized intermediate representation.
2. Logic Optimization:
- Synthesis tools apply optimization algorithms to improve PPA (Power, Performance, Area) for the target design.
3. Technology Mapping and Optimization:
- Includes design constraints to ensure the synthesis stays within specified boundaries.
- Incorporates a technology-specific standard cell library for mapping.
- The choice of standard cells is influenced by variations like high-Vt, low-Vt, fast/slow processes, and PVT (Process, Voltage, Temperature) variations.
For a deeper understanding, watch related episodes covering PVT and RC corner variations, as well as PPA optimization, linked in the video description.
4. Optimized Gate-Level Netlist:
- The final output is an optimized, technology-specific gate-level netlist, ready for the next stage of the design flow.
Synthesis connects the generic design (written in HDL) to a specific technology node by integrating the library and constraints. This process marks the beginning of technology-specific implementation.
What Happens During Synthesis :
Two-Level Boolean Minimization:
- Crucial for optimization.
- Targets finite state machines for improvement.
- Aims to reduce product terms and their sizes for a more compact and faster implementation.
- Seeks to find an equivalent FSM with fewer states.
- Advisable to reduce the problem size before technology mapping and technology-dependent optimizations.
Automatic Synthesis of Logic Implementation:
- Involves several steps:
- HDL synthesis programs process the code.
- These programs infer logic and state elements.
- Technology-independent optimizations are performed, including logic simplification and state assignment.
- Elements are mapped to the target technology.
- Technology-dependent optimizations are applied, such as multi-level logic optimization.
Logic Synthesis : Initial & Final Stages
Logic synthesis, the initial and the final stages. In this slide, we will explain using infographics and we will point out the things that we have said during the last flowchart we have explained. Here, the table contains 3 columns. 1st column is named as equation, so here we'll have the Boolean equation. Next, we have the initial intermediate netlist and sometimes this is called the initial netlist or the intermediate netlist also.
And here, we will show you the final optimized netlist. Sometimes it is called the final netlist and sometimes it is called the optimized netlist also. These names can have variants from either taking partial name from these 2 or from these 2. And so you must be very careful and hence, we have included all the possible words here. And we'll have 2 different rows.
That means we'll be talking about 2 different equations. So the first equation is this is a Boolean equation. You can see z equals to a and b and which we are ordering with c. How the netlist will look? So there will be then this netlist.
So there is a ending b and all is or to c. So this is c is or to the a and b. And there's a very simple thing that we can draw by hand. So this will be done by the synthesis tool as a initial netlist. However, as it further goes down and goes through optimization, it will transform it for the technology optimized one.
So here you can see the NAND gates are there. These are the gates which require less spaces. Obviously, this netlist can be in a different form and shape as per the kind of technology optimization that you are doing. As part of the library, as part of the PPA and the PVD and RC corner, all those things. Obviously, RC will not come here because it's a front end.
However, for the process corners and all those things, they will be there. And they will be residing inside the standard cell library. That's why I have just uttered these terms. Next equation is z is equal to del then question mark then a or b. So this is a ternary operator, you know, from Verilog language.
Or even this ternary operator is there in the c language also. However, this gives out a mux, which is a 2 to 1 mux where c is the selecting. So, generally, this is the initial net list that will be generated by the synthesis tool After a set of optimization and including the technology optimization, it might result bucket like this, where we have either the feed optimized or the area optimized gates. So these are the technology gates that are from the standard cell library. So all those things will be there.
Or it might happen the standard cell has different variants of this particular mux in it, and the required mux will be picked up by the synthesis tool. That can also happen. These are not hard coded things and these are set of infographics for understanding. I am not hard coding that this will happen or that will happen. I am not predicting that.
So you have to be very careful when you are running this kind of optimization and you will see that what kind of optimization is done and what is the initial, what is the final netlist. Here we are done through the infographics for the initial and the final stages of the optimization or a circuit. And this is just an example. The actual case may have different form and shapes of, initial and the final net list. We are done talking about this.
So let's move on to the next slide. Two types of optimization. Here, basically, we will talk about 2 different types of optimization that we do in Eosys as a synthesis tool. 1st, there are optimizations. The first type of optimization, initial or non recursive, that means they will be only at the beginning and they will optimize once.
And there are some of the optimization that are recursive. That means, these will repeat until a stable result is achieved. So these are optimization algorithms. Some of them will run one time and some of them will run multiple time. EOC's optimization passes.
EOC offers optimization passes for HDL synthesis including the opt pass, which performs various simple optimizations. These optimizations involve removing unused signals and cells and constant folding. This is another algorithm that we will be talking in the next slide. It's recommended to run the opt pass after significant synthesis script steps for better results. So this is an algorithm that we can include more than one time.
The opt pass comprises multiple individual passes. So this is basically a macro, and that will contain multiple optimization processes. Each of the substeps focusing on specific simple optimization task. So once you run the opt routine, it will run small small steps. That is the beauty of having a synthesis tool where there are some macros which contains some couple of set of optimization that will run once you execute that particular optimization.
And it is called optimization. It is not called a macro. Macro is a generic term that we are using. A macro is a set of commands are tied together. That is the definition of a macro.
And in VLSI, you will find another macro which is called a macro cell. We are clarifying it right away.
Two Types of Optimizations:
Yosys Optimization Passes:
Yosys offers optimization passes for HDL synthesis, including: The "opt" pass, which performs various simple optimizations. These optimizations involve removing unused signals and cells, and constant folding. It's recommended to run the "opt" pass after significant synthesis script steps for better results. The "opt" pass comprises multiple individual passes, each focusing on specific simple optimization tasks.
Constant Folding Algorithm :
The "opt_expr" pass in Yosys focuses on constant folding for internal combinational cell types. It replaces cells with all constant inputs with the constant value they drive, and sometimes optimizes cells with some constant inputs. Replacement rules for optimizing $_AND_ gates are defined, including const folding and propagation of undef (X) states. Undef states are allowed to propagate only in specific cases, as per IEEE Std. 1364-2005. In cases where no other substitutions are possible in the module, the pass assumes the value 0 for undef states. $_AND_ gates with a constant-1 input can be replaced with a buffer. Additionally, 1-bit wide $eq and $ne cells with one constant input can be replaced with buffers or not-gates. The "opt_expr" pass is cautious when optimizing $mux cells to avoid interfering with decision-tree modeling and other optimizations.
