diff --git a/.github/workflows/code.yml b/.github/workflows/code.yml new file mode 100644 index 0000000..083271e --- /dev/null +++ b/.github/workflows/code.yml @@ -0,0 +1,39 @@ +name: Test Code Examples + +on: [push] + +jobs: + Verify-Solution: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v3 + - name: Set up Python 3.x + uses: actions/setup-python@v4 + with: + python-version: '3.x' + - name: Download FuseSoC + run: | + python -m pip install --upgrade pip + pip install fusesoc + fusesoc --version + - name: Install gcc-10 + run: | + sudo apt update + sudo apt install -y build-essential + sudo apt install -y gcc-10 g++-10 cpp-10 + sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-10 100 --slave /usr/bin/g++ g++ /usr/bin/g++-10 --slave /usr/bin/gcov gcov /usr/bin/gcov-10 + gcc --version + - name: Download OSS + run: | + curl -JOL https://github.com/YosysHQ/oss-cad-suite-build/releases/download/2023-05-23/oss-cad-suite-linux-x64-20230523.tgz + tar -xzvf oss-cad-suite-linux-x64-20230523.tgz -C ./ + rm -rf oss-cad-suite-linux-x64-20230523.tgz + echo "$GITHUB_WORKSPACE/oss-cad-suite/bin" >> $GITHUB_PATH + - name: Test C-like + run: | + cd $GITHUB_WORKSPACE/code/c-like + make + - name: Test Cache Lab + run: | + cd $GITHUB_WORKSPACE/code/cache_lab + make diff --git a/code/c-like/Makefile b/code/c-like/Makefile new file mode 100644 index 0000000..b6b562d --- /dev/null +++ b/code/c-like/Makefile @@ -0,0 +1,10 @@ + +all: clean verilator + +obj_dir/Vtb: tb.sv high.svh low.svh + verilator tb.sv --binary -Wall -Wno-fatal --top tb +verilator: obj_dir/Vtb + ./obj_dir/Vtb + +clean: + rm -rf obj_dir Vtb.vvp build diff --git a/code/c-like/high.svh b/code/c-like/high.svh new file mode 100644 index 0000000..0c9e8b6 --- /dev/null +++ b/code/c-like/high.svh @@ -0,0 +1,10 @@ + +function automatic logic [4:0] find_first_set32(logic [31:0] in); + logic [4:0] out = 0; + for (integer i = 1; i < 32; i++) + if (in[i]) + out = i; + return out; +endfunction + +assign out = find_first_set32(in); diff --git a/code/c-like/low.svh b/code/c-like/low.svh new file mode 100644 index 0000000..1aa4904 --- /dev/null +++ b/code/c-like/low.svh @@ -0,0 +1,18 @@ + +assign out = + in[31] ? 31 : in[30] ? 30 : + in[29] ? 29 : in[28] ? 28 : + in[27] ? 27 : in[26] ? 26 : + in[25] ? 25 : in[24] ? 24 : + in[23] ? 23 : in[22] ? 22 : + in[21] ? 21 : in[20] ? 20 : + in[19] ? 19 : in[18] ? 18 : + in[17] ? 17 : in[16] ? 16 : + in[15] ? 15 : in[14] ? 14 : + in[13] ? 13 : in[12] ? 12 : + in[11] ? 11 : in[10] ? 10 : + in[ 9] ? 9 : in[ 8] ? 8 : + in[ 7] ? 7 : in[ 6] ? 6 : + in[ 5] ? 5 : in[ 4] ? 4 : + in[ 3] ? 3 : in[ 2] ? 2 : + in[ 1] ? 1 : 0; diff --git a/code/c-like/tb.sv b/code/c-like/tb.sv new file mode 100644 index 0000000..7147577 --- /dev/null +++ b/code/c-like/tb.sv @@ -0,0 +1,48 @@ +module find_first_set32 #( + parameter string IMPLEMENTATION +) ( + input logic [31:0] in, + output logic [4:0] out +); + +if (IMPLEMENTATION == "LOW") begin : low + `include "low.svh" +end else if (IMPLEMENTATION == "HIGH") begin : high + `include "high.svh" +end else begin : bad + initial begin + $error("Expected valid values for IMPLEMENTATION are \"LOW\" or \"HIGH\". Received \"%s\".", IMPLEMENTATION); + $finish; + end +end + +endmodule + +module tb; + +logic clk = 0; +always #1 clk <= ~clk; + +logic [31:0] value; + +find_first_set32 #(.IMPLEMENTATION("LOW")) l (.in(value)); +find_first_set32 #(.IMPLEMENTATION("HIGH")) h (.in(value)); + +always @(negedge clk) begin + if (l.out !== h.out) begin + $error("Not equivalent for in=%0h: l=%d h=%d", value, l.out, h.out); + $finish; + end +end + +integer i; +initial begin + for (i = 0; i < 100000; i++) begin + value = $urandom(); + @(posedge clk); + end + $display("All equal."); + $finish; +end + +endmodule diff --git a/code/cache_lab/Makefile b/code/cache_lab/Makefile new file mode 100644 index 0000000..1cf13ee --- /dev/null +++ b/code/cache_lab/Makefile @@ -0,0 +1,12 @@ + +all: clean verify + +verify: build/cache.svh + diff cache.svh build/cache.svh + +build/cache.svh: + mkdir -p build + curl -s "https://raw.githubusercontent.com/sifferman/labs-with-cva6/2b788a9511ce8e0282f4ee5a8cbae2135eb0c540/labs/caching/part2/starter/ucsbece154b_victim_cache.sv" | sed -n "148,168p" > $@ + +clean: + rm -rf build diff --git a/code/cache_lab/cache.svh b/code/cache_lab/cache.svh new file mode 100644 index 0000000..8886a55 --- /dev/null +++ b/code/cache_lab/cache.svh @@ -0,0 +1,21 @@ +// DLL Structure // +// MRU - ... - way.mru - way - way.lru - ... - LRU // + +typedef logic [$clog2(NR_ENTRIES)-1:0] way_index_t; + +struct packed { + logic [TAG_SIZE-1:0] tag; + way_index_t lru; // less recently used + way_index_t mru; // more recently used + logic valid; +} dll_d[NR_ENTRIES], dll_q[NR_ENTRIES]; + +// lru register +way_index_t lru_d, lru_q, mru_d, mru_q; + +// index to bump +way_index_t read_index, write_index; + + +// separate the data from the dll help with optimization +logic [LINE_WIDTH-1:0] data_d[NR_ENTRIES], data_q[NR_ENTRIES]; diff --git a/code/digitaljs_online.sv b/code/digitaljs_online.sv new file mode 100644 index 0000000..7c14263 --- /dev/null +++ b/code/digitaljs_online.sv @@ -0,0 +1,30 @@ +module piso #( + parameter [7:0] DATA_WIDTH = 16 +) ( + input logic clk, + input logic rst_n, + input logic load_i, + input logic [DATA_WIDTH-1:0] loaddata_i, + output logic serial_o +); + +logic [DATA_WIDTH-1:0] data_d, data_q; + +always_comb begin + if (load_i) + data_d = loaddata_i; + else + data_d = (data_q >> 1); +end + +always_ff @(posedge clk or negedge rst_n) begin + if (!rst_n) begin + data_q <= '0; + end else begin + data_q <= data_d; + end +end + +assign serial_o = data_q[0]; + +endmodule diff --git a/code/opt.svh b/code/opt.svh new file mode 100644 index 0000000..65929df --- /dev/null +++ b/code/opt.svh @@ -0,0 +1,7 @@ +wire [2:0] a; +always_comb begin + out = 0; + for (integer i = 0; i < 3; i++) + if (a[i]) + out = 1; +end diff --git a/figures/c-like.tex b/figures/c-like.tex new file mode 100644 index 0000000..33f059a --- /dev/null +++ b/figures/c-like.tex @@ -0,0 +1,26 @@ + +\begin{figure}[t] + \centering + + \subfloat[ + Using purely structural constructs to create MUXes can provide long and superfluous code. + ]{ + \begin{minipage}{0.8\textwidth} + \footnotesize + \inputminted[frame=single]{systemverilog}{code/c-like/low.svh} + \end{minipage} + } + + \subfloat[ + Using C-like constructs such as a \mintinline{systemverilog}{function}, \mintinline{systemverilog}{if} statement, and \mintinline{systemverilog}{for} loop can provide much cleaner code. + ]{ + \begin{minipage}{0.8\textwidth} + \footnotesize + \inputminted[frame=single]{systemverilog}{code/c-like/high.svh} + \end{minipage} + } + + \caption{Comparison of purely structural Verilog versus C-like Verilog. To demonstrate this comparison, provided are two different implementations of the Find First Set operation.} + \label{fig:c-like} + +\end{figure} diff --git a/figures/cache_lab.tex b/figures/cache_lab.tex new file mode 100644 index 0000000..33ba705 --- /dev/null +++ b/figures/cache_lab.tex @@ -0,0 +1,7 @@ + +\begin{figure}[t] + \centering + \inputminted[frame=single]{systemverilog}{code/cache_lab/cache.svh} + \caption{Snippet of ``Labs with CVA6'' cache lab starter code \cite{labsWithCVA6}} + \label{fig:cache_lab} +\end{figure} diff --git a/figures/dc_vs_synplify.tex b/figures/dc_vs_synplify.tex index d067a73..c1995a5 100644 --- a/figures/dc_vs_synplify.tex +++ b/figures/dc_vs_synplify.tex @@ -2,6 +2,6 @@ \begin{figure}[t] \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}} + \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/figures/digitaljs_online.pdf b/figures/digitaljs_online.pdf new file mode 100644 index 0000000..14b9e63 Binary files /dev/null and b/figures/digitaljs_online.pdf differ diff --git a/figures/digitaljs_online.tex b/figures/digitaljs_online.tex new file mode 100644 index 0000000..36b051f --- /dev/null +++ b/figures/digitaljs_online.tex @@ -0,0 +1,7 @@ + +\begin{figure}[t] + \centering + \includegraphics[width=\linewidth]{figures/digitaljs_online.pdf} + \caption{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/figures/opt.tex b/figures/opt.tex new file mode 100644 index 0000000..60017a5 --- /dev/null +++ b/figures/opt.tex @@ -0,0 +1,34 @@ + +\begin{figure}[t] + \centering + + \subfloat[ + If any bits of \mintinline{systemverilog}{a} are set, then \mintinline{systemverilog}{out} is \mintinline{systemverilog}{1}. + ]{ + \begin{minipage}{0.8\textwidth} + \inputminted[frame=single]{systemverilog}{code/opt.svh} + \end{minipage} + } + + \subfloat[ + Vivado infers the code as one parallel LUT. + ]{ + \includegraphics[width=0.9\linewidth]{figures/opt/vivado.pdf} + } + + \subfloat[ + Yosys without optimizations enabled infers the code as a series of 2:1 MUXes. + ]{ + \includegraphics[width=0.7\linewidth]{figures/opt/yosys_noopt.pdf} + } + + \subfloat[ + Yosys with optimizations enabled infers the code as one parallel OR gate. + ]{ + \includegraphics[width=0.7\linewidth]{figures/opt/yosys_opt.pdf} + } + + \caption{Comparison of differences in synthesis.} + \label{fig:opt} + +\end{figure} diff --git a/figures/opt/vivado.pdf b/figures/opt/vivado.pdf new file mode 100644 index 0000000..3f3970e Binary files /dev/null and b/figures/opt/vivado.pdf differ diff --git a/figures/opt/yosys_noopt.pdf b/figures/opt/yosys_noopt.pdf new file mode 100644 index 0000000..9e4e842 Binary files /dev/null and b/figures/opt/yosys_noopt.pdf differ diff --git a/figures/opt/yosys_opt.pdf b/figures/opt/yosys_opt.pdf new file mode 100644 index 0000000..8f3f054 Binary files /dev/null and b/figures/opt/yosys_opt.pdf differ diff --git a/tex/chapters/3_digital_design.tex b/tex/chapters/3_digital_design.tex index aeef09b..b519fe1 100644 --- a/tex/chapters/3_digital_design.tex +++ b/tex/chapters/3_digital_design.tex @@ -6,25 +6,41 @@ \chapter{Using SystemVerilog for Digital Design Education} \section{Netlist graph viewers teach Verilog inference intuition.} -[Fig] By providing a visual representation of the synthesis process, students can gain a deeper insight into how their high-level descriptions are transformed into hardware components. DigitalJS Online [ref] stands as a notable example of such netlist graph viewers. Through its zero-setup, interactive web interface, students can witness rapid translation of their Verilog code into synthesized hardware, which encourages experimentation and rapid prototyping. Additionally, its text editor runs automatic linting with Verilator, which gives incredibly helpful feedback if a syntax-related bad-practice is detected. During a volunteer lecture for UCSB's IEEE student chapter, I taught Verilog concepts from DigitalJS Online's text editor, which seamlessly visualized the logic I was describing in my examples. Also, as a TA for ECE 152A and 154B, I curated several assignments that challenged students to use DigitalJS Online to transform \mintinline{systemverilog}{for} loops and \mintinline{systemverilog}{if} statements into comprehensive, hand-drawn circuit diagrams. [fig] Similarly, UC Santa Cruz Professor Dustin Richmond uses netlist graph viewers to teach best-practices concerning \mintinline{systemverilog}{case} and \mintinline{systemverilog}{if} statements. [ref] Through a process of hands-on exploration with netlist graph viewers, students can learn the mechanics of translating SystemVerilog constructs into tangible hardware and gain the ability to convert Verilog to schematics by hand. By assigning homework and in-lecture exercises that prompt students to deduce logical constructs from visual synthesis outputs, their aptitude to understand both Verilog and synthesis is significantly enhanced. +\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. 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. \autoref{fig:digitaljs_online} 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} 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. + +\FloatBarrier \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 \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. +\input{figures/opt} + +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 \autoref{fig:opt}, it is crucial to maintain a balance. Experimentation can stimulate curiosity and self-directed learning, but there may be instances where netlist graph viewers hinder rather than facilitate understanding. For example, as students start working with larger designs, the chances are increased that a quietly-applied, tool-specific synthesis optimization will result in a netlist that, while valid, would take too much time to decipher and understand. This may turn instructors entirely away from using netlist graph viewers due to the additional confusion that they cause. However, I argue that they are still an essential resource for introducing Verilog, helping students transition from gate schematics to HDLs. These tools serve as a foundation for students to build their intuition for synthesis, ultimately empowering them to undertake the more advanced design challenges. Even if netlist graph viewers lose their effectiveness as designs get complex, they illustrate to students the vital connection between digital design concepts and Verilog concepts. A similar example is providing simplified schematics of transistor implementations of digital gates to relate electrical engineering students to their prior knowledge of analog design. Because transistor implementation specifics are largely unimportant due to the low demand for PDK designers, it is fine to simply introduce basic technologies such as pass-transistor logic instead of analyzing modern multi-finger FinFET CMOS designs. But only after receiving some connection to their prior experience with transistors will electrical engineering students feel comfortable working with gates. Similarly, when introducing Verilog to students, using netlist graph viewers can connect prior knowledge of digital elements to code syntax. Much like electrical engineers need some familiarity with transistor-level gate implementations prior to diving into digital design, Verilog students greatly benefit from a foundational understanding of the behavior of synthesis tools. +\FloatBarrier + \section{Rely on style guides for synthesizable SystemVerilog.} \input{figures/dc_vs_synplify} -RTL engineers use C-like constructs [gloss] such as procedural blocks, \mintinline{systemverilog}{for} loops, and \mintinline{systemverilog}{if} statements from Verilog; and \mintinline{systemverilog}{struct}, \mintinline{systemverilog}{union}, and \mintinline{systemverilog}{enum} constructs from SystemVerilog. To promote uniformity among tools, IEEE standardized synthesis of Verilog 1364 features under the label ``1364.1". However, there has been no official ``1800.1" SystemVerilog synthesis standard to discuss the many new features that were added with SystemVerilog. With that said, many SystemVerilog features are endorsed by numerous projects and designers, as evidenced by the abundance of style guides [appx] that act as a current but unofficial documentation of SystemVerilog's synthesizable features. The SystemVerilog IEEE 1800 specification also describes many elements that are not consistently synthesizable, such as classes, hierarchical references, interfaces, and dynamic arrays. [ref] This may be due to poor tool-support for a feature, or that the feature is similar to a prohibited feature in the 1364.1 standard. For example, \autoref{fig:dc_vs_synplify} shows differences in synthesis support between two Synopsys synthesis tools. +RTL engineers use C-like constructs [gloss] such as procedural blocks, \mintinline{systemverilog}{for} loops, and \mintinline{systemverilog}{if} statements from Verilog; and \mintinline{systemverilog}{struct}, \mintinline{systemverilog}{union}, and \mintinline{systemverilog}{enum} constructs from SystemVerilog. To promote uniformity among tools, IEEE standardized synthesis of Verilog 1364 features under the label ``1364.1". However, there has been no official ``1800.1" SystemVerilog synthesis standard to discuss the many new features that were added with SystemVerilog. With that said, many SystemVerilog features are endorsed by numerous projects and designers, as evidenced by the abundance of style guides [appx] that act as a current but unofficial documentation of SystemVerilog's synthesizable features. The SystemVerilog IEEE 1800 specification also describes many elements that are not consistently synthesizable, such as classes, hierarchical references, interfaces, and dynamic arrays \cite{1800-2017, sutherland}. This may be due to poor tool-support for a feature, or that the feature is similar to a prohibited feature in the IEEE 1364.1 standard. For example, \autoref{fig:dc_vs_synplify} shows differences in synthesis support between two Synopsys synthesis tools. + +\FloatBarrier \section{It is important to teach C-like constructs that rely on inference.} -A reaction to the inconsistency and ambiguity in SystemVerilog synthesis may be to teach only obviously-synthesizable constructs such as continuous assignment and standard cell initialization, but that would neglect important language features that have become popular in industry designs. [Fig] Similarly, in computer programming courses, once students understand the underlying mechanisms, it is common to allow use of standard library functions and data structures. This philosophy should extend to the realm of SystemVerilog. As long as the code adheres to course-specified style guides, and students understand the resulting synthesis, higher-level syntax should be prioritized when it improves code clarity and structure. [Fig] +\input{figures/c-like} + +A reaction to the inconsistency and ambiguity in SystemVerilog synthesis may be to teach only obviously-synthesizable constructs such as continuous assignment and standard cell initialization, but that would neglect important language features that have become popular in industry designs. Similarly, in computer programming courses, once students understand the underlying mechanisms, it is common to allow use of standard library functions and data structures. This philosophy should extend to the realm of SystemVerilog. As long as the code adheres to course-specified style guides, and students understand the resulting synthesis, higher-level syntax should be prioritized when it improves code clarity and structure. For example, observe \autoref{fig:c-like}. + +\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 in UCSB's ECE 154B, where an assignment I wrote expected students to implement a fully-associative cache. Students were expected to implement a doubly-linked-list to execute a least-recently-used replacement policy. With the helpful abstraction layer of structs, \mintinline{systemverilog}{for} loops, and \mintinline{systemverilog}{if} statements, students were able to demonstrate understanding of the LRU algorithm while also understanding the hardware that was generated. [fig] +\input{figures/cache_lab} + +With the full set of synthesizable features being utilized, Verilog can be a useful abstraction layer to better explain complex design concepts such as state machines, pipelining, and handshakes. This parallels the use of abstraction in programming courses, where students often draft pseudocode to conceptualize algorithms before delving into detailed implementation. Transferring this approach to digital design can promote a more rapid and comprehensive learning experience. As long as students demonstrate a strong understanding of how Verilog can be synthesized, they will also have an understanding of the circuits needed to implement the complex design concepts. An example of this in practice was in UCSB's ECE 154B, where an assignment I wrote expected students to implement a fully-associative cache. Students were expected to implement a doubly-linked-list to execute a least-recently-used replacement policy. With the helpful abstraction layer of structs, \mintinline{systemverilog}{for} loops, and \mintinline{systemverilog}{if} statements, (as seen in \autoref{fig:cache_lab}) students were able to demonstrate understanding of the LRU algorithm while also understanding the hardware that was generated. diff --git a/tex/thesis.bib b/tex/thesis.bib index 0152a1d..f79c930 100644 --- a/tex/thesis.bib +++ b/tex/thesis.bib @@ -17,10 +17,10 @@ @article{blum:article url = {https://www.insidehighered.com/advice/2017/11/14/significant-learning-benefits-getting-rid-grades-essay} } -@inproceedings{sutherland, +@misc{sutherland, author = {Sutherland, Stuart and Mills, Don}, title = {Synthesizing SystemVerilog: Busting the Myth that SystemVerilog is only for Verification}, - series = {Synopsys Users Group (SNUG) Silicon Valley conference, Santa Clara, California}, + note = {Synopsys Users Group (SNUG) Silicon Valley conference, Santa Clara, California}, month = {March}, year = {2013} } @@ -54,7 +54,7 @@ @misc{GooglePartnersWithSkyWater @misc{googleSilicon, author = {{Google for Developers}}, - title = {{S}ilicon}, + title = {{B}uild your own silicon}, howpublished = {\url{https://developers.google.com/silicon}}, note = {[Accessed 18-09-2023]}, } @@ -186,3 +186,26 @@ @misc{RichmondLatchUp year = {2023}, note = {Latch-Up}, } + +@article{1800-2017, + author = {IEEE}, + journal = {IEEE Std 1800-2017 (Revision of IEEE Std 1800-2012)}, + title = {IEEE Standard for SystemVerilog--Unified Hardware Design, Specification, and Verification Language}, + year = {2018}, + doi = {10.1109/IEEESTD.2018.8299595}, + note = {\doi{10.1109/IEEESTD.2018.8299595}} +} + +@misc{DigitalJSOnline, + author = {Marek Materzok}, + title = {{D}igital{J}{S} {O}nline}, + howpublished = {\url{https://digitaljs.tilk.eu/}}, + note = {[Accessed 18-09-2023]}, +} + +@misc{labsWithCVA6, + author = {Ethan Sifferman}, + title = {{L}abs with {C}{V}{A}6}, + howpublished = {\url{https://github.com/sifferman/labs-with-cva6}}, + note = {[Accessed 18-09-2023]}, +} diff --git a/tex/thesis.tex b/tex/thesis.tex index ce0b55d..11c7766 100644 --- a/tex/thesis.tex +++ b/tex/thesis.tex @@ -16,8 +16,8 @@ \usepackage{soul} \usepackage[outputdir=build]{minted} \usepackage{siunitx} - -%\usepackage{subfigure} (Subfigure package clashes with another package) +\usepackage{doi} +\usepackage{placeins} %---New Definitions and Commands------------------------------------------------------ \def\p{\partial}