Differences

This shows you the differences between two versions of the page.

--- 2014:think_comparch [2014/12/17 13:05]
skumarasena [How can someone else build on it?]
+++ 2014:think_comparch [2014/12/18 16:58] (current)
skumarasena [What did you do?]
@@ Line 6: / Line 6: @@
 We designed our project to be readable from start to finish, but with standalone sections. The sections grow in complexity and build upon each other. This allows people to either read the entire guide, or use it as a reference manual to look up specific sections on an as-needed basis. Our explanations also include working sample code that a reader could incorporate into his/her own code and expand on. Examples were designed to be simple, with the intention of making it easier for people to generalize.
+The link to the public ShareLatex document: https://www.sharelatex.com/project/54934cbbe2d91b2f78ae0fa5
 ===== Why did you do it?=====
@@ Line 11: / Line 14: @@
 ===== How did you do it?=====
-We began our Verilog section by explaining what HDLs are, and how they might be different from other languages that new CompArch students are likely to be familiar with. Knowing Python or C might help someone learn Verilog faster, but could also confuse them when it comes to variable declaration and how modules work. To resolve these confusions, we explained Verilog as similar to actually building a circuit. After explaining the basic concepts, and how modules work, we explain some basic syntax as well as links to more extensive resources on syntax. We then move on to provide examples of both behavioral and structural Verilog, and when each might be best used. Procedural assignments and always blocks are a common confusion in Verilog, so we included examples of each as well as well as detailed descriptions of how they work. Test benches are an important part of Verilog design, so we also talked about the fundamentals of test benches and some potential pitfalls. All our examples have accompanying .do files, but are included in an appendix. We explain how to write a .do file in the ModelSim section.
+Since Verilog is an HDL (Hardware Description Languages), we began our Verilog section by explaining what HDLs are, and how they might be different from other languages that new CompArch students are likely to be familiar with. Knowing Python or C might help someone learn Verilog faster, but could also confuse them when it comes to variable declaration and how modules work. To resolve these confusions, we explained Verilog as similar to actually building a circuit. After explaining the basic concepts, and how modules work, we explain some basic syntax as well as links to more extensive resources on syntax. We also talked about the differences between Behavioral and Structural Verilog. Structural Verilog focuses on designing and simulating real circuits made of logic gates and physical components. Behavioral Verilog focuses on simulating the behavior of such circuits. We also talked about when each might be best used -- Behavioral Verilog is simpler but less efficient, and Structural Verilog is more analogous to a circuit but can get very difficult to keep track of once designs start getting complicated. The differences between Verilog's various data types is also a common confusion for students, so we included examples of each as well as well as detailed descriptions of how they work. Additionally, we talked about how students might test their designs -- test benches are an important part of Verilog design, so we talked about the fundamentals of test benches and some potential pitfalls. All our examples have accompanying files, as well as instructions on how to run them.
-The ModelSim section begins with explaining how to create a project and clear libraries. A major confusion that some of us had were about .do files, how they worked, and how to write them. The ModelSim section explained what each line of code in some sample .do files did, as well as provided a link to a resource about more complicated .do files. We also included some hazards of ModelSim, and some of its user-unfriendly quirks, such as its tendency to delete all your code when you press Ctrl + Z. The compiler errors in ModelSim are sometimes uninformative, so we also included a list of the more common errors in ModelSim as well as their potential causes. Unfortunately, this won’t help our future CompArch student catch all their errors, so we also included a section about some of ModelSim’s useful debugging features. These sections included step-by-step instructions as well as screenshots for clarity. Some of the more insidious errors are hard to catch, particularly those caused by crosstalk between procedural blocks. Our ModelSim section included a warning about procedural blocks in design, and how these could mess up your timing.
+The ModelSim section begins with explaining how to create a project and clear libraries. A major confusion that some of us had were about .do files (files that run the simulations), how they worked, and how to write them. The ModelSim section explained what each line of code in some sample .do files did, as well as provided a link to a resource about more complicated .do files. We also included some hazards of ModelSim and some of its user-unfriendly quirks, such as its tendency to delete all your code when you press Ctrl + Z. The compiler errors in ModelSim are sometimes uninformative, so we also included a list of the more common errors in ModelSim as well as their potential causes. Unfortunately, this won’t help our future CompArch student catch all their errors, so we also included a section about some of ModelSim’s useful debugging features. These sections included step-by-step instructions as well as screenshots for clarity. Some of the more insidious errors are hard to catch, particularly those caused by crosstalk between procedural blocks. Our ModelSim section included a warning about procedural blocks in design, and how these could mess up your timing.
-Finally, we wrote a section of the guide explaining what the MIPS architecture is, and how to use its instructions. We explained what RTL stands for and how it is useful when decoding a MIPS instruction. We then have a section describing MIPS instructions and the three major formats: I, J and R. Under each format, we explain what makes it unique, the registers it involves, immediates and their respective length. We also give examples of some of the most commonly used instructions, explaining them in the context of their respective instruction format.
+Finally, we wrote a section of the guide explaining what the MIPS architecture is, and how to use its instructions. MIPS is an educational architecture, and we imagine that future CompArch classes will continue to use it when simulating their processors. We also explained what Register Transfer Language is (RTL is a means of describing what a given instruction does) because instructions are frequently described using RTL. We then have a section describing MIPS instructions and the three major instruction formats: I-type, J-type, and R-type. Under each format, we explain what makes it unique and how it is formatted. We also give examples of some of the most commonly used instructions, explaining them in the context of their respective instruction format.
 =====How can someone else build on it?=====
-Someone else could expand this guide to involve other topics in CompArch. Some of us felt confused by the timing lecture on latches and flip-flops. A section that outlines some examples of when to use different latches and when to use them would be helpful. Another nice feature to add to our guide would be exercises for people to practice different skills and concepts with. Although our guide includes code examples and helpful explanations, we don’t provide many opportunities for the reader to check his/her understanding of each concept. Students should get practice from homework and labs assigned throughout the semester, but if there is a concept a student finds confusing, it could be helpful for him/her to be able to do a couple of practice exercises. All the materials for continuing the project (the LaTeX files, all images, and all code examples) can be found at https://github.com/skumarasena/ThinkCompArch. The .pdf document can be found {{2014:Think_CompArch.pdf | here}}
+Someone else could expand this guide to involve other topics in CompArch. Some of us felt confused by the timing lecture on latches and flip-flops. A section that outlines some examples of when to use different latches and when to use them would be helpful. Another nice feature to add to our guide would be exercises for people to practice different skills and concepts with. Although our guide includes code examples and helpful explanations, we don’t provide many opportunities for the reader to check his/her understanding of each concept. Students should get practice from homework and labs assigned throughout the semester, but if there is a concept a student finds confusing, it could be helpful for him/her to be able to do a couple of practice exercises. All the materials for continuing the project (the LaTeX files, all images, and all code examples) can be found at https://github.com/skumarasena/ThinkCompArch. The .pdf document can be found {{2014:Think_CompArch.pdf | here.}} Download this PDF if you want to be able to use the internal links -- this will be very helpful because this document is pretty big.
 ====Difficulties====

ca Wiki

User Tools

Site Tools

Differences

Page Tools