![](https://csdnimg.cn/release/download_crawler_static/11195605/bg6.jpg)
SNUG San Jose 2002 RTL Coding Guide 6
1.2.4 Use separate always@ processes for sequential logic and combinatorial logic
This used to be part of a religious war between synthesis and simulation users. It still might be –
but I have always used it. It works. Three benefits – 1. It helps organize your RTL description
(for example, you can easily describe a pipelined design). 2. There is a sequential optimization
process in DC, which uses your coding style description of the sequential element to map it to the
best sequential element in your technology library. When you combine sequential and
combinatorial logic descriptions together, the tool can get confused and might not recognize the
type of sequential element you are describing. 3. For synchronous-reset type designs – the
synchronous reset signal is easily identified in case there are problems with it getting lost in a
more complex (combined combo & sequential) description and the subsequent optimization.
1.2.5 Use blocking (=) for combinatorial logic and non-blocking (<=) for sequential logic
Another holdover from the synthesis vs. simulation wars. A compromise of sorts. Recognizes
that combinatorial logic can be described with blocking statements without fear of losing implied
structure. While sequential logic must be described by non-blocking assignments to prevent
unanticipated loss of register stages due to the nature of a blocking statement (i.e. this is a “safe”
coding style). The safest coding style is to use non-blocking assignments exclusively throughout
your design – I will leave that decision up to you.
1.2.6 Know whether you have prioritized or parallel conditions
Designers like to use the “if “ statement a lot. It is very popular. Unfortunately it can abused.
Whether to use an “if” statement or not should depend on the select operator (the condition). If
the conditions are mutually exclusive (i.e. parallel) then a case statement is better, because it is
easier to read and it organizes the parallel states of the description. If multiple conditions can
occur at the same time, use the “if” statement and prioritize the conditions (from highest to
lowest or most often to least often) using “else if” for each subsequent condition. Priority
encoded if statements infer a cascading multiplexer structure while parallel-encoded case
statements infer a “tall and skinny” type of structure. Priority encoded muxes can impact timing
due to their cascading structural nature. However, a priority mux can also be used to speed up a
design by placing the late arriving operand and its condition at the top of the if –else-if statement
– that way it travels through the least number of levels of logic. Know the type of conditions that
exist so that you can use the proper construct.
1.2.7 Completely specify all branches of all conditional statements
A case statement, by default, in verilog, is prioritized from top to bottom. However, if you
completely specify all possible combinations of 1’s and 0’s for the different cases (or use a
default case) and
you use the same select operator for all cases – DC will automatically recognize
that case statement is fully specified and parallel (i.e. mutually exclusive). This is without any
other user input (i.e. user doesn’t need to use full_case or parallel_case directives). DC does this
for if statements as well. As a rule, I try to completely specify all branches of all conditional
statements. I challenge the designer not to use or rely on the “full_case” and “parallel_case”
directives except when it is necessary. It forces the designer to completely think out his/her
design (all possible cases). And it helps define all states of operation, so that the design never
comes up from a power on sequence in an unknown (or unreachable) state (that would be bad).
There will be designs where the directives have to be used. For example, one-hot muxes – they