RTL编码与优化指南：设计编译器的前期关键

需积分: 9 133 浏览量更新于2024-07-17 1 收藏 161KB PDF 举报

"RTL编码与优化指南用于Design Compiler" 这篇文档是Jack Marshall为Tera Systems Inc.撰写的，他分享了自己在Synopsys公司9年间的前端设计经验，涉及了高级设计、编码风格、综合、脚本、优化技术、时序收敛和质量-of-result(QoR)等多个方面。Jack指出当前行业对设计周期的关注点有误，过于依赖后期的布局技术来解决时序问题，而实际上，如果时序问题不能通过布局解决，设计师必须回到RTL代码并重新编写以解决问题。 RTL（寄存器传输级）编码是集成电路设计的关键步骤，它定义了硬件逻辑的功能和行为。正确的RTL编码能够减少后期设计中的问题，提高设计的可综合性和优化效率。本文档着重强调了在设计初期就应考虑实施障碍和潜在问题的重要性，避免在设计流程后期遇到难以解决的时序收敛问题。在RTL编码中，设计师需要关注以下几点： 1. **清晰的模块结构**：模块应该有明确的输入、输出和内部状态，以实现良好的模块划分，便于复用和测试。 2. **数据路径的优化**：优化数据路径可以减少延迟，例如使用并行处理、流水线设计等方法。 3. **避免复杂逻辑**：尽量减少组合逻辑的复杂度，复杂的布尔表达式可能导致合成工具难以优化。 4. **时序约束**：在编码阶段就应该考虑时序约束，这有助于确保设计满足速度目标。 5. **使用综合友好型语法**：避免使用综合工具难以处理的语法结构，如不必要的嵌套条件语句、大范围的case语句等。 6. **寄存器重定时**：通过寄存器重定时可以优化时序，但需要谨慎操作，避免引入新的问题。 7. **脚本自动化**：利用脚本自动化可以提高设计效率，如Perl或Tcl脚本，用于预处理、后处理和定制综合过程。 8. **代码风格和规范**：遵循一致的编码风格和标准，提高代码的可读性和可维护性。 9. **仿真验证**：在编码过程中进行频繁的仿真验证，确保功能正确，并提前发现可能的性能问题。 10. **早期功耗考虑**：在RTL级别考虑低功耗设计，如门控时钟、多电压域等。通过遵循这些指导原则，设计师可以编写出更高效、更容易综合的RTL代码，从而在设计流程早期就能实现更好的时序收敛，减少对先进布局技术的依赖，提高整个设计流程的效率和成功率。这份"RTL编码指南"是设计者在实践中的宝贵参考资料，旨在帮助他们避免后期设计中的困境，提高设计质量和可靠性。

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

SNUG San Jose 2002 RTL Coding Guide 7

use a different select operator for each state of the case statement and DC cannot determine

whether the select operators are mutually exclusive (i.e. parallel) or completely specified (i.e. full

case).

When you elaborate a design into DC – you can check the log file to see if DC is properly

interpreting the case statements. DC lists the line of code and whether it was able to

automatically determine “full” or “parallel” case based on your description, or if you used

directives it will list “user” for that particular case statement.

1.2.8 Initialize output of conditional statements prior to defining the statements

This goes along with fully specifying all branches of a conditional statement. Just in case you

don’t – initialize the output(s) of the conditional statement by assigning it (them) prior to the

conditional statement. This is a safe coding style. Be careful selecting what value you initialize

the output to. If there isn’t a default state for that part of the design – then try to pick the “most

popular” state to initialize the output to – that should help reduce extra switching (power) during

operation.

1.2.9 Use high level constructs (case, if, always@) as much as possible.

Synthesis works best (i.e. it has the most freedom to try different optimizations) with high level

RTL constructs. Low level gates or Boolean level constructs (verilog primitives) constrain DC.

Later chapters will discuss how coding styles influence optimization. Also – don’t spend a lot of

time trying to force DC to implement a gate level solution by describing the logic with

primitives. DC takes Boolean expressions and gate level instantiations and replaces them with a

sum-of-products “pla”-like internal description that is fed to the gate level mapping optimization.

You will never get exactly what you want and you will only frustrate yourself.

1.2.10 Don’t instantiate gates unless you have to; make the code technology independent.

This goes along with the idea of getting exactly what you want. If it isn’t a specification

requirement or a design reuse situation – then don’t instantiate standard cells in your design.

You want portability – to be able to take the design description and synthesize it using any

technology. If there are any instantiations in the code – they will have to be resolved (i.e.

changed to match the new technology) before it can be synthesized into a new technology. Ugh.

If it isn’t necessary – then don’t do it. A trick that works well is to put a “wrapper” around the

gate level design. The wrapper enables a plug-n-play type swap out of different gate level

implementations of the design while not interfering with the hierarchical description. The design

// no directives needed

case (a)

2’b00 : c = x;

2’b01 : c = y;

2’b10 : c = z;

2’b11 : c = w;

endcase

Figure 7: Only use full_case & parallel_case directives when you have to.

// directives needed

case (1’b1) // synopsys full_case parallel_case

a : c = x;

b : c = y;

c : c = z;

d : c = w;

endcase

剩余30页未读，继续阅读

drjiachen

粉丝: 171
资源: 2139

RTL编码与优化指南：设计编译器的前期关键

HDL Compiler for Verilog User Guide.pdf

REALTEK WIN USB PGTOOL v2.0.5

RTL8152 8153 windows烧录工具 USB PGTOOL v2.0.3

dft compiler rtl test design rule checking user guide.pdf

如何学习design compiler

design compiler中文教程

design compiler怎么打开

designcompiler中文讲义

rtl8111hs.pdf

rtl8367s_datasheet.pdf

最新资源