diff --git a/figures/asic_flow.tex b/figures/asic_flow.tex index 3072c2f..022f65f 100644 --- a/figures/asic_flow.tex +++ b/figures/asic_flow.tex @@ -1,7 +1,7 @@ \begin{figure}[t] - \label{fig:asic_flow} \centering \includegraphics[width=90mm]{figures/asic_flow.jpg} \caption{Abbreviated diagram of ASIC design flow published by Kynix \cite{kynixDesignFlow}} + \label{fig:asic_flow} \end{figure} diff --git a/figures/dc_vs_synplify.tex b/figures/dc_vs_synplify.tex index 5850e81..d067a73 100644 --- a/figures/dc_vs_synplify.tex +++ b/figures/dc_vs_synplify.tex @@ -1,7 +1,7 @@ \begin{figure}[t] - \label{fig:dc_vs_synplify} \centering \frame{\includegraphics[width=\linewidth]{figures/dc_vs_synplify.pdf}} \caption{Differences in SystemVerilog Support in DC vs. Synplify-Pro from ``Synthesizing SystemVerilog: Busting the Myth that SystemVerilog is only for Verification''\cite{sutherland}} + \label{fig:dc_vs_synplify} \end{figure} diff --git a/tex/chapters/1_introduction.tex b/tex/chapters/1_introduction.tex index cf123ad..983975d 100644 --- a/tex/chapters/1_introduction.tex +++ b/tex/chapters/1_introduction.tex @@ -6,7 +6,7 @@ \chapter{Introduction} \input{figures/asic_flow} -In the semiconductor industry, the process of designing an application-specific integrated circuit (ASIC) follows a well-defined sequence, where each step requires training and practice. \cite{intelDesignFlow, anysiliconDesignFlow, kynixDesignFlow} The following presents an abbreviated flow tailored for students and open-source tool usage, as illustrated in \autoref{asic_flow}. This process begins with the design phase, where engineers specify the functionality and requirements of the finished integrated circuit (IC). Then, they use hardware description languages (HDLs) like SystemVerilog to detail the circuit's operations and verify its correctness through simulation. After the HDL implementation passes a series of behavioral simulations, it is synthesized for the standard cell library of the target and paired with additional digital and mixed-signal IP blocks. Further testing can include running logical equivalence checks (LECs) to ensure the synthesized netlist is correct, rerunning the behavioral simulations on the synthesized netlist to check for reset behavior, or by running intensive simulations on an FPGA. Once these circuit-level tests pass, layout is completed according to timing constraints and design rule checks (DRC). If timing cannot be met, the layout or HDL implementation may need to be adjusted. Finally, after the layout and simulations checks pass, the design is converted into a Graphic Data Stream (GDS) file which is sent to a semiconductor foundry for mass-production. +In the semiconductor industry, the process of designing an application-specific integrated circuit (ASIC) follows a well-defined sequence, where each step requires training and practice. \cite{intelDesignFlow, anysiliconDesignFlow, kynixDesignFlow} The following presents an abbreviated flow tailored for students and open-source tool usage, as illustrated in \autoref{fig:asic_flow}. This process begins with the design phase, where engineers specify the functionality and requirements of the finished integrated circuit (IC). Then, they use hardware description languages (HDLs) like SystemVerilog to detail the circuit's operations and verify its correctness through simulation. After the HDL implementation passes a series of behavioral simulations, it is synthesized for the standard cell library of the target and paired with additional digital and mixed-signal IP blocks. Further testing can include running logical equivalence checks (LECs) to ensure the synthesized netlist is correct, rerunning the behavioral simulations on the synthesized netlist to check for reset behavior, or by running intensive simulations on an FPGA. Once these circuit-level tests pass, layout is completed according to timing constraints and design rule checks (DRC). If timing cannot be met, the layout or HDL implementation may need to be adjusted. Finally, after the layout and simulations checks pass, the design is converted into a Graphic Data Stream (GDS) file which is sent to a semiconductor foundry for mass-production. Because of how many skills are required to create an ASIC design it is crucial for Universities to offer a strong foundation for writing and working with HDLs to design hardware. Nevertheless, HDLs come with a formidable learning curve, partly due to the difficulties of distinguishing between what code is synthesizable (able to be converted into hardware) and what should be used solely for verification purposes. Additionally, the prevalence of bugs in common HDL tools, the extraordinary inaccessibility of proprietary tools, and the lack of reliable online educational resources are a major deterrent for students and hobbyists who wish to experiment with digital design on their own. Another factor contributing to the complexity is the interdisciplinary nature of ASIC design. For many students, especially those with a software background, this may be their first experience with hardware design, while hardware students must also transition into a more software-centric environment. Bridging this gap and understanding both aspects is vital in today's world of using computer-aided design (CAD) software to design hardware. Universities must recognize the formidable learning curve associated with HDLs and provide comprehensive educational resources, practical hands-on experiences, and interdisciplinary exposure to prepare students for the intricate realm of ASIC design. diff --git a/tex/chapters/2_open_source_tools.tex b/tex/chapters/2_open_source_tools.tex index 492acd9..9846216 100644 --- a/tex/chapters/2_open_source_tools.tex +++ b/tex/chapters/2_open_source_tools.tex @@ -2,22 +2,22 @@ \chapter{Advantages of Open-Source Tools in Education} \label{chapter:open_source_tools} -Although proprietary Verilog tools are predominant in industry and often boast a wide assortment of features, I argue that they can be one of the biggest deterrents for those first learning digital design. Whether students become aghast at the preposterous licensing fees or become hung up on the steep learning curve of the interfaces, the most popular Verilog tools often have trouble exciting students into furthering their Verilog education. Fortunately, there are several open-source Verilog tools that are praised for their accessibility and ease-of-use. A valuable resource for open-source hardware tools, generators, and reusable designs can be found in the curated list provided here: \url{https://github.com/aolofsson/awesome-opensource-hardware}. For example, a common collection of tools include the simulators Icarus [ref] and Verilator [ref], the waveform viewer GTKWave [ref], the synthesis tool Yosys [ref], the FPGA place and route tools Nextpnr [ref] and VTR [ref], the ASIC flow OpenLane [ref], and the hardware package manager and build system FuseSoC [ref]. In this section, I will explain why open-source tools excel over proprietary tools in introducing Verilog and digital design to students. +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 section, I will explain why open-source tools excel over proprietary tools in introducing Verilog and digital design to students. \section{Proprietary tool prices deter students.} -Many students choose to pursue a degree in computer engineering due to the plethora of creative outlets that it introduces them to. Consider the hands-on process of purchasing affordable components and assembling circuits on breadboards. Likewise, platforms like Arduinos and Raspberry Pis are often explored alongside the utilization of programming languages such as C++, Python, and JavaScript. The accessibility and low cost of these mediums often foster self-directed learning. Similarly, introductory Verilog courses can serve as yet another avenue for creative expression, particularly when orchestrated using free and open-source tools. However, a significant obstruction emerges when proprietary alternatives such as Questa, VCS, and Xcelium, coupled with licensing fees over \$5,000, [ref] become the focal point of a student's introduction to Verilog. Such financial barriers can easily deter enthusiasm for self-guided learning, particularly when students anticipate losing access to the software upon graduation. This is likely the reason why several students in UC Santa Barbara's Verilog courses choose to disobey the requirement of using ModelSim, and instead use Icarus and GTKWave. Students don't want to feel like their time is wasted learning a tool if they lose access to it upon graduation. +Many students choose to pursue a degree in computer engineering due to the plethora of creative outlets that it introduces them to. Consider the hands-on process of purchasing affordable components and assembling circuits on breadboards. Likewise, platforms like Arduinos and Raspberry Pis are often explored alongside the utilization of programming languages such as C++, Python, and JavaScript. The accessibility and low cost of these mediums often foster self-directed learning. Similarly, introductory Verilog courses can serve as yet another avenue for creative expression, particularly when orchestrated using free and open-source tools. However, a significant obstruction emerges when proprietary alternatives such as Questa, VCS, and Xcelium, coupled with licensing fees over \$5,000, \cite{olofssonLatchUp, licensePricesReddit} become the focal point of a student's introduction to Verilog. Such financial barriers can easily deter enthusiasm for self-guided learning, particularly when students anticipate losing access to the software upon graduation. This is likely the reason why several students in UC Santa Barbara's Verilog courses choose to disobey the requirement of using ModelSim, and instead use Icarus and GTKWave. Students don't want to feel like their time is wasted learning a tool if they lose access to it upon graduation. \section{Open-source tools are easy to install.} -Even if students aren't hoping to expand their arsenal of tools for expressing their creativity, it is still important to keep Verilog tools accessible by improving students' first-time user experience. For example, Vivado is infamous for its tedious and complex installation process while taking up over 16-60GB when installed. This is contrasted with the overall positive first-time user experience that open-source tools offer. For example, with the ``OSS CAD Suite'' project [ref], you can download all the latest binaries of the most popular open-source Verilog tools in under a minute. This beats Vivado's complicated installation process by a mile and is more-likely to remain on student's computers after the course is over since all the tools only take up half a gigabyte, as opposed to the 16-60GB that Vivado requires. +Even if students aren't hoping to expand their arsenal of tools for expressing their creativity, it is still important to keep Verilog tools accessible by improving students' first-time user experience. For example, Vivado is infamous for its tedious and complex installation process while taking up over 16-60GB when installed. This is contrasted with the overall positive first-time user experience that open-source tools offer. For example, with the ``OSS CAD Suite'' project \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 more desired by beginners. For example, Icarus runs short simulations much faster than proprietary simulators, making it perfect for receiving instant feedback as students are still learning the language syntax. Similarly, Yosys and Nextpnr perform synthesis and layout significantly faster than tools such as Vivado and Design Compiler, allowing for more rapid prototyping. Also, while ModelSim may happily parse and simulate un-synthesizable code, Verilator will give much more strict warnings, helping to demonstrate the syntax and features that should be allowed in synthesizable designs. (This is further discussed in Section III.) Finally, open-source tools get updates every day, and instructors are able to report bugs and request new features. Depending on the difficulty of the request, the tool maintainers may complete the request within a few months. Multiple of my courses have directly benefited from this [appx]. Instructors may even decide they want to do a pull-request themselves; I personally have contributed two new warnings to Verilator in hopes of teaching best-practices. [appx] This is contrasted with the fact that many universities are not always running the most up-to-date proprietary software. For example, as of 9/10/23, UC Santa Barbara's Engineering Computing Infrastructure's latest version of ModelSim is 10.7d (from April 2019), which does not support width-casting from parameters, which affected the UCSB Spring 2023 ECE 152A course experience. Bugs in tools will undoubtedly happen, but the only solution Siemens offers is to pay for an updated version with the bug fixed. Contrast this with submitting a GitHub issue with Verilator, and having the bug fixed by the next time the course is offered. Open-source tools are often simply the better choice for instructors. +Undoubtedly, proprietary tools offer a multitude of functionalities for advanced users that open-source tools cannot offer. However, open-source tools offer many unique features that are more desired by beginners. For example, Icarus runs short simulations much faster than proprietary simulators, making it perfect for receiving instant feedback as students are still learning the language syntax. Similarly, Yosys and Nextpnr perform synthesis and layout significantly faster than tools such as Vivado and Design Compiler, allowing for more rapid prototyping. Also, while ModelSim may happily parse and simulate un-synthesizable code, Verilator will give much more strict warnings, helping to demonstrate the syntax and features that should be allowed in synthesizable designs. (This is further discussed in \autoref{chapter:digital_design}.) Finally, open-source tools get updates every day, and instructors are able to report bugs and request new features. Depending on the difficulty of the request, the tool maintainers may complete the request within a few months. Multiple of my courses have directly benefited from this [appx]. Instructors may even decide they want to do a pull-request themselves; I personally have contributed two new warnings to Verilator in hopes of teaching best-practices. [appx] This is contrasted with the fact that many universities are not always running the most up-to-date proprietary software. For example, as of 9/10/23, UC Santa Barbara's Engineering Computing Infrastructure's latest version of ModelSim is 10.7d from April 2019, which does not support width-casting from parameters, which affected the UCSB Spring 2023 ECE 152A course experience. Bugs in tools will undoubtedly happen, but the only solution Siemens offers is to pay for an updated version with the bug fixed. Contrast this with submitting a GitHub issue with Verilator, and having the bug fixed by the next time the course is offered. Open-source tools are often simply the better choice for instructors. \section{Avoid graphical user interfaces.} -One of the most important ways to make Verilog more accessible is by guiding students to use command line interfaces (CLIs). Nearly all large-scale Verilog designs are paired with user-friendly build scripts and Makefiles for running simulation and synthesis. [ref] This is contrasted with the complex graphical user interfaces in tools like Vivado, ModelSim, VCS, and Quartus, which can feel daunting for beginners due to the number of options that users have direct access to. UC Santa Cruz Professor Dustin Richmond compares learning Vivado to being stuck in a ``point-and-click adventure game'' in his talk ``So, you want to be an open sourcerer?'' [ref]. By using CLIs, you can abstract away and decouple tool-specifics from digital design concepts. +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 the complex graphical user interfaces in tools like Vivado, ModelSim, VCS, and Quartus, which can feel daunting for beginners due to the number of options that users have direct access to. UC Santa Cruz Professor Dustin Richmond compares learning Vivado to being stuck in a ``point-and-click adventure game'' in his talk ``So, you want to be an open sourcerer?'' \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 [ref] attempt to standardize build files for all Verilog tools with a central \mintinline{bash}{.core} file. The \mintinline{bash}{.core} file, interpretable by FuseSoC, contains the ``run'' specifications, which are then seamlessly communicated to Edalize for the automated generation and execution of build scripts with the designated tool. FuseSoC is compatible with nearly every Verilog tool, so switching simulators is often as easy as changing one line of code. While TAing for UCSB's ECE 152A, 154A, and 154B, I capitalized on the utility of FuseSoC and Edalize to substantially accelerate assignment setup time. I could provide students with the Makefile automatically generated by Edalize, or I could provide the \mintinline{bash}{.core} file for students to run themselves with FuseSoC. Either option was effective in simplifying the build process so students could better focus on the learning-goals of the assignments. +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 ``run'' specifications, which are then seamlessly communicated to Edalize for the automated generation and execution of build scripts with the designated tool. FuseSoC is compatible with nearly every Verilog tool, so switching simulators is often as easy as changing one line of code. While TAing for UCSB's ECE 152A, 154A, and 154B, I capitalized on the utility of FuseSoC and Edalize to substantially accelerate assignment setup time. I could provide students with the Makefile automatically generated by Edalize, or I could provide the \mintinline{bash}{.core} file for students to run themselves with FuseSoC. Either option was effective in simplifying the build process so students could better focus on the learning-goals of the assignments. diff --git a/tex/chapters/3_digital_design.tex b/tex/chapters/3_digital_design.tex index 6f6faf5..aeef09b 100644 --- a/tex/chapters/3_digital_design.tex +++ b/tex/chapters/3_digital_design.tex @@ -9,8 +9,9 @@ \section{Netlist graph viewers teach Verilog inference intuition.} [Fig] By providing a visual representation of the synthesis process, students can gain a deeper insight into how their high-level descriptions are transformed into hardware components. DigitalJS Online [ref] stands as a notable example of such netlist graph viewers. Through its zero-setup, interactive web interface, students can witness rapid translation of their Verilog code into synthesized hardware, which encourages experimentation and rapid prototyping. Additionally, its text editor runs automatic linting with Verilator, which gives incredibly helpful feedback if a syntax-related bad-practice is detected. During a volunteer lecture for UCSB's IEEE student chapter, I taught Verilog concepts from DigitalJS Online's text editor, which seamlessly visualized the logic I was describing in my examples. Also, as a TA for ECE 152A and 154B, I curated several assignments that challenged students to use DigitalJS Online to transform \mintinline{systemverilog}{for} loops and \mintinline{systemverilog}{if} statements into comprehensive, hand-drawn circuit diagrams. [fig] Similarly, UC Santa Cruz Professor Dustin Richmond uses netlist graph viewers to teach best-practices concerning \mintinline{systemverilog}{case} and \mintinline{systemverilog}{if} statements. [ref] Through a process of hands-on exploration with netlist graph viewers, students can learn the mechanics of translating SystemVerilog constructs into tangible hardware and gain the ability to convert Verilog to schematics by hand. By assigning homework and in-lecture exercises that prompt students to deduce logical constructs from visual synthesis outputs, their aptitude to understand both Verilog and synthesis is significantly enhanced. \section{Enabling optimizations in netlist graph viewers creates complexity.} +\label{section:optimizations_in_netlist_graph_viewers} -While synthesis tools may run their own specific optimizations, learning these intricacies are not critical, given the overall proficiency of available tools and the limited need for target-specific code optimization. Instead, the primary focus should be on teaching students to write clear and transferable code, adhering to best practices covered in the class. (See more in the autograder leaderboard section.) While it is acceptable to encourage students to explore various tool and language features as illustrated in [fig], it is crucial to maintain a balance. Experimentation can stimulate curiosity and self-directed learning, but there may be instances where netlist graph viewers hinder rather than facilitate understanding. For example, as students start working with larger designs, the chances are increased that a quietly-applied, tool-specific synthesis optimization will result in a netlist that, while valid, would take too much time to decipher and understand. This may turn instructors entirely away from using netlist graph viewers due to the additional confusion that they cause. However, I argue that they are still an essential resource for introducing Verilog, helping students transition from gate schematics to HDLs. These tools serve as a foundation for students to build their intuition for synthesis, ultimately empowering them to undertake the more advanced design challenges. Even if netlist graph viewers lose their effectiveness as designs get complex, they illustrate to students the vital connection between digital design concepts and Verilog concepts. +While synthesis tools may run their own specific optimizations, learning these intricacies are not critical, given the overall proficiency of available tools and the limited need for target-specific code optimization. Instead, the primary focus should be on teaching students to write clear and transferable code, adhering to best practices covered in the class. (See more in \autoref{section:leaderboard}.) While it is acceptable to encourage students to explore various tool and language features as illustrated in [fig], it is crucial to maintain a balance. Experimentation can stimulate curiosity and self-directed learning, but there may be instances where netlist graph viewers hinder rather than facilitate understanding. For example, as students start working with larger designs, the chances are increased that a quietly-applied, tool-specific synthesis optimization will result in a netlist that, while valid, would take too much time to decipher and understand. This may turn instructors entirely away from using netlist graph viewers due to the additional confusion that they cause. However, I argue that they are still an essential resource for introducing Verilog, helping students transition from gate schematics to HDLs. These tools serve as a foundation for students to build their intuition for synthesis, ultimately empowering them to undertake the more advanced design challenges. Even if netlist graph viewers lose their effectiveness as designs get complex, they illustrate to students the vital connection between digital design concepts and Verilog concepts. A similar example is providing simplified schematics of transistor implementations of digital gates to relate electrical engineering students to their prior knowledge of analog design. Because transistor implementation specifics are largely unimportant due to the low demand for PDK designers, it is fine to simply introduce basic technologies such as pass-transistor logic instead of analyzing modern multi-finger FinFET CMOS designs. But only after receiving some connection to their prior experience with transistors will electrical engineering students feel comfortable working with gates. Similarly, when introducing Verilog to students, using netlist graph viewers can connect prior knowledge of digital elements to code syntax. Much like electrical engineers need some familiarity with transistor-level gate implementations prior to diving into digital design, Verilog students greatly benefit from a foundational understanding of the behavior of synthesis tools. diff --git a/tex/chapters/4_resources.tex b/tex/chapters/4_resources.tex index 86d8ba2..cdecbaf 100644 --- a/tex/chapters/4_resources.tex +++ b/tex/chapters/4_resources.tex @@ -10,9 +10,9 @@ \section{Stuart Sutherland's synthesis guide is most valuable.} \section{Style guides record synthesizable features and best-practices.} -Even while avoiding unsynthesizable SystemVerilog features, design tools are infamous for misinterpreting syntax and often providing little or misleading information on errors. Therefore, following a well-verified style guide is crucial to ensure that an RTL implementation will work on an assortment of tools. As mentioned in Section III, style guides help direct engineers away from ambiguous or poorly-supported language features, and towards styles and features that are verified to tape-out chips successfully. By introducing Verilog syntax alongside an exhaustive and highly-verified style guide, students can feel much more confident exploring new language features. +Even while avoiding unsynthesizable SystemVerilog features, design tools are infamous for misinterpreting syntax and often providing little or misleading information on errors. Therefore, following a well-verified style guide is crucial to ensure that an RTL implementation will work on an assortment of tools. As mentioned in \autoref{chapter:digital_design}, style guides help direct engineers away from ambiguous or poorly-supported language features, and towards styles and features that are verified to tape-out chips successfully. By introducing Verilog syntax alongside an exhaustive and highly-verified style guide, students can feel much more confident exploring new language features. -See [appx] for a(n incomplete) list of style guides. The lowRISC Style Guide discusses many best-practices surrounding language features such as the alias statement, automatic scopes, package imports, and floating begin-end blocks. The Bespoke Silicon Group Style Guide is also strong due to its discussion of structures, enumerations, and memories. Personally, I teach the lowRISC style guide because of the clarity in \mintinline{systemverilog}{_d} and \mintinline{systemverilog}{_q} as suffixes for register inputs and outputs, and to match the ``Labs with CVA6'' project (Section [cva6]). +See [appx] for a(n incomplete) list of style guides. The lowRISC Style Guide discusses many best-practices surrounding language features such as the alias statement, automatic scopes, package imports, and floating begin-end blocks. The Bespoke Silicon Group Style Guide is also strong due to its discussion of structures, enumerations, and memories. Personally, I teach the lowRISC style guide because of the clarity in \mintinline{systemverilog}{_d} and \mintinline{systemverilog}{_q} as suffixes for register inputs and outputs, and to match the ``Labs with CVA6'' project. (See \autoref{chapter:labs_with_cva6}.) \section{Verilog tutorial websites should be treated cautiously.} diff --git a/tex/chapters/6_autograders.tex b/tex/chapters/6_autograders.tex index e9d6b56..5518385 100644 --- a/tex/chapters/6_autograders.tex +++ b/tex/chapters/6_autograders.tex @@ -15,8 +15,9 @@ \section{Autograders can run remotely without complex local-setup.} As mentioned, an autograder test suite that closely mirrors industry quality should follow all the verification steps demonstrated in Figure [fig]. First, it is important to run behavioral simulations with multiple tools such as Icarus, which supports propagation of unknown (\mintinline{systemverilog}{x}) values, and simulation with Verilator, which has stronger restrictions on bad syntax. Only by passing simulations with both tools should the autograder grant full points. Furthermore, code linters such as Verilator and Verible can ensure adherence to essential coding standards and practices, checking for issues like latches in \mintinline{systemverilog}{always_comb} blocks, correct use of blocking and non-blocking assignments, net-width discrepancies, and more. Considering that the frontends of tools do not always offer helpful warnings, this detailed syntax checking from Verilator and Verible is invaluable for students when fixing otherwise cryptic issues. Then, to deploy SystemVerilog synthesis with open-source tools, Yosys and Nextpnr must be paired with a frontend such as Surelog or zachjs/sv2v. The Yosys synthesis and Nextpnr layout process can verify if students are using too many logic cells, if their design is too slow, or if their design infers prohibited logic cells. As a final post-synthesis step, Icarus can be run one final time on the Yosys output to initiate a gate-level simulation (GLS) with unknown value propagation, and Yosys EQY can be run to perform logical equivalence checking (LEC). All of these features (*aside from LEC with EQY {ran out of time}) have been successfully implemented in autograders from ECE 152A, 154A, and 154B. \section{``For-fun'' leaderboards can excite and inspre students.} +\label{section:leaderboard} -Aside from a grade assigned by the autograder, another form of feedback can be provided through a class leaderboard. Students can see how their submission compares to the rest of the class on statistics such as logic cell usage, max clock frequency, or branch predictor hit percentage. Since the leaderboards in ECE 152A and 154B didn't count towards any points, students really enjoyed seeing how each of their designs compared to their peers' designs, then would try to beat their friends for bragging rights. Because of this, I added leaderboards to every assignment that I could. However, it is important to clarify to students that code readability should be prioritized over moving up in the leaderboard by saving 1-2 logic cells. However, because autograders running purely open-source tools must only rely on Yosys and ABC for synthesis, students may be incorrectly rewarded for submissions that are not well-optimized for other more prevalent synthesis tools such as Design Compiler or Vivado. This was a rare edge case that only visibly affected 1 submission ([fig]) total across the 800+ different submissions from the classes I introduced leaderboards to, but is important to monitor. (See more in the Netlist Graph Viewer [section].) Overall, the leaderboard increased student enthusiasm without bringing additional stress or responsibilities. +Aside from a grade assigned by the autograder, another form of feedback can be provided through a class leaderboard. Students can see how their submission compares to the rest of the class on statistics such as logic cell usage, max clock frequency, or branch predictor hit percentage. Since the leaderboards in ECE 152A and 154B didn't count towards any points, students really enjoyed seeing how each of their designs compared to their peers' designs, then would try to beat their friends for bragging rights. Because of this, I added leaderboards to every assignment that I could. However, it is important to clarify to students that code readability should be prioritized over moving up in the leaderboard by saving 1-2 logic cells. However, because autograders running purely open-source tools must only rely on Yosys and ABC for synthesis, students may be incorrectly rewarded for submissions that are not well-optimized for other more prevalent synthesis tools such as Design Compiler or Vivado. This was a rare edge case that only visibly affected 1 submission ([fig]) total across the 800+ different submissions from the classes I introduced leaderboards to, but is important to monitor. (See more in \autoref{section:optimizations_in_netlist_graph_viewers}.) Overall, the leaderboard increased student enthusiasm without bringing additional stress or responsibilities. \section{Autograders can foster community and collaboration.} diff --git a/tex/chapters/9_conclusion.tex b/tex/chapters/9_conclusion.tex index 1b77106..5a6c101 100644 --- a/tex/chapters/9_conclusion.tex +++ b/tex/chapters/9_conclusion.tex @@ -1,6 +1,6 @@ \chapter{Conclusion} -\label{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. @@ -8,7 +8,7 @@ \chapter{Conclusion} \item \textbf{Synthesizable vs. Verification Features:} A critical issue in Verilog education lies in distinguishing between synthesizable and verification features. This thesis has addressed this concern through multiple avenues. Using netlist graph viewers like DigitalJS Online, which enables students to visualize the synthesis process, helps visually demonstrate what constructs lead to valid netlists. Additionally, style guides like from the lowRISC Organization act as the best practices for writing synthesizable code. Finally, autograders can provide immediate, personalized feedback to students on whether their code is both behaviorally correct and synthesizable. \item \textbf{Prevalence of Bugs in Common HDL Tools:} Common Verilog and SystemVerilog tools often suffer from bugs when using lesser-used features. To mitigate this, style guides by lowRISC, Bespoke Silicon Group, and more should be used to teach students the best syntax and strategies for avoiding common pitfalls. Autograders can also play a pivotal role by seamlessly testing student code across a multitude of tools. If a submission passes tests for several tools, it is much more likely that it will work properly for all tools. \item \textbf{Inaccessibility of Proprietary Tools:} The reliance on proprietary tools in Verilog education has been a barrier to accessibility for many beginners. Open-source tools highlighted in this work present a solution by being cost-free, easier to install, and more user-friendly. This shift towards open-source tools enhances equity in education and industry and enables a broader spectrum of engineers to engage effectively with Verilog. - \item \textbf{The Lack of Reliable Educational Resources:} There is a shortage of reliable educational resources in Verilog/SystemVerilog. In this thesis, a comprehensive list of resources has been provided in Section IV, serving as a valuable reference for both instructors and students. These resources cover a range of use-cases and are designed to support a deeper understanding of Verilog. + \item \textbf{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 Verilog. \item \textbf{Interdisciplinary Nature of Chip Design:} Verilog and SystemVerilog education must acknowledge the interdisciplinary nature of chip design, involving both software and hardware components. This thesis emphasizes the importance of dedicating time to teaching essential skills like Git version control. Furthermore, I have described that DigitalJS Online should be used to create a stronger connection between Verilog code and hardware circuits, helping both software and hardware engineers become more well-rounded. \end{itemize} diff --git a/tex/thesis.bib b/tex/thesis.bib index d335ed1..0152a1d 100644 --- a/tex/thesis.bib +++ b/tex/thesis.bib @@ -83,3 +83,106 @@ @misc{anysiliconDesignFlow howpublished = {\url{https://anysilicon.com/asic-design-flow-ultimate-guide/}}, note = {[Accessed 18-09-2023]}, } + +@misc{icarusGitHub, + author = {Stephen Williams}, + title = {steveicarus/iverilog: {I}carus {V}erilog}, + howpublished = {\url{https://github.com/steveicarus/iverilog}}, + note = {[Accessed 18-09-2023]}, +} + +@misc{verilatorGitHub, + author = {Wilson Snyder}, + title = {verilator/verilator: {V}erilator open-source {S}ystem{V}erilog simulator and lint system}, + howpublished = {\url{https://github.com/verilator/verilator}}, + note = {[Accessed 18-09-2023]}, +} + +@misc{gtkwaveGitHub, + author = {Ralf Fuest}, + title = {gtkwave/gtkwave: {G}{T}{K}{W}ave is a fully featured {G}{T}{K}+ based wave viewer for {U}nix and {W}in32 which reads {L}{X}{T}, {L}{X}{T}2, {V}{Z}{T}, {F}{S}{T}, and {G}{H}{W} files as well as standard {V}erilog {V}{C}{D}/{E}{V}{C}{D} files}, + howpublished = {\url{https://github.com/gtkwave/gtkwave}}, + note = {[Accessed 18-09-2023]}, +} + +@misc{yosysGitHub, + author = {{Y}osys{H}{Q}}, + title = {{Y}osys {O}pen {S}{Y}nthesis {S}uite}, + howpublished = {\url{https://github.com/YosysHQ/yosys}}, + note = {[Accessed 18-09-2023]}, +} + +@misc{nextpnrGitHub, + author = {{Y}osys{H}{Q}}, + title = {nextpnr portable {F}{P}{G}{A} place and route tool}, + howpublished = {\url{https://github.com/YosysHQ/nextpnr}}, + note = {[Accessed 18-09-2023]}, +} + +@misc{vtrGitHub, + title = {verilog-to-routing/vtr-verilog-to-routing: {V}erilog to {R}outing -- {O}pen {S}ource {C}{A}{D} {F}low for {F}{P}{G}{A} {R}esearch}, + howpublished = {\url{https://github.com/verilog-to-routing/vtr-verilog-to-routing}}, + note = {[Accessed 18-09-2023]}, +} + +@inproceedings{OpenLaneGitHub, + author = {Shalan, Mohamed and Edwards, Tim}, + booktitle = {2020 IEEE/ACM International Conference On Computer Aided Design (ICCAD)}, + title = {Building OpenLANE: A 130nm OpenROAD-based Tapeout- Proven Flow : Invited Paper}, + year = {2020}, + pages = {1-6}, + note = {\url{https://github.com/The-OpenROAD-Project/OpenLane}}, +} + +@misc{fusesocGitHub, + author = {Olof Kindgren}, + title = {olofk/fusesoc: {P}ackage manager and build abstraction tool for {F}{P}{G}{A}/{A}{S}{I}{C} development}, + howpublished = {\url{https://github.com/olofk/fusesoc}}, + note = {[Accessed 18-09-2023]}, +} + +@misc{edalizeGitHub, + author = {Olof Kindgren}, + title = {olofk/edalize: {A}n abstraction library for interfacing {E}{D}{A} tools}, + howpublished = {\url{https://github.com/olofk/edalize}}, + note = {[Accessed 18-09-2023]}, +} + +@misc{awesomeOpenSourceHardware, + author = {Andreas Olofsson}, + title = {aolofsson/awesome-opensource-hardware: {L}ist of awesome open source hardware tools, generators, and reusable designs}, + howpublished = {\url{https://github.com/aolofsson/awesome-opensource-hardware}}, + note = {[Accessed 18-09-2023]}, +} + +@misc{olofssonLatchUp, + title = {Goodbye Make, Hello SiliconCompiler!}, + author = {Olofsson, Andreas}, + howpublished = {\url{https://youtu.be/GM9PKAfTlmQ}}, + year = {2023}, + note = {Latch-Up}, +} + +@misc{licensePricesReddit, + author = {u/[deleted]}, + title = {{M}odelsim and {Q}uesta license price: {T}oo expensive?}, + howpublished = {\url{https://www.reddit.com/r/FPGA/comments/c8z1x9/modelsim_and_questa_license_price_too_expensive/}}, + month = {July}, + year = {2019}, + note = {[Accessed 18-09-2023]}, +} + +@misc{osscadsuitebuildGitHub, + author = {{Y}osys{H}{Q}}, + title = {{M}ulti-platform nightly builds of open source digital design and verification tools}, + howpublished = {\url{https://github.com/YosysHQ/oss-cad-suite-build}}, + note = {[Accessed 18-09-2023]}, +} + +@misc{RichmondLatchUp, + title = {So, you want to be an open sourcerer?}, + author = {Richmond, Dustin}, + howpublished = {\url{https://youtu.be/-rXgQxWRKIg}}, + year = {2023}, + note = {Latch-Up}, +} diff --git a/tex/thesis.tex b/tex/thesis.tex index b524ab0..ce0b55d 100644 --- a/tex/thesis.tex +++ b/tex/thesis.tex @@ -41,6 +41,7 @@ \newcommand{\D}[2]{\frac{d#1}{d#2}} \renewcommand{\chapterautorefname}{Chapter} +\renewcommand{\sectionautorefname}{Section} %---Set Margins ------------------------------------------------------ \setlength\oddsidemargin{0.25 in} \setlength\evensidemargin{0.25 in} \setlength\textwidth{6.25 in} \setlength\textheight{8.50 in}