User Tools

Site Tools


2014:think_comparch

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
2014:think_comparch [2014/12/16 13:34]
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. 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?===== ===== Why did you do it?=====
-We decided to create a guide for CompArch because it would give us a chance to go back over areas and concepts that were confusing, and solidify our understanding. In particular, we found ModelSim and Verilog to be confusing, especially at the start of the semester. There were many important concepts that we didn’t understand about Verilog until close to the end of the semester, ​along with whole set of useful features in ModelSim, that we wish we had known about at the start of the semester. Even at the end of the semester, there were some gaps in our understanding that we learned to work-around without really ​trying to understand why. In this guide, we hope to address why in addition to how. This is our chance to help future students and improve their experience in CompArch as well as their overall understanding of the subject matter. ​+We decided to create a guide for CompArch because it would give us a chance to go back over areas and concepts that were confusing, and solidify our understanding. In particular, we found ModelSim and Verilog to be confusing, especially at the start of the semester. There were many important concepts that we didn’t understand about Verilog until close to the end of the semester. Wires and registers were confusing at firstand procedural blocks didn't make much sense to us. Additionally,​ we described ​a set of useful features in ModelSim, that we wish we had known about at the start of the semester. Even at the end of the semester, ​we found that there were some gaps in our understanding that we learned to work around without really ​understanding the fundamental concepts. In this guide, we hope to address ​the //why// in addition to the //how//: students should have a strong understanding of what they are doing. This is our chance to help future students and improve their experience in CompArch as well as their overall understanding of the subject matter.
  
 ===== How did you do it?===== ===== 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 ModelSimand 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 ​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?===== =====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.+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==== ====Difficulties====
2014/think_comparch.1418754896.txt.gz · Last modified: 2014/12/16 13:34 by skumarasena