chapter 2

figures/asic_flow.tex

@@ -1,7 +1,7 @@
 
 \begin{figure}[t]
-    \label{fig:asic_flow}
     \centering
     \includegraphics[width=90mm]{figures/asic_flow.jpg}
     \caption{Abbreviated diagram of ASIC design flow published by Kynix \cite{kynixDesignFlow}}
+    \label{fig:asic_flow}
 \end{figure}

figures/dc_vs_synplify.tex

@@ -1,7 +1,7 @@
 
 \begin{figure}[t]
-    \label{fig:dc_vs_synplify}
     \centering
     \frame{\includegraphics[width=\linewidth]{figures/dc_vs_synplify.pdf}}
     \caption{Differences in SystemVerilog Support in DC vs. Synplify-Pro from ``Synthesizing SystemVerilog: Busting the Myth that SystemVerilog is only for Verification''\cite{sutherland}}
+    \label{fig:dc_vs_synplify}
 \end{figure}

tex/chapters/1_introduction.tex

@@ -6,7 +6,7 @@ \chapter{Introduction}
 
 \input{figures/asic_flow}
 
-In the semiconductor industry, the process of designing an application-specific integrated circuit (ASIC) follows a well-defined sequence, where each step requires training and practice. \cite{intelDesignFlow, anysiliconDesignFlow, kynixDesignFlow} The following presents an abbreviated flow tailored for students and open-source tool usage, as illustrated in \autoref{asic_flow}. This process begins with the design phase, where engineers specify the functionality and requirements of the finished integrated circuit (IC). Then, they use hardware description languages (HDLs) like SystemVerilog to detail the circuit's operations and verify its correctness through simulation. After the HDL implementation passes a series of behavioral simulations, it is synthesized for the standard cell library of the target and paired with additional digital and mixed-signal IP blocks. Further testing can include running logical equivalence checks (LECs) to ensure the synthesized netlist is correct, rerunning the behavioral simulations on the synthesized netlist to check for reset behavior, or by running intensive simulations on an FPGA. Once these circuit-level tests pass, layout is completed according to timing constraints and design rule checks (DRC). If timing cannot be met, the layout or HDL implementation may need to be adjusted. Finally, after the layout and simulations checks pass, the design is converted into a Graphic Data Stream (GDS) file which is sent to a semiconductor foundry for mass-production.
+In the semiconductor industry, the process of designing an application-specific integrated circuit (ASIC) follows a well-defined sequence, where each step requires training and practice. \cite{intelDesignFlow, anysiliconDesignFlow, kynixDesignFlow} The following presents an abbreviated flow tailored for students and open-source tool usage, as illustrated in \autoref{fig:asic_flow}. This process begins with the design phase, where engineers specify the functionality and requirements of the finished integrated circuit (IC). Then, they use hardware description languages (HDLs) like SystemVerilog to detail the circuit's operations and verify its correctness through simulation. After the HDL implementation passes a series of behavioral simulations, it is synthesized for the standard cell library of the target and paired with additional digital and mixed-signal IP blocks. Further testing can include running logical equivalence checks (LECs) to ensure the synthesized netlist is correct, rerunning the behavioral simulations on the synthesized netlist to check for reset behavior, or by running intensive simulations on an FPGA. Once these circuit-level tests pass, layout is completed according to timing constraints and design rule checks (DRC). If timing cannot be met, the layout or HDL implementation may need to be adjusted. Finally, after the layout and simulations checks pass, the design is converted into a Graphic Data Stream (GDS) file which is sent to a semiconductor foundry for mass-production.
 
 Because of how many skills are required to create an ASIC design it is crucial for Universities to offer a strong foundation for writing and working with HDLs to design hardware. Nevertheless, HDLs come with a formidable learning curve, partly due to the difficulties of distinguishing between what code is synthesizable (able to be converted into hardware) and what should be used solely for verification purposes. Additionally, the prevalence of bugs in common HDL tools, the extraordinary inaccessibility of proprietary tools, and the lack of reliable online educational resources are a major deterrent for students and hobbyists who wish to experiment with digital design on their own. Another factor contributing to the complexity is the interdisciplinary nature of ASIC design. For many students, especially those with a software background, this may be their first experience with hardware design, while hardware students must also transition into a more software-centric environment. Bridging this gap and understanding both aspects is vital in today's world of using computer-aided design (CAD) software to design hardware. Universities must recognize the formidable learning curve associated with HDLs and provide comprehensive educational resources, practical hands-on experiences, and interdisciplinary exposure to prepare students for the intricate realm of ASIC design.
 

tex/chapters/2_open_source_tools.tex

@@ -2,22 +2,22 @@
 \chapter{Advantages of Open-Source Tools in Education}
 \label{chapter:open_source_tools}
 
-Although proprietary Verilog tools are predominant in industry and often boast a wide assortment of features, I argue that they can be one of the biggest deterrents for those first learning digital design. Whether students become aghast at the preposterous licensing fees or become hung up on the steep learning curve of the interfaces, the most popular Verilog tools often have trouble exciting students into furthering their Verilog education. Fortunately, there are several open-source Verilog tools that are praised for their accessibility and ease-of-use. A valuable resource for open-source hardware tools, generators, and reusable designs can be found in the curated list provided here: \url{https://github.com/aolofsson/awesome-opensource-hardware}. For example, a common collection of tools include the simulators Icarus [ref] and Verilator [ref], the waveform viewer GTKWave [ref], the synthesis tool Yosys [ref], the FPGA place and route tools Nextpnr [ref] and VTR [ref], the ASIC flow OpenLane [ref], and the hardware package manager and build system FuseSoC [ref]. In this section, I will explain why open-source tools excel over proprietary tools in introducing Verilog and digital design to students.
+Although proprietary Verilog tools are predominant in industry and often boast a wide assortment of features, I argue that they can be one of the biggest deterrents for those first learning digital design. Whether students become aghast at the preposterous licensing fees or become hung up on the steep learning curve of the interfaces, the most popular Verilog tools often have trouble exciting students into furthering their Verilog education. Fortunately, there are several open-source Verilog tools that are praised for their accessibility and ease-of-use. A valuable resource for open-source hardware tools, generators, and reusable designs can be found in the curated list provided here: \url{https://github.com/aolofsson/awesome-opensource-hardware} \cite{awesomeOpenSourceHardware}. For example, a common collection of tools include the simulators Icarus \cite{icarusGitHub} and Verilator \cite{verilatorGitHub}, the waveform viewer GTKWave \cite{gtkwaveGitHub}, the synthesis tool Yosys \cite{yosysGitHub}, the FPGA place and route tools Nextpnr \cite{nextpnrGitHub} and VTR \cite{vtrGitHub}, the ASIC flow OpenLane \cite{OpenLaneGitHub}, and the hardware package manager and build system FuseSoC \cite{fusesocGitHub, edalizeGitHub}. In this section, I will explain why open-source tools excel over proprietary tools in introducing Verilog and digital design to students.
 
 \section{Proprietary tool prices deter students.}
 
-Many students choose to pursue a degree in computer engineering due to the plethora of creative outlets that it introduces them to. Consider the hands-on process of purchasing affordable components and assembling circuits on breadboards. Likewise, platforms like Arduinos and Raspberry Pis are often explored alongside the utilization of programming languages such as C++, Python, and JavaScript. The accessibility and low cost of these mediums often foster self-directed learning. Similarly, introductory Verilog courses can serve as yet another avenue for creative expression, particularly when orchestrated using free and open-source tools. However, a significant obstruction emerges when proprietary alternatives such as Questa, VCS, and Xcelium, coupled with licensing fees over \$5,000, [ref] become the focal point of a student's introduction to Verilog. Such financial barriers can easily deter enthusiasm for self-guided learning, particularly when students anticipate losing access to the software upon graduation. This is likely the reason why several students in UC Santa Barbara's Verilog courses choose to disobey the requirement of using ModelSim, and instead use Icarus and GTKWave. Students don't want to feel like their time is wasted learning a tool if they lose access to it upon graduation.
+Many students choose to pursue a degree in computer engineering due to the plethora of creative outlets that it introduces them to. Consider the hands-on process of purchasing affordable components and assembling circuits on breadboards. Likewise, platforms like Arduinos and Raspberry Pis are often explored alongside the utilization of programming languages such as C++, Python, and JavaScript. The accessibility and low cost of these mediums often foster self-directed learning. Similarly, introductory Verilog courses can serve as yet another avenue for creative expression, particularly when orchestrated using free and open-source tools. However, a significant obstruction emerges when proprietary alternatives such as Questa, VCS, and Xcelium, coupled with licensing fees over \$5,000, \cite{olofssonLatchUp, licensePricesReddit} become the focal point of a student's introduction to Verilog. Such financial barriers can easily deter enthusiasm for self-guided learning, particularly when students anticipate losing access to the software upon graduation. This is likely the reason why several students in UC Santa Barbara's Verilog courses choose to disobey the requirement of using ModelSim, and instead use Icarus and GTKWave. Students don't want to feel like their time is wasted learning a tool if they lose access to it upon graduation.
 
 \section{Open-source tools are easy to install.}
 
-Even if students aren't hoping to expand their arsenal of tools for expressing their creativity, it is still important to keep Verilog tools accessible by improving students' first-time user experience. For example, Vivado is infamous for its tedious and complex installation process while taking up over 16-60GB when installed. This is contrasted with the overall positive first-time user experience that open-source tools offer. For example, with the ``OSS CAD Suite'' project [ref], you can download all the latest binaries of the most popular open-source Verilog tools in under a minute. This beats Vivado's complicated installation process by a mile and is more-likely to remain on student's computers after the course is over since all the tools only take up half a gigabyte, as opposed to the 16-60GB that Vivado requires.
+Even if students aren't hoping to expand their arsenal of tools for expressing their creativity, it is still important to keep Verilog tools accessible by improving students' first-time user experience. For example, Vivado is infamous for its tedious and complex installation process while taking up over 16-60GB when installed. This is contrasted with the overall positive first-time user experience that open-source tools offer. For example, with the ``OSS CAD Suite'' project \cite{osscadsuitebuildGitHub}, you can download all the latest binaries of the most popular open-source Verilog tools in under a minute. This beats Vivado's complicated installation process by a mile and is more-likely to remain on student's computers after the course is over since all the tools only take up half a gigabyte, as opposed to the 16-60GB that Vivado requires.
 
 \section{Unique benefits and features of open-source tools.}
 
-Undoubtedly, proprietary tools offer a multitude of functionalities for advanced users that open-source tools cannot offer. However, open-source tools offer many unique features that are more desired by beginners. For example, Icarus runs short simulations much faster than proprietary simulators, making it perfect for receiving instant feedback as students are still learning the language syntax. Similarly, Yosys and Nextpnr perform synthesis and layout significantly faster than tools such as Vivado and Design Compiler, allowing for more rapid prototyping. Also, while ModelSim may happily parse and simulate un-synthesizable code, Verilator will give much more strict warnings, helping to demonstrate the syntax and features that should be allowed in synthesizable designs. (This is further discussed in Section III.) Finally, open-source tools get updates every day, and instructors are able to report bugs and request new features. Depending on the difficulty of the request, the tool maintainers may complete the request within a few months. Multiple of my courses have directly benefited from this [appx]. Instructors may even decide they want to do a pull-request themselves; I personally have contributed two new warnings to Verilator in hopes of teaching best-practices. [appx] This is contrasted with the fact that many universities are not always running the most up-to-date proprietary software. For example, as of 9/10/23, UC Santa Barbara's Engineering Computing Infrastructure's latest version of ModelSim is 10.7d (from April 2019), which does not support width-casting from parameters, which affected the UCSB Spring 2023 ECE 152A course experience. Bugs in tools will undoubtedly happen, but the only solution Siemens offers is to pay for an updated version with the bug fixed. Contrast this with submitting a GitHub issue with Verilator, and having the bug fixed by the next time the course is offered. Open-source tools are often simply the better choice for instructors.
+Undoubtedly, proprietary tools offer a multitude of functionalities for advanced users that open-source tools cannot offer. However, open-source tools offer many unique features that are more desired by beginners. For example, Icarus runs short simulations much faster than proprietary simulators, making it perfect for receiving instant feedback as students are still learning the language syntax. Similarly, Yosys and Nextpnr perform synthesis and layout significantly faster than tools such as Vivado and Design Compiler, allowing for more rapid prototyping. Also, while ModelSim may happily parse and simulate un-synthesizable code, Verilator will give much more strict warnings, helping to demonstrate the syntax and features that should be allowed in synthesizable designs. (This is further discussed in \autoref{chapter:digital_design}.) Finally, open-source tools get updates every day, and instructors are able to report bugs and request new features. Depending on the difficulty of the request, the tool maintainers may complete the request within a few months. Multiple of my courses have directly benefited from this [appx]. Instructors may even decide they want to do a pull-request themselves; I personally have contributed two new warnings to Verilator in hopes of teaching best-practices. [appx] This is contrasted with the fact that many universities are not always running the most up-to-date proprietary software. For example, as of 9/10/23, UC Santa Barbara's Engineering Computing Infrastructure's latest version of ModelSim is 10.7d from April 2019, which does not support width-casting from parameters, which affected the UCSB Spring 2023 ECE 152A course experience. Bugs in tools will undoubtedly happen, but the only solution Siemens offers is to pay for an updated version with the bug fixed. Contrast this with submitting a GitHub issue with Verilator, and having the bug fixed by the next time the course is offered. Open-source tools are often simply the better choice for instructors.
 
 \section{Avoid graphical user interfaces.}
 
-One of the most important ways to make Verilog more accessible is by guiding students to use command line interfaces (CLIs). Nearly all large-scale Verilog designs are paired with user-friendly build scripts and Makefiles for running simulation and synthesis. [ref] This is contrasted with the complex graphical user interfaces in tools like Vivado, ModelSim, VCS, and Quartus, which can feel daunting for beginners due to the number of options that users have direct access to. UC Santa Cruz Professor Dustin Richmond compares learning Vivado to being stuck in a ``point-and-click adventure game'' in his talk ``So, you want to be an open sourcerer?'' [ref]. By using CLIs, you can abstract away and decouple tool-specifics from digital design concepts.
+One of the most important ways to make Verilog more accessible is by guiding students to use command line interfaces (CLIs). Nearly all large-scale Verilog designs are paired with user-friendly build scripts and Makefiles for running simulation and synthesis. This is contrasted with the complex graphical user interfaces in tools like Vivado, ModelSim, VCS, and Quartus, which can feel daunting for beginners due to the number of options that users have direct access to. UC Santa Cruz Professor Dustin Richmond compares learning Vivado to being stuck in a ``point-and-click adventure game'' in his talk ``So, you want to be an open sourcerer?'' \cite{RichmondLatchUp}. By using CLIs, you can abstract away and decouple tool-specifics from digital design concepts.
 
-To aid in the usually lengthy crafting of TCL scripts and Makefiles, an extremely powerful pair of open-source tools named FuseSoC and Edalize [ref] attempt to standardize build files for all Verilog tools with a central \mintinline{bash}{.core} file. The \mintinline{bash}{.core} file, interpretable by FuseSoC, contains the ``run'' specifications, which are then seamlessly communicated to Edalize for the automated generation and execution of build scripts with the designated tool. FuseSoC is compatible with nearly every Verilog tool, so switching simulators is often as easy as changing one line of code. While TAing for UCSB's ECE 152A, 154A, and 154B, I capitalized on the utility of FuseSoC and Edalize to substantially accelerate assignment setup time. I could provide students with the Makefile automatically generated by Edalize, or I could provide the \mintinline{bash}{.core} file for students to run themselves with FuseSoC. Either option was effective in simplifying the build process so students could better focus on the learning-goals of the assignments.
+To aid in the usually lengthy crafting of TCL scripts and Makefiles, an extremely powerful pair of open-source tools named FuseSoC and Edalize \cite{fusesocGitHub, edalizeGitHub} attempt to standardize build files for all Verilog tools with a central \mintinline{bash}{.core} file. The \mintinline{bash}{.core} file, interpretable by FuseSoC, contains the ``run'' specifications, which are then seamlessly communicated to Edalize for the automated generation and execution of build scripts with the designated tool. FuseSoC is compatible with nearly every Verilog tool, so switching simulators is often as easy as changing one line of code. While TAing for UCSB's ECE 152A, 154A, and 154B, I capitalized on the utility of FuseSoC and Edalize to substantially accelerate assignment setup time. I could provide students with the Makefile automatically generated by Edalize, or I could provide the \mintinline{bash}{.core} file for students to run themselves with FuseSoC. Either option was effective in simplifying the build process so students could better focus on the learning-goals of the assignments.