In general, report evaluation will depend on technical contents
(key
points address in each lab) and format (appearance, presentation, etc.)
In the lab report, do not just give the end result of a design
(e.g., just the simulation output). Give all the design steps.
Due Dates
- Prelab report is due at the beginning of its lab. Please have
your prelab ready for the TA to look at once lab starts.
- Final lab report is due 1 week after your lab session. Please
hand them in by 5:30 pm in the CENG 465 lab cabinets.
Report Contents
The lab report must be complete enough for the reader to understand,
compile, and simulate your system without consulting other references.
Your
well-typed report should include at least the following items
(information provided for each item must be concise):
- Problem description.
State objectives and specification of the lab in your own language.
Briefly address the required background and necessary information to
perform the lab.
- Design solution.
Explain your design methodology. This should include design steps,
system partitioning, special techniques, programming tricks, etc.
Identify the low-level components and the method of instantiating
them to build a top-level description. Explain the type of
architectures selected (behavioral, dataflow, or structural) and
justify your choice. For behavioral descriptions, explain and justify
how they are divided into processes. Clearly state the function of
each process.
- Structural diagrams. Identify
the lab modules according to your modeling.
For each module draw an icon showing all input and output signals.
Also, show connections between modules. Summarize signal information
in the form of a table. For each signal, show its name, mode, type,
and any other comments. In addition, any relevant timing diagrams
necessary to understand your lab should be carefully drawn.
- Test procedure.
Clearly explain your test strategy to ensure the correctness of the
model. (Remember that designing testbenches is an integral part of
the lab.) Describe in detail the steps executed by the used
testbenches. Justify these steps and show that they are sufficient
for testing your design. Turn in all code used for testing and
include any script either entered directly from the main simulator
window or saved in a command file.
- VHDL source code listing.
All source code
must be fully documented. Please follow the code style guidelines
included above.
- Simulation snapshots. Snapshots
from your simulation (test case) outputs should be included in
the report. You can include more than one test case in a single
screen snapshot. You might want to annotate the simulation snapshots
with any relevant comments. Manual annotations are acceptable.
Different ways for taking
simulation snapshots are included in the tools web page.
- Results and
discussion. Briefly comment on your design and its
relation to the stated specifications. Summarize errors, pitfalls,
and problems encountered while doing the lab. Mention new things
learned from the lab.
- References. Any
design portion that is copied or modified must be referenced. Do not
copy each other's design!
In preparing your report, please notice the difference between the
following diagrams:
- Block
diagram: A diagram that shows the interconnection between the
different system modules (components).
- Schematic
diagram: A diagram that details the elements (circuit and logic)
of a system, including labeled signals.
- Wiring
diagram: A diagram that focuses on the wires and signals.
- Icon
diagram: A diagram that shows a module as a block box with input
and output signals labeled (including the clock and set/reset signals).
Code Style
- You are expected to write VHDL code that could be easily read and
understood
by others.
- You should be using a strong visual layout that will make it easy
to mark.
- You should be consistent with your use of indentation and you
should space
out your code both vertically and horizontally so that it is easy to
read
but do not get carried away.
- Your code has to be very well commented:
- Each source file should
include a heading
comment that includes the file name, date, author, and the overall
functionality
of the modules included in the file in addition to the required inputs
and outputs.
- Each design unit (entity,
architecture,
package, etc.) must start with a couple of sentences describing
its interface and functionality. Design units should hold descriptive
names.
- Each code block must be accompanied by a comment that indicates
what purpose
the block serves.
- All variables, signals, and constants, etc. must be commented
when declared.
- If you have defined any new data structure you must explain its
purpose
and comment on the nature of each field.
- You are also expected to use logical names for signals,
variables, constants,
processes, etc. It is okay to use x and y for loop variables, but for
others
refrain from using names like that when a longer name would be more
easily
understood and reflect the item
nature,
function, or process task.
- Include every piece of code
used to
develop the lab.
- Any code that is copied or
modified
must be referenced.
