Cautionary Points for Design Data Submission


Item

The following is a summary of important points when submitting design data for Experiment 3HW to GitHub.
In the final report, if any of the following points describes the design data you submitted under the "release for the tag name (Tag version) called final," you may be instructed to resubmit the design data. Please make sure you understand the details and take sufficient precautions.

1. Staff are unable to synthesize/write to board

This is when the required files for a Quartus project have not been added to the git repository.

For one thing, the .qpf file that contains the configuration information for the Quartus project may not exist in the GitHub remote repository. In many cases, it is not possible to synthesize only with the files in the repository cloned by the staff (third party). Please check to see whether you have been a little too diligent in managing your .gitignore.

Also, sometimes files required for the project are not registered (you may have missed "Add Files in Project..."). In addition, it may refer to a file in a local directory outside of git management. For example, be careful if you are using a circuit created in an introductory assignment or a module designed in a different directory. (The easy way to do this is to copy them into the 2022-simple-<GitAccount> directory and then Add Files to the project.)
In such a situation, the following error or warning will be output during Compilation.

Warning (12019): Can't analyze file -- file ../../intro/led.v is missing
Error (12006): Node instance ""inst1"" instantiates undefined entity ""LED"". Ensure that required library paths are specified correctly, define the specified entity, or change the instantiation. If this entity represents Intel FPGA or third-party IP, generate the synthesis files for the IP.

Synthesis can be completed on a staff (third-party) PC, but writing to the FPGA board may not be possible. One cause is that the .qsf file, in which the pin assignments are recorded, does not exist in the GitHub remote repository. This is also a .gitignore management issue.
In such a situation, the following warning will be output during compilation (especially applicable if x is the same value in "x pins of x total pins").

Critical Warning (169085): No exact pin location assignment(s) for x pins of x total pins. For the list of pins please refer to the I/O Assignment Warnings table in the fitter report.

The .mif RAM data file, is often out of git management. In this case, the initial data is fed to RAM on your end, but the initial value remains zero on the staff's end. In other words, the FPGA board will not be able to reproduce the operation when run by the staff (third party).
In this situation, the following warning will be output during compilation.

Critical Warning (127003): Can't find Memory Initialization File or Hexadecimal (Intel-Format) File C:/hogehoge/memory.mif -- setting all initial values to 0

A quick way to check if there are no problems with this is to try cloning your GitHub remote repository into a completely different directory than usual. It is best to avoid using the same level of directory hierarchy as usual (since file locations are recorded in relative paths within the Quartus project).
Clone your own repository to a different directory than usual, and try synthesizing, writing, and running on the actual device there.

2. A critical warning remains

Critical warnings must be resolved so that no more messages are displayed. In this case, it is often the case that synthesis is successful only to fail in the simulation or actual device verification stage. The meanings of typical messages are explained in the "HDL Handbook.(In Japanese)" Of course, you can also copy and google it for more information.
You can filter messages by selecting the purple "Show Critical Warning Messages" filter in the Messages window at the bottom of Quartus.

However, the following Critical Warning is acceptable.

Critical Warning (169085): No exact pin location assignment(s) for m pins of n total pins. For the list of pins please refer to the I/O Assignment Warnings table in the fitter report.

The above is output when there are unassigned pins in the Pin Planner.
It may be necessary to connect many signals to an output for debugging, or to connect only the signals to be probed, depending on the situation. Also, altera_reserved_{tck,tdi,tdo,tms} are JTAG-related signal lines and can be ignored.

On the same topic, be sure to periodically look at the messages during synthesis, even if synthesis is going well. Often, hints for better design will be indicated.
The blue "Show Warning Messages" option can be ignored if the user understands what the warning is about and can determine that there is no problem. CAD tools tend to output severe warnings, some of which can never be deleted. In addition, when a synthesis error occurs, not only the message in red, but also the blue Warnings in the vicinity often give clues to the problem. Click the > symbol to open the warnings, as it may be nested.

3. Timing constraints are not set (.sdc not present)

Setting timing constraints is mandatory.
Be sure to run the TimeQuest Timing Analyzer by referring to the document entitled "
Setting and Verifying Timing Constraints." In addition, if the TimeQuest Timing Analyzer was executed but the .sdc file was not exported, or if the name was changed from .out.sdc to .sdc but the file was not registered in the project (via Add Files to Project...), or it may be out of git management.
In such a situation, the following warning will be output during Compilation.

Critical Warning (332012): Synopsys Design Constraints File file not found: 'simple.sdc'. A Synopsys Design Constraints File is required by the TimeQuest Timing Analyzer to get proper timing constraints. Without it, the Compiler will not properly optimize the design.

To check if the timing constraints are properly set (i.e., if the .sdc files are registered in the project as intended), check the "SDC File List" entry in the "TimeQuest Timing Analyzer" of the Compilation Report > Table of Contents. Or, if no clock signal is shown in the "Clocks" field (there is only altera_reserved_tck), the clock constraint is not working.

4. Timing constraints not satisfied

You must also verify and satisfy timing constraints.
If "TimeQuest Timing Analyzer" in Compilation Report > Table of Contents is displayed in red, some constraints are not satisfied. In such a case, the following warning will be output during compiling.

Critical Warning (332168): The following clock transfers have no clock uncertainty assignment. For more accurate results, apply clock uncertainty assignments or use the derive_clock_uncertainty command.
        Critical Warning (332169): From clock (Rise) to clock (Rise) (setup and hold)

Refer to the document "Setting and Verifying Timing Constraints." to review the design of modules related to the Critical Path or change the constraints.