FishTail tools are used to perform the following tasks:

constraintverification
Constraint Verification
The inputs to this flow are the following:

     •  RTL or Netlist
     •  SDC or TCL Constraints
     •  Architectural information (optional)

In this flow, Refocus is first used to apply the SDC or TCL constraints to the design description. Constraints that cannot be applied because of errors in SDC syntax, or because they refer to design objects that do not exist are flagged. Refocus is able to map gate-level constraints to RTL, RTL constraints to netlist. This allows signoff STA constraints to be verified using RTL input. Once constraint mapping is done, Confirm is used to verify constraints. This requires four separate runs:

    1) Clock Verification
    2) Generated Clock Waveform Verification
    3) Datapath False Path Verification
    4) Multi-Cycle Path Verification

In the Clock Verification run Confirm flag issues related to clock definition, clock propagation, generated clocks, clock groups, clock-to-clock false paths, i/o delays, case analysis. Among the clock definition issues identified by Confirm are unclocked registers, clocks defined on hierarchical pins. Among the clock propagation issues identified by Confirm are re-convergent clocks, clocks propagating through non-unate cells whose side-inputs are not set to a constant value, false paths in the clock generation logic that result in STA tools propagating a clock to pins that the clock will simply not propagate to. Among the generated clock issues flagged by Confirm are generated clocks that no master clock propagates to, generated clocks that block the propagation of other clocks, generated clocks that are not specified relative to all the master clocks that propagate to them, generated clocks with incorrect edge specification. Among the clock crossing issues flagged by Confirm are incorrect logically or physically exclusive clock groups, incorrect clock-to-clock exceptions, missing clock groups, missing timing exceptions between clocks with non-integer clock periods. Confirm flags missing input/output delays and the propagation of conflicting constant values to the same pin. Confirm also flags the situation where case analysis values specified on multiple combinational pins cannot be simultaneously satisfied once you consider the logic cones that drive these pins. For a conceptual overview of some of these warning messages refer the document Formal_Constraint_Verification.pdf. For detail on each of the clock, case analysis and IO warnings flagged by the tool refer the document Clock_IO_CA.pdf.

In the Generated Clock Waveform verification run Confirm verifies whether the period, low and high pulse specified on a generated clock is consistent with the logic on the design. Confirm also verifies whether the alignment between generated clocks derived from the same master clock is consistent with the logic on the design. As part of this run, you can provide input to the tool telling it how configuration registers that control clock division are programmed.

In the False-Path (FP) Verification run Confirm establishes whether a non-clock-to-clock false path between synchronous clocks that applies to the setup timing check in STA is correctly specified. Proving that a false-path specification is correct requires establishing that it is impossible for a transition on a startpoint to propagate to an endpoint. A user can provide architectural input to the tool indicating that some startpoints are static, some endpoints do not to meet timing, or that some condition is guaranteed never to occur based on the architecture of the chip. This architectural input allows the tool to prove more false paths as correct. Alternately, a user can take assertions that Confirm generates for failing false paths and apply them to RTL functional simulation to see if they pass or fail. The benefit of the assertion flow is that it accounts for the way a design will be used and avoids the need for a user to provide architectural input to Confirm’s formal proof. In general, the value of Confirm is to verify false paths that are supported by the logic on the design. False paths that are there solely because you do not care to meet timing on a certain path should be waived.

In the Multi-Cycle Path (MCP) Verification run Confirm establishes whether a multi-cycle path between synchronous clocks is correctly specified. This requires proving that when a startpoint transitions this change cannot propagate to the endpoint in the same clock cycle, or for an MCP greater than 2, for as many clock cycles as specified by the user. There is no limit on the MCP shift verified by Confirm. Both setup and hold MCPs are verified if they relax the timing on a path. So, for example, a 0 cycle setup MCP is not verified because it tightens the timing requirement on a path. Nor is a 3 cycle hold MCP that is paired with a 4 cycle setup MCP, because in this situation there is no change to the default 0 cycle hold check. A user is warned if a setup MCP is specified without an accompanying hold MCP, or if the hold shift is less than setup – 1. The use of clock-gating logic to ensure MCP behavior is accounted for. If engineers allow flops to go metastable then that information can be communicated to Confirm and the formal proof is altered. All timing paths constrained by an exception are verified and engineers are presented with a complete picture on a timing exception – the paths that are truly false or multi-cycle, those that aren’t. Confirm’s sequential verification engine ensures that inconclusive results are never reported. Timing exceptions only pass formal verification if they are safe from glitches.

