From b94b488e6171033a3041ba46dff8ddce2f049cbd Mon Sep 17 00:00:00 2001 From: Ethan Sifferman Date: Sun, 1 Oct 2023 10:18:02 -0700 Subject: [PATCH] 1 sentence per line --- tex/chapters/1_introduction.tex | 38 +++++++++++++++---- tex/chapters/2_open_source_tools.tex | 53 ++++++++++++++++++++++---- tex/chapters/3_digital_design.tex | 57 ++++++++++++++++++++++++---- tex/chapters/4_resources.tex | 45 ++++++++++++++++++---- tex/chapters/5_scalability.tex | 30 +++++++++++++-- tex/chapters/6_autograders.tex | 49 ++++++++++++++++++++---- tex/chapters/7_labs_with_cva6.tex | 22 +++++++++-- tex/chapters/8_other_classes.tex | 22 +++++++++-- tex/chapters/9_conclusion.tex | 38 +++++++++++++++---- tex/figures/OoO.tex | 6 ++- tex/figures/always_ff.tex | 2 +- tex/figures/asic_flow.tex | 2 +- tex/figures/asicworld.tex | 3 +- tex/figures/branch_predictor.tex | 3 +- tex/figures/c-like.tex | 3 +- tex/figures/cache_lab.tex | 4 +- tex/figures/chipdev_hack.tex | 4 +- tex/figures/chipdev_questions.tex | 2 +- tex/figures/cva6_overview.tex | 3 +- tex/figures/dc_vs_synplify.tex | 2 +- tex/figures/digitaljs_online.tex | 2 +- tex/figures/leaderboard.tex | 4 +- tex/figures/opt.tex | 2 +- tex/final/appendix.tex | 5 ++- tex/preliminary/abstract.tex | 8 +++- tex/preliminary/vitae.tex | 4 +- 26 files changed, 337 insertions(+), 76 deletions(-) diff --git a/tex/chapters/1_introduction.tex b/tex/chapters/1_introduction.tex index 605cc86..f6bda07 100644 --- a/tex/chapters/1_introduction.tex +++ b/tex/chapters/1_introduction.tex @@ -2,27 +2,49 @@ \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 tool-chains to lower the barrier of entry for new Silicon engineers \cite{GooglePartnersWithSkyWater, googleSilicon}. Investments like these have created a never-ending demand for chip developers, and Universities should be working to meet this demand. +At the end of Dennard scaling, it may be tempting to think that VLSI and digital design are becoming less-important engineering fields. +However, the United States government wouldn't agree, considering they are investing \$280 billion over the next ten years into the CHIPS Act \cite{mckinsey}. +Similarly, TSMC, the world's leading semiconductor manufacturer, is expecting to open three new advanced-node fabs in 2024 \cite{taipeitimes}. +In addition, in 2020, Google started a partnership with GlobalFoundries, SkyWater Technology, and Efabless to provide fully open-source Process Design Kits (PDKs) and tool-chains to lower the barrier of entry for new Silicon engineers \cite{GooglePartnersWithSkyWater, googleSilicon}. +Investments like these have created a never-ending demand for chip developers, and Universities should be working to meet this demand. \input{figures/asic_flow} -In the semiconductor industry, the process of designing an application-specific integrated circuit (ASIC) follows a well-defined sequence, where each step requires extensive 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 target's standard cell library 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 a Field Programmable Gate Array (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 the multitude of skills are required to create an ASIC design, it is crucial for Universities to offer a strong foundation in 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 can be 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 may also be transitioning into a more software-centric environment. Bridging the gap between hardware and software is vital in today's world due to the prevalence of computer-aided design (CAD) software. 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. +In the semiconductor industry, the process of designing an application-specific integrated circuit (ASIC) follows a well-defined sequence, where each step requires extensive 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 target's standard cell library 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 a Field Programmable Gate Array (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 the multitude of skills are required to create an ASIC design, it is crucial for Universities to offer a strong foundation in 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 can be 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 may also be transitioning into a more software-centric environment. +Bridging the gap between hardware and software is vital in today's world due to the prevalence of computer-aided design (CAD) software. +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: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: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. 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:resources} explores the best resources for learning synthesizable SystemVerilog. +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: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. diff --git a/tex/chapters/2_open_source_tools.tex b/tex/chapters/2_open_source_tools.tex index 5c341d4..baca2b8 100644 --- a/tex/chapters/2_open_source_tools.tex +++ b/tex/chapters/2_open_source_tools.tex @@ -2,24 +2,63 @@ \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} \cite{awesomeOpenSourceHardware}. For example, a common collection of tools include the simulators Icarus \cite{icarusGitHub} and Verilator \cite{verilatorGitHub}, the waveform viewer GTKWave \cite{gtkwaveGitHub}, the synthesis tool Yosys \cite{yosysGitHub}, the FPGA place and route tools Nextpnr \cite{nextpnrGitHub} and VTR \cite{vtrGitHub}, the ASIC flow OpenLane \cite{OpenLaneGitHub}, and the hardware package manager and build system FuseSoC \cite{fusesocGitHub, edalizeGitHub}. In this chapter, I explain why open-source tools excel over proprietary tools in introducing Verilog and digital design to students. +Although proprietary Verilog tools are predominant in industry and often boast a wide assortment of features, I argue that they can be one of the biggest deterrents for those first learning digital design. +Whether students become aghast at the preposterous licensing fees or become hung up on the steep learning curve of the interfaces, the most popular Verilog tools often have trouble exciting students into furthering their Verilog education. +Fortunately, there are several open-source Verilog tools that are praised for their accessibility and ease-of-use. +A valuable resource for open-source hardware tools, generators, and reusable designs can be found in the curated list provided here: \url{https://github.com/aolofsson/awesome-opensource-hardware} \cite{awesomeOpenSourceHardware}. +For example, a common collection of tools include the simulators Icarus \cite{icarusGitHub} and Verilator \cite{verilatorGitHub}, the waveform viewer GTKWave \cite{gtkwaveGitHub}, the synthesis tool Yosys \cite{yosysGitHub}, the FPGA place and route tools Nextpnr \cite{nextpnrGitHub} and VTR \cite{vtrGitHub}, the ASIC flow OpenLane \cite{OpenLaneGitHub}, and the hardware package manager and build system FuseSoC \cite{fusesocGitHub, edalizeGitHub}. +In this chapter, I 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 circuit components for 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 do not 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 circuit components for 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 do not 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 do not want 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 \enquote{OSS CAD Suite} project \cite{osscadsuitebuildGitHub}, you can download all the latest binaries of the most popular open-source Verilog tools in under a minute. This beats Vivado's complicated installation process by a mile and is more-likely to remain on student's computers after the course is over since all the tools only take up half a gigabyte, as opposed to the 16-60GB that Vivado requires. +Even if students do not want 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 \enquote{OSS CAD Suite} project \cite{osscadsuitebuildGitHub}, you can download all the latest binaries of the most popular open-source Verilog tools in under a minute. +This beats Vivado's complicated installation process by a mile and is more-likely to remain on student's computers after the course is over since all the tools only take up half a gigabyte, as opposed to the 16-60GB that Vivado requires. \section{Unique benefits and features of open-source tools.} -Undoubtedly, proprietary tools offer a multitude of functionalities for advanced users that open-source tools cannot offer. However, open-source tools offer many unique features that are often better for beginners. For example, Icarus runs short simulations much faster than proprietary simulators, making it perfect for receiving instant feedback as students are still learning the language syntax. Similarly, Yosys and Nextpnr perform synthesis and layout significantly faster than tools such as Vivado and Design Compiler, allowing for more rapid prototyping. Also, while ModelSim may happily parse and simulate unsynthesizable code, Verilator will give much more strict warnings, helping to demonstrate the syntax and features that should be allowed in synthesizable designs. (This is further discussed in \autoref{section:style_guides}). +Undoubtedly, proprietary tools offer a multitude of functionalities for advanced users that open-source tools cannot offer. +However, open-source tools offer many unique features that are often better for beginners. +For example, Icarus runs short simulations much faster than proprietary simulators, making it perfect for receiving instant feedback as students are still learning the language syntax. +Similarly, Yosys and Nextpnr perform synthesis and layout significantly faster than tools such as Vivado and Design Compiler, allowing for more rapid prototyping. +Also, while ModelSim may happily parse and simulate unsynthesizable code, Verilator will give much more strict warnings, helping to demonstrate the syntax and features that should be allowed in synthesizable designs. +(This is further discussed in \autoref{section:style_guides}). -But possibly the most important attribute of open-source tools is that they get updates every day, and offer full transparency when reporting bugs and requesting new features. Depending on the difficulty of the request, the tool maintainers may complete the request within a few weeks. Instructors may even decide they want to do a pull-request themselves; I personally have made several contributions to multiple tools (see \autoref{appx:contributions}). This is contrasted with the fact that many universities are not always running the most up-to-date proprietary software. For example, as of 9/10/23, UC Santa Barbara's Engineering Computing Infrastructure's latest version of ModelSim is 10.7d from April 2019, which does not support width-casting from parameters. This negatively affected one of the UCSB Spring 2023 ECE 152A labs. Bugs in tools will undoubtedly happen, but the only solution Siemens offers is to pay for an updated version with the bug fixed. Contrast this with submitting a GitHub issue with Verilator, and having the bug fixed by the next time the course is offered. Open-source tools are often simply the better choice for instructors and students alike. +But possibly the most important attribute of open-source tools is that they get updates every day, and offer full transparency when reporting bugs and requesting new features. +Depending on the difficulty of the request, the tool maintainers may complete the request within a few weeks. +Instructors may even decide they want to do a pull-request themselves; I personally have made several contributions to multiple tools (see \autoref{appx:contributions}). +This is contrasted with the fact that many universities are not always running the most up-to-date proprietary software. +For example, as of 9/10/23, UC Santa Barbara's Engineering Computing Infrastructure's latest version of ModelSim is 10.7d from April 2019, which does not support width-casting from parameters. +This negatively affected one of the UCSB Spring 2023 ECE 152A labs. +Bugs in tools will undoubtedly happen, but the only solution Siemens offers is to pay for an updated version with the bug fixed. +Contrast this with submitting a GitHub issue with Verilator, and having the bug fixed by the next time the course is offered. +Open-source tools are often simply the better choice for instructors and students alike. \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. This is contrasted with 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 \enquote{point-and-click adventure game} in his talk \enquote{So, you want to be an open sourcerer?} \cite{RichmondLatchUp}. By using CLIs, you can abstract away and decouple tool-specifics from digital design concepts. +One of the most important ways to make Verilog more accessible is by guiding students to use command line interfaces (CLIs). +Nearly all large-scale Verilog designs are paired with user-friendly build scripts and Makefiles for running simulation and synthesis. +This is contrasted with 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 \enquote{point-and-click adventure game} in his talk \enquote{So, you want to be an open sourcerer?} \cite{RichmondLatchUp}. +By using CLIs, you can abstract away and decouple tool-specifics from digital design concepts. -To aid in the usually lengthy crafting of TCL scripts and Makefiles, an extremely powerful pair of open-source tools named FuseSoC and Edalize \cite{fusesocGitHub, edalizeGitHub} attempt to standardize build files for all Verilog tools with a central \mintinline{bash}{.core} file. The \mintinline{bash}{.core} file, interpretable by FuseSoC, contains the \enquote{run} specifications, which are then seamlessly communicated to Edalize for automated generation and execution of build scripts. FuseSoC is compatible with nearly every Verilog tool, so switching simulators is often as easy as changing one line of code in the \mintinline{bash}{.core} file. While TAing for UCSB's ECE 152A, 154A, and 154B, I capitalized on the utility of FuseSoC and Edalize to substantially accelerate assignment setup time. I could provide students with the Makefile automatically generated by Edalize, or I could provide the \mintinline{bash}{.core} file for students to run themselves with FuseSoC. Either option was effective in simplifying the build process so students could better focus on the learning-goals of the assignments. +To aid in the usually lengthy crafting of TCL scripts and Makefiles, an extremely powerful pair of open-source tools named FuseSoC and Edalize \cite{fusesocGitHub, edalizeGitHub} attempt to standardize build files for all Verilog tools with a central \mintinline{bash}{.core} file. +The \mintinline{bash}{.core} file, interpretable by FuseSoC, contains the \enquote{run} specifications, which are then seamlessly communicated to Edalize for automated generation and execution of build scripts. +FuseSoC is compatible with nearly every Verilog tool, so switching simulators is often as easy as changing one line of code in the \mintinline{bash}{.core} file. +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 index 4369000..f895f88 100644 --- a/tex/chapters/3_digital_design.tex +++ b/tex/chapters/3_digital_design.tex @@ -2,13 +2,26 @@ \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. Teaching this intuition 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 trade-off 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.} +Navigating the realm of Verilog/SystemVerilog education presents a distinctive challenge: effectively bridging the gap between abstract Verilog syntax and tangible hardware implementations. +Teaching this intuition 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 trade-off 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.} \input{figures/digitaljs_online} -By using netlist graph viewers to provide 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 \cite{DigitalJSOnline} stands as a notable example of such netlist graph viewers (see \autoref{fig:digitaljs_online}). Through its zero-setup, interactive web interface, students can witness instant 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. Similarly, UC Santa Cruz Professor Dustin Richmond uses netlist graph viewers to teach best practices concerning \mintinline{SystemVerilog}{case} and \mintinline{SystemVerilog}{if} statements \cite{RichmondLatchUp}. Plus, after enough exploration with netlist graph viewers, students can gain the ability to convert Verilog to schematics by hand. By assigning homework and in-lecture exercises that prompt students to deduce hardware constructs from abstract Verilog syntax, their aptitude to understand both Verilog and synthesis will be significantly enhanced. +By using netlist graph viewers to provide 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 \cite{DigitalJSOnline} stands as a notable example of such netlist graph viewers (see \autoref{fig:digitaljs_online}). +Through its zero-setup, interactive web interface, students can witness instant 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. +Similarly, UC Santa Cruz Professor Dustin Richmond uses netlist graph viewers to teach best practices concerning \mintinline{SystemVerilog}{case} and \mintinline{SystemVerilog}{if} statements \cite{RichmondLatchUp}. +Plus, after enough exploration with netlist graph viewers, students can gain the ability to convert Verilog to schematics by hand. +By assigning homework and in-lecture exercises that prompt students to deduce hardware constructs from abstract Verilog syntax, their aptitude to understand both Verilog and synthesis will be significantly enhanced. \FloatBarrier @@ -17,9 +30,22 @@ \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. (This focus is also described 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 create confusion 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 away entirely from using netlist graph viewers due to the additional complexity 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 \emph{some} connection to their prior experience with transistors will electrical engineering students feel comfortable working with gates. Similarly, when introducing Verilog, 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. +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. +(This focus is also described 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 create confusion 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 away entirely from using netlist graph viewers due to the additional complexity 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 \emph{some} connection to their prior experience with transistors will electrical engineering students feel comfortable working with gates. +Similarly, when introducing Verilog, 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 @@ -28,14 +54,29 @@ \section{Teaching features that rely on inference is difficult but important.} \input{figures/dc_vs_synplify} -To promote uniformity among tools, IEEE standardized synthesis of Verilog 1364 features under the label \enquote{1364.1}. However, there has been no official \enquote{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. 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 further discussed in \autoref{section:style_guides} and \autoref{chapter:autograders}. +To promote uniformity among tools, IEEE standardized synthesis of Verilog 1364 features under the label \enquote{1364.1}. +However, there has been no official \enquote{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. +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 further discussed in \autoref{section:style_guides} and \autoref{chapter:autograders}. \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 (\mintinline{SystemVerilog}{assign}) 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}. +A reaction to the inconsistency and ambiguity in SystemVerilog synthesis may be to teach only obviously-synthesizable constructs such as continuous assignment (\mintinline{SystemVerilog}{assign}) 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}. \FloatBarrier \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 when UCSB ECE 154B students were assigned my \enquote{Labs with CVA6} Cache Lab, where students were expected to implement a doubly-linked-list to execute a least-recently-used (LRU) replacement policy. With the helpful abstraction layer of structs, \mintinline{SystemVerilog}{for} loops, and \mintinline{SystemVerilog}{if} statements, (as seen in \autoref{fig:cache_lab}), students were able to demonstrate a high-level understanding of the LRU algorithm while also understanding the low-level hardware that was generated. +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 when UCSB ECE 154B students were assigned my \enquote{Labs with CVA6} Cache Lab, where students were expected to implement a doubly-linked-list to execute a least-recently-used (LRU) replacement policy. +With the helpful abstraction layer of structs, \mintinline{SystemVerilog}{for} loops, and \mintinline{SystemVerilog}{if} statements, (as seen in \autoref{fig:cache_lab}), students were able to demonstrate a high-level understanding of the LRU algorithm while also understanding the low-level hardware that was generated. diff --git a/tex/chapters/4_resources.tex b/tex/chapters/4_resources.tex index fd92ba8..2e5f92b 100644 --- a/tex/chapters/4_resources.tex +++ b/tex/chapters/4_resources.tex @@ -2,30 +2,54 @@ \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, provided to students should be a curated set of resources dedicated to synthesis as additional materials for outside the classroom. +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, provided to students should be a curated set of resources dedicated to synthesis as additional materials for outside the classroom. \section{Stuart Sutherland's synthesis guide is most valuable.} -\enquote{Synthesizing SystemVerilog: Busting the Myth that SystemVerilog is only for Verification} by Stuart Sutherland and Don Mills acts as a comprehensive list of synthesizable SystemVerilog features. Despite the absence of an official SystemVerilog synthesis standard, this paper gives valuable insight into synthesizable language features, emphasizing their practical application into modern hardware designs. Sutherland and Mills surveyed the Synopsys tools, Design Compiler and Synplify-Pro, to trace the evolution of Verilog-1984 though SystemVerilog-2009 as a comprehensive hardware design and verification language. To assist those working on \enquote{Labs with CVA6}, I composed and included a summary of Sutherland's synthesis guide \cite{labsWithCVA6}. Since then, I have shared this summary with dozens of students looking to improve their understanding of synthesizable Verilog. Sutherland's guide (or my summary) should be provided to students to ensure a strong introduction to synthesizable Verilog syntax and best practices. +\enquote{Synthesizing SystemVerilog: Busting the Myth that SystemVerilog is only for Verification} by Stuart Sutherland and Don Mills acts as a comprehensive list of synthesizable SystemVerilog features. +Despite the absence of an official SystemVerilog synthesis standard, this paper gives valuable insight into synthesizable language features, emphasizing their practical application into modern hardware designs. +Sutherland and Mills surveyed the Synopsys tools, Design Compiler and Synplify-Pro, to trace the evolution of Verilog-1984 though SystemVerilog-2009 as a comprehensive hardware design and verification language. +To assist those working on \enquote{Labs with CVA6}, I composed and included a summary of Sutherland's synthesis guide \cite{labsWithCVA6}. +Since then, I have shared this summary with dozens of students looking to improve their understanding of synthesizable Verilog. +Sutherland's guide (or my summary) should be provided to students to ensure a strong introduction to synthesizable Verilog syntax and best practices. \section{Style guides and linters record synthesizable features and best practices.} \label{section:style_guides} -Even while avoiding commonly unsynthesizable SystemVerilog features, design tools are infamous for misinterpreting syntax and often providing little or misleading information on errors. Therefore, using linters and well-verified style guides is crucial in ensuring that an RTL implementation will work on an assortment of tools. As mentioned in \autoref{section:inference_is_inconsistent}, style guides and linters help direct engineers away from ambiguous or poorly-supported language features, and towards syntax and features that are verified to tape-out chips successfully. By introducing Verilog alongside an exhaustive style guide, and providing test flows with linting, students can feel much more confident exploring new language features. +Even while avoiding commonly unsynthesizable SystemVerilog features, design tools are infamous for misinterpreting syntax and often providing little or misleading information on errors. +Therefore, using linters and well-verified style guides is crucial in ensuring that an RTL implementation will work on an assortment of tools. +As mentioned in \autoref{section:inference_is_inconsistent}, style guides and linters help direct engineers away from ambiguous or poorly-supported language features, and towards syntax and features that are verified to tape-out chips successfully. +By introducing Verilog alongside an exhaustive style guide, and providing test flows with linting, students can feel much more confident exploring new language features. -The lowRISC Style Guide discusses many best practices of language features such as the \mintinline{SystemVerilog}{alias} statement, \mintinline{SystemVerilog}{automatic} scopes, \mintinline{SystemVerilog}{package} imports, and floating \mintinline{SystemVerilog}{begin}-\mintinline{SystemVerilog}{end} blocks \cite{lowRISCstyleguides}. The Bespoke Silicon Group Style Guide is also strong due to its discussion of structures, enumerations, and memories \cite{BSGstyleguide}. There are also style guides published by tool manufacturers that show how what syntax works best using their flows \cite{Xilinxstyleguide, Intelstyleguide, Latticestyleguide}. There are many style guides available; see \autoref{appx:style_guides} for a(n incomplete) list. Personally, I teach the lowRISC style guide because of its thorough explanations, because of the clarity in \mintinline{SystemVerilog}{_d} and \mintinline{SystemVerilog}{_q} as suffixes for register inputs and outputs, and to match the \enquote{Labs with CVA6} project (as described in \autoref{chapter:labs_with_cva6}). +The lowRISC Style Guide discusses many best practices of language features such as the \mintinline{SystemVerilog}{alias} statement, \mintinline{SystemVerilog}{automatic} scopes, \mintinline{SystemVerilog}{package} imports, and floating \mintinline{SystemVerilog}{begin}-\mintinline{SystemVerilog}{end} blocks \cite{lowRISCstyleguides}. +The Bespoke Silicon Group Style Guide is also strong due to its discussion of structures, enumerations, and memories \cite{BSGstyleguide}. +There are also style guides published by tool manufacturers that show how what syntax works best using their flows \cite{Xilinxstyleguide, Intelstyleguide, Latticestyleguide}. +There are many style guides available; see \autoref{appx:style_guides} for a(n incomplete) list. +Personally, I teach the lowRISC style guide because of its thorough explanations, because of the clarity in \mintinline{SystemVerilog}{_d} and \mintinline{SystemVerilog}{_q} as suffixes for register inputs and outputs, and to match the \enquote{Labs with CVA6} project (as described in \autoref{chapter:labs_with_cva6}). -Linters such as Verible \cite{veribleGitHub}, Verilator \cite{verilatorGitHub}, and svlint \cite{svlintGitHub} are all popular in design flows. Each are configurable to warn on or forbid specific language features, and many open-source projects choose to lint with more than one of these tools. For example, Verible is known for its auto-formatting capabilities; Verilator is powerful enough to warn on multi-driven signals and accidental latches in \mintinline{SystemVerilog}{always_comb} blocks; and Svlint is unique for its ability to verify complex whitespace layouts and enforce custom net naming styles. Each has their purpose and should be used on student submissions to ensure best practices are enforced (see \autoref{chapter:autograders}). +Linters such as Verible \cite{veribleGitHub}, Verilator \cite{verilatorGitHub}, and svlint \cite{svlintGitHub} are all popular in design flows. +Each are configurable to warn on or forbid specific language features, and many open-source projects choose to lint with more than one of these tools. +For example, Verible is known for its auto-formatting capabilities; Verilator is powerful enough to warn on multi-driven signals and accidental latches in \mintinline{SystemVerilog}{always_comb} blocks; and Svlint is unique for its ability to verify complex whitespace layouts and enforce custom net naming styles. +Each has their purpose and should be used on student submissions to ensure best practices are enforced (see \autoref{chapter:autograders}). \section{Verilog tutorial websites should be treated cautiously.} \label{section:tutorial_websites} -It is important to stress to students the importance of following the provided style guides and linters for Verilog syntax over some of the most popular Verilog tutorial websites such as ASIC World, Chipverify, and Nandland. Despite the user-friendly appearance adopted by these websites, which mirror renowned programming tutorial platforms such as GeekforGeeks, many Verilog tutorial websites often propagate misguided advice for novice hardware developers. While style-guides and linters 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 course's subset of synthesizable features, then tutorial websites can be used as resources. +It is important to stress to students the importance of following the provided style guides and linters for Verilog syntax over some of the most popular Verilog tutorial websites such as ASIC World, Chipverify, and Nandland. +Despite the user-friendly appearance adopted by these websites, which mirror renowned programming tutorial platforms such as GeekforGeeks, many Verilog tutorial websites often propagate misguided advice for novice hardware developers. +While style-guides and linters 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 course's subset of synthesizable features, then tutorial websites can be used as resources. \input{figures/always_ff} \input{figures/asicworld} -For example, while a TA for ECE 152A, 154A, and 154B, the most prevalent misinformation I saw them encourage in students was to put combinational logic inside of \mintinline{SystemVerilog}{always_ff} blocks (see \autoref{fig:asicworld}). The lowRISC Style Guide, the BSG SystemVerilog Coding Standards, and the IEEE 1364.1-2005 Verilog Synthesis Standard all recommend only putting reset, set, and enable logic in \mintinline{SystemVerilog}{always_ff} blocks \cite{lowRISCstyleguides, BSGstyleguide, 1364.1-2005}. Unnecessarily large \mintinline{SystemVerilog}{always_ff} blocks are prone to bugs because \mintinline{SystemVerilog}{always_ff} blocks do not offer warnings on unhandled code paths, blocking and non-blocking assignment mismatches can lead to undefined behavior, and synthesis tools may incorrectly infer the incorrect type of flip-flop (see \autoref{fig:always_ff}). In my experience teaching SystemVerilog, whenever a student asked for help solving a bug, but followed this design practice, I immediately asked them to separate the block into an \mintinline{SystemVerilog}{always_comb} and \mintinline{SystemVerilog}{always_ff}. Over half the time, that simple refactor incidentally fixed the student's bug. +For example, while a TA for ECE 152A, 154A, and 154B, the most prevalent misinformation I saw them encourage in students was to put combinational logic inside of \mintinline{SystemVerilog}{always_ff} blocks (see \autoref{fig:asicworld}). +The lowRISC Style Guide, the BSG SystemVerilog Coding Standards, and the IEEE 1364.1-2005 Verilog Synthesis Standard all recommend only putting reset, set, and enable logic in \mintinline{SystemVerilog}{always_ff} blocks \cite{lowRISCstyleguides, BSGstyleguide, 1364.1-2005}. +Unnecessarily large \mintinline{SystemVerilog}{always_ff} blocks are prone to bugs because \mintinline{SystemVerilog}{always_ff} blocks do not offer warnings on unhandled code paths, blocking and non-blocking assignment mismatches can lead to undefined behavior, and synthesis tools may incorrectly infer the incorrect type of flip-flop (see \autoref{fig:always_ff}). +In my experience teaching SystemVerilog, whenever a student asked for help solving a bug, but followed this design practice, I immediately asked them to separate the block into an \mintinline{SystemVerilog}{always_comb} and \mintinline{SystemVerilog}{always_ff}. +Over half the time, that simple refactor incidentally fixed the student's bug. \FloatBarrier @@ -34,4 +58,9 @@ \section{ChipDev.io can be used to practice Verilog (if used effectively).} \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. +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. diff --git a/tex/chapters/5_scalability.tex b/tex/chapters/5_scalability.tex index 2b8b03c..e20f74f 100644 --- a/tex/chapters/5_scalability.tex +++ b/tex/chapters/5_scalability.tex @@ -2,18 +2,40 @@ \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 500 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 \cite{cva6}. 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. For 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. +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 500 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 \cite{cva6}. +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. +For 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.} \input{figures/ece152a_pkg} -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. \cite{lowRISCstyleguides, zachjssv2vGitHub} These features may not be \emph{required} to implement hardware algorithms such as instruction decoding and serial interfaces, but are still extremely prevalent in well-organized, large-scale Verilog designs. In ECE 152A, ECE 154A, and ECE 154B, we were sure to teach students to apply these code organization strategies (see \autoref{fig:ece152a_pkg}). +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. +\cite{lowRISCstyleguides, zachjssv2vGitHub} These features may not be \emph{required} to implement hardware algorithms such as instruction decoding and serial interfaces, but are still extremely prevalent in well-organized, large-scale Verilog designs. +In ECE 152A, ECE 154A, and ECE 154B, we were sure to teach students to apply these code organization strategies (see \autoref{fig:ece152a_pkg}). \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 (see \autoref{appx:contributions} and \autoref{appx:style_guides}). Moreover, Git submodules and subtrees provide an elegant and popular solution for integrating IP blocks into designs seamlessly, enhancing reusability and collaboration. Plus, allowing students to post code they have 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 essential hard-skill for all engineers. +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 (see \autoref{appx:contributions} and \autoref{appx:style_guides}). +Moreover, Git submodules and subtrees provide an elegant and popular solution for integrating IP blocks into designs seamlessly, enhancing reusability and collaboration. +Plus, allowing students to post code they have 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 essential 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, projects may need to use \mintinline{SystemVerilog}{`ifdef} macros to disable UVM and SVA calls on a per-tool basis, may need to limit themselves to the subset of supported features, or may need to resort to a basic \mintinline{SystemVerilog}{always} blocks instead. Verilator has limited support for UVM and SVA, but is getting closer to full support every day \cite{VerilatorUVM, BieganskiORConf, VerilatorSVA}. But no matter the specific implementation, in-module verification is a valuable design practice to teach students. In ECE 152A, ECE 154A, and ECE 154B, 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. +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, projects may need to use \mintinline{SystemVerilog}{`ifdef} macros to disable UVM and SVA calls on a per-tool basis, may need to limit themselves to the subset of supported features, or may need to resort to a basic \mintinline{SystemVerilog}{always} blocks instead. +Verilator has limited support for UVM and SVA, but is getting closer to full support every day \cite{VerilatorUVM, BieganskiORConf, VerilatorSVA}. +But no matter the specific implementation, in-module verification is a valuable design practice to teach students. +In ECE 152A, ECE 154A, and ECE 154B, 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 index b2cb08f..f78b6c3 100644 --- a/tex/chapters/6_autograders.tex +++ b/tex/chapters/6_autograders.tex @@ -2,18 +2,42 @@ \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 student submissions. 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 152A, 154A, and 154B courses, students responded extremely positively to autograders, visibly enhancing their mastery over synthesizable Verilog. +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 student submissions. +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 152A, 154A, and 154B courses, students responded extremely positively to autograders, visibly enhancing their mastery over 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. In the autograders that I set up, it is worth noting that a significant majority of students eventually achieve a 100\% score by the assignment deadline. Therefore, autograders fall under the educational approach known as \enquote{Ungrading,} where the emphasis shifts strongly toward providing valuable feedback over assigning traditional grades. 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. \cite{kohn:book, blum:article} However, arguably Ungrading's largest downside is that the instructor may not have time to provide personalized feedback to all students. 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 easily tap into this pedagogical insight, offering students a more effective way to grasp digital design principles. +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. +In the autograders that I set up, it is worth noting that a significant majority of students eventually achieve a 100\% score by the assignment deadline. +Therefore, autograders fall under the educational approach known as \enquote{Ungrading,} where the emphasis shifts strongly toward providing valuable feedback over assigning traditional grades. +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. +\cite{kohn:book, blum:article} However, arguably Ungrading's largest downside is that the instructor may not have time to provide personalized feedback to all students. +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 easily tap into this pedagogical insight, offering students a more effective way to grasp digital design principles. \section{Autograders can run remotely without complex local-setup.} \label{section:complex_tool_setups} -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 \autoref{fig:asic_flow}. 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\footnote{Inclusion of LEC with EQY into an autograder remains outstanding due to time constraints during the project's development.} have been successfully implemented in autograders for ECE 152A, 154A, and 154B. +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 \autoref{fig:asic_flow}. +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\footnote{Inclusion of LEC with EQY into an autograder remains outstanding due to time constraints during the project's development.} have been successfully implemented in autograders for ECE 152A, 154A, and 154B. \section{\enquote{For-fun} leaderboards can excite and inspire students.} \label{section:leaderboard} @@ -21,8 +45,19 @@ \section{\enquote{For-fun} leaderboards can excite and inspire students.} \input{figures/leaderboard} \input{figures/unreadable_opt} -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 (see \autoref{fig:leaderboard}). Since the leaderboards in ECE 152A and 154B did not 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 (similar to \autoref{section:optimizations_in_netlist_graph_viewers}). This was a rare edge case that only visibly affected 1 submission (\autoref{fig:unreadable_opt}) across the 600+ leaderboard submissions I saw, but it is still important to monitor in students. Overall, creating assignment leaderboards was a great way to increase student enthusiasm without bringing additional stress or responsibilities. +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 (see \autoref{fig:leaderboard}). +Since the leaderboards in ECE 152A and 154B did not 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 (similar to \autoref{section:optimizations_in_netlist_graph_viewers}). +This was a rare edge case that only visibly affected 1 submission (\autoref{fig:unreadable_opt}) across the 600+ leaderboard submissions I saw, but it is still important to monitor in students. +Overall, creating assignment leaderboards was a great way to increase 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 \enquote{passing all the tests}, we saw students combine strategies and knowledge with confidence. Plus, ungraded leaderboards offered a fun but optional way for students to collaborate in friendly competitions. Communal engagement not only strengthens individual understanding, but also enriches the overall learning ecosystem. By integrating autograders, students experience a much more positive learning environment while still being provided critical skills and insights for their future engineering endeavors. +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 \enquote{passing all the tests}, we saw students combine strategies and knowledge with confidence. +Plus, ungraded leaderboards offered a fun but optional way for students to collaborate in friendly competitions. +Communal engagement not only strengthens individual understanding, but also enriches the overall learning ecosystem. +By integrating autograders, students experience a much more positive learning environment while still being provided 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 index 0bbc487..a7bd225 100644 --- a/tex/chapters/7_labs_with_cva6.tex +++ b/tex/chapters/7_labs_with_cva6.tex @@ -4,7 +4,12 @@ \chapter{Labs with CVA6 Project} \input{figures/cva6_overview} -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 \enquote{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 \cite{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 (see \autoref{fig:cva6_overview}). 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 \cite{labsWithCVA6}. +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 \enquote{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 \cite{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 (see \autoref{fig:cva6_overview}). +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 \cite{labsWithCVA6}. \FloatBarrier @@ -15,10 +20,21 @@ \section{These labs provide hands-on exploration of architectural concepts.} \input{figures/OoO} \input{figures/virtual_memory} -\enquote{Labs with CVA6} consists of four labs covering branch prediction, caching, out-of-order, and virtual memory. The Branch Prediction Lab guides students in modifying the CVA6 testbench to display hit rate results and in adapting the CVA6 branch prediction unit RTL into a global predictor (see \autoref{fig:branch_predictor}). Similarly, the Caching Lab asks students to write RTL for a victim-cache module, then requests the creation of assembly scripts that demonstrate CVA6's cache hierarchies and memory management (see \autoref{fig:cache_lab}). Then moving away from custom RTL, in the Out-of-Order Lab, students further practice writing assembly to test their comprehension of out-of-order execution (see \autoref{fig:OoO}). Finally, the Virtual Memory Lab enables students to configure privilege modes and add page-table entries by modifying a provided bootloader and OS (see \autoref{fig:virtual_memory}). 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. The openness of CVA6's source code was pivotal to the labs' success, as it granted students the opportunity to interact with every implementation detail and feature of the core. By studying open-source hardware designs, students can gain valuable and distinctive insights that traditional textbooks simply cannot provide. +\enquote{Labs with CVA6} consists of four labs covering branch prediction, caching, out-of-order, and virtual memory. +The Branch Prediction Lab guides students in modifying the CVA6 testbench to display hit rate results and in adapting the CVA6 branch prediction unit RTL into a global predictor (see \autoref{fig:branch_predictor}). +Similarly, the Caching Lab asks students to write RTL for a victim-cache module, then requests the creation of assembly scripts that demonstrate CVA6's cache hierarchies and memory management (see \autoref{fig:cache_lab}). +Then moving away from custom RTL, in the Out-of-Order Lab, students further practice writing assembly to test their comprehension of out-of-order execution (see \autoref{fig:OoO}). +Finally, the Virtual Memory Lab enables students to configure privilege modes and add page-table entries by modifying a provided bootloader and OS (see \autoref{fig:virtual_memory}). +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. +The openness of CVA6's source code was pivotal to the labs' success, as it granted students the opportunity to interact with every implementation detail and feature of the core. +By studying open-source hardware designs, students can gain valuable and distinctive insights that traditional textbooks simply cannot provide. \FloatBarrier \section{There is high demand for hands-on learning experiences.} -Because \enquote{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 \enquote{Labs with CVA6} at \enquote{Latch-Up}, a conference hosted by The Free and Open Source Silicon Foundation \cite{SiffermanLatchUp}. 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, notably Rick O'Connor, the President and CEO at OpenHW Group, who notified me of the new OpenHW Group RISC-V core, CV-Wally \cite{cvwally}, that is designed as a supplemental codebase for the upcoming textbook, \enquote{RISC-V System-on-Chip Design}. The popularity that \enquote{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. +Because \enquote{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 \enquote{Labs with CVA6} at \enquote{Latch-Up}, a conference hosted by The Free and Open Source Silicon Foundation \cite{SiffermanLatchUp}. +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, notably Rick O'Connor, the President and CEO at OpenHW Group, who notified me of the new OpenHW Group RISC-V core, CV-Wally \cite{cvwally}, that is designed as a supplemental codebase for the upcoming textbook, \enquote{RISC-V System-on-Chip Design}. +The popularity that \enquote{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 index 375fe46..c4e2134 100644 --- a/tex/chapters/8_other_classes.tex +++ b/tex/chapters/8_other_classes.tex @@ -2,16 +2,30 @@ \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. +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{\enquote{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: \enquote{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 compatibility with UVM and SVA, but is getting closer to full support every day \cite{VerilatorUVM, BieganskiORConf, VerilatorSVA}. If full UVM and SVA functionality is required, the open-source build-manager FuseSoC can provide an accessible CLI for proprietary tools, lowering the learning curve. Additionally, adopting a comprehensive Design Verification (DV) style guide and testbench linter 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 \cite{lowRISCstyleguides}, and PySlint was advertised as a testbench linter at ORConf 2023 \cite{paulORConf}. +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: \enquote{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 compatibility with UVM and SVA, but is getting closer to full support every day \cite{VerilatorUVM, BieganskiORConf, VerilatorSVA}. +If full UVM and SVA functionality is required, the open-source build-manager FuseSoC can provide an accessible CLI for proprietary tools, lowering the learning curve. +Additionally, adopting a comprehensive Design Verification (DV) style guide and testbench linter 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 \cite{lowRISCstyleguides}, and PySlint was advertised as a testbench linter at ORConf 2023 \cite{paulORConf}. \section{\enquote{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 \cite{hdlutilhdmiGitHub, projfdisplaycontrollerGitHub, cliffordwolfSimpleVOutGitHub}, Ethernet \cite{alexforencichverilogethernetGitHub}, PCIe \cite{alexforencichverilogpcieGitHub, enjoydigitallitepcieGitHub}, AXI \cite{pulpplatformaxiGitHub, alexforencichverilogaxiGitHub}, and more. An educator could provide a similar experience to my \enquote{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, so a course of this style could be highly beneficial for students. +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 \cite{hdlutilhdmiGitHub, projfdisplaycontrollerGitHub, cliffordwolfSimpleVOutGitHub}, Ethernet \cite{alexforencichverilogethernetGitHub}, PCIe \cite{alexforencichverilogpcieGitHub, enjoydigitallitepcieGitHub}, AXI \cite{pulpplatformaxiGitHub, alexforencichverilogaxiGitHub}, and more. +An educator could provide a similar experience to my \enquote{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, so a course of this style could be highly beneficial for students. \section{\enquote{ASIC and VLSI Projects}} -For courses focusing on Application-Specific Integrated Circuits (ASICs), open-source resources become critical. Licensing and signing Non-Disclosure Agreements 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. UC Berkeley's EE 194: \enquote{The Tapeout Class} utilized Hammer and OpenROAD to offer students the opportunity to tape out an SoC in a semester \cite{ZhaoLatchUp}. Moreover, affordable SKY130 fabrication opportunities like Tinytapeout (\SI{160}{\micro\metre}~\texttimes~\SI{100}{\micro\metre} for \$100) \cite{tinytapeoutTinyTapeout} and Google MPW lottery (\SI{2920}{\micro\metre}~\texttimes~\SI{3520}{\micro\metre} for free) \cite{efablessCaravel} enable students to take their designs from simulation to real-world fabrication, providing a hands-on experience of the ASIC design process. +For courses focusing on Application-Specific Integrated Circuits (ASICs), open-source resources become critical. +Licensing and signing Non-Disclosure Agreements 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. +UC Berkeley's EE 194: \enquote{The Tapeout Class} utilized Hammer and OpenROAD to offer students the opportunity to tape out an SoC in a semester \cite{ZhaoLatchUp}. +Moreover, affordable SKY130 fabrication opportunities like Tinytapeout (\SI{160}{\micro\metre}~\texttimes~\SI{100}{\micro\metre} for \$100) \cite{tinytapeoutTinyTapeout} and Google MPW lottery (\SI{2920}{\micro\metre}~\texttimes~\SI{3520}{\micro\metre} for free) \cite{efablessCaravel} enable students to take their designs from simulation to real-world fabrication, providing a hands-on experience of the ASIC design process. diff --git a/tex/chapters/9_conclusion.tex b/tex/chapters/9_conclusion.tex index d992026..544f392 100644 --- a/tex/chapters/9_conclusion.tex +++ b/tex/chapters/9_conclusion.tex @@ -2,14 +2,38 @@ \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. +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 and linters such as Verilator document 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 and linters 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 \autoref{chapter:resources}, 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 synthesizable 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 software essential skills like Git version control and code scalability. Furthermore, I have described that DigitalJS Online should be used to create a stronger connection between Verilog code and hardware circuits, helping bridge the gap between hardware and software. + \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 and linters such as Verilator document 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 and linters 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 \autoref{chapter:resources}, 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 synthesizable 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 software essential skills like Git version control and code scalability. + Furthermore, I have described that DigitalJS Online should be used to create a stronger connection between Verilog code and hardware circuits, helping bridge the gap between hardware and software. \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 \enquote{for-fun} leaderboards and \enquote{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. +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 \enquote{for-fun} leaderboards and \enquote{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/tex/figures/OoO.tex b/tex/figures/OoO.tex index b71d2fc..ace37b1 100644 --- a/tex/figures/OoO.tex +++ b/tex/figures/OoO.tex @@ -14,7 +14,8 @@ \vspace{4pt} \subfloat[ - Screenshot of WaveForm. \emph{(Note: this figure omits redundant cycles to improve readability)}. + Screenshot of WaveForm. + \emph{(Note: this figure omits redundant cycles to improve readability)}. ]{ \includegraphics[width=0.9\linewidth]{media/graphics/labs_with_cva6/OoO.png} } @@ -23,7 +24,8 @@ \caption[ Out-of-Order Demonstration with CVA6 ]{ - Out-of-Order Demonstration with CVA6: FPU and LSU finish before MULT \cite{SiffermanLatchUp}. In the Out-of-Order lab, participants are asked to write an assembly program to demonstrate code with and without different data-hazards. + Out-of-Order Demonstration with CVA6: FPU and LSU finish before MULT \cite{SiffermanLatchUp}. + In the Out-of-Order lab, participants are asked to write an assembly program to demonstrate code with and without different data-hazards. } \label{fig:OoO} diff --git a/tex/figures/always_ff.tex b/tex/figures/always_ff.tex index 5894180..2c431fc 100644 --- a/tex/figures/always_ff.tex +++ b/tex/figures/always_ff.tex @@ -7,7 +7,7 @@ \caption[ Examples of bug-prone \mintinline{SystemVerilog}{always_ff} blocks ]{ - Potentially confusing behaviors of \mintinline{SystemVerilog}{always_ff} blocks + Potentially confusing behaviors of \mintinline{SystemVerilog}{always_ff} blocks. } \label{fig:always_ff} \end{figure} diff --git a/tex/figures/asic_flow.tex b/tex/figures/asic_flow.tex index 0817a89..3861287 100644 --- a/tex/figures/asic_flow.tex +++ b/tex/figures/asic_flow.tex @@ -5,7 +5,7 @@ \caption[ Abbreviated diagram of ASIC design flow ]{ - Abbreviated diagram of ASIC design flow published by Kynix \cite{kynixDesignFlow} + Abbreviated diagram of ASIC design flow published by Kynix \cite{kynixDesignFlow}. } \label{fig:asic_flow} \end{figure} diff --git a/tex/figures/asicworld.tex b/tex/figures/asicworld.tex index 0c29d7f..ef6f88d 100644 --- a/tex/figures/asicworld.tex +++ b/tex/figures/asicworld.tex @@ -5,7 +5,8 @@ \caption[ ASIC World bad example ]{ - This is an example provided by ASIC World that encourages putting combinational logic inside \mintinline{SystemVerilog}{always_ff} blocks. \cite{asicworld} I explain why this is a bad design practice in \autoref{section:tutorial_websites}. + This is an example provided by ASIC World that encourages putting combinational logic inside \mintinline{SystemVerilog}{always_ff} blocks. + \cite{asicworld} I explain why this is a bad design practice in \autoref{section:tutorial_websites}. } \label{fig:asicworld} \end{figure} diff --git a/tex/figures/branch_predictor.tex b/tex/figures/branch_predictor.tex index 97afecf..c30455b 100644 --- a/tex/figures/branch_predictor.tex +++ b/tex/figures/branch_predictor.tex @@ -5,7 +5,8 @@ \caption[ Branch Predictor Design for \enquote{Labs with CVA6} ]{ - Block diagram of the Global Two-Level Branch Predictor Design featured in \enquote{Labs with CVA6}. Participants are tasked with transforming CVA6's branch predictor into a more-sophisticated global predictor, enhancing the processor's performance by improving branch hit-rate for specifically designed benchmarks \cite{labsWithCVA6}. + Block diagram of the Global Two-Level Branch Predictor Design featured in \enquote{Labs with CVA6}. + Participants are tasked with transforming CVA6's branch predictor into a more-sophisticated global predictor, enhancing the processor's performance by improving branch hit-rate for specifically designed benchmarks \cite{labsWithCVA6}. } \label{fig:branch_predictor} \end{figure} diff --git a/tex/figures/c-like.tex b/tex/figures/c-like.tex index 9a95960..1b3d5a1 100644 --- a/tex/figures/c-like.tex +++ b/tex/figures/c-like.tex @@ -25,7 +25,8 @@ \caption[ Structural vs.\ C-like Verilog ]{ - Provided is an example of when C-like constructs can be used to write cleaner code compared to purely structural constructs. Sub-figures \ref{subfig:structural_only} and \ref{subfig:c-like_allowed} both implement the Find First Set operation, but \ref{subfig:c-like_allowed} is better. + Provided is an example of when C-like constructs can be used to write cleaner code compared to purely structural constructs. + Sub-figures \ref{subfig:structural_only} and \ref{subfig:c-like_allowed} both implement the Find First Set operation, but \ref{subfig:c-like_allowed} is better. } \label{fig:c-like} diff --git a/tex/figures/cache_lab.tex b/tex/figures/cache_lab.tex index 3a23c52..7bdcab8 100644 --- a/tex/figures/cache_lab.tex +++ b/tex/figures/cache_lab.tex @@ -8,7 +8,9 @@ \caption[ Caching Lab starter code snippet ]{ - Snippet of \enquote{Labs with CVA6}'s Cache Lab starter code \cite{labsWithCVA6}. This lab focuses on implementing a victim cache with LRU replacement policy to improve hit rate when CVA6 is configured with a direct-mapped cache. Participants are expected to use modern SystemVerilog \mintinline{SystemVerilog}{typedef} and \mintinline{SystemVerilog}{struct} constructs. + Snippet of \enquote{Labs with CVA6}'s Cache Lab starter code \cite{labsWithCVA6}. + This lab focuses on implementing a victim cache with LRU replacement policy to improve hit rate when CVA6 is configured with a direct-mapped cache. + Participants are expected to use modern SystemVerilog \mintinline{SystemVerilog}{typedef} and \mintinline{SystemVerilog}{struct} constructs. } \label{fig:cache_lab} \end{figure} diff --git a/tex/figures/chipdev_hack.tex b/tex/figures/chipdev_hack.tex index ac3a84e..6f21a27 100644 --- a/tex/figures/chipdev_hack.tex +++ b/tex/figures/chipdev_hack.tex @@ -5,7 +5,9 @@ \caption[ Error in ChipDev's verification flow ]{ - 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 in the future to incorporate a similar verification flow to what is outlined in \autoref{section:complex_tool_setups}. + 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 in the future to incorporate a similar verification flow to what is outlined in \autoref{section:complex_tool_setups}. } \label{fig:chipdev_hack} \end{figure} diff --git a/tex/figures/chipdev_questions.tex b/tex/figures/chipdev_questions.tex index 330248b..a535dd9 100644 --- a/tex/figures/chipdev_questions.tex +++ b/tex/figures/chipdev_questions.tex @@ -5,7 +5,7 @@ \caption[ ChipDev's website ]{ - An example of questions that ChipDev offers. \cite{ChipDev} + An example of questions that ChipDev offers \cite{ChipDev}. } \label{fig:chipdev_questions} \end{figure} diff --git a/tex/figures/cva6_overview.tex b/tex/figures/cva6_overview.tex index 4f425a1..81f31e6 100644 --- a/tex/figures/cva6_overview.tex +++ b/tex/figures/cva6_overview.tex @@ -5,7 +5,8 @@ \caption[ CVA6 Block Diagram ]{ - CVA6 Block Diagram provided by the core documentation \cite{cva6}. Students spend the Branch Prediction and Out-of-Order labs studying each of the 6 stages: \enquote{PC Generation}, \enquote{Instruction Fetch}, \enquote{Instruction Decode}, \enquote{Issue}, \enquote{Execute}, \enquote{Commit.} + CVA6 Block Diagram provided by the core documentation \cite{cva6}. + Students spend the Branch Prediction and Out-of-Order labs studying each of the 6 stages: \enquote{PC Generation}, \enquote{Instruction Fetch}, \enquote{Instruction Decode}, \enquote{Issue}, \enquote{Execute}, \enquote{Commit.} } \label{fig:cva6_overview} \end{figure} diff --git a/tex/figures/dc_vs_synplify.tex b/tex/figures/dc_vs_synplify.tex index 06385b5..6a9fd01 100644 --- a/tex/figures/dc_vs_synplify.tex +++ b/tex/figures/dc_vs_synplify.tex @@ -5,7 +5,7 @@ \caption[ Inconsistencies in SystemVerilog Support in synthesis tools ]{ - Differences in SystemVerilog Support in Synopsys Design Compiler vs.\ Synopsys Synplify-Pro from \enquote{Synthesizing SystemVerilog: Busting the Myth that SystemVerilog is only for Verification} \cite{sutherland} + Differences in SystemVerilog Support in Synopsys Design Compiler vs.\ Synopsys Synplify-Pro from \enquote{Synthesizing SystemVerilog: Busting the Myth that SystemVerilog is only for Verification} \cite{sutherland}. } \label{fig:dc_vs_synplify} \end{figure} diff --git a/tex/figures/digitaljs_online.tex b/tex/figures/digitaljs_online.tex index 5714d12..695f089 100644 --- a/tex/figures/digitaljs_online.tex +++ b/tex/figures/digitaljs_online.tex @@ -5,7 +5,7 @@ \caption[ DigitalJS Online Example ]{ - Schematic for a Parallel-in Serial-out shift register generated by the netlist graph viewer DigitalJS Online \cite{DigitalJSOnline} + Schematic for a Parallel-in Serial-out shift register generated by the netlist graph viewer DigitalJS Online \cite{DigitalJSOnline}. } \label{fig:digitaljs_online} \end{figure} diff --git a/tex/figures/leaderboard.tex b/tex/figures/leaderboard.tex index 54b4904..f0e1a5e 100644 --- a/tex/figures/leaderboard.tex +++ b/tex/figures/leaderboard.tex @@ -5,7 +5,9 @@ \caption[ Gradescope Leaderboard ]{ - Example of a Gradescope leaderboard for a counter lab (same lab as in \autoref{fig:unreadable_opt}). Student designs were ranked on cell usage and maximum frequency as calculated by Yosys and Nextpnr-ice40. (Student names have been obfuscated for privacy reasons). + Example of a Gradescope leaderboard for a counter lab (same lab as in \autoref{fig:unreadable_opt}). + Student designs were ranked on cell usage and maximum frequency as calculated by Yosys and Nextpnr-ice40. + (Student names have been obfuscated for privacy reasons). } \label{fig:leaderboard} \end{figure} diff --git a/tex/figures/opt.tex b/tex/figures/opt.tex index 659e5cd..9958638 100644 --- a/tex/figures/opt.tex +++ b/tex/figures/opt.tex @@ -31,7 +31,7 @@ \caption[ Comparison of synthesis optimizations ]{ - Comparison of synthesis optimizations + Comparison of synthesis optimizations. } \label{fig:opt} diff --git a/tex/final/appendix.tex b/tex/final/appendix.tex index 8d44b57..529e436 100644 --- a/tex/final/appendix.tex +++ b/tex/final/appendix.tex @@ -6,13 +6,14 @@ \chapter{Open-source Contributions} \label{appx:contributions} -This appendix identifies several open-source issues and contributions I have made. Most of the contributions in this appendix are related to my efforts as an HDL educator. +This appendix identifies several open-source issues and contributions I have made. +Most of the contributions in this appendix are related to my efforts as an HDL educator. \section{Open-source issues and contributions created by me} \begin{itemize} \item [\mergedicon] \githubpull{olofk/fusesoc}{645}: Improved inheritance elaboration - \item [\mergedicon] \githubpull{verilator/verilator}{4409}: Check for conflicting options e.g. \texttt{--binary} and \texttt{--lint-only} + \item [\mergedicon] \githubpull{verilator/verilator}{4409}: Check for conflicting options e.g.\ \texttt{--binary} and \texttt{--lint-only} \item [\pullrequesticon] \githubpull{olofk/edalize}{389}: Added support for additional Verilator modes \item [\mergedicon] \githubpull{Rain92/FPGA-Mandelbrot}{1}: Fixed build issues \item [\mergedicon] \githubpull{lowRISC/style-guides}{66}: Prohibit functions from using non-local references diff --git a/tex/preliminary/abstract.tex b/tex/preliminary/abstract.tex index ae8f26a..624ee76 100644 --- a/tex/preliminary/abstract.tex +++ b/tex/preliminary/abstract.tex @@ -5,6 +5,12 @@ \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) often acts as a significant barrier for students hoping to pursue a career in digital design. Drawing upon my experience as a HDL 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. +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) often acts as a significant barrier for students hoping to pursue a career in digital design. +Drawing upon my experience as a HDL 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/tex/preliminary/vitae.tex b/tex/preliminary/vitae.tex index d2cef3b..76ff656 100644 --- a/tex/preliminary/vitae.tex +++ b/tex/preliminary/vitae.tex @@ -3,8 +3,8 @@ \begin{vitaesection}{Education} \vspace{-0.1cm} - \item [Sep\,23 \emph{(expected)}] M.S. in Computer Engineering, University of California, Santa Barbara - \item [June\,22] B.S. in Computer Engineering, University of California, Santa Barbara + \item [Sep\,23 \emph{(expected)}] M.S.\ in Computer Engineering, University of California, Santa Barbara + \item [June\,22] B.S.\ in Computer Engineering, University of California, Santa Barbara \end{vitaesection} \begin{vitaesection}{Professional Experience}