final spelling and formatting

tex/chapters/1_introduction.tex

@@ -2,7 +2,7 @@
 \chapter{Introduction}
 \label{chapter:introduction}
 
-At the end of Dennard scaling, it may be tempting to think that VLSI and digital design are becoming less-important engineering fields. However, the United States government wouldn't agree, considering they are investing \$280 billion over the next ten years into the CHIPS Act \cite{mckinsey}. Similarly, TSMC, the world's leading semiconductor manufacturer, is expecting to open three new advanced-node fabs in 2024 \cite{taipeitimes}. In addition, in 2020, Google started a partnership with GlobalFoundries, SkyWater Technology, and Efabless to provide fully open-source Process Design Kits (PDKs) and toolchains to lower the barrier of entry for new Silicon engineers \cite{GooglePartnersWithSkyWater, googleSilicon}. Investments like these have created a never-ending demand for chip developers, and Universities should be working to meet this demand.
+At the end of Dennard scaling, it may be tempting to think that VLSI and digital design are becoming less-important engineering fields. However, the United States government wouldn't agree, considering they are investing \$280 billion over the next ten years into the CHIPS Act \cite{mckinsey}. Similarly, TSMC, the world's leading semiconductor manufacturer, is expecting to open three new advanced-node fabs in 2024 \cite{taipeitimes}. In addition, in 2020, Google started a partnership with GlobalFoundries, SkyWater Technology, and Efabless to provide fully open-source Process Design Kits (PDKs) and tool-chains to lower the barrier of entry for new Silicon engineers \cite{GooglePartnersWithSkyWater, googleSilicon}. Investments like these have created a never-ending demand for chip developers, and Universities should be working to meet this demand.
 
 \input{figures/asic_flow}
 

tex/chapters/2_open_source_tools.tex

@@ -14,7 +14,7 @@ \section{Open-source tools are easy to install.}
 
 \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 often better for 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{section:style_guides}).
+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 often better for 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 unsynthesizable 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{section:style_guides}).
 
 But possibly the most important attribute of open-source tools is that they get updates every day, and offer full transparency when reporting bugs and requesting new features. Depending on the difficulty of the request, the tool maintainers may complete the request within a few weeks. Instructors may even decide they want to do a pull-request themselves; I personally have made several contributions to multiple tools (see \autoref{appx:contributions}). 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. This negatively affected one of the UCSB Spring 2023 ECE 152A labs. 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 and students alike.
 

tex/chapters/4_resources.tex

@@ -8,14 +8,14 @@ \section{Stuart Sutherland's synthesis guide is most valuable.}
 
 \enquote{Synthesizing SystemVerilog: Busting the Myth that SystemVerilog is only for Verification} by Stuart Sutherland and Don Mills acts as a comprehensive list of synthesizable SystemVerilog features. Despite the absence of an official SystemVerilog synthesis standard, this paper gives valuable insight into synthesizable language features, emphasizing their practical application into modern hardware designs. Sutherland and Mills surveyed the Synopsys tools, Design Compiler and Synplify-Pro, to trace the evolution of Verilog-1984 though SystemVerilog-2009 as a comprehensive hardware design and verification language. To assist those working on \enquote{Labs with CVA6}, I composed and included a summary of Sutherland's synthesis guide \cite{labsWithCVA6}. Since then, I have shared this summary with dozens of students looking to improve their understanding of synthesizable Verilog. Sutherland's guide (or my summary) should be provided to students to ensure a strong introduction to synthesizable Verilog syntax and best practices.
 
-\section{Style guides and linters record synthesizable features and best-practices.}
+\section{Style guides and linters record synthesizable features and best practices.}
 \label{section:style_guides}
 
 Even while avoiding commonly unsynthesizable SystemVerilog features, design tools are infamous for misinterpreting syntax and often providing little or misleading information on errors. Therefore, using linters and well-verified style guides is crucial in ensuring that an RTL implementation will work on an assortment of tools. As mentioned in \autoref{section:inference_is_inconsistent}, style guides and linters help direct engineers away from ambiguous or poorly-supported language features, and towards syntax and features that are verified to tape-out chips successfully. By introducing Verilog alongside an exhaustive style guide, and providing test flows with linting, students can feel much more confident exploring new language features.
 
-The lowRISC Style Guide discusses many best-practices of language features such as the \mintinline{systemverilog}{alias} statement, \mintinline{systemverilog}{automatic} scopes, \mintinline{systemverilog}{package} imports, and floating \mintinline{systemverilog}{begin}-\mintinline{systemverilog}{end} blocks \cite{lowRISCstyleguides}. The Bespoke Silicon Group Style Guide is also strong due to its discussion of structures, enumerations, and memories \cite{BSGstyleguide}. There are also style guides published by tool manufacturers that show how what syntax works best using their flows \cite{Xilinxstyleguide, Intelstyleguide, Latticestyleguide}. There are many style guides available; see \autoref{appx:style_guides} for a(n incomplete) list. Personally, I teach the lowRISC style guide because of its thorough explanations, because of the clarity in \mintinline{systemverilog}{_d} and \mintinline{systemverilog}{_q} as suffixes for register inputs and outputs, and to match the \enquote{Labs with CVA6} project (as described in \autoref{chapter:labs_with_cva6}).
+The lowRISC Style Guide discusses many best practices of language features such as the \mintinline{SystemVerilog}{alias} statement, \mintinline{SystemVerilog}{automatic} scopes, \mintinline{SystemVerilog}{package} imports, and floating \mintinline{SystemVerilog}{begin}-\mintinline{SystemVerilog}{end} blocks \cite{lowRISCstyleguides}. The Bespoke Silicon Group Style Guide is also strong due to its discussion of structures, enumerations, and memories \cite{BSGstyleguide}. There are also style guides published by tool manufacturers that show how what syntax works best using their flows \cite{Xilinxstyleguide, Intelstyleguide, Latticestyleguide}. There are many style guides available; see \autoref{appx:style_guides} for a(n incomplete) list. Personally, I teach the lowRISC style guide because of its thorough explanations, because of the clarity in \mintinline{SystemVerilog}{_d} and \mintinline{SystemVerilog}{_q} as suffixes for register inputs and outputs, and to match the \enquote{Labs with CVA6} project (as described in \autoref{chapter:labs_with_cva6}).
 
-Linters such as Verible \cite{veribleGitHub}, Verilator \cite{verilatorGitHub}, and svlint \cite{svlintGitHub} are all popular in design flows. Each are configurable to warn on or forbid specific language features, and many open-source projects choose to lint with more than one of these tools. For example, Verible is known for its auto-formatting capabilities; Verilator is powerful enough to warn on multidriven signals and accidental latches in \mintinline{systemverilog}{always_comb} blocks; and Svlint is unique for its ability to verify complex whitespace layouts and enforce custom net naming styles. Each has their purpose and should be used on student submissions to ensure best-practices are enforced (see \autoref{chapter:autograders}).
+Linters such as Verible \cite{veribleGitHub}, Verilator \cite{verilatorGitHub}, and svlint \cite{svlintGitHub} are all popular in design flows. Each are configurable to warn on or forbid specific language features, and many open-source projects choose to lint with more than one of these tools. For example, Verible is known for its auto-formatting capabilities; Verilator is powerful enough to warn on multi-driven signals and accidental latches in \mintinline{SystemVerilog}{always_comb} blocks; and Svlint is unique for its ability to verify complex whitespace layouts and enforce custom net naming styles. Each has their purpose and should be used on student submissions to ensure best practices are enforced (see \autoref{chapter:autograders}).
 
 \section{Verilog tutorial websites should be treated cautiously.}
 \label{section:tutorial_websites}
@@ -25,7 +25,7 @@ \section{Verilog tutorial websites should be treated cautiously.}
 \input{figures/always_ff}
 \input{figures/asicworld}
 
-For example, while a TA for ECE 152A, 154A, and 154B, the most prevalent misinformation I saw them encourage in students was to put combinational logic inside of \mintinline{systemverilog}{always_ff} blocks (see \autoref{fig:asicworld}). The lowRISC Style Guide, the BSG SystemVerilog Coding Standards, and the IEEE 1364.1-2005 Verilog Synthesis Standard all recommend only putting reset, set, and enable logic in \mintinline{systemverilog}{always_ff} blocks \cite{lowRISCstyleguides, BSGstyleguide, 1364.1-2005}. Unnecessarily large \mintinline{systemverilog}{always_ff} blocks are prone to bugs because \mintinline{systemverilog}{always_ff} blocks don't offer warnings on unhandled code paths, blocking and nonblocking-assignment mismatches can lead to undefined behavior, and synthesis tools may incorrectly infer the incorrect type of flip-flop (see \autoref{fig:always_ff}). In my experience teaching SystemVerilog, whenever a student asked for help solving a bug, but followed this design practice, I immediately asked them to separate the block into an \mintinline{systemverilog}{always_comb} and \mintinline{systemverilog}{always_ff}. Over half the time, that simple refactor incidentally fixed the student's bug.
+For example, while a TA for ECE 152A, 154A, and 154B, the most prevalent misinformation I saw them encourage in students was to put combinational logic inside of \mintinline{SystemVerilog}{always_ff} blocks (see \autoref{fig:asicworld}). The lowRISC Style Guide, the BSG SystemVerilog Coding Standards, and the IEEE 1364.1-2005 Verilog Synthesis Standard all recommend only putting reset, set, and enable logic in \mintinline{SystemVerilog}{always_ff} blocks \cite{lowRISCstyleguides, BSGstyleguide, 1364.1-2005}. Unnecessarily large \mintinline{SystemVerilog}{always_ff} blocks are prone to bugs because \mintinline{SystemVerilog}{always_ff} blocks don't offer warnings on unhandled code paths, blocking and non-blocking assignment mismatches can lead to undefined behavior, and synthesis tools may incorrectly infer the incorrect type of flip-flop (see \autoref{fig:always_ff}). In my experience teaching SystemVerilog, whenever a student asked for help solving a bug, but followed this design practice, I immediately asked them to separate the block into an \mintinline{SystemVerilog}{always_comb} and \mintinline{SystemVerilog}{always_ff}. Over half the time, that simple refactor incidentally fixed the student's bug.
 
 \FloatBarrier