cv and added section on linting

dependencies.patch

@@ -1,6 +1,6 @@
 diff -Naur dependencies/ucsb/sty/ucthesis-CA2012.cls build/dependencies/ucsb/sty/ucthesis-CA2012.cls
 --- dependencies/ucsb/sty/ucthesis-CA2012.cls	2023-09-19 13:18:37.076212700 -0700
-+++ build/dependencies/ucsb/sty/ucthesis-CA2012.cls	2023-09-19 13:17:51.913885500 -0700
++++ build/dependencies/ucsb/sty/ucthesis-CA2012.cls	2023-09-19 17:33:03.264495400 -0700
 @@ -206,12 +206,9 @@
      \bigskip \medskip \vspace{6ex}
      \fmfont {\bfseries \Large {\@title} \par}   % Formatting of the Dissertation title
@@ -16,7 +16,15 @@ diff -Naur dependencies/ucsb/sty/ucthesis-CA2012.cls build/dependencies/ucsb/sty
      \bigskip \medskip by \par
      \bigskip \medskip {\@author} \par
    \end{center}
-@@ -357,6 +354,7 @@
+@@ -338,6 +335,7 @@
+ \newenvironment{vitae}{
+   \if@openright\cleardoublepage \else\clearpage \fi
+   \ssp
++  \phantomsection
+   \begin{center}
+     {\large \bfseries \vitaename} \par
+     {\large \@author}
+@@ -357,6 +355,7 @@
  % \title and \author macros
  \def\abstract{
      \if@openright\cleardoublepage \else\clearpage \fi

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 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}.)
+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}).
 
 Possibly the most important attribute of open-source tools is that they get updates every day, and instructors have 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 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.
 

tex/chapters/3_digital_design.tex

@@ -17,25 +17,23 @@ \section{Enabling optimizations in netlist graph viewers creates complexity.}
 
 \input{figures/opt}
 
-While synthesis tools may run their own specific optimizations \cite{1364.1-2005}, 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 \autoref{section:leaderboard}.) While it is acceptable to encourage students to explore various tool and language features as illustrated in \autoref{fig:opt}, 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.
+While synthesis tools may run their own specific optimizations \cite{1364.1-2005}, 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. (Similar to \autoref{section:leaderboard}). While it is acceptable to encourage students to explore various tool and language features as illustrated in \autoref{fig:opt}, 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 basic understanding of the behavior of synthesis tools.
 
 \FloatBarrier
 
-\section{Rely on style guides for synthesizable SystemVerilog.}
+\section{Teaching features that rely on inference is difficult but important.}
 
 \input{figures/dc_vs_synplify}
 
-RTL engineers use C-like constructs 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 \cite{1800-2017, sutherland}. This may be due to inconsistent tool-support for a feature \cite{svtests}, or that the feature is similar to a prohibited feature in the IEEE 1364.1 standard. For example, \autoref{fig:dc_vs_synplify} shows differences in synthesis support between two Synopsys synthesis tools.
-
-\FloatBarrier
-
-\section{It is important to teach C-like constructs that rely on inference.}
+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. Many SystemVerilog IEEE 1800 features are not consistently synthesizable by popular synthesis tools, such as classes, interfaces, and dynamic arrays \cite{1800-2017, sutherland}. This may result from a SystemVerilog feature being subjectively similar to a prohibited feature in the IEEE 1364.1 standard, or may be due to insufficient tool development time. For these reasons, support for many features is inconsistent across different open-source tools \cite{svtests}, and \autoref{fig:dc_vs_synplify} shows Synopsys' own tools have inconsistencies across each-other.
 
 \input{figures/c-like}
 
-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. 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. For example, observe \autoref{fig:c-like}.
+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. Modern-day RTL engineers regularly use constructs 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. 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 linters and well-verified style guides, and students understand the resulting synthesis, higher-level syntax should be prioritized when it improves code clarity and structure, such as in \autoref{fig:c-like}.
+
+Since there is no official synthesis standard, style guides and linters have filled the role of unofficial documentation of SystemVerilog's synthesizable features to help engineers navigate the inconsistencies across different tools. This is futher discussed in \autoref{section:style_guides} and \autoref{chapter:autograders}.
 
 \FloatBarrier