« Prev | Next » Best-Practices in Speeding Up Design Linting of Large Designs Introduction ALINT-PRO is a state-of-the-art Static Verification solution aimed to improve various aspects of RTL coding. It parses, elaborates and synthesizes the RTL code as well as applies and propagates clock and resets tags using design constraints. In fact, it acts as a "lightweight" implementation tool, revealing real implementation issues at early stages of RTL code development. In addition to code implementation, ALINT-PRO builds various models used for rule checking. These models are built during different processing phases - elaboration, synthesis and so on. For large ASIC or FPGA designs, the process of processing the code, propagating design constraints and building models takes time. The following Application Note outlines various strategies for speeding up large design linting. The following strategies help speed-up large design linting: Ensuring correct "Description Style" settings Disabling RTL BDD Analysis Disabling netlist BDD Analysis Running Linting by phases Reducing maximum limit of violations per rule Let's explain each strategy in detail. Ensuring correct "Description Style" settings ALINT-PRO classifies design units by the description style into the following four types: testbench, structural, RTL and behavioral. Checks and code processing that should be applied to a unit vary depending on its description style. For example, code of a design unit that contains behavioral description is usually non-synthesizable. Hence, such unit causes an error at the synthesis phase and the phase fails. In order to avoid synthesis error, the design unit description style should be explicitly specified as a behavioral one. If the unit description style is set to behavioral, then this unit is handled as a black box during the synthesis. It is important to ensure that all behavioral models instantiated in design are properly identified with "behavioral" Description style keyword. By default, Alint-PRO tries to automatically identify and assign unit description styles. In some cases, Alint-PRO may fail to identify such models. For example, RAM or FIFO models may contain synthesizable code as well, with thousands of register variables in memory array. In some cases, Alint-PRO may not mark such unit with the "behavioral" description style keyword, and this may impact RTL code processing and linting times. To ensure proper behavioral style: Start running Linting by phases, running "Parse" phase first. Open Library Viewer and review all Project unit's description styles, as shown in Figure 1: As we may see, generic ROM, SPRAM and FIFO instances are still assigned with "RTL" description style. To speed up Synthesis and Linting, change Description Style to "Behavioral" right-clicking on selected units (Figure 2): Figure 1: Library Viewer with description style detected as RTL Figure 2: Library Viewer with modified Description Styles for behavioral models Disabling RTL BDD Analysis The "BDD" stands for "Binary Decision Diagrams". Basically, these are binary trees built from the RTL code expressions. This process allows for complete checking of unreachable branches in this tree, causing the whole condition to be unreachable and as a result, redundant. For example, the following RTL code condition for dout variable assignment (Figure 3) never executes, causing non-implemented register and code redundancy (Figure 3): Figure 3: RTL code example with unreachable assignment Alint-PRO builds the BDD tree from each set of RTL conditions to check that all of them are reachable. For the example above, Alint-PRO builds the following binary decision tree: Figure 4: BDD for RTL code example with unreachable branch Each path from the tree root to one of its leaves represents one of the following possible condition sets: (c1 & c2) & (~c2 & c3) (c1 & c2) & (~(~c2 & c3)) (~(c1 & c2)) & (~c2 & c3) (~(c1 & c2)) & (~(~c2 & c3)) The BDD engine checks all of these conditions for Boolean redundancy. As we may see, the conditions equal to 0 (c2 &~c2 == 0) independently from c1, c2, and c3 values. Therefore, the rightmost BDD path is not reachable and a corresponding violation will be issued by the tool. Users may disable the RTL BDD engine to speed up the synthesis phase. This may save time, especially for designs with complex nested "if" and "case" statements. Once disabled, the rules such as ALINT_VLOG.2.7.2.3 (Do not describe conditions that cannot be executed) will be disabled as well. To disable the RTL BDD engine, use global.pref.disablertlbddanalysis or project.pref.disablertlbddanalysis from console or Set the "Disable RTL BDD Analysis" option in Design Entry-> Elaboration/Synthesis -> Synthesis menu (Figure 5): Figure 5: Disabling RTL BDD Analysis option from Project Properties Window Disabling netlist BDD Analysis The Clock Domain Crossing verification requires identification and grouping of "related" CDC paths. If such paths reconverge at receiving clock domain, the value at the reconvergence point may be corrupted during Clock Domain Crossing transition. It is important to identify such paths through the topological analysis of synthesized netlist. To identify the reconvergence, Alint-PRO builds BDD structures at netlist level. Using these diagrams, the tool is able to identify CDC paths reconvergence even though they reconverge after N register stages. Being the powerful feature it is, this option also consumes time and memory, when reconvergence structures and CDC paths are present in design. To speed up design processing, users may completely disable the reconvergence analysis or just reduce the number of divergence / convergence stages using the following commands at either global or project levels: global.pref.reconvergenceanalysis , project.pref.reconvergenceanalysis global.pref.divergencedepth, project.pref.divergencedepth global.pref.convergencedepth, project.pref.convergencedepth Alternatively, use Design Entry -> Constraints -> CDC GUI Window (Figure 6): Figure 6: Disabling / Limiting reconvergence search from CDC window Note: Disabling reconvergence also disables the "reconvergence-specific" CDC rules, such as ALDEC_CDC.2.8 (Avoid reconvergence of synchronized signals) Running Linting by phases Alint-PRO contains the lightweight implementation engine allowing customers to run various implementation-specific checks at early stages of code development. Any Alint-PRO rule belongs to either one of the codes implementations phases. Also, Alint-PRO provides a Flow Manager tools, allowing users to run either one of the two flows: Default Linting or CDC Verification. The main reason behind using the Flow Manager is to "Divide and Conquer" the linting process using RTL processing phases: Parse, Elaborate, Synthesize and Constrain. Violations from early processing phases may trigger other violations related to later phases, thus increasing the total number of violations. Also, it is important to verify the correctness of Description Styles definitions prior to Synthesis phase. For each phase, it is convenient to define the set of rules with Severity "Error" that fail the phase. Using this method, it is required to fix or waive failing rules prior to moving on to the next phase. Overall, the phase-based verification method may significantly reduce the number of violations, leading to smaller Violation Database size and faster linting. To run linting by phases, use Flow Manager Window (Figure 7) or the following commands: Figure 7: Flow Manager Window project.parse project.lint -parse project.elaborate project.lint - elaborate project.synthesize project.lint -synthesize project.constrain project.lint -constraints Reducing maximum limit of violations per rule It is important to reduce the number of violations, as this may significantly reduce Linting phases time. Also, large-size Violation Database access times may cause inconveniences while working with waivers, as each database modification operations "freeze" the tool for a few seconds or more. To reduce the database size, it is useful to reduce the maximum limit of violations per rule. The default maximum number of violations per rule is 5000. The maximum violations amount per rule may be significantly reduced, depending on design size and structure. By doing that, it is important to make sure that all important violations are fixed by running repetitive linting and bug fixing / waiving. Change the maximum number of violations per rule using Linting window in Project properties (Figure 8) or using the following commands: project.pref.maxviolationsperrule global.pref.maxviolationsperrule Figure 8: Setting Maximum number of violations per rule Previous article Next article