Just like the FP verification run, a user can specify architectural input and take assertions for failing MCPs into RTL functional simulation. Confirm is accompanied with a debug environment that explains why an MCP is incorrect, shows the failure stimulus that leads to a failure, and justifies the value of a signal at any point in time. Engineers are able to view simulation waveforms that show how a failure state is reached. Timing paths and objects in the RTL can be cross-probed and viewed in a schematic browsing system like Verdi.

Top of page

cdcverification
CDC Verification
The inputs to this flow are the following:

     •  RTL
     •  SDC or TCL constraints

In this flow Confirm is used to verify asynchronous clock domain crossings and whether these crossings are correctly synchronized. Asynchronous clock domains are inferred based on the constraints in an SDC file (set_clock_group, set_false_path). Double synchronizers are automatically identified by the tool. A user can also provide the tool a list of module names that are considered safe for the purpose of sampling a signal at a clock-domain crossing. A clock-domain crossing that ends at a synchronizer cell is consider good and the user is warned if a multi-bit wide signal where more than one bit can change at the same time is sampled by the same synchronizer cell. If a clock-domain crossing does not end at a synchronizer cell, the tool formally proves that the logic on the design ensures that a 0-cycle path between the clock crossing can never happen, and that the handshake signals that control the clock crossing provide at least 1 cycle for the data to propagate from one clock crossing to another, regardless of the potential phase alignment of the clocks. Users do not provide the tool a list of legitimate synchronizer structures. The objective is to formally establish whether a clock-domain crossing is correctly synchronized based on the functionality of the design.

Top of page

constraintgeneration
Constraint Generation
The inputs to this flow are the following:

     •  RTL or Netlist
     •  SDC or TCL constraints (optional)

In this flow, designers use Focus to generate the clock, I/O constraints, clock groups and timing exceptions for their design. A user can decide whether to generate all of these constraints or only clocks, I/O delays, clock groups or timing exceptions. Constraint generation takes place through four runs:

    1) Clock and I/O constraint generation.
    2) Clock group generation.
    3) FP generation.
    4) MCP generation.

The only required input to the tool for clock generation is the RTL or netlist description for a design. If some existing constraints are already in place, they are honoured, and first missing clocks, I/O constraints are generated. Focus has the ability to analyze the clock generation logic for a design to identify the ports and pins on which clocks and generated clocks should be created. This requires being able to tell the difference between registers or ports that control clock-gating, clock muxing, from those that are used to define a periodic clock waveform. The clock and I/O constraints generated by Focus are viewed and managed using Excel. There is also a script which enables engineers to change the names of clocks, their periods or waveforms, manage I/O budgets, specify corners using spreadsheets and convert them back to sdc. In addition to generating clock and I/O constraints,

Once the clock definitions are in place Focus is used to generate the clock groups and clock senses for a design. Focus establishes the clock crossings on a design and identifies clocks that are logically or physically exclusive to each other. If a pair of clocks is partially exclusive, i.e. for some register pairs the clocks are exclusive, but for others they are not, Focuscan optionally automatically insert divide-by-1 generated clocks to limit the scope of an exclusive clock group relationship to the portion of the design where it applies. Engineers can also have the tool generate clock groups that are appropriate for signoff analysis with SI delay calculation turned on. This results in the creation of additional divide-by-1 generated clocks so that clocks can be flagged as physically exclusive, rather than just logically exclusive.

In addition to generating clock groups, Focus generates clock sense commands if the propagation of a clock is completely stopped at some stage in the clock network, or if the propagation of a specific sense (positive or negative) is stopped. Focus can also be optionally asked to block the propagation of slow clocks in the design if the timing requirements established by the slow clocks are superseded by faster clocks in the design. When deciding whether the propagation of a slow clock can be blocked Focus considers the timing exceptions, the clock crossings and clock latencies specified in the constraint file. Stopping the propagation of slow clocks helps reduce clocks/register and allows chip-implementation tools to run faster without any impact on QoR.

Once clock senses and clock groups have been generated Focus can be asked to generate false and multi-cycle paths for a design. False paths generated by Focus are combinationally unsensitizable and are safe from the propagation of glitches. Multi-cycle paths are generated if Focus can establish that data cannot propagate from launch to capture flop in a single clock cycle. Focus generates a complete list of formally provable timing exceptions for the design. The generated timing exceptions are then compacted. All Focus generated timing exceptions initially are from a flop to a flop. In the compaction step the tool looks to see if the same paths can be constrained by moving the exception to through pins. Often thousands of flop-to-flop exceptions are compacted into a few dozen exceptions. This is key to ensuring that these exceptions provide the desired impact during chip implementation, i.e. an improvement in QoR without any adverse impact to synthesis, static timing or P&R runtime.

Once Focus is done generating timing exceptions, Confirm is used to verify that the generated exceptions are correct: unless there is a bug in Focus all exceptions are expected to pass Confirm verification. Additionally, engineers may ask Confirm to generate assertions for each of the Focus generated exceptions and take these assertions into RTL functional simulation to confirm that the Focus generated exceptions are correct.
 

Top of page

modemerging
Mode Merging
This inputs to this flow are the following:

     •  Netlist/RTL
     •  SDC or TCL constraints for signoff modes

In this flow Focus takes as input signoff constraints for each of the design modes and creates a merged super mode constraint file that covers the signoff modes. The objective of mode-merging is to improve multi-mode implementation runtime by 50% with no impact to QoR by using merged super-mode constraints instead of multiple signoff modes to drive synthesis/P&R. P&R tools have automatic scenario reduction capability, where they attempt to see if some of the design modes are completely covered by others. However, it is fairly common for a portion of the design to have critical timing requirements in one mode and another portion of the design to have critical timing requirements in another mode. When the modes do not completely dominate each other they cannot be dropped from consideration and automatic scenario reduction has muted impact. The automated mode merging technology in Focus collapses modes into super modes even when modes do not dominate each other. Focus is able to generate merged constraints that keep just the critical timing impact of each mode, while discarding the non-critical timing requirements specified by a mode. The clocks/register in the Focus generated super mode constraint file is comparable to the clocks/register in each of the signoff modes provided as input to the tool.

The quality of the merged constraint file generated by Focus is measured by running a TCL procedure called verify_merge_mode_sdc in an STA tool. This procedure computes the worst-case setup and hold slack for each endpoint for the individual mode constraints and for the merged constraints. If the merged constraints have slack greater than the worst individual mode slack, then this is indicative of optimism. If the slack for an endpoint in the merged constraints is less than the worst individual mode slack, then this is indicative of pessimism. The verify_merged_mode_sdc procedure reports a variety of metrics related to the pessimism and optimism in the super mode constraint file. As the procedure compares differences in slack between merged and individual modes, the actual delay model used in STA is irrelevant. The expectation is that the Focus generated super mode constraint file will have no optimism and limited pessimism.
 

Top of page

constraintpromotion
Constraint Promotion
The inputs to this flow are the following:

     •  RTL or Netlist for SoC
     •  SDC or TCL Constraints for SoC
     •  SDC or TCL Constraints for SIPs

In this flow, Refocus takes as input a stand-alone constraint file for an IP and creates a version of the constraint file that can be sourced at the SoC level where the IP is instantiated. During this process Refocus rewrites references to ports on an IP as references to hierarchical pins with the appropriate hierarchy prefix inserted. Additionally, Refocus identifies any timing exceptions in the IP that refer to clocks and inserts divide-by-1 generated clocks to limit the scope of these exceptions to the block even after it is instantiated in the SoC. As part of constraint promotion process Refocus identifies the correct SoC master clocks for generated clocks defined inside the IP and rewrites the IP generated clock definitions with this information. The value of constraint promotion is that engineers do not need to maintain two versions of an IP constraint file (one, where the IP is implemented standalone and the other where the IP is instantiated in a SoC). Also, with automated constraint promotion designers do not need to know anything about SoC constraints, clock names etc. and SoC integrators do not need to know anything about IP constraints. IP and SoC integrators can develop their constraints independently and rely on Refocus to stitch the SoC and IP constraints together as part of constraint promotion.

An alternative constraint promotion flow is to create missing SoC constraints using IP constraints and to flag conflicts between IP constraints and SoC constraints. In this flow, rather than create a sourceable version of an IP constraint file at the SoC level, Focus is used to simultaneously promote IP constraints for multiple blocks up to the SoC and push clock and I/O constraints toward the boundary of the SoC. During this process Focus flags clock, I/O or case analysis definitions for an IP that conflict with the corresponding definition for another IP or with the SoC constraint definition. Missing clock and I/O constraints at the SoC are created using the IP constraints.

Top of page

sdcequivalence
SDC Equivalence
The inputs to this flow are the following:

     •  RTL, Netlist, or Lib
     •  SDC or TCL constraints

The objective of this flow is to compare the timing requirements established by one design representation to another to see if they are the same, and if they are different to understand why. A design representation could be RTL, netlist, or .lib along with its associated SDC constraints (no SDC is required if the input is a .lib model). A designer tells the tool to treat one design representation as “golden” and another as “reference”. Confirm is used to establish the path timing requirements of each design representation. These are the critical timing requirements that must be met by each path in the design (a path is a unique start/end pair of flops). The timing requirements for a design are established after accounting for the clocks, constants and timing exceptions specified in a constraint file. Once Confirm has established path timing requirements for each design, Refocus compares these requirements to see if they are the same. Differences are bucketized based on their severity and a debug environment is provided to help users rootcause the reason for a difference (i.e. is it because of a difference in the way clocks propagate, constants propagate, or timing exceptions apply to a design). The objective of this flow is similar to logical equivalence check, i.e., if one design representation is considered golden, is another equivalent to it. There are four different applications of this flow:

    1) For the same design (RTL or netlist) establish if two different constraint files constrain the design in the same way.
       This allows you to compare if, for example, an optimization to an SDC file has no impact on the way a design is constrained.
    2) Establish if two different, but logically equivalent design representations are constrained in the same way. This, for example,
       could be used to compare if the RTL and synthesis constraints are equivalent to a post P&R implementation of the RTL and
       the constraints that are applied to this implementation.
    3) Establish if the way a block is constrained in the context of a full-chip design is equivalent to the way the block is
       constrained standalone. This, for example, could be used to check if block-level constraints have been correctly promoted
       to the full-chip, or if top-level constraints have been correctly pushed down.
    4) Establish if a .lib model is equivalent to the netlist from which it was extracted, or if the .lib model extracted from RTL is
       equivalent to the .lib extracted at the end of chip-implementation by STA. In this flow boundary timing arcs in one design
       representation are compared to another.

 

libgeneration
Lib Generation
The inputs to this flow are the following:

     •  RTL
     •  Template.lib
     •  SDC or TCL Constraints (optional)

In this flow,Focus takes RTL and constraints as input to generate .lib for a module. If no user constraints are provided, Focus creates a template SDC that contains clock and IO constraints. This SDC file is then provided as input to the tool to generate .lib. A template.lib is necessary for this flow, the technology information is taken from the template.lib and copied into the output.lib. The .lib is generated by examining the structure of the design, establishing the clocks that propagate to interface flops and the timing requirements on interface paths. The delay value for timing arcs in the .lib model are established based on the I/O delay specified for ports – it is assumed that the specified delay is consumed by the logic outside the block, and the left over delay is the delay of the logic inside the block. Timing exceptions on interface paths are honored. Timing senses are correctly computed for all timing arcs. The generated .lib is used for design implementation at the top-level where the block is instantiated. The generated .lib is also compared against the .lib extracted after implementation by an STA tool to ensure that the I/O timing arcs remain the same after chip implementation.

Top of page


Copyright ©2015 FishTail Design Automation, All rights reserved