# Coding Style Guidelines

 старонка 4/4 Дата канвертавання 24.04.2016 Памер 116.6 Kb.
1   2   3   4

## Logic Level Reduction

To minimize the number of cascaded logic levels, we need to follow a few simple rules of coding. ### If-Then-Else and Case Statements

If-then-else and case statements can cause unwanted effects in a design. Specifically, nested If-then-else and case statements may cause extra levels of logic inference. This occurs because if-then-else statements generally infer priority-encoded logic. However, one level of an if-then-else will not necessarily create priority-encoded logic. For that matter, synthesis tools generally handle if-then-else or case statements very well and create parallel logic rather than priority encoded logic.

Often, a nested if statement can be combined in the original if statement and result in a reduced amount of inferred logic. A simple example is shown in Figure 13-24, which shows how priority encoded logic creates cascaded logic. Nested case statements can have the same effect, as can the combination of nested case and if-then-else statements. process (clk)

begin

if rising_edge(clk) then

if data(2 downto 0) = “110” then

if cs = ‘1’ then

if en = ‘1’ then

data_q <= data + 1;

end if;

--

if en = ‘1’…

end if;

--

if cs = ‘1’ …

end if;

--

if da

ta(2 downto 0)…

end if;

--

if rising_edge(clk)…

end process;

--

should be replaced with…

process (clk)

begin

if rising_edge(clk) then

if data(2 downto 0) = “110” and cs = ‘1’ and en = ‘1’ then

data_q <= data + 1;

end if;  en cs data(1) data(0) data(2)       en cs data(1)

) data(0) data(2)                  Figure 13 24 Priority Encoded Logic

Priority-encoded logic can be generated for other reasons. The use of overlapping conditions in if-then-else branches causes the generation of priority-encoded logic. This condition should be avoided. There are times that priority-encoded logic must be used and may be intended. If the selector expressions in the if-then-else statement branches are not related, then priority-encoded logic will be created. Although this may be the intent, its use should be cautioned.
Rules for If-Then-Else and Case Statements

• Limit the use of nested if-then-else and case statements.

• Avoid overlapping conditions in if-then-else statements – this condition will infer priority-encoded logic.

• Avoid using mutually exclusive branch expressions if possible. This condition will always infer priority-encoded logic.

• Instead, use mutually exclusive if-then statements for each expression (if possible).

### For Loops

Similar to the use of if-then-else and case statements, "for loops" can create priority-encoded logic. While for loops can be a very powerful tool for creating logic, the designer should evaluate their effects.

A simple example of the adverse effect of for loops is shown in Figure 13-25. Fortunately, this is a situation that most tools handle well, but in our goal of creating reusable (portable) code, this situation should be avoided.

Figure 13-25 For-Loop Cascaded Logic Implementation

Rule for For Loops

• Be cautious of using for loops for creating logic. Evaluate the logic created by the synthesis tool. There will likely be another way to write the code to implement the same functionality with the logic implemented in parallel.

### Inadvertent latch inference is a common problem that is easily avoided. Latches are inferred for two primary reasons: one, not covering all possible branches in if-then-else statements and two, not assigning to each signal in each branch. This is only a problem in a combinatorial process. For a clocked process, registers with clock enables are synthesized (as covered in the Xilinx- Specific Coding section, section 4).

A latch inference example for each of these cases is shown in Figure 13-26. For section one, each possible state was not covered. This is a very common mistake for one-hot encoded state machines. Section one is an example of Moore FSM output decoding. The latch inference would be eliminated by the use of a final "else" statement with an assignment in that branch to the signal "cs."

Figure 13 26 Latch Inference

For the second section of code, the latches are inferred because each signal is not assign in each state.
In Figure 13-27, the inference of latches is eliminated by covering all possible branches and assignging to each signal in each branch. The fixes are highlighted in blue. For the case implementation, the default assignment to cs before the case statement specifies a default assignment for each state. This way, each bit is changed depending on the state. This si equivalent to making a signal assignment in each branch. For the if-then-else statement, adding the else clause solves the problem.

F igure 13 27 Elimination of Inadvertent Latch Inference

Rules for Avoidance of Latch Inference

• Cover all possible branches.

• Assign to all signals at all branches. 1   2   3   4

База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі