|
Guidelines for writing reports and correcting CSD projects |
||
The primary objective of technical report writing is to develop the ability to produce high-quality documentation. Technical reports serve to communicate circuit designs and analyses to peers and instructors. Written reports should resemble tutorials or exemplary projects commonly utilised in classroom and laboratory settings. |
CSD reports submitted for post-lab assignment submissions are corrected and assessed according to these general ideas:
Start writing your report only when your project works correctly, and you have already obtained some results.
VHDL reports in Chapters 1 and 2 have at least four sheets of paper, each one representing a project section: (1) specifications - (2) planning - (3) development - (4) verification.
C language reports in Chapter 3 have at least three sheets of paper, each one representing a project section: (1) specifications - (2) planning - (3 - 4) interactive development and testing (debugging).
Circuit analysis projects: each analysis method (I, II, III and IV) in P1 section A and in P5 is a report. For instance, analysing a logic circuit using Proteus (method II) requires (1) specifications - (2) planning what you are going to do when using Proteus - (3) development: capturing the circuit using the given library of components and running the simulation to obtain the circuit's truth table - (4) verification: a text paragraph explaining that you have got the same result (truth table) running at least another analysis method, for instance method III.
Circuit design projects: each plan (A, B, C1, C2, X, Y) is a report. For instance, inventing a combinational circuit using plan A requires the four sections: (1) specifications: truth table, symbol, timing diagram; (2) planning: what equation strategy are you using; (3) development: using EDA tools to synthesise your circuit in a target chip; (4) verification: using VHDL simulation testbenches to check that the circuit generates the specified truth table.
When using plan A, be aware of including the following materials in your report sections:
Planning: the idea of your equations that define the structure of your circuit.
Developing: when applicable, the translation of your truth table into a TBL text file for Minilog. The printing of Minilog results (minimised equations corrected). The RTL schematic generated by Quartus Prime, to check that it matches your original equations. The VHDL file, which is the literal translation of your minimised equations in an annex.
Testing: The testbench fixture schematic that allows you to apply stimulus vectors.
NOTE for validating your report: As a consequence, if you are using AI tools, use them only for specifications; never copy VHDL files or schematics for planning, development, or testing that are not crafted from your handwritten materials in CSD style. Study how to use our know-how through all our examples.
When using Plan B, be aware of including the following materials in your report sections:
Planning: the idea of your high-level interface schematic or flowchart that defines the behaviour of your circuit.
Developing: The RTL schematic generated by Quartus Prime to check that it follows your high-level descriptions. The VHDL file, which is the literal translation of your flowchart or truth table interface schematic in an annex.
Testing: The testbench fixture schematic that allows you to apply stimulus vectors.
NOTE for validating your report: As a consequence, if you are using AI tools, use them only for specifications and planning; never copy VHDL files or schematics for developing and testing that are not crafted from your handwritten materials in CSD style. Study how to use our know-how through all our examples.
When using plan C2, be aware of including the following materials in your report sections:
Planning: the hand-drawing of your top circuit based on components, signals and logic.
Developing: The printing of the RTL schematic generated by Quartus Prime, to check that it looks like your own drawing. The VHDL file, which is the literal translation of your drawing in planning in an annex.
Testing: The testbench fixture schematic that allows you to apply stimulus vectors.
NOTE on report validation: Consequently, if generative AI tools are used, they must be restricted solely to the specification and planning phases. Under no circumstances should you copy VHDL files or schematics for development and testing that do not directly originate from your own handwritten, CSD-style designs. We advise you to study our established methodologies through the provided examples. In all cases, you must explicitly document how AI was utilised as an auxiliary tool in the organisation of your project.
When using plan C2, the report sections (1) - (2) - (3) - (4) are referring to the main (top) project in design. Other designed components or collateral tutorial work or related theory can be added to the report as annexes.
Note: If your PLA consist of several design steps and phases: report only step #1 as a full project including all the project sections. Report the next steps as annexes including and describing only what is modified, added or adapted. |
Theory and other learning materials are attached to section (1). If you are given several project assignments, include theory only in one project report.
Sketches, schematics and diagrams are handwritten and original. Draw and adapt our materials from digsys, other websites, or from books.
Word processors are NOT used in CSD; use handwritten text instead. For this introductory course on digital design, word processors are simply a waste of study time. You can handwrite using both pen and paper or electronic ink (tablets).
Academic integrity at the UPC is always considered. Two or more students cannot have the same pictures or materials because each one generates their own class-notes. Group work is always encouraged for discussion and to clarify ideas; all CSD post-lab assignments with the exception of PLA1 are completed in cooperative groups.
Printed results from EDA tools are discussed using pens and handwritten explanations on paper or electronic ink on tablets. A printed schematic or printed computer results without annotations has no value and is not marked.
Printed graphics have a white background and a preferred colour scheme. Do not waste your printer ink printing black backgrounds. Never use a black background in pictures captured or printed from instruments.
Sections of VHDL and C language source files are printed following these indications.
Entity names are not invented. All our project specifications will include the entity names under analysis or design.
In CSD, projects must be developed and stored in the given locations indicated in the corresponding planning section (2). Other project locations cannot be corrected and will not be marked. For instance, the location of the analysis of Circuit_L in PLA1 using Proteus is:
C:\CSD\P1\Circuit_L\proteus\(files, pictures, sketches, pdf, etc.)
VHDL translations and C language source files contain comments and references to the schematics or flowcharts being translated. Or, if we put it another way: VHDL and C code do not exist without the original schematic/flowchart on paper.
In testbenches, there is no need to print all stimulus vectors or the raw template; print using the colour scheme only a few of them and discuss the waveforms.
Pay attention and discuss your RTL and technology schematics, verifying that they are similar to your planned circuits.
IMPORTANT NOTE: CSD materials and proceedings are specially crafted for you to be asking questions very often. If you have doubts or queries on how to solve or do something, do not hesitate and ask us questions preferably in class or by other ways in order to save much of your study time.
IMPORTANT NOTE: The best way to save and optimise your study time is to attend all lectures and laboratory sessions and be active asking as many questions as possible while taking quality class-notes in paper or electronic ink.