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.

===== 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 a 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. 

===== 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.

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.

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.

=====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. These files can also be found {{2014:think_comparch | here.}}

====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
