Computer Systems & Organisation

Below we provide general guidelines for writing a good design document.

Tone & Style

• Please treat the design document as a professional piece of academic writing.
• Spell check and proof-read your document
• Use grammatically correct sentences to the extent possible
• Organize your design document using reasonable headings
• There are no prescribed headings or formatting. A normal 11pt font is fine.
• Stick to the page limit (the title does not count towards this).

Structure

You should always include the following in all written assessment:

• Title
• Your full name and university ID
• Date (probably best to go with the submission date)

Some ideas for sections we would like to see in your document:

• Overview: it is a good idea to provide a short overview section which gives a “big picture” view of what you’ve done. E.g., what extension did you add to your CPU, and why is it useful?
• Implementation: how did you do what you did? This description should be at an appropriate level of detail—don’t be too vague (too high-level), but do not explain your entire circuit gate-by-gate.
• Reflection: what did you learn? What was tricky/interesting/confusing?

What Did You Do?

Your DD must include a description of the workings of your CPU to a level of detail where the reader could implement a CPU with a similar microarchitecture without seeing your circuits. It is not sufficient to say, “I extended the CPU to support XOR.” Where did you add this extension (register file, ALU, control unit, multiple places)? What is the corresponding machine code you defined for it?

You should include text that is relevant to the overall story. For example, you might discuss a failed approach you tried initially and why it did not work. However, including a “debugging diary” (I did this, and I got that error, then I fixed it and got this new error, etc.) is a bad idea because most of that process is irrelevant to the overall point you’re trying to make.

How/Why Did You Do It?

Consider the specific parts of your circuit—what design decisions have you made in structuring/organising it the way you did?

You must motivate and explain the choices you made when your built your circuit.

For example,

I connected a wire between output A of the Foo and input B of the Bar.

The above sentence does not convey anything useful. It is better to explain why you connected that wire. Do not explain your circuit wire-by-wire!

Pictures, Graphs & Diagrams

If you use pictures, graphs or diagrams (which is encouraged!) then make sure they’re either vector-based, or, if you need to include raster images (e.g. PNG, JPEG) make sure they’re at a high-enough resolution that they don’t look ugly and pixelated when printed at A4 size.

Do not hand-draw a diagram and include a photo of it in your DD. That’s not professional and shows a lack of care about your work.

Circuit Screenshots

Even though you should not explain your circuit gate-by-gate, this does not mean that you cannot include circuit screenshots. However, you should only include a circuit if you have a good reason to, which might include:

• The circuit is from a “previous attempt” at writing your CPU that you want to discuss. Because it is from a previous attempt it is not in the circuit part of your submission so including it in the report makes sense.
• You want to show an alternative implementation you tried (and are going to explain why you made a different choice).

If you do include a circuit screenshot, do not include it as a low-resolution screenshot of your circuit. It must be clear and easy to read, even when zoomed in.

Be Clear & Specific

• Provide a crisp and precise explanation for the role of each new component you add in your CPU.

• Do not write generic statements, such as, “I think the component is very important.”

What Questions Should I Answer in My DD?

1. What extension did you implement and why? Explain the assembly syntax and machine language representation for using your extension.

2. How do all the parts of the CPU fit together? What’s the typical flow from reading instruction to executing it to starting the next instruction? Briefly explain what happens during the execution of a typical instruction.

3. What are the interesting/tricky/confusing parts of your CPU or approach. Do consider using text boxes in your circuits to more easily refer to them in the design document.

4. What did you learn during the process (2-3 sentences)?