It is not uncommon for students to have perfectly good simulations but not have a circuit that works when they download it. These types of problems are difficult to debug and require additional skill and experience to resolve. This guide summarizes the approach I follow when I work with a student in this situation. Try these steps when helping students with difficult to debug situations.
Always review the synthesis report: The synthesis report usually provides hints of a problem in the warnings it provides. Carefully review the warnings and make sure you are comfortable with the warnings. Any warning that you don't understand or looks suspicious should be reviewed carefully. There are two common types of warnings that signal a problem:
Logic that is optimized away: The synthesis tool will often optimize the circuit by removing logic that is not needed. This happens often in our circuits but sometimes it will remove a large amount of circuitry (even the full design!). Carefully review these messages and see if logic is being removed that should not be removed. Usually
Latches: Students frequently make mistakes that cause latches to be inferred in the design. If you see these, you must resolve them. Latches are typically caused by using a signal other than the clock in a “posedge“ clause, and not covering all the cases in a combinational block. These are discussed in detail below.
always blocks: The always blocks are frequently the cause of problems in student circuits. When students have a problem I look first at each of their always blocks. This is what I look for:
always_ff: Make sure that they are using only the global clock in the “posedge” clause. Sometimes students will use some other signal as a clock. They should never use any other signal than the clock! I also look for the use of non-blocking statements, ⇐. If they use blocking statements, = , I have them change them to non-blocking, ⇐. See chapter 17 for more details.
always_comb. This is where most of the problems occur. First I make sure they are using the blocking statements, =, and not the non-blocking, ⇐. See chapter 18 for more details. Next, I look to make sure that any signal assigned in the block is assigned a value under all conditions. I look for default value statements at the top. If they don't have default values I carefully review each branch of the code and make sure every signal being assigned in the clause is assigned under all conditions.
Initial values: All sequential signals should have an initial value. These usually show up in simulation. No combination signals should have an initial value. I have seen logic getting optimized away because a student gave an initial value to a combinational signal.
Mis-spelled names. SystemVerilog allows you to use new signals without declaring them (it will automatically declare them for you). The problem with this is that you can have two names that look a like but do not match (perhaps one letter has a different case or a letter is missing). This can be very difficult to debug. Consider adding the `default_nettype none directive at the top of the file (See page 88 of the text book). This will require you to declare your signals before you use them and find these misspellings more easily.