ca Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Think CompArch ======
By Samantha Kumarasena, Anne Wilkinson, and Tenzin Choetso

===== What did you do?=====
For our final CompArch project, we created a detailed tutorial that will explain to future CompArch students how to use Verilog and ModelSim effectively. We also included a section explaining basic MIPS architecture, since it was an area that we felt could use some consolidation.

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?=====
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 first, and 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?=====
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 (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. 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.}} 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====
We encountered some difficulties in deciding on the format and the order in which concepts should be presented. Some modules are interdependent, and require a concept introduced in a different section to be effectively explained. This led to the question of which sections should come first. We tried to order things sequentially, but in some cases we included links and references to different sections if there was a component necessary for explanation that had not yet been introduced. It was also difficult to decided what to include in our guide. Additionally, we don’t know whether this information will be helpful to most CompArch students. We sent out a survey to the CompArch list, but did not receive many responses so much of the content was based off of our own struggles.

====Work Plan Reflection====
Once we decided on the content, we created a work plan to divide up tasks and decide intermediary deadlines. Our plan involved a lot of independent work on different sections of the guide, followed by group meetings to edit, ensure coherent transitions between sections, and discuss any questions we had on content. Drafts were periodically sent to NINJAs for proofreading, primarily for accuracy of content, secondarily for grammar and writing style. We managed to stick to our intermediary deadlines, and surpassed the requirements we originally established for our guide. Since we had initially prepared a final draft for Tuesday (and later found that the deadline was Thursday), we had extra time to edit and polish the guide.
ca Wiki

User Tools

Site Tools

Page Tools
