chapter 4

code/always_ff.svh

@@ -0,0 +1,20 @@
+
+    // not cumulative
+    always_ff @(posedge clk) begin
+        data1_q <= data1_q + 1;
+        data1_q <= data1_q + 1;
+        data1_q <= data1_q + 1;
+        data1_q <= data1_q + 1;
+    end
+
+    // doesn't warn that there is no default case
+    always_ff @(posedge clk) begin
+        if (rst)
+            data2_q <= '0;
+    end
+
+    // unclear whether this is a DFF or DFFE
+    always_ff @(posedge clk) begin
+        if ( pkg::func(data3_i) )
+            data3_q <= data3_d;
+    end

figures/always_ff.tex

@@ -0,0 +1,7 @@
+
+\begin{figure}[t]
+    \centering
+    \inputminted[frame=single]{systemverilog}{code/always_ff.svh}
+    \caption{Potentially confusing behaviors of \mintinline{systemverilog}{always_ff} blocks}
+    \label{fig:always_ff}
+\end{figure}

figures/asicworld.tex

@@ -0,0 +1,7 @@
+
+\begin{figure}[t]
+    \centering
+    \frame{\includegraphics[width=\textwidth,height=0.9\textheight,keepaspectratio]{figures/asicworld.pdf}}
+    \caption{This is an example provided by ASIC World that encourages bad design practices \cite{asicworld}}
+    \label{fig:asicworld}
+\end{figure}

figures/chipdev_hack.tex

@@ -0,0 +1,7 @@
+
+\begin{figure}[t]
+    \centering
+    \frame{\includegraphics[width=0.9\linewidth]{figures/chipdev_hack.pdf}}
+    \caption{This example shows ChipDev \cite{ChipDev} incorrectly accepting this submission despite a potential mismatch between simulation and synthesis. For example, Verilator will override the \mintinline{systemverilog}{always_comb} with the \mintinline{systemverilog}{assign}, but Yosys will override the \mintinline{systemverilog}{assign} with the \mintinline{systemverilog}{always_comb}. This could be corrected if ChipDev chooses to incorporate a similar verification flow to what is outlined in \autoref{section:complex_tool_setups}.}
+    \label{fig:chipdev_hack}
+\end{figure}

figures/chipdev_questions.tex

@@ -0,0 +1,7 @@
+
+\begin{figure}[t]
+    \centering
+    \frame{\includegraphics[width=0.7\linewidth]{figures/chipdev_questions.pdf}}
+    \caption{An example of questions that ChipDev offers. \cite{ChipDev}}
+    \label{fig:chipdev_questions}
+\end{figure}

tex/chapters/1_introduction.tex

@@ -2,11 +2,11 @@
 \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 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.
 
 \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{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.
+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

@@ -6,7 +6,7 @@ \chapter{Advantages of Open-Source Tools in Education}
 
 \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, \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.
+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.}
 

tex/chapters/4_resources.tex

@@ -6,7 +6,7 @@ \chapter{Best Resources for Learning Synthesizable SystemVerilog}
 
 \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.
+``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 ``Labs with CVA6'', I composed 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. Providing both Sutherland's guide and my summary ensures that students receive a strong introduction to synthesizable Verilog syntax and best practices.
 
 \section{Style guides record synthesizable features and best-practices.}
 
@@ -18,8 +18,16 @@ \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.
+\input{figures/asicworld}
+\input{figures/always_ff}
+
+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. (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 resets, sets, and enables 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.
+
+\FloatBarrier
 
 \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.
+\input{figures/chipdev_questions}
+\input{figures/chipdev_hack}
+
+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; (see \autoref{fig:chipdev_questions}.) If students are looking for lots of practice questions as job interview preparation or for general practice, I always recommend ChipDev. However, ChipDev does not run gate-level simulation or logical equivalence checks, so bad submissions may be incorrectly rewarded; (see \autoref{fig:chipdev_hack}.) 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 or other synthesis tools before feeling they have a mastery over any question.