6.111 Phase Two Hints and Guidelines
Link to 28 February
Presentation Slides
Project Reports for 6.111 should include the following sections
Read the following sections in The
Mayfield Handbook. If you find discrepancies between the instructions
in The Mayfield Handbook and the instructions in this handout, follow
the specific instructions in this handout.
-
To qualify for Phase Two, the 6.111 report must contain a minimum of 2500
words of text in the body of the report. Appendices do not count.
-
Draw graphics with drafting aids (template and straightedge) or graphics
software. You may label graphics by hand. Be sure to include units-of-measure.
-
Describe the project from the beginning. Assume the reader has not read
the abstract and is unfamiliar with this project.
-
Describe the whole before the parts. Orient the reader with a general statement
before you plunge into specific details.
-
Divide long sections into logical topics, and put each topic in a subsection,
with sub-heads and at least one introductory sentence.
-
Use technical terminology when appropriate. Define at first use any terms
that a colleague with no specific knowledge of this project would not understand.
Avoid jargon or slang terms.
Overview (1 - 2 pages)
Begin with an overview of the device's purpose and construction.
-
Describe briefly the device's purpose. What does it do?
-
Describe briefly the device's use. How does a user use it?
-
Describe briefly the subsystem organization of the device. Emphasize the
internal features of the design that result in the main features of the
device that are visible to the user.
-
Give a plan for the report, also called an advanced organizer
or road map, for the paper -- like a Table of Contents in words. Say what's
in the paper, section by section, so the reader can find things.
Description (5 - 7 pages)
-
Describe the device in enough detail so that a skilled engineer can understand
how the device works, reconstruct it, and verify your results.
-
Give the functional specifications for the device.
-
Describe, in detail, the design element used to accomplish each specified
function and how the design works.
-
Document fully any non-standard, clever, or hack design elements, both
to help other engineers understand your design and to help you remember
why you did it that way in the first place.
-
Describe how the design elements work together.
-
Organize the description of the design to mirror the organization of the
design itself. Describe each design element in a separate section. Start
each section with at least one introductory sentence.
e.g., The device consists of two subsystems, which . . .
-
Order the sections according to the flow of information through the device
(input to output) or, if that's not applicable, then according to importance,
most important first.
-
Illustrate the paper with tables and figures, where appropriate. (See the
section in this handout on Graphics.) Include block diagrams. If appropriate,
include wiring diagrams, timing diagrams, state diagrams, schematics, and
oscilloscope tracings.
-
Put detailed logic diagrams in an appendix.
-
If you programmed a PAL or EPROM, put each programming file in a separate
appendix, such as PALSAM source files, µCode assembler source (.as),
and specification (.sp) files.
Testing and Debugging
-
Describe the procedure for testing each subsystem.
-
Describe the process for debugging each subsystem that didn't work the
first time you tried it.
-
If you couldn't get a device to work, describe which systems did work and
to what extent, and describe which systems didn't work and what the problems
were. If you fixed a problem, describe how. If you didn't fix it, describe
the problem and what your next testing and debugging steps would have been.
Conclusion (1 or 2 pages)
-
Summarize the most important or innovative design features.
-
Summarize the test results.
-
Discuss the problems with your initial design and the solutions you implemented.
-
Suggest improvements to the design.
Circuit Diagrams
-
Circuit diagrams convey information about design elements, making building
and debugging easier.
-
Always use a template and a straightedge.
-
Where possible, design circuit diagrams so that information flows from
left to right and top to bottom.
-
Derive the part location from the coordinates for column (in your kit,
pads A through E, left to right) and row (chip position, from top to bottom).
-
Whenever possible, put the gate input on the left, output on the right.
-
For chips containing small gates (including buffer and register chips),
draw out the individual gates. Do not draw the chip as a block, with wires
connected to the pins in their real-world positions. This practice leads
to confusing diagrams that obscure the functions of circuits.
-
For larger, complicated chips (counters, adders, etc.), draw the chip as
a block, and label it by function (signal inputs together, outputs together,
similar control inputs together, etc.), not by the physical layout of the
chip's pins.
-
Label all input and output signals to a circuit. If possible, use one starting
point for each signal, and split the signal to show multiple inputs. If
dense diagrams require multiple starting points for a signal, then label
all instances of a signal.
-
To show wires, use only horizontal and vertical lines, drawn with a straightedge.
To show a connection, use a dot. To show a non-connection point, use intersecting
lines with no dot: do not use a "hop-over."
Timing Diagrams
Timing diagrams show that the signals in a system behave in an orderly
fashion to achieve a design goal. They show the cause-and-effect relationships
among signals.
-
If possible, group signals by operations of short duration. Draw separate
diagrams for each operation. Examples include memory reads and writes,
data buffering, video frame synchronization, etc.
-
Show only the relevant signals, such as control signals and some signal
that indicates the state of data lines (usually either valid or invalid).
-
In synchronous systems, show a clock signal.
-
Show each signal with a separate trace, even if the trace is identical
to that of another signal. Label all signals.
-
Usually, do not show propagation delays.
-
Indicate situations in which an edge on one signal causes a change in another
signal. (See Figure C6.)
-
Abbreviate data bus contents unless one of the data bits must be drawn
separately for one of the above reasons.