diff --git a/.gitignore b/.gitignore
index c09e885..4f436f3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,9 @@
+
+# Misc
+.DS_Store
 build
+
+# LaTeX
 *.aux
 *.bbl
 *.blg
@@ -6,4 +11,9 @@ build
 *.out
 *.pdf.tmp
 *.toc
-.DS_Store
+
+# Verilator
+obj_dir
+
+# Icarus
+*.vvp
diff --git a/Makefile b/Makefile
index c74ce7a..071dfcf 100644
--- a/Makefile
+++ b/Makefile
@@ -1,10 +1,10 @@
 
 BUILD_DIR := $(CURDIR)/build
 
-PDFLATEX := TEXINPUTS=$(CURDIR):$(CURDIR)/src:${BUILD_DIR}/dependencies/ucsb/sty: \
-	pdflatex -interaction=nonstopmode -halt-on-error -output-directory ${BUILD_DIR}
+PDFLATEX := TEXINPUTS=$(CURDIR):$(CURDIR)/tex:${BUILD_DIR}/dependencies/ucsb/sty: \
+	pdflatex -interaction=nonstopmode -halt-on-error -shell-escape -output-directory ${BUILD_DIR}
 
-BIBTEX := BSTINPUTS=${BUILD_DIR}/dependencies/ucsb: BIBINPUTS=$(CURDIR)/src: \
+BIBTEX := BSTINPUTS=${BUILD_DIR}/dependencies/ucsb: BIBINPUTS=$(CURDIR)/tex: \
 	bibtex
 
 JUNK := *.pdf *.aux *.log *.bbl *.blg *.toc *.out *.fdb_latexmk *.fls *.synctex.gz
diff --git a/docs/index.html b/docs/index.html
index 0ec1dd3..0bb310f 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -3,7 +3,7 @@
 <head>
     <meta charset="UTF-8">
     <meta name="viewport" content="width=device-width, initial-scale=1.0">
-    <title>Ethan Sifferman Thesis</title>
+    <title>Ethan Sifferman Masters Thesis</title>
     <style>
         html, body {
             margin: 0;
diff --git a/figures/dc_vs_synplify.tex b/figures/dc_vs_synplify.tex
index e521c5e..9798ac5 100644
--- a/figures/dc_vs_synplify.tex
+++ b/figures/dc_vs_synplify.tex
@@ -1,3 +1,3 @@
-\caption{Differences in SystemVerilog Support in DC vs. Synplify-Pro [ref]}
+\caption{Differences in SystemVerilog Support in DC vs. Synplify-Pro \cite{sutherland}}
 \includegraphics[width=\linewidth]{figures/dc_vs_synplify.pdf}
 \label{fig:dc_vs_synplify}
diff --git a/src/chapters/1_introduction.tex b/src/chapters/1_introduction.tex
deleted file mode 100644
index 881e6f9..0000000
--- a/src/chapters/1_introduction.tex
+++ /dev/null
@@ -1,13 +0,0 @@
-\chapter{Introduction}
-
-Words
-
-Words2
-
-\begin{section}{Permissions and Attributions}
-\begin{enumerate}
-
-\item The content of chapter 2 and appendix A is the result of a collaboration with Alice and Bob, and has previously appeared in the (Journal) (paper citation). It is reproduced here with the permission of (Institution): \url{http://}.
-
-\end{enumerate}
-\end{section}
diff --git a/src/chapters/2_open_source_tools.tex b/src/chapters/2_open_source_tools.tex
deleted file mode 100644
index 2a223a5..0000000
--- a/src/chapters/2_open_source_tools.tex
+++ /dev/null
@@ -1,7 +0,0 @@
-\chapter{Chapter 2 Title}
-%---  Section -------------------------
-\begin{section}{Section Title}
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris et neque massa. Fusce sit amet orci libero. Morbi venenatis quam ante, in vehicula diam. Cras in dui sem, et fermentum ligula. Sed sed tellus ut purus semper pharetra euismod nec tellus. Nullam tortor justo, tincidunt sed varius vel, rhoncus id ipsum. Sed ipsum sem, bibendum id posuere sit amet, dignissim vel odio. Integer pretium mattis metus eu porta. Sed luctus, eros eu feugiat euismod, nulla augue fringilla nisi, sed gravida sem orci ac urna.
-
-\end{section}
diff --git a/src/chapters/3_digital_design.tex b/src/chapters/3_digital_design.tex
deleted file mode 100644
index 087860c..0000000
--- a/src/chapters/3_digital_design.tex
+++ /dev/null
@@ -1,11 +0,0 @@
-\chapter{Chapter 3 Title}
-%---  Introduction -------------------------
-\begin{section}{Section Title}
-
-\cite{Maldacena:1997re,joesbook}. Figure \ref{fig:dc_vs_synplify}.
-
-\begin{figure}[t]
-\input{figures/dc_vs_synplify.tex}
-\end{figure}
-
-\end{section}
diff --git a/src/chapters/4_resources.tex b/src/chapters/4_resources.tex
deleted file mode 100644
index e69de29..0000000
diff --git a/src/chapters/5_scalability.tex b/src/chapters/5_scalability.tex
deleted file mode 100644
index e69de29..0000000
diff --git a/src/chapters/6_autograders.tex b/src/chapters/6_autograders.tex
deleted file mode 100644
index e69de29..0000000
diff --git a/src/chapters/7_labs_with_cva6.tex b/src/chapters/7_labs_with_cva6.tex
deleted file mode 100644
index e69de29..0000000
diff --git a/src/chapters/8_conclusion.tex b/src/chapters/8_conclusion.tex
deleted file mode 100644
index e69de29..0000000
diff --git a/src/preliminary/abstract.tex b/src/preliminary/abstract.tex
deleted file mode 100644
index 6625ebb..0000000
--- a/src/preliminary/abstract.tex
+++ /dev/null
@@ -1,12 +0,0 @@
-%
-%  Abstract
-%
-
-\begin{abstract}
-\addcontentsline{toc}{chapter}{Abstract}
-%todo: max 350 words
-
-Abstract text.
-
-%\abstractsignature
-\end{abstract}
diff --git a/src/thesis.bib b/src/thesis.bib
deleted file mode 100644
index e74f8a8..0000000
--- a/src/thesis.bib
+++ /dev/null
@@ -1,26 +0,0 @@
-%Thou shalt cite Maldacena.
-@article{Maldacena:1997re,
-      author         = "Maldacena, Juan Martin",
-      title          = "{The Large N limit of superconformal field theories and
-                        supergravity}",
-      journal        = "Adv.Theor.Math.Phys.",
-      volume         = "2",
-      pages          = "231-252",
-      year           = "1998",
-      eprint         = "hep-th/9711200",
-      archivePrefix  = "arXiv",
-      primaryClass   = "hep-th",
-      reportNumber   = "HUTP-98-A097",
-      SLACcitation   = "%%CITATION = HEP-TH/9711200;%%",
-}
-
-@book{joesbook,
-  title = {String Theory, Volumes 1 and 2},
-  publisher = {Cambridge University Press},
-  year = {2005},
-  author = {Joseph {Polchinski}},
-  address = {Cambridge},
-  edition = {first},
-  owner = {public domain},
-  timestamp = {}
-}
diff --git a/tex/chapters/1_introduction.tex b/tex/chapters/1_introduction.tex
new file mode 100644
index 0000000..1b75c6c
--- /dev/null
+++ b/tex/chapters/1_introduction.tex
@@ -0,0 +1,29 @@
+
+\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. [ref] Similarly, TSMC, the world's leading semiconductor manufacturer, is expecting to open three new advanced-node fabs in 2024. [ref] 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. [ref] Investments like these have created a never-ending demand for chip developers, and Universities should be working to meet this demand.
+
+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. The following presents an abbreviated flow tailored for students and open-source tool usage, as illustrated in [fig]. 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.
+
+To aid educators in combating the intrinsic difficulty in teaching digital design, this thesis presents a collection of methods and resources for Verilog education that will adequately prepare students for writing synthesizable Verilog in industry.
+
+\begin{itemize}
+
+    \item \autoref{chapter:open_source_tools} delves into the accessibility of open-source tools, highlighting how they provide a cost-effective alternative for students, unlike proprietary tools burdened with high licensing fees. It also discusses the ease of installation and the unique features offered by open-source tools, emphasizing their ability to foster a more exciting and accessible learning environment.
+
+    \item \autoref{chapter:digital_design} shifts the focus to teaching SystemVerilog from a synthesis perspective, and how SystemVerilog can be effectively used for digital design education. It argues that a synthesis-oriented approach to teaching SystemVerilog can bridge the gap between abstract syntax and tangible hardware implementations, providing students with a deeper understanding of digital circuits.
+
+    \item \autoref{chapter:resources} explores the best resources for learning synthesizable SystemVerilog, emphasizing resources dedicated to synthesis. It argues the significance of SystemVerilog style guides in ensuring code quality and adherence to industry standards while warning against relying solely on popular yet misleading Verilog tutorial websites.
+
+    \item \autoref{chapter:scalability} emphasizes the importance of teaching students how to efficiently work on large-scale Verilog projects, discussing features in SystemVerilog that aid in code organization and the significance of version control and in-module verification.
+
+    \item \autoref{chapter:autograders} argues for the incorporation of autograders in Verilog/SystemVerilog education, demonstrating their value in providing instant, high-quality feedback to students. It also discusses how autograders can facilitate remote testing of Verilog designs and foster a sense of community and collaboration among students.
+
+    \item \autoref{chapter:labs_with_cva6} culminates the thesis by showcasing a series of assignments I created that provide hands-on experience with advanced computer architecture concepts using the open-source CVA6 RISC-V core.
+
+    \item Finally, \autoref{chapter:future_classes} explores how ideas presented in this thesis could enhance advanced Verilog courses such as verification with Universal Verification Methodology (UVM) and SystemVerilog Assertions (SVA) for verification, embedded system and System-on-Chip (SoC) design, and ASIC and VLSI projects.
+
+\end{itemize}
diff --git a/tex/chapters/2_open_source_tools.tex b/tex/chapters/2_open_source_tools.tex
new file mode 100644
index 0000000..49a3651
--- /dev/null
+++ b/tex/chapters/2_open_source_tools.tex
@@ -0,0 +1,23 @@
+
+\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.
+
+\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.
+
+\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.
+
+\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.
+
+\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.
+
+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.
diff --git a/tex/chapters/3_digital_design.tex b/tex/chapters/3_digital_design.tex
new file mode 100644
index 0000000..1debfcc
--- /dev/null
+++ b/tex/chapters/3_digital_design.tex
@@ -0,0 +1,31 @@
+
+\chapter{Using SystemVerilog for Digital Design Education}
+\label{chapter:digital_design}
+
+Navigating the realm of Verilog/SystemVerilog education presents a distinctive challenge: effectively bridging the gap between abstract Verilog syntax and tangible hardware implementations. Striking this balance is of paramount importance, as it can equip aspiring electrical engineers with a deep comprehension of digital circuits, while giving them the hard-skills in computer-aided circuit creation. While it may feel there is a tradeoff between teaching Verilog design strategies and teaching circuit design strategies, I argue that teaching inference and synthesis of Verilog will actually augment student understanding of more advanced digital circuit concepts. I would compare this to a programming course using C++ to teach algorithms. For many computer science students, algorithms are synonymous with code, not with logic proofs. For computer engineering students, \ul{as long as Verilog is taught with a synthesis-oriented approach, the connection between theoretical circuit concepts and tangible hardware construction becomes seamless, facilitating a more rapid and all-encompassing digital design education.}
+
+\section{Netlist graph viewers teach Verilog inference intuition.}
+
+[Fig] By providing a visual representation of the synthesis process, students can gain a deeper insight into how their high-level descriptions are transformed into hardware components. DigitalJS Online [ref] stands as a notable example of such netlist graph viewers. Through its zero-setup, interactive web interface, students can witness rapid translation of their Verilog code into synthesized hardware, which encourages experimentation and rapid prototyping. Additionally, its text editor runs automatic linting with Verilator, which gives incredibly helpful feedback if a syntax-related bad-practice is detected. During a volunteer lecture for UCSB's IEEE student chapter, I taught Verilog concepts from DigitalJS Online's text editor, which seamlessly visualized the logic I was describing in my examples. Also, as a TA for ECE 152A and 154B, I curated several assignments that challenged students to use DigitalJS Online to transform \mintinline{systemverilog}{for} loops and \mintinline{systemverilog}{if} statements into comprehensive, hand-drawn circuit diagrams. [fig] Similarly, UC Santa Cruz Professor Dustin Richmond uses netlist graph viewers to teach best-practices concerning \mintinline{systemverilog}{case} and \mintinline{systemverilog}{if} statements. [ref] Through a process of hands-on exploration with netlist graph viewers, students can learn the mechanics of translating SystemVerilog constructs into tangible hardware and gain the ability to convert Verilog to schematics by hand. By assigning homework and in-lecture exercises that prompt students to deduce logical constructs from visual synthesis outputs, their aptitude to understand both Verilog and synthesis is significantly enhanced.
+
+\section{Enabling optimizations in netlist graph viewers creates complexity.}
+
+While synthesis tools may run their own specific optimizations, learning these intricacies are not critical, given the overall proficiency of available tools and the limited need for target-specific code optimization. Instead, the primary focus should be on teaching students to write clear and transferable code, adhering to best practices covered in the class. (See more in the autograder leaderboard section.) While it is acceptable to encourage students to explore various tool and language features as illustrated in Figure [fig], it is crucial to maintain a balance. Experimentation can stimulate curiosity and self-directed learning, but there may be instances where netlist graph viewers hinder rather than facilitate understanding. For example, as students start working with larger designs, the chances are increased that a quietly-applied, tool-specific synthesis optimization will result in a netlist that, while valid, would take too much time to decipher and understand. This may turn instructors entirely away from using netlist graph viewers due to the additional confusion that they cause. However, I argue that they are still an essential resource for introducing Verilog, helping students transition from gate schematics to HDLs. These tools serve as a foundation for students to build their intuition for synthesis, ultimately empowering them to undertake the more advanced design challenges. Even if netlist graph viewers lose their effectiveness as designs get complex, they illustrate to students the vital connection between digital design concepts and Verilog concepts.
+
+A similar example is providing simplified schematics of transistor implementations of digital gates to relate electrical engineering students to their prior knowledge of analog design. Because transistor implementation specifics are largely unimportant due to the low demand for PDK designers, it is fine to simply introduce basic technologies such as pass-transistor logic instead of analyzing modern multi-finger FinFET CMOS designs. But only after receiving some connection to their prior experience with transistors will electrical engineering students feel comfortable working with gates. Similarly, when introducing Verilog to students, using netlist graph viewers can connect prior knowledge of digital elements to code syntax. Much like electrical engineers need some familiarity with transistor-level gate implementations prior to diving into digital design, Verilog students greatly benefit from a foundational understanding of the behavior of synthesis tools.
+
+\section{Rely on style guides for synthesizable SystemVerilog.}
+
+\begin{figure}[t]
+\input{figures/dc_vs_synplify.tex}
+\end{figure}
+
+RTL engineers use C-like constructs [gloss] such as procedural blocks, \mintinline{systemverilog}{for} loops, and \mintinline{systemverilog}{if} statements from Verilog; and \mintinline{systemverilog}{struct}, \mintinline{systemverilog}{union}, and \mintinline{systemverilog}{enum} constructs from SystemVerilog. To promote uniformity among tools, IEEE standardized synthesis of Verilog 1364 features under the label ``1364.1". However, there has been no official ``1800.1" SystemVerilog synthesis standard to discuss the many new features that were added with SystemVerilog. With that said, many SystemVerilog features are endorsed by numerous projects and designers, as evidenced by the abundance of style guides [appx] that act as a current but unofficial documentation of SystemVerilog's synthesizable features. The SystemVerilog IEEE 1800 specification also describes many elements that are not consistently synthesizable, such as classes, hierarchical references, interfaces, and dynamic arrays. [ref] This may be due to poor tool-support for a feature, or that the feature is similar to a prohibited feature in the 1364.1 standard. For example, \autoref{fig:dc_vs_synplify} shows differences in synthesis support between two Synopsys synthesis tools.
+
+\section{It is important to teach C-like constructs that rely on inference.}
+
+A reaction to the inconsistency and ambiguity in SystemVerilog synthesis may be to teach only obviously-synthesizable constructs such as continuous assignment and standard cell initialization, but that would neglect important language features that have become popular in industry designs. [Fig] Similarly, in computer programming courses, once students understand the underlying mechanisms, it is common to allow use of standard library functions and data structures. This philosophy should extend to the realm of SystemVerilog. As long as the code adheres to course-specified style guides, and students understand the resulting synthesis, higher-level syntax should be prioritized when it improves code clarity and structure. [Fig]
+
+\section{HDLs can be abstractions for complex hardware concepts.}
+
+With the full set of synthesizable features being utilized, Verilog can be a useful abstraction layer to better explain complex design concepts such as state machines, pipelining, and handshakes. This parallels the use of abstraction in programming courses, where students often draft pseudocode to conceptualize algorithms before delving into detailed implementation. Transferring this approach to digital design can promote a more rapid and comprehensive learning experience. As long as students demonstrate a strong understanding of how Verilog can be synthesized, they will also have an understanding of the circuits needed to implement the complex design concepts. An example of this in practice was in UCSB's ECE 154B, where an assignment I wrote expected students to implement a fully-associative cache. Students were expected to implement a doubly-linked-list to execute a least-recently-used replacement policy. With the helpful abstraction layer of structs, \mintinline{systemverilog}{for} loops, and \mintinline{systemverilog}{if} statements, students were able to demonstrate understanding of the LRU algorithm while also understanding the hardware that was generated. [fig]
diff --git a/tex/chapters/4_resources.tex b/tex/chapters/4_resources.tex
new file mode 100644
index 0000000..3ff89b4
--- /dev/null
+++ b/tex/chapters/4_resources.tex
@@ -0,0 +1,25 @@
+
+\chapter{Best Resources for Learning Synthesizable SystemVerilog}
+\label{chapter:resources}
+
+When writing synthesizable SystemVerilog, not all features present in the IEEE 1800 specification can be utilized, as synthesis tools support only a subset of these features. Unfortunately, many educational resources for Verilog and SystemVerilog fail to document which features are synthesizable and which are for verification only. To combat this ambiguity, a curated set of resources dedicated to synthesis should be prioritized when giving students additional materials for outside the classroom.
+
+\section{Stuart Sutherland's synthesis guide is most valuable.}
+
+``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 students, I compiled a summary of Sutherland's synthesis guide which I shared with UCSB ECE 152A and ECE 154B students, [ref]. Providing both of these resources ensures that students receive a strong introduction to synthesizable Verilog syntax and best practices.
+
+\section{Style guides record synthesizable features and best-practices.}
+
+Even while avoiding unsynthesizable SystemVerilog features, design tools are infamous for misinterpreting syntax and often providing little or misleading information on errors. Therefore, following a well-verified style guide is crucial to ensure that an RTL implementation will work on an assortment of tools. As mentioned in Section III, style guides help direct engineers away from ambiguous or poorly-supported language features, and towards styles and features that are verified to tape-out chips successfully. By introducing Verilog syntax alongside an exhaustive and highly-verified style guide, students can feel much more confident exploring new language features.
+
+See [appx] for a(n incomplete) list of style guides. The lowRISC Style Guide discusses many best-practices surrounding language features such as the alias statement, automatic scopes, package imports, and floating begin-end blocks. The Bespoke Silicon Group Style Guide is also strong due to its discussion of structures, enumerations, and memories. Personally, I teach the lowRISC style guide because of the clarity in \mintinline{systemverilog}{_d} and \mintinline{systemverilog}{_q} as suffixes for register inputs and outputs, and to match the ``Labs with CVA6" project (Section [cva6]).
+
+\section{Verilog tutorial websites should be treated cautiously.}
+
+It is important to stress the importance of following the provided style guides for Verilog syntax over some of the most popular Verilog tutorial websites, such as ASIC World, Chipverify, and Nandland. Despite the user-friendly approach adopted by these websites, which mirror renowned programming tutorial platforms such as GeekforGeeks, Verilog tutorial websites often propagate misguided advice for novice hardware developers. While style-guides can act as a reference to well-verified practices for beginners and professionals alike, tutorial websites do not always teach current-day, synthesizable design syntax that is compatible with a multitude of tools. Only if students maintain adherence to the instructor-specified style-guides and the subset of synthesizable features, then tutorial websites can be used as resources.
+
+For example, while a TA for ECE 152A, 154A, and 154B, the most prevalent misinformation they encouraged in students was to put combinational logic inside of \mintinline{systemverilog}{always_ff} blocks. [fig] The lowRISC Style Guide, the BSG SystemVerilog Coding Standards, and the IEEE 1364.1-2005 Verilog Synthesis Standard all recommend only putting resets, sets, and enables in \mintinline{systemverilog}{always_ff} blocks. [ref] 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 Figure [fig]) 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.
+
+\section{ChipDev.io can be used to practice Verilog (if used effectively).}
+
+The final resource I like to share with students is ChipDev.io, which offers an online collection of popular Verilog questions, paired with an online IDE and testbench. The 30+ questions range from implementing a shift register to designing an ALU. [fig] If students are looking for lots of practice questions as job interview preparation or to gain general practice, I always recommend ChipDev. Unfortunately, they do not run gate-level simulation or logical equivalence checks, so it may incorrectly reward answers that are unsynthesizable. [ref] Plus, after speaking with the ChipDev team, they notified me that synthesis was not on their priority list. Therefore, I strongly urge students to verify their answers with DigitalJS Online before feeling they have a mastery over the current question.
diff --git a/tex/chapters/5_scalability.tex b/tex/chapters/5_scalability.tex
new file mode 100644
index 0000000..b4204e7
--- /dev/null
+++ b/tex/chapters/5_scalability.tex
@@ -0,0 +1,17 @@
+
+\chapter{Teaching Code Scalability and Development Practices}
+\label{chapter:scalability}
+
+Aside from ensuring that student code follows best-practices and correctly synthesizes, an equally important skill to teach students is how to efficiently work on large-scale projects. As the number of transistors on an integrated circuit has increased, the scale of Verilog designs has also drastically increased. At Intel, the SoC that my team was verifying had over 800 Verilog source files in the design. Similarly, one of the most popular RISC-V cores, CVA6, is written in nearly 17,000 lines of code. Ensuring seamless development and limiting the number of bugs within these colossal codebases requires strong project management skills. This is achieved by automatic regression, consistent coding styles, and employing version control. In more advanced Verilog courses such as Computer Architecture or SoC design, I argue that teaching code scalability is often just as important as teaching microarchitecture implementation methods.
+
+\section{SystemVerilog offers many features to aid in code organization.}
+
+Features such as packages, structs, and parameters are incredibly popular in large-scale SystemVerilog projects. And although IEEE 1364 Verilog does not support packages and structs, many RTL designers have found workarounds with \mintinline{systemverilog}{`include} files and functions. [ref:lowrisc, sv2v] These features may not be required to implement hardware algorithms, but are still extremely prevalent in well-organized, large-scale Verilog designs as well as in complex hardware algorithms such as instruction decoding and serial interfaces. In ECE 152A, ECE 154A, and ECE 154B, we were sure to teach students to apply these code organization strategies. [fig]
+
+\section{Version control should be used in Verilog designs.}
+
+Aside from code structure, a cornerstone of modern software development is version control. Intel, numerous other companies, and most RISC-V projects extensively rely on Git and GitHub for version management. Moreover, Git submodules and subtrees provide an elegant solution for integrating IP blocks into designs seamlessly, enhancing reusability and collaboration. Plus, allowing students to post code they've written themselves to GitHub is a great way to aid them in creating an online portfolio for themselves. In ECE 154B, students practiced using Git and GitHub to explore open-source projects, collaborate with peers, add open-source cores as submodules, and more. While software might not be the core focus for some students, being able to work with it efficiently and professionally is still extremely valuable. Because of the invaluable aid Git offers in code quality, and its extreme prevalence in all software development, it is an invaluable hard-skill for all engineers.
+
+\section{SystemVerilog assertions and in-module verification are important.}
+
+The final design strategy for promoting code scalability is to promote in-module verification. Waveform viewers are incredibly powerful and useful tools, but work best when supplemented with \mintinline{systemverilog}{$display} statements that have already identified where and when a simulation error occurred. Most SystemVerilog in industry designs is full of self-verifying modules by use of SystemVerilog assertions (SVA) and Universal Verification Methodology (UVM). Note that as of 9/10/23, since there is poor SVA and UVM support in open-source tools, many open-source projects have success using \mintinline{systemverilog}{`ifdef} macros to disable UVM and SVA calls on a per-tool basis, or projects only may use a subset of the features which are supported, or the projects resort to a basic always blocks instead. [fig] But no matter the specific implementation, in-module verification is a valuable design practice to teach students. In ECE 154A, ECE 154B, and ECE 152A, students were often required to design modules that incorporated simulation-only logic to test basic functionality. By adopting these universal standards, Verilog education becomes better aligned with real-world methodologies for enhanced scalability and proficiency.
diff --git a/tex/chapters/6_autograders.tex b/tex/chapters/6_autograders.tex
new file mode 100644
index 0000000..b14a648
--- /dev/null
+++ b/tex/chapters/6_autograders.tex
@@ -0,0 +1,23 @@
+
+\chapter{Autograders}
+\label{chapter:autograders}
+
+The incorporation of autograders within Verilog/SystemVerilog education is arguably the most valuable aspect of RTL education. These tools, particularly exemplified by platforms like Gradescope, can introduce a dynamic and interactive dimension to the learning process, revolutionizing the way students engage with Verilog concepts. Leveraging custom docker containers and custom Bash scripts, Gradescope's autograders easily facilitate Verilog testbench simulations, strict linting, synthesis, gate-level simulation, and more, yielding insights and feedback on various aspects of the code. However, managing software licenses on autograder servers can be a hassle, so all these functionalities are often best deployed with open-source tools. In the context of UCSB's ECE 154A, ECE 154B, and ECE 152A courses, students responded extremely positively to autograders, visibly enhancing their mastery of appropriate syntax and proficient implementation of synthesizable Verilog.
+
+\section{Autograders offer instant, high-quality feedback.}
+
+Students are empowered to submit their code multiple times, enabling them to refine their solutions and learn from their mistakes in real time. This back-and-forth approach ensures that students can practice a Verilog concept and receive as much help as they need until they pass all the instructor-defined tests. Autograders fall under the educational approach known as ``Ungrading," where the emphasis shifts strongly toward providing valuable feedback over assigning traditional grades. In the autograders that I set up, it's worth noting that a significant majority of students eventually achieve a 100\% score by the assignment deadline. This phenomenon essentially transforms the grading system into a confidence-building mechanism rather than a competitive ranking system. Ungrading has been shown to help students by reducing stress, inspiring creativity, and encouraging healthy risk taking. [ref] However, arguably Ungrading's largest downside is that the instructor may not have time to provide personalized feedback to all students. [ref] Fortunately, an intrinsic attribute of software, (such as HDL implementations), is that code quality and correctness can be run with automatic, subjective computer algorithms. Therefore, by implementing autograders, Verilog educators can tap into this pedagogical insight extremely easily, offering students a more effective way to grasp digital design principles.
+
+\section{Autograders can run remotely without complex local-setup.}
+
+When instructing students on crafting Verilog code that maintains accurate synthesizability across various platforms, it is essential to follow the industry standard of verifying a design with a wide selection of tools. Autograders streamline this process, making it accessible and efficient for students to perform comprehensive testing without the need for local installation. For example, the autograders that I created for ECE 152A, 154A, and 154B would consistently use anywhere from 6 to 10 different tools, sometimes requiring complex installation and setup procedures. Expecting students to complete these setup procedures is often tedious and counterproductive. Therefore, simply giving students access to a fully prepared autograder can remove the setup barrier completely.
+
+As mentioned, an autograder test suite that closely mirrors industry quality should follow all the verification steps demonstrated in Figure [fig]. First, it is important to run behavioral simulations with multiple tools such as Icarus, which supports propagation of unknown (\mintinline{systemverilog}{x}) values, and simulation with Verilator, which has stronger restrictions on bad syntax. Only by passing simulations with both tools should the autograder grant full points. Furthermore, code linters such as Verilator and Verible can ensure adherence to essential coding standards and practices, checking for issues like latches in \mintinline{systemverilog}{always_comb} blocks, correct use of blocking and non-blocking assignments, net-width discrepancies, and more. Considering that the frontends of tools do not always offer helpful warnings, this detailed syntax checking from Verilator and Verible is invaluable for students when fixing otherwise cryptic issues. Then, to deploy SystemVerilog synthesis with open-source tools, Yosys and Nextpnr must be paired with a frontend such as Surelog or zachjs/sv2v. The Yosys synthesis and Nextpnr layout process can verify if students are using too many logic cells, if their design is too slow, or if their design infers prohibited logic cells. As a final post-synthesis step, Icarus can be run one final time on the Yosys output to initiate a gate-level simulation (GLS) with unknown value propagation, and Yosys EQY can be run to perform logical equivalence checking (LEC). All of these features (*aside from LEC with EQY {ran out of time}) have been successfully implemented in autograders from ECE 152A, 154A, and 154B.
+
+\section{``For-fun" leaderboards can excite and inspre students.}
+
+Aside from a grade assigned by the autograder, another form of feedback can be provided through a class leaderboard. Students can see how their submission compares to the rest of the class on statistics such as logic cell usage, max clock frequency, or branch predictor hit percentage. Since the leaderboards in ECE 152A and 154B didn't count towards any points, students really enjoyed seeing how each of their designs compared to their peers' designs, then would try to beat their friends for bragging rights. Because of this, I added leaderboards to every assignment that I could. However, it is important to clarify to students that code readability should be prioritized over moving up in the leaderboard by saving 1-2 logic cells. However, because autograders running purely open-source tools must only rely on Yosys and ABC for synthesis, students may be incorrectly rewarded for submissions that are not well-optimized for other more prevalent synthesis tools such as Design Compiler or Vivado. This was a rare edge case that only visibly affected 1 submission ([fig]) total across the 800+ different submissions from the classes I introduced leaderboards to, but is important to monitor. (See more in the Netlist Graph Viewer [section].) Overall, the leaderboard increased student enthusiasm without bringing additional stress or responsibilities.
+
+\section{Autograders can foster community and collaboration.}
+
+In ECE 152A, students discussed their challenges, insights, and strategies with peers, creating a collective learning environment. Since each student had a clear goal of ``passing all the tests", we saw students combine strategies and knowledge with confidence. This communal engagement not only strengthens individual understanding but also enriches the overall learning ecosystem. Autograders not only enrich Verilog education but also reinforce the bridge between theoretical knowledge and practical industry demands. By integrating autograders, students are provided with a holistic learning experience that equips them with critical skills and insights for their future engineering endeavors.
diff --git a/tex/chapters/7_labs_with_cva6.tex b/tex/chapters/7_labs_with_cva6.tex
new file mode 100644
index 0000000..1e15eec
--- /dev/null
+++ b/tex/chapters/7_labs_with_cva6.tex
@@ -0,0 +1,13 @@
+
+\chapter{Labs with CVA6 Project}
+\label{chapter:labs_with_cva6}
+
+Standing as a culmination of all the Verilog education philosophies described in this thesis is a set of assignments I designed under the project label ``Labs with CVA6". By drawing on my experiences from my time at Intel, my contributions to open-source projects, and interactions with industry contacts, I wrote four labs that aimed to give students practical experience with advanced computer architecture concepts. Each lab is centered around the fully featured RISC-V core CVA6, which is perfect for advanced architecture education due to its 6-stage pipeline, dynamic branch predictor, L1 cache, scoreboard unit, and virtual memory support. [fig] The labs presented students with a unique chance to engage with a fully-featured and transparent RISC-V core. This hands-on interaction facilitated a deeper comprehension of important architectural principles while also enhancing their ability to work with large and complex SystemVerilog designs. These labs are available for free under the BSD-3-Clause license. [ref]
+
+\section{These labs provide hands-on exploration of architectural concepts.}
+
+For instance, the Branch Prediction Lab guided students in modifying CVA6 simulations to display hit rate results and in adapting the CVA6 branch prediction unit into a global predictor. [fig] Similarly, the Caching Lab showed students how to incorporate a victim-cache module, then required creation of an assembly script to demonstrate an understanding of how the cache hierarchies and memory management would be affected. [fig] Then moving away from custom RTL, in the Out-of-Order Lab, students further practiced writing assembly programs to test their comprehension of out-of-order execution by demonstrating data hazards. [fig] Finally, the Virtual Memory Lab enabled students to configure privilege modes and set up page-table entries by modifying an assembly program that acted as a simple bootloader and OS. [fig] Each of these labs were only made possible with CVA6's open-source framework. Based on ECE 154B student responses and post-lab discussions, it was evident that the practical insights offered by these labs substantially deepen understanding of the concepts.
+
+\section{There is high demand for hands-on learning experiences.}
+
+Because ``Labs with CVA6" is available under the BSD-3-Clause license, it has attracted attention from many non-ECE 154B audiences including instructors seeking to enrich their own architecture courses, researchers aiming to familiarize themselves with the specifics of CVA6, and SystemVerilog beginners eager to learn best-practices. In addition, I gave a well-appreciated talk about ``Labs with CVA6" at ``Latch-Up", a conference hosted by The Free and Open Source Silicon Foundation. [ref:youtube] During my presentation, I expressed the practical and unique skills that students acquire through studying the code of well-verified, open-source designs. This resonated deeply with several attendees, especially Rick O'Connor, the President and CEO at OpenHW Group, who notified me of the new RISC-V core, CV-Wally [ref:cvwally], that is designed as a supplemental codebase for the new textbook, ``RISC-V System-on-Chip Design" [ref:harris]. The popularity that ``Labs with CVA6" has seen, and the recent creation of CV-Wally shows that there is strong demand for curriculums that offer transparency on implementation methods of real-world designs.
diff --git a/tex/chapters/8_other_classes.tex b/tex/chapters/8_other_classes.tex
new file mode 100644
index 0000000..70bfd5b
--- /dev/null
+++ b/tex/chapters/8_other_classes.tex
@@ -0,0 +1,17 @@
+
+\chapter{Potential Applications in Other Classes}
+\label{chapter:other_classes}
+
+So far, this thesis has described approaches that could significantly benefit courses in introductory Verilog, digital design, and computer architecture. However, Verilog education stands to gain much more from open-source and publicly available resources. In this short section, I will summarize potential ways that open-source resources could be used in other advanced courses.
+
+\section{``Verification with UVM and SVA"}
+
+Verification is an enormous aspect of chip design, so teaching students the principles of Universal Verification Methodology (UVM) and SystemVerilog Assertions (SVA) can be of paramount value in industry preparation. Courses like North Carolina State University's ECE 748: ``Advanced Verification with UVM" have seen large popularity as companies are in constant demand for well-trained verification engineers. As of 9/17/23, Verilator has limited support for UVM and SVA, but is getting closer to full support every day [ref:video,issue]. If complete support is required, the open-source build-manager FuseSoC can still provide an accessible CLI for proprietary tools, lowering the learning curve. Additionally, adopting a comprehensive Design Verification (DV) style guide can ensure that students continue following best practices when working on verification tasks. Notably, lowRISC has a popular and thorough UVM and SystemVerilog DV feature style-guide. [ref]
+
+\section{``Embedded Systems and SoC Design"}
+
+Embedded systems and SoC design courses can leverage a plethora of open-source, high-speed IP blocks that are commonly used in FPGA designs. There are many popular open-source designs for HDMI [ref], DVI [ref], Ethernet [ref], PCIe [ref], and AXI [ref]. An educator could provide a similar experience to my ``Labs with CVA6" project by teaching students the inner workings of advanced serial communication modules. Proficiency in high-speed interfaces is highly sought after in industry positions.
+
+\section{``ASIC and VLSI Projects"}
+
+For courses focusing on Application-Specific Integrated Circuits (ASICs), open-source resources become critical. Licensing and signing Non-Disclosure Agreements (NDAs) for proprietary PDKs are often impractical or time-consuming for instructors, limiting course opportunities. Fortunately, initiatives like the OpenROAD Project and the SkyWater PDK (SKY130) offer students access to fully-featured ASIC flows. For example, UC Berkeley's EE 194: ``The Tapeout Class" utilized Hammer and OpenROAD to offer students the opportunity to tape out an SoC in a semester. Moreover, affordable SKY130 fabrication opportunities like Tinytapeout (\SI{160}{\micro\metre} \texttimes \SI{100}{\micro\metre} for \$100) and Google MPW lottery (\SI{2920}{\micro\metre} \texttimes \SI{3520}{\micro\metre} for free) enable students to take their designs from simulation to real-world fabrication, providing a hands-on experience that reinforces their understanding of the ASIC design process.
diff --git a/tex/chapters/9_conclusion.tex b/tex/chapters/9_conclusion.tex
new file mode 100644
index 0000000..d54941d
--- /dev/null
+++ b/tex/chapters/9_conclusion.tex
@@ -0,0 +1,15 @@
+
+\chapter{Conclusion}
+\label{chapter:Conclusion}
+
+Universities should be working to lower the barrier of entry into SystemVerilog design. Throughout this thesis, several critical challenges in Verilog/SystemVerilog education have been addressed and resolved, contributing to the enhancement of the learning experience for students. These issues encompassed a range of areas, and the solutions put forward have had a significant impact.
+
+\begin{itemize}
+    \item \textbf{Synthesizable vs. Verification Features:} A critical issue in Verilog education lies in distinguishing between synthesizable and verification features. This thesis has addressed this concern through multiple avenues. Using netlist graph viewers like DigitalJS Online, which enables students to visualize the synthesis process, helps visually demonstrate what constructs lead to valid netlists. Additionally, style guides like from the lowRISC Organization act as the best practices for writing synthesizable code. Finally, autograders can provide immediate, personalized feedback to students on whether their code is both behaviorally correct and synthesizable.
+    \item \textbf{Prevalence of Bugs in Common HDL Tools:} Common Verilog and SystemVerilog tools often suffer from bugs when using lesser-used features. To mitigate this, style guides by lowRISC, Bespoke Silicon Group, and more should be used to teach students the best syntax and strategies for avoiding common pitfalls. Autograders can also play a pivotal role by seamlessly testing student code across a multitude of tools. If a submission passes tests for several tools, it is much more likely that it will work properly for all tools.
+    \item \textbf{Inaccessibility of Proprietary Tools:} The reliance on proprietary tools in Verilog education has been a barrier to accessibility for many beginners. Open-source tools highlighted in this work present a solution by being cost-free, easier to install, and more user-friendly. This shift towards open-source tools enhances equity in education and industry and enables a broader spectrum of engineers to engage effectively with Verilog.
+    \item \textbf{The Lack of Reliable Educational Resources:} There is a shortage of reliable educational resources in Verilog/SystemVerilog. In this thesis, a comprehensive list of resources has been provided in Section IV, serving as a valuable reference for both instructors and students. These resources cover a range of use-cases and are designed to support a deeper understanding of Verilog.
+    \item \textbf{Interdisciplinary Nature of Chip Design:} Verilog and SystemVerilog education must acknowledge the interdisciplinary nature of chip design, involving both software and hardware components. This thesis emphasizes the importance of dedicating time to teaching essential skills like Git version control. Furthermore, I have described that DigitalJS Online should be used to create a stronger connection between Verilog code and hardware circuits, helping both software and hardware engineers become more well-rounded.
+\end{itemize}
+
+In light of the rapidly evolving landscape of open-source hardware, there is a pressing need for more universities and educators to modernize their digital design and computer architecture curriculums. Students deserve a curriculum that not only imparts technical knowledge but also inspires them to explore the field further. By incorporating elements like open-source tools, hands-on projects, and interactive platforms, educators can make Verilog education more engaging and appealing to a broader range of students. Furthermore, as demonstrated by the inclusion of ``for-fun" leaderboards and ``Ungrading" with autograders, fostering a collaborative and vibrant environment can help create a more valuable and enthusiastic learning experience. Institutions should be urged to reevaluate and revamp their Verilog courses to provide students with a more exciting and fulfilling educational experience, ultimately preparing them for the challenges and opportunities in the ever-evolving world of digital design and computer architecture.
diff --git a/src/final/appendix.tex b/tex/final/appendix.tex
similarity index 100%
rename from src/final/appendix.tex
rename to tex/final/appendix.tex
diff --git a/src/final/glossary.tex b/tex/final/glossary.tex
similarity index 100%
rename from src/final/glossary.tex
rename to tex/final/glossary.tex
diff --git a/src/final/references.tex b/tex/final/references.tex
similarity index 100%
rename from src/final/references.tex
rename to tex/final/references.tex
diff --git a/tex/preliminary/abstract.tex b/tex/preliminary/abstract.tex
new file mode 100644
index 0000000..7b29a49
--- /dev/null
+++ b/tex/preliminary/abstract.tex
@@ -0,0 +1,10 @@
+%
+%  Abstract
+%
+
+\begin{abstract}
+\addcontentsline{toc}{chapter}{Abstract}
+
+In the rapidly expanding semiconductor industry, there is an increasing demand for skilled chip developers. Yet, the steep learning curve associated with Hardware Description Languages (HDLs), such as Verilog, often acts as a significant barrier for students hoping to pursue a career in digital design. Drawing upon my experience as an educator, which includes teaching Verilog to UCSB's IEEE student chapter and serving as a Teaching Assistant for UCSB's Verilog courses, I have meticulously developed and refined a comprehensive set of methods and resources for Verilog education. My objective encompassed two key facets: equipping students with quality industry-preparation and kindling passion for exploring hardware design. Through a strategic blend of approaches consisting of the integration of accessible open-source tools, the enforcement of popular coding style guides, the implementation of autograders for personalized feedback, and the incorporation of open-source IP blocks into lessons, students can attain proficiency in designing RTL (Register Transfer Level) for rigorously verified hardware systems. These strategies help reduce Verilog's steep learning curve while also expediting the introduction of more advanced topics in digital design and computer architecture. The methods and resources detailed in this thesis will prepare students for the expectations of the semiconductor industry, enhance their coding skills, and promote an accessible and engaging learning environment, ultimately meeting the growing demand for chip developers.
+
+\end{abstract}
diff --git a/src/preliminary/title.tex b/tex/preliminary/title.tex
similarity index 100%
rename from src/preliminary/title.tex
rename to tex/preliminary/title.tex
diff --git a/src/preliminary/vitae.tex b/tex/preliminary/vitae.tex
similarity index 100%
rename from src/preliminary/vitae.tex
rename to tex/preliminary/vitae.tex
diff --git a/tex/thesis.bib b/tex/thesis.bib
new file mode 100644
index 0000000..f0b4198
--- /dev/null
+++ b/tex/thesis.bib
@@ -0,0 +1,31 @@
+% https://www.bibtex.com/e/entry-types/
+
+@book{kohn:book,
+  title =      {Ungrading: Why Rating Students Undermines Learning (and What to Do Instead) (Teaching and Learning in Higher Education)},
+  author =     {Kohn, Alfie and Blum, Susan D.},
+  publisher =  {West Virginia University Press},
+  isbn =       {1949199827,9781949199826,9781949199833},
+  year =       {2020},
+  series =     {},
+  edition =    {},
+  volume =     {},
+  url =        {}
+}
+
+@article{blum:article,
+  author = {Blum, Susan},
+  year = {2017},
+  month = {11},
+  pages = {},
+  title = {The significant learning benefits of getting rid of grades},
+  journal = {Inside Higher Ed},
+  url = {https://www.insidehighered.com/advice/2017/11/14/significant-learning-benefits-getting-rid-grades-essay}
+}
+
+@inproceedings{sutherland,
+  author          = {Sutherland, Stuart and Mills, Don},
+  title           = {Synthesizing SystemVerilog: Busting the Myth that SystemVerilog is only for Verification},
+  series          = {Synopsys Users Group (SNUG) Silicon Valley conference, Santa Clara, California},
+  month           = {March},
+  year            = {2013}
+}
diff --git a/src/thesis.tex b/tex/thesis.tex
similarity index 87%
rename from src/thesis.tex
rename to tex/thesis.tex
index 1738e95..066e93e 100644
--- a/src/thesis.tex
+++ b/tex/thesis.tex
@@ -11,6 +11,10 @@
 \usepackage{braket}
 \usepackage{color}
 \usepackage{setspace}
+\usepackage{titlesec}
+\usepackage{soul}
+\usepackage[outputdir=build]{minted}
+\usepackage{siunitx}
 %\usepackage{subfigure} (Subfigure package clashes with another package)
 
 %---New Definitions and Commands------------------------------------------------------
@@ -34,10 +38,16 @@
 \newcommand{\pd}[2]{\frac{\p#1}{\p#2}}
 \newcommand{\D}[2]{\frac{d#1}{d#2}}
 
+\renewcommand{\chapterautorefname}{Chapter}
+
 %---Set Margins ------------------------------------------------------
 \setlength\oddsidemargin{0.25 in} \setlength\evensidemargin{0.25 in} \setlength\textwidth{6.25 in} \setlength\textheight{8.50 in}
 \setlength\footskip{0.25 in} \setlength\topmargin{0 in} \setlength\headheight{0.25 in} \setlength\headsep{0.25 in}
 
+%---Fonts ------------------------------------------------------
+\titleformat{\section}
+  {\normalfont\fontsize{12}{15}\bfseries}{\thesection}{1em}{}
+
 %%%---DOCUMENT---%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \begin{document}
 
@@ -47,7 +57,7 @@
 	\maketitle
 	\approvalpage
 	\copyrightpage
-	\input{preliminary/vitae}
+	% \input{preliminary/vitae}
 	\input{preliminary/abstract}
 	\tableofcontents
 \end{frontmatter}
@@ -91,12 +101,13 @@
 \include{chapters/5_scalability}
 \include{chapters/6_autograders}
 \include{chapters/7_labs_with_cva6}
-\include{chapters/8_conclusion}
+\include{chapters/8_other_classes}
+\include{chapters/9_conclusion}
 
 %=== Final ============================================
 
-\include{final/appendix}
-\include{final/glossary}
+% \include{final/appendix}
+% \include{final/glossary}
 
 \end{mainmatter}
 
