Formality使用指南【精选】

合集下载

【VIP专享】Formality使用指南

push_ctrl.v, gray2bin.v, pop_ctrl.v, rs_flop.v。
Lib：门级网表需要的技术库；包含lsi_10k.db。 Gate：综合的门级网表；包含fifo.vg 和fifo_mod.vg。 Gate_with_scan：插入扫描链的门级网表；
包含fifo_with_scan.v。
由于fifo.v 是源代码，fifo.vg只是综合的源代码，没有添加SCAN和JTAG链。故可以省略这一步
检查reference design4和.MImatpclehmention design的比较
点是否匹配点击Match按钮，选择Run Matching按钮，进行匹
配检查。出现下图结果：没有不匹配的比较点，可以进入下
在点击Set Top Design按钮，出现下图。
在choose a library 中选择WORK，在choose a design中选择fifo（顶层设计的模块名）在Set and link the top design中点击Set Top，出现下图同时在Reference按钮上出现绿色的对号符：
（一）图形用户界面进行形式验证
在UNXI提示符下进入 tutorial目录：输入fm（或 formality）。
1.设置reference design
点击formality图形界面的reference按钮，进入Read Design File
点击Verilog按钮，出现添加Verilog文件的对话框。如下图：
由于验证失败，系统直接进入DEBUG工作区。在 Failing Points的报告工作区里显示两设计的出不一致的比较点
在Failing Points的报告工作区内点击鼠标右键，选择Show All Cone Size ,在Size栏里显示每个compar point所包含的cell的数目

formality简介教学文案

Formality简介Formality，synopsis的工具，我们常说的形式验证、formal check 都是用它做的。

作用就是比较两者“r、i”在功能上是否一致，跟时序一点儿关系都没有！在数字ic的flow中，一般会做两次formal check：一．rtl对DC netlist做一次；二．DC netlist对PR后的netlist做一次。

先看个rtl对DC netlist的脚本：#-------------------------------------------------------------------------# Formal check for Capture.vhd ( rtl vs dc_nlist )#-------------------------------------------------------------------------set TOP_REF Captureset TOP_IMP Captureset REF_NAME Capture.vhdset IMP_NAME Capture.vset REF_PATH /home/project/9602-360-100/Dig/d1/work_jh/synop199/rtlset IMP_PATH /home/project/9602-360-100/Dig/d1/work_jh/synop199/dc1/nlist set RPT /home/project/9602-360-100/Dig/d1/work_jh/synop199/fm/rptset hdlin_dwroot /edatools/synopsys/syn_vX-2008.9-SP4set verification_failing_point_limit 2000set synopsys_auto_setup trueset_svf /home/project/9602-360-100/Dig/d1/work_jh/synop199/dc1/default.svf set search_path ". /home/project/9602-360-100/Dig/d1/synop199 //edatools/synopsys/syn_vX-2008.9-SP4/libraries/syn"read_db {chrt35_ss_75_1pt3_SYNOPSYS2_MMSIM.db dw_foundation.sldb}read_vhdl -r $REF_PATH/$REF_NAME -l work > $RPT/read_design.rptset_top $TOP_REF > $RPT/set_top.rptreport_hdlin_mismatch > $RPT/rpt_hdlin_mismatch.rptread_verilog -i $IMP_PATH/$IMP_NAME -l work >> $RPT/read_design.rpt set_top $TOP_IMP >> $RPT/set_top.rpt#set_constant -type port r:/.../ 0#set_constant -type port i:/.../ 0match > $RPT/match.rptreport_matched_points > $RPT/matched_point.rptreport_unmatched_points > $RPT/unmatched_point.rptreport_loops -limit 0 -unfold > $RPT/loops.rptverify#以上内容可以放在一个文件里作为脚本，调用方法就是在fm_work下$ fm_shell –f ../scripts/fm_rtl2dc.tcl如果成功要看详细信息或者失败要debug的话，再输入start_gui，进入-GUI模式。

Synopsys Formality EC Solution说明书

DATASHEETOverview Formality ® is an equivalence-checking (EC) solution that uses formal, static techniques to determine if two versions of a design are functionally equivalent.Formality delivers capabilities for ECO assistance and advanced debugging to help guide the user in implementing and verifying ECOs. These capabilities significantly shorten the ECO implementation cycle.The size and complexity of today’s designs, coupled with the challenges of meeting timing, area, power and schedule, requires that the newest, most advanced synthesis optimizations be fully verifiable.Formality supports all of the out-of- the-box Design Compiler ® and Fusion Compiler™ optimizations and so provides the highest quality of results that are fully verifiable.Formality supports verification of power-up and power-down states, multi-voltage, multi- supply and clock gated designs.Formality’s easy-to-use, flow-based graphical user interface and auto-setup mode helps even new users successfully complete verification in the shortest possible time.Figure 1: Formality equivalence checking solutionIndependent formalverification of DesignCompiler and FusionCompiler synthesisresults, with built-in intelligencedelivering the highestverifiable QoRFormality Equivalence Checking and Interactive ECOKey Benefits• Perfect companion to Design Compiler and Fusion Compiler—supports all default optimizations• Intuitive flow-based graphical user interface• Verifies low-power designs including power-up and power-down states• ECO implementation assistance, fast verification of the ECO, and advanced debugging• Auto setup mode reduces “false failures” caused by incorrect or missing setup information• Multicore verification boosts performance• Automated guidance boosts completion with Design Compiler and Fusion Compiler• Verifies full-custom and memory designs when including ESP technologyFormalityThe Most Comprehensive Equivalence Checking SolutionFormality delivers superior completion on designs compiled with Design Compiler or Fusion Compiler. Design Compiler is the industry leading family of RTL Synthesis solutions. Fusion Compiler is the next generation RTL-to-GDSII implementation system architected to address the complexities of advanced process node design. Designers no longer need to disable the powerful optimizations available with Design Compiler or Fusion Compiler to get equivalence checking to pass. Design Compiler/Fusion Compiler combined with Formality delivers maximum quality of results (QoR) that are fully verifiable.Easy to Use with Auto-setup modeFormality’s auto-setup mode simplifies verification by reducing false failures caused by incorrect or missing setup information. Auto-setup applies setup information in Formality to match the assumptions made by Design Compiler or Fusion Compiler, including naming styles, unused pins, test inputs and clock gating.Critical files such as RTL, netlists and libraries are automatically located. All auto-setup information is listed in a summary report.Guided SetupFormality can account for synthesis optimizations using a guided setup file automatically generated by Design Compiler or Fusion Compiler. Guided setup includes information about name changes, register optimizations, multiplier architectures and many other transformations that may occur during synthesis. This correct-by-construction information improves performance and first-pass completion by utilizing the most efficient algorithms during matching and verification.Formality-guided setup is a standard, documented format that removes unpredictability found in tools relying on log file parsing.Independent VerificationEvery aspect of a guided setup flow is either implicitly or explicitly verified, and all content is available for inspection in an ASCII file.Figure 2: Automatic cone pruning improves schematic readability when debuggingHier-IQ TechnologyPatented Hier-IQ technology provides the performance benefits of hierarchical verification with flat verification’s out-of- the-box usability.Error-ID TechnologyError-ID identifies the exact logic causing real functional differences between two design representations. Error-ID can isolate and report several logic differences when multiple discrepancies exist. Error-ID will also present alternative logic that can be changed to correct a given functional difference; this flexibility allows the designer to select the change that is easiest to implement.Failing Pattern Display WindowAll failing input patterns can be viewed in a familiar spreadsheet-like format. The failing pattern window is an ideal way to quickly identify trends indicating the cause of a failing verification or improper setup.Figure 3: Problem areas can be easy identified by visual inspection of the Failing Pattern WindowPower-aware VerificationFormality is fully compatible with Power Compiler™ and verifies power-up and power-down states, multi-voltage, multi-supply and clock gated designs.When a reference design block is powered up, Formality verifies functionality. If the implementation design powers up differently, failing points will occur.Formality functionally verifies that the implementation powers down when the reference powers down and will detectfunctional states where the implementation does not power down as expected. The valid power states are defined in the power state table (PST).Power intent is supplied to Formality through IEEE 1801 Unified Power Format (UPF).Figure 4: Power connectivity is easy to see and debug from the schematic viewAccelerated Time to ResultsFormality’s performance is enhanced with multicore verification. This Formality capability allows verification of the design using up to four cores simultaneously to reduce verification time.Other Time-Saving FeaturesFormality’s Hierarchical Scripting provides a method to investigate sub-blocks without additional setup and is ideal for isolating problems and verifying fixes.The Source Browser opens RTL and netlist source files to highlight occurrences of a selected instance. This can help users correlate between the RTL and gate-level design versions.Error Region Correlation provides a quick, visual identification of the logic from one design that correspond to the errors isolated by Error-ID within the other.Command Line Editing allows you to take advantage of history and common text editor commands when working from Formality’s command line.Interactive ECOKey BenefitsProvides GUI-driven ECO implementation assistance, fast ECO verification, and advanced debugging. Formality guides the user through the implementation of ECOs, and then quickly verifies only the changed logic.Formality Interactive ECO FlowFormality uses the ECO RTL and an unmodified netlist. Guided GUI driven changes are made to the netlist. Once the ECO has been implemented, a quick verification is run on only the affected logic cones, eliminating the need for a full verification run on the design to verify that the ECO was implemented correctly.Once all ECO’s are implemented and fully verified, a list of IC Compiler™ commands is generated to assist in implementing the physical changes to the design.ECO GuidanceFormality highlights equivalent nets between the reference and implementation designs, and nets that have lost their equivalence due to the ECO changes in the reference. This helps the designer quickly identify where the change should be made in the implementation.Implementing the ECOEditing commands in Formality are used to modify the netlist in-place using the GUI.Rapid ECO VerificationFormality can identify and verify just the portion of the design affected by the ECO. This ensures that the ECO was implemented correctly. If the ECO verification fails, the ECO can be interactively “undone” and new edits can be made again. Once the partial verification passes, the changes are committed. This partial verification eliminates having to verify the entire design to assure that the ECO was implemented correctly, dramatically reducing the total time required to implement and verify the ECO.Figure 5: Equivalent net is highlighted between Reference design (left) and Implementation design (right)Figure 6: On a completed ECO, the schematic shows the nets affected by ECO in yellow, and the new component and net in orangeFigure 7: Formality transcript shows a successful partial verification of the portion of the design that was affected by the ECOInterface with IC Compiler IIOnce the ECO’s are implemented and verified, a final complete verification run is performed to assure that the ECO RTL and the ECO netlist are functionally equivalent.Formality produces IC Compiler II compatible ECO command file, easing the implementation in the physical design.Advanced DebuggingFormality incorporates advanced debugging capabilities that help the designer identify and debug verifications that do not pass. The designer can find compare points, equivalences (and inverted-equivalences) between reference and implementation designs, perform “what if” analysis by interactively modifying the designs, and verify equivalence between two (or multiple) points.Transistor VerificationESP combines with Formality to offer fast verification of custom circuits, embedded memories and complex I/Os. ESP technology directly reads existing SPICE and behavioral RTL models and does not require restrictive mapping or translation.Input Formats• Synopsys DC, DDC, Milkyway™• IEEE 1800 SystemVerilog• Verilog-95, Verilog-2001• VHDL-87, VHDL-93• IEEE 1801 Unified Power Format (UPF)Guided Setup Formats• Synopsys V-SDC• Formality Guide Files (SVF)Platform Support• Linux Suse, Red Hat and Enterprise• SPARC SolarisFor more information about Synopsys products, support services or training, visit us on the web at: , contact your local sales representative or call 650.584.5000.©2019 Synopsys, Inc. All rights reserved. Synopsys is a trademark of Synopsys, Inc. in the United States and other countries. A list of Synopsys trademarks isavailable at /copyright.html . All other names mentioned herein are trademarks or registered trademarks of their respective owners.。

Formality_Debugging_FailingVerificationsLabInstructions

Overview of Formality Labs forDebugging Failing VerificationsPurpose: These labs are designed for you to find, analyze, and solve common equivalency checking problems using Formality. You can use these labs to increase your awareness of Formality and to practice debugging skills.Content: These labs use public-domain RTL source. The netlists were generated using Design Compiler F-2011.09 release software. Procedure:∙There is a README file for every lab describing what to do.∙Each lab has a “runme.fms” FM Tcl script you can use initially.∙Each lab has a “hint” directory containing a README file if you need some helpful pointers on what to do.∙If you find that a lab is too difficult, there is a “.solution”sub-directory with the correct solution.∙Please compare your results with the correct results when you finish each lab.∙This lab document will guide you through each lab.Invoke Formality in this manner:"fm_shell -gui -f runme.fms |tee runme.log" or"formality -f runme.fms |tee runme.log"FM Lab1: Missing Verification Files Objective: This lab shows an example of what happens in verificationif pieces of the reference and implementation designs are missing andif guidance is missing. The focus of this lab is to review transcript messages. You need to change the "runme.fms" FM Tcl script to get a successful verification.Lab flow:1.) Run the verification using the existing "runme.fms" script.2.)Finding clues to indicate potential problems:2a) Transcript messages:Formality debugging involves collecting information that may point to the reason why the design fails verification. Always look at the transcript messages first.Note the following warning messages in the transcript:Status: Creating black-box designs...Created technology library 'FM_BBOX' in container 'r' for black-box designsCreated black-box design 'mAlu' in library 'FM_BBOX'Warning: 1 blackbox designs were created for missing references. (FM-064)Status: Attempting to resolve unlinked cells by using black-boxes...Warning: 150 black-box pins of unknown direction found; see formality.log for list (FM-230)Top design set to 'r:/WORK/mR4000' with warningsFormality is creating a black-box in the reference design to represent a missing piece of the design. The missing piece is “mAlu”. Perhapsan engineer forgot to send over that portion of the RTL, or merely left it out of the FM Tcl script.This transcript message is only a warning instead of an error because the customer included this variable setting in the FM TCL script: set hdlin_unresolved_modules black_boxOtherwise, by default Formality would have stopped processing the design.When faced with a missing piece of the reference design, you can either find the missing piece and try verification again. Or, you can try to black-box the equivalent sub-design in the implementation design, ifthe hierarchy was retained during synthesis.3.) For this lab, you can find the missing RTL by quickly browsing in the “rtl” sub-directory and include the missing file in your FM Tcl script. Re-run verification.4.) After running verification again, notice that the transcript still has these messages:set_top i:/WORK/mR4000Setting top design to 'i:/WORK/mR4000'Warning: Cannot link cell '/WORK/mR4000/DP_OP_94J1_124_8045_U32' to its reference design 'fa2a0'. (FE-LINK-2)Warning: Cannot link cell '/WORK/mR4000/DP_OP_94J1_124_8045_U31' to its reference design 'fa1b0'. (FE-LINK-2)Warning: Cannot link cell '/WORK/mR4000/DP_OP_94J1_124_8045_U30' to its reference design 'fa2a0'. (FE-LINK-2)Warning: Cannot link cell '/WORK/mR4000/DP_OP_94J1_124_8045_U29' to its reference design 'fa1b0'. (FE-LINK-2)Warning: Cannot link cell '/WORK/mR4000/DP_OP_94J1_124_8045_U28' to its reference design 'fa2a0'. (FE-LINK-2)Warning: Cannot link cell '/WORK/mR4000/DP_OP_94J1_124_8045_U27' to its reference design 'fa1b0'. (FE-LINK-2)Warning: Cannot link cell '/WORK/mR4000/DP_OP_94J1_124_8045_U26' to its reference design 'fa2a0'. (FE-LINK-2)Warning: Cannot link cell '/WORK/mR4000/DP_OP_94J1_124_8045_U25' to its reference design 'fa1b0'. (FE-LINK-2)This indicates that Formality cannot find several library componentcells for the implementation design. Formality is creating black-boxes for them. This is a sign that a library is missing from the setup. 5.) Since verification already ran, i f you run the “Analyze” command, Formality will indicate that there are unmatched black-box nets in the implementation design that do not exist in the reference design. Thisis another indication of something missing in the implementation design.6.) Find the missing library and include it in the FM Tcl script. Re-run verification.7.) During this verification run, Formality located all of the design pieces and library information. However, verification is stillfailing. The only clue for this issue is the following statement inthe transcript:Info: Formality Guide Files (SVF) can improve verification success by automating setup.You need to include the SVF guidance file in the FM Tcl script: set_svf mR4000.svf8.) Since there is no clock-gating nor scan involved, there is no additional setup needed. Auto setup mode is not required.9.) Try verification again. You should now get a successfulverification.9.) You can automatically create a FM Tcl script by using UNIX command “fm_mk_script”. Try the following:fm_mk_script mR4000.svf10.)View the resulting FM Tcl script “fm_mk_script.tcl”, and try it out with Formality.FM Lab2: Synthesis PragmasObjective: This lab contains Verilog RTL using Synopsys Parallel Case and Full Case synthesis pragmas. You must change the "runme.fms" FM TCL script to get a successful verification.Lab flow:1.) Run the verification using the existing "runme.fms" script.2.)Find clues to indicate potential problems.2a) Transcript messages:Formality debugging involves collecting information that may point to the reason why the design fails verification. Always review the transcript messages first.Note the following warning message in the transcript:************ RTL Interpretation Summary ************************ Design: r:/WORK/mR4000full_case ignored (7 total, 1 with unspecified cases)parallel_case ignored (7 total, 1 with overlapping cases)Please refer to the Formality log file for more details,or execute report_hdlin_mismatches.****************************************************This is our first clue that there may be simulation/synthesis mismatches due to specifying full case and parallel case pragmas in the RTL.2b) Messages from analyze_point commands:Under the Debug tab, run "Analyze". Formality knows that the logic cones are different, but cannot pinpoint the specific problem.2d) Pattern Viewer:View the pattern window of one of the failing compare points. Notice that the logic just seems to be different even though the logic cone inputs are the same:In many situations where one compare point is holding a value while the other compare point is loading a different value, this is an indication of RTL interpretation differences between Formality and Design Compiler. It is likely that something like parallel/full case pragma interpretation is making a difference in the verification of this design.3.) Resolve the RTL interpretation issue. You can set these variables:set synopsys_auto_setup trueOr, set these:set hdlin_ignore_parallel_case falseset hdlin_ignore_full_case falseset hdlin_error_on_mismatch_message false4.) Fix up the FM TCL script and re-run verification. If you do notget a successful verification, view the .solution directory.FM Lab3: Scan ModeObjective: This lab contains an implementation design with scan and clock-gating inserted. You must change the "runme.fms" FM TCL scriptto get a successful verification.Lab flow:1.) Run the verification using the existing "runme.fms" script.2.)Find clues to indicate potential problems and fix them.2a) Transcript messages:Formality debugging involves collecting information that may point to the reason why the design fails verification. Always review the transcript messages first.Note the SVF Guidance Summary in the transcript:***************************** Guidance Summary *****************************StatusCommand Accepted Rejected Unsupported Unprocessed Total----------------------------------------------------------------------------change_names : 2 0 0 0 2environment : 4 0 0 0 4instance_map : 3 0 0 0 3mark : 4 0 0 0 4reg_constant : 24 0 0 0 24scan_input : 0 1 0 0 1uniquify : 33 0 0 0 33Unless the Auto Setup Mode is enabled, Formality will ignore scan_input guidance found in the SVF file. You will need to disable scan mode in your FM Tcl script. Continue on with the debugging first.2b) Using the GUI, run “Analyze” on the failing compare points. Youwill see the following:There appear to be two different problems with this verification. The first is a list of unmatched implementation latches that are named “clk_gate_....”. This is an indication that clock-gating is in the design. Since these are not recognized as clock-gating latches, it is probable that the variable “verification_clock_gate_hold_mode” was not set. So, Formality is treating these latches as compare points, and failing the verification.The second issue is an unconstrained implementation input “test_se”. From this we can assume that no constant was set on the test input to disable scan mode. This needs to be done to have a successful verification.3.) Before changing the FM Tcl script, view the Match tab. Look at theunmatched points listed for the implementation design.Again, note the unmatched input port “test_se” in the implementation design. This is an indication of scan in the netlist.Also note that the “clk_gate_...” latches are of type “LAT” and not “CGLAT” denoting clock-gating latches.4.) Set a constant on the test input as recommended by the analyze points command. Also, set the clock-gating variable to “low”.s etupset_constant i:/WORK/aes_cipher_top/test_se 0set verification_clock_gate_hold_mode lowverify5.) Fix up the FM TCL script and re-run verification. If you do not get a successful verification, view the .solution directory.6.) Note that if you use the Auto Setup Mode with “setsynopsys_auto_setup true”, Formality will automatically disable scan and turn on clock-gating. You would not have to do anything else forsetup.FM Lab4: Constant Register Recognition(Modifying SVF File)Objective: This lab requires you to modify the SVF file so thatFormality can recognize a constant register to successfully verify the design.Note that this is a design contrived specifically to show an example of a naming issue between DC and Formality.Key ideas:a.) Practice using these Formality SVF debugging command:∙“analyze_points” with the option “-failing”∙“report_svf_operation” with the options“-summary”“-status rejected”“compare_point(s)”b.) Practice modifying an ASCII SVF file:∙Use your favorite text editor to replace DC name in SVF with the corresponding Formality name of the potentially constantregisterLab flow:1.) Run the verification using the existing "runme.fms" script.2.)Find clues to indicate potential problems.2a) Transcript messages:Formality debugging involves collecting information that may point to the reason why the design fails verification. Always review the transcript messages first.Note the SVF Guidance Summary in the transcript:***************************** Guidance Summary *****************************StatusCommand Accepted Rejected Unsupported Unprocessed Total----------------------------------------------------------------------------change_names : 7 0 0 0 7environment : 3 0 0 0 3instance_map : 2 0 0 0 2mark : 2 0 0 0 2reg_constant : 0 1 0 0 1uniquify : 2 0 0 0 2There is 1 rejected SVF guide_reg_constant operation. For several designs, this may be fine. Formality can figure out most constant registers; however, for this lab, this testcase will fail verification because this register is not recognized as a constant register.This Guidance Summary table can be produced anytime after matching by using the command “report_guidance –summary”.2b) Here is a picture of the GUI unmatched points tab. Notice the single unmatched register in the reference design that does not exist in the implementation design. Sometimes this is fine. We need to confirm with using either the “analyze” command or the patte rn viewer to see if this register contributes to failing compare points.2c) Run “analyze –failing” on the testcase.fm_shell (verify)> analyze_points -failing*********************************** Analysis Results***********************************Found 1 Unmatched Cone Input--------------------------------Unmatched cone inputs result either from mismatched compare pointsor from differences in the logic within the cones. Only unmatchedinputs that are suspected of contributing to verification failuresare included in the report.The source of the matching or logical differences may be determinedusing the schematic, cone and source views.--------------------------------r:/WORK/crc_insert/rs_crcblock_regIs globally unmatched affecting 4 compare point(s):i:/WORK/crc_insert/crc_block/S1/q_regi:/WORK/crc_insert/crc_block/S2/q_regi:/WORK/crc_insert/crc_block/S3/q_regi:/WORK/crc_insert/reset_crc4-------------------------------------------Found 1 Rejected Guidance Command--------------------------------The rejection of some SVF guidance commands will almost invariablycause verification failures. For more information use:'report_svf_operation -status rejected -command command_name--------------------------------reg_constant-------------------------------------------********************************************************************************** ******Notice the suggestion to run the command report_svf_operation. We will do that after just a few more steps.3.) Let’s take a quick view of the failing patterns:The patterns indicate that single unmatched reference register has a value of “0” for every failing pattern. Perhaps it is a constant1 register?4.) Now, l et’s look at the reason for Formality rejecting the SVFreg_constant guidance.fm_shell (verify)> report_svf_operation -status rejected -command reg_constant## SVF Operation 11 (Line: 82) - reg_constant. Status: rejected## Operation Id: 11guide_reg_constant \-design { crc_insert } \{ rs_crcblk_reg } 1Info: guide_reg_constant 11 (Line: 82) Cannot find master reference cell'rs_crcblk_reg'.Formality cannot find the register named “rs_crcblk_reg” in the reference design it created. However, the unmatched register in the reference design is named “rs_crcblock_reg”. The names are close, but do not completely match up, so Formality rejected the guidance. The problem could be a naming concordance difference between DesignCompiler and Formality when each tool created the design from the RTL.5.) Modify the svf.txt file located under “formality_svf” directorythat was automatically generated during the “set_svf crc_insert.svf” command. Change the name of the register in the SVF from“rs_crcblk_reg” to “rs_crcblock_reg” which Formality will recognize in its reference container.6.) After modifying the svf.txt file, rename the directory from “formality_svf” to “modified_svf”. Change the Formality TCL script to point to the new directory. Formality will look for SVF files in the specified directory.7.) After running with the modified SVF file, the Guidance Summary should be clean. You should have a successful verification.***************************** Guidance Summary *****************************StatusCommand Accepted Rejected Unsupported Unprocessed Total----------------------------------------------------------------------------change_names : 7 0 0 0 7environment : 3 0 0 0 3instance_map : 2 0 0 0 2mark : 2 0 0 0 2reg_constant : 1 0 0 0 1uniquify : 2 0 0 0 2 Formality will perform an internal verification check on thepotentially constant register before accepting reg_constant guidance.8.) Instead of modifying the SVF, you could have verified this register against a constant1, and found that it was truly a constant 1. Then, you could use the set_constant command to manually set this register to a constant1 value. This will also give a successful verification result.FM Lab5: Recognizing Clock-gatingObjective: This is a gate_vs_gate verification. This testcase has clock-gating circuitry in both the reference and implementation designs. You must change the "runme.fms" FM TCL script to get a successful verification.Note: The legacy variable verification_clock_gate_hold_mode turns on functionality that identifies clock-gating circuitry leading to a clk-pin of a rising edge DFF.Lab flow:1.) Run the verification using the existing "runme.fms" script.2.)Find clues to indicate potential problems.2a) Transcript messages:The only message is the name of the failing compare point:Status: Verifying...Compare point u1/LOCKUP failed (is not equivalent)Lockup latches are usually positioned at the end of the clock-gating chain during clock tree synthesis.Let’s investi gate this failure further.2b) Messages from matching:Bring up the GUI and view the Match tab. Here is a picture of the GUI unmatched points tab.Remember that this is a gate_vs_gate design with clk-gating latches in both the reference and implementation. Here we see an extra clock-gating latch in the implementation only.It is common for a clock-gating cell to be split into multiple clock-gating cells to satisfy fanout requirements and skew requirements during clock-tree synthesis.2c) Run “analyze –failing” on the testcase.Here we see some hints about what is happening. The failing compare point r:/WORK/core/u1/LOCKUP is affected by a globally unmatched latch i:/WORK/core/u1/clk_gate_stage1_reg2/latch1.3.) Viewing the pattern viewer for the failing compare point:It appears that even though these latches are clk-gating latches, they are not acting like clock-gating latches for this failing compare point. It appears that the failures are happening if FM places opposite values on them. Normally, clock-gating latches do not act as “active” logic cone inputs.4.) The logic cones confirm that Formality is placing and usingdifferent values on these supposed clock-gating latches:At this point you can see that these clk-gating latches are not driving the clk-pin of a rising edge DFF, but rather are going into the lockup latch instead.The legacy variable verification_clock_gate_hold_mode is not designedto handle this situation.5.) Our alternative is to try the new clock-gating algorithm invoked by using the variable verification_clock_gate_edge_analysis.6.) Re-run Formality with the new variable to get a successful verification.FM Lab6: ECO ProblemUsing Graphical DebuggingObjective: This lab will help you identify and repair a design difference. You must correctly change the gate-level netlist to get a successful verification.Background: This is an ECO RTL_vs_gate verification. There is no SVF file. A design engineer changed both the RTL and the gate-levelnetlist manually without re-running synthesis. The modified RTL is correct and golden. It passed simulation with great results.Your friend, a new engineer, is trying to verify the design and is having problems with debugging the failing verification.Please help him modify the gate-level netlist to correctly implement the ECO.Lab flow:1.) Run the verification using the existing "runme.fms" script.2.)Find clues to indicate potential problems. The transcriptindicates some interesting things in the implementation design: Warning: 0 (1) undriven nets found in reference (implementation) design; see formality.log for list (FM-399)Info: 0 (2) multiply-driven nets found in reference (implementation) design;see formality.log for list.3a) The analyze command has no suggestions.3b) View the pattern window:The reference design has two input ports that are named “global_rst” and “reset”. These seem to be missing in the logic cone for this compare point. Notice the “X” on the D-input of this implementation register compare point.4.) View the logic cone to visually inspect the problem.5.) Using the popup menu, perform a “Prune/R estore -> Expand Schematic”. Then, select the net with the “X” value in theimplementation leading to the SD pin of the DFF. Use the popup menu to "Find X Sources". This will trace back to the source of the "X",highlighting the problem in the netlist.Note the undriven net in the implementation design. This is the key to the verification difference. The net name is "internal_reset".6.) Search for this net in the Verilog netlist. You will need to edit the netlist. Use your favorite editor to view and repair the netlist. (FYI - You can bring up a browser window by selecting the componentthis net drives, bringing up the menu (right mouse click), andselecting View Source. However, cannot edit using this browser.)You might also want to view the netlist object for this net using the menu item View Object.7.) Trace this net in the netlist to the components it connects with. Ponder why it is not working and fix it.8.) Re-run verification. If you do not get a successful verification, view the .solution directory.FM Lab7: Solving Multiple ProblemsObjective: This lab will help you identify and overcome multiple verification problems. You must change the "runme.fms" FM Tcl scriptto get a successful verification.Lab flow:1.) Run the verification using the existing "runme.fms" script.2.)Find clues to indicate potential problems.3.) Transcript messages:Formality debugging involves collecting information that may point to the reason why the design fails verification. Always look at the transcript messages first.Note the following messages in the transcript:…set signature_analysis_match_compare_points false…Info: Formality Guide Files (SVF) can improve matching performance and success by automating setup.…If you got this script from another engineer in your company, pleaseask them why they are turning off signature analysis? Ask them whythey are not using the SVF file?4.) Run “Analyze”. Formality indicates that there are logic coneinputs that exist in the implementation design that do not exist in the reference design. This could be caused by clock-gating or by scan, or other problems.5.) Messages from matching:*********************************** Matching Results ***********************************77 Compare points matched by name0 Compare points matched by signature analysis0 Compare points matched by topology14 Matched primary inputs, black-box outputs314(351) Unmatched reference(implementation) compare points0(2) Unmatched reference(implementation) primary inputs, black-box outputs177(0) Unmatched reference(implementation) unread points---------------------------------------------------------------------------------------- Unmatched Objects REF IMPL ---------------------------------------------------------------------------------------- Input ports (Port) 0 2 Registers 314 351 DFF 314 314 LAT 0 36 Constant 1 0 1 **************************************************************************************** There are several unmatched compare points. This can be one of the problems with this verification.Here is a picture of the GUI unmatched points tab.Several compare points look similar but remained unmatched.6.) At this point we are confident that at least some of the failures are due to matching problems. Try one of the following to correct this issue:∙Use the SVF file.∙Or, write compare rules to fix up matching.7.) After correcting the script, run through verification again to see what problems remain. Notice that the number of unmatched points has significantly diminished.8.) View the GUI unmatched points tab again:Several of these unmatched objects are "…/clk_gate_..."; however, they are defined as latches. These are probably clock-gating latches.9.) Resolve the clock-gating latch identification issue by setting this variable:set verification_clock_gate_hold_mode low7.) Re-run verification with the corrected FM Tcl script.8.) Matching now looks good; however, there are still failing compare points. Try using the “Analyze” feature to get clues for debugging.9.) Formality indicates that test logic is not disabled, but should be for RTL vs Gate verification.10.) Set a constant to disable scan mode.setup; set_constant i:/WORK/tv80s/test_se 0 ;verify11.) Fix up the FM TCL script and re-run verification. View the example “runme.fms” under the .solution directory.。

Formality在rtl-gate等价性验证中的应用

３验证建立．
对设计的命名规则、电路结构都进行了大量改动，使
得很多比较点不能匹配、甚至匹配错误，从而导致在验证阶段发生错误。下面我们会从几个不同的方面
针对在实际操作中所遇到的一些具体问题给出实际果所有的逻辑锥的功能都是一致的，那么两个设计有效的解决方法，通过正确的运用这些方法可以解就是等价的。决大多数的不匹配和错误匹配的问题。
●主输出３
ＤＣ会根据这两个参数
来翻译代码，有无这两个设置，综合出的结果可能会有所不同。由于Ｆｒａｔ认的是忽略ｐｒ一ｏｌｍｉｙ默ａｌａ
１ｌｃｓ和ｆｌｃｓ，以我们必须重新设置：ｅａｅｕ＿ａｅ所ｌ
＿
Ｆｒａｔ的验证流程如图２３ｏｌｙｍｉ — 所示。
图２１基本验证原理图－
改变了该设计的逻辑功能。如果证实了改动后的设
计和源设计是等价的之后，就可以把修改后的设计
作为下一次验证时的 “ 源设计” 由于结构相似的设。计所需要的比较时间较短，这样也就节省了花费在
验证上的时间。
２Ｆｒａｉｙ的验证原理．ｏｍＩｔ
Ｆｒａｔ在验证时不需要任何输入矢量，所以会带ｏｌｍｉｙ来两个显著的优点：
●更短的验证时间
●更完全的验证结果
它与静态时序分析工具结合在一起，可以在相
当大的程度上改善数字电路的设计过程。
任何时候对一个电路设计进行了改动之后，都
可以使用Ｆｒａｔ来验证这种改动是否影响或者ｏｌｍｉｙ
的等价性验证中所遇到的一些问题给出一些解决方案，通过正确的使用这些方法减小了设计者在非

Formily讲解_2

的模块名） • 在Set and link the top design中点击Set Top
设置Implementation Design
• 点击Implement按钮，在Read Design Files 中点击Veril og，出现Add verilog files对话框，
• 选择netlist_w_svf目录下的verlog网表文件mR4000.gat es.v
• 选择Set Top Design,在Choose a library中选择WORK ( Design Library)
• 在Choose a design中选择顶层模块名mR4000 • 点击Set Top按钮。此时在Implementation出现绿色的
对号符。
Match
• 检查reference design 和 Implemention des
4
5 6 7
内容
形式化验证简介
形式化验证的优点
Formality同其他的工具的区别 Formality使用范围重要概念 Formality工作流程 Formality操作方法
形式化验证简介
形式化验证方法不需要仿真向量，通过数学方法比较实现与参考是否等价。
Reference Design
module top (…); always @ (posedge clk) . . . endmodule
• 一般调试是从cell数目最小的compare point开始。在这里我们从第一个compare point开始。
• 选择错误点, 击鼠标右键，选择菜单中的view Lo gic Cones，出现Logic Cones View窗口。
• 在这个新窗口里显示的是reference design 和Imeplemention design的原理图，

synopsys_formality指导手册_概述说明

synopsys formality指导手册概述说明1. 引言1.1 概述在硬件设计领域，验证是一个非常重要的环节。

在设计过程中，我们需要确保设计的正确性和可靠性。

为了实现这个目标，Formality工具被广泛应用于电子设计自动化(EDA)过程中的形式验证。

Synopsys Formality是一款强大的形式验证工具，它可以帮助我们验证两个不同层次或版本的设计之间的等效性。

通过使用Formality，我们可以有效地检查逻辑门级网表和原始RTL之间是否存在功能差异或者错误。

本指导手册将介绍Formality工具的基本概念、应用场景以及使用步骤。

你将了解到如何利用Formality进行验证，并掌握其使用方法和技巧。

1.2 文章结构本文将分为以下几个部分：- 引言：对Formality进行概述并介绍文章结构。

- 正文：详细介绍Formality工具及其相关内容。

- Formality基本概念：解释Formality中涉及到的关键概念和术语。

- Formality的应用场景：探讨使用Formality解决哪些问题以及在哪些情况下选择使用该工具。

- 使用Formality进行验证的步骤：分步骤介绍如何使用Formality进行验证。

- 结论：总结本文的主要内容，并指出Formality在硬件验证中的重要性和前景。

1.3 目的本指导手册的目的是为读者提供对于Formality工具的全面理解。

通过阅读本文，读者将能够了解Formality在形式验证中的基本概念、功能和应用场景，从而能够更好地应用该工具来提高硬件设计的准确性和可靠性。

2. 正文Formality是Synopsys公司开发的一款形式验证工具，它旨在为硬件设计工程师提供一种高效且可靠的形式验证解决方案。

Formality通过比较两个逻辑设计的等效性来进行验证，确保电路实现与规范之间不存在功能差异或逻辑错误。

Formality作为一种形式验证工具，在电路设计领域中有着广泛的应用。

Formality使用指南

目录说明 (2)一.验证RTL与GATE网表 (2)（一）图形用户界面进行形式验证 (2)1.设置reference design (3)1.1读取源文件 (3)1.2设置搜索目录 (4)1.3设置搜索目录 (4)1.4加载源文件 (5)1.5设置fifo为reference的顶层 (6)2.设置Implementation Design (7)2.1加载Technology library (7)3.设置环境(Setup) (8)4.Match (8)5.Verify (9)6. Debug (9)7.清理工作 (13)（二）命令行方式进行形式验证 (13)命令行方式运行 (13)二. 验证GATE网表和插入扫描链的GATE网表 (14)1. set referenc design (14)2. set implementation design (15)3. setup (16)设置SCAN链的功能无效 (16)4. match (17)5. verify (18)三. 验证带有扫描链和JTAG链的GA TE网表和插入扫描链的GATE网表 (19)检查fifo_with_scan_jtag.v和fifo_with_scan.v一致性 (19)禁止scan和jtag功能 (20)运行match (21)Verify (21)说明FiFo的Tutorial目录下包含以下几个子目录：Rtl：fifo的RTL源代码；包含fifo.v, gray_counter.v, push_ctrl.v, gray2bin.v, pop_ctrl.v, rs_flop.v。

Lib：门级网表需要的技术库；包含lsi_10k.db。

Gate：综合的门级网表；包含fifo.vg 和fifo_mod.vg。

Gate_with_scan：插入扫描链的门级网表；包含fifo_with_scan.v。

Gate_with_scan_jtag：带有扫描链和JTAG链的门级网表；包含fifo_with_scan_jtag.v。

发言稿上亲爱的和尊敬的用法

发言稿上亲爱的和尊敬的用法英文回答：When to Use "Dear" vs. "Honorable" in a Speech.In a speech, the appropriate use of "dear" and "honorable" depends on the context and the audience you are addressing. Here's a general guideline:Use "Dear"When addressing a group of individuals you know well and have a close relationship with.In informal settings or when you want to establish a warm and friendly tone.To address individuals by their first name (e.g., "Dear John") or their title followed by their first name (e.g., "Dear Professor Smith")。

Use "Honorable"When addressing individuals in positions of high esteem, such as judges, government officials, or religious leaders.In formal settings or when you want to convey respect and formality.To address individuals by their full title or official designation (e.g., "Honorable Judge Jones")。

Synopsys系列软件安装说明

Synopsys系列软件安装说明magellan。

Synopsys软件一共有三个：VCS、formality、安装这是一套验证软件，现在我们说一下它们的安装流程：VWmare1.安装执行可执行文件。

安装无注意事项。

按照步骤安装直到完成。

REDHAT4.22.安装REDHAT 。

加载运行虚拟机，在file选项下选择new下的virtual mashine在左下角虚拟光驱中加载接下来按照提示加载在提示加载其他的光盘时，disc1.这。

加载之后记得connect（安装前提是硬盘空间最小要15G）剩下的光盘镜像，样直到安装完成。

3.安装VMware Tools开始启动系统，然后用安装完系统后，点击start this virtual machine账号登陆，密码就是在安装系统时自己设置的密码。

在上面的工具栏菜单root界面外，不LINUX选择VM\install VMware Tools（目的是鼠标可以直接移动到共享文件windowsLINUX界面的大小,同时也可以实现和再需要Ctrl+Alt;设置拷贝到任何目VMwareTools-6.0.0-45731.tar.gz夹），生成VmWare Tools后将zxvf录下，然后在终端中的该目录下用tar –命令进行解压，然后进入解压后得到的VMwareTools-7.8.4-126130.tar.gz一切选择./ vmware-install.pl进行安装(vmware-tools-distrib的目录，执行默认就行)。

安装目录下的一个另一种方法：如果第一种方法不行，出现错误，就加载VM里面有个文件linux.iso镜像，在系统中打开cd-romhomeTools压缩包。

把它拷贝到VMwareTools-8.1.3-203739.tar.gz就是VMwarexvzfVMwareTools-8.1.3-203739.tar.gz 解压缩文件，文件夹下，然后用tar – ./vmware-install.pl 进行安装。

PrimeTime使用说明(中文)

摘要：
本文介绍了数字集成电路设计中静态时序分析（Static Timing Analysis）和形式验证（Formal Verification）的一般方法和流程。这两项技术提高了时序分析和验证的速度，在一定程度上缩短了数字电路设计的周期。本文使用 Synopsys 公司的 PrimeTime 进行静态时序分析，用 Formality 进行形式验证。由于它们都是基于 Tcl（Tool Command Language）的工具，本文对 Tcl 也作了简单的介绍。
Tcl 与 pt_shell 的使用
6
第三章 Tcl 与 pt_shell 的使用
Tcl 是 Tool Command Language 的缩写，由于 PrimeTime 的命令语言是基于 Tcl 标准的，所以在这一章里我想大致介绍一下 Tcl 在 PrimeTime 中的基本使用。除了一些最常用的 Tcl 命令之外，主要介绍了 pt_shell 中有关对象和属性的操作。
7.2 一些基本概念
7.2.1 Reference Design 和 Implementation Design
7.2.2 container
7.3 读入共享技术库
7.4 设置 Reference Design
7.5 设置 Implementation Design
7.6 保存及恢复所作的设置
7.7 验证
PrimeTime 简介
4
在数字集成电路设计的流程中，版图前、全局布线之后已经版图后，都可以使用 PrimeTime 进行静态时序分析。
§2.2 PrimeTime 进行时序分析的流程使用 PrimeTime 对一个电路设计进行静态时序分析，一般要经过下面的步骤： 1）设置设计环境在可以进行时序分析之前，首先要进行一些必要的设置和准备工作。具体来说包括了： ² 设置查找路径和链接路径 ² 读入设计和库文件 ² 链接顶层设计 ² 对必要的操作条件进行设置，这里包括了线上负载的模型、端口负载、驱动、以及转换时间等 ² 设置基本的时序约束并进行检查 2）指定时序约束 (？？timing assertions/constraints) 包括定义时钟周期、波形、不确定度(uncertainty)、潜伏性(latency)，以及指明输入输出端口的延时等。 3）设置时序例外(？？timing exceptions)：这里包括了： ² 设置多循环路径（multicycle paths） ² 设置虚假路径（false paths） ² 定义最大最小延时、路径的分段(path segmentation)以及无效的 arcs 4）进行时序分析：在作好以上准备工作的基础上，可以对电路进行静态时序分析，生成 constra -int reports 和 path timing reports。以上仅仅是 PrimeTime 进行静态时序分析的简单流程，在本文以下的部份中将会有更详细的叙述。

WIPO Sequence Validator操作手册 (2)

WIPO Sequence Validator –操作手册1.1.0版本文件的目的是支持知识产权局部署WIPO Sequence Validator 微服务，并对Validator的配置提供支持。

目录1.简介 (3)1.1.Validator工作流程概述 (3)1.2.关于Validator文件系统结构的定义 (4)2.部署WIPO Sequence Validator (6)2.1.将Validator作为Spring Boot JAR启动 (6)2.1.1.将Validator作为可执行的应用程序进行部署 (7)2.2.作为WAR Web服务进行部署 (8)2.2.1.验证报告 (8)2.2.2.回调端点请求 (9)2.3.配置 (16)2.3.1.默认设置 (16)2.3.2.本地化消息 (18)2.3.3.自定义生物体名称 (18)2.3.4.引用ST.26 DTD文件 (18)3.Validator REST API (20)3.1.验证WIPO ST.26文件 (20)3.2.请求验证状态 (23)附件一：验证报告示例 (26)附件二：完整的API规范（YAML） (28)附件三：属性名称（JSON） (32)1. 简介WIPO Sequence Validator（下称Validator或工具）的主要目的是为知识产权局提供一项微服务，对WIPO ST.26格式的XML文件进行验证，以确保这类文件符合产权组织标准ST.26。

虽然使用WIPO Sequence桌面应用程序起草的序列表符合WIPO ST.26，但用户可以使用自认为最合适的任何工具。

本文件的目的是解释该工具的构成、部署、设置和文件用户系统，详细内容见以下各节。

1.1. VALIDATOR工作流程概述该工具提供以下四个用例：- 验证WIPO ST.26文件；- 请求正在运行的验证的状态；- 更新配置文件（仅限知识产权局管理员）；以及- 当验证过程完成后，用验证过程的结果调用一个回调端点。

FormalityDKUG

Other Sources of Information
o Synopsys Manuals ♦ Formality User Guide ♦ Formality Reference Manual
(formality_install_dir/doc/fm/*.pdf)
o Toshiba Documentation "User Guide" and "Command Reference" manuals of the following sign-off systems. ♦ PrimeTime Sign-Off System
i
Preface
♦ VSO ♦ VITALSO
Formality Design Kit User gn Kit User Guide
Contents
Contents
Chapter 1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
The Toshiba products listed in this document are intended for usage in general electronics applications (computer, personal equipment, office equipment, measuring equipment, industrial robotics, domestic appliances, etc.). These Toshiba products are neither intended nor warranted for usage in equipment that requires extraordinarily high quality and/or reliability or a malfunction or failure of which may cause loss of human life or bodily injury ("Unintended Usage"). Unintended Usage include atomic energy control instruments, airplane or spaceship instruments, transportation instruments, traffic signal instruments, combustion control instruments, medical instruments, all types of safety devices, etc. Unintended Usage of Toshiba products listed in this document shall be made at the customer’s own risk.

SOC验证——用Formality做形式验证

用Formality 做形式验证1. 什么是形式验证？形式验证是一种系统化方法，用穷举的算法技术证明设计实现满足设计规范的特征。

它覆盖了输入的所有可能序列，不需要开发测试向量，检查所有的边角逻辑，提供了完整的覆盖率。

2. Formality 的验证原理找到reference design 和 implementation design 二者相对应的 compare points, 把相邻两个 compare point之间的组合逻辑电路转化为数学模型，把每一个 compare point 的输入的各种逻辑情况都遍历一遍，比较二者是否一致，即比较每一个 compare point 在输入相同的情况下所得到的值是否相同。

相邻两个 compare point之间是一些组合逻辑电路，Formality 主要就是比较这两个组合逻辑电路的功能是否一致。

compare point: a compare point can be an output port, register, latch, black box input pin, or net driven by multiple drivers.3. Formality 的验证步骤(1) load reference design and implementation design(2) match compare points(3) verify4. 一个通过验证的模块的reportReference design is 'r:/WORK/Dsss_TX'Implementation design is 'i:/WORK/Dsss_TX'Status: Checking designs...Status: Building verification models...Status: Generating datapath components ...Arch Source Instance PathNo multipliers match these criteria.Status: Qualifying datapath components ...Status: Datapath qualification complete.Status: Matching...************************ Matching Results************************ 7 Compare points matched by name199 Compare points matched by signature analysis0 Compare points matched by topology47 Matched primary inputs, black-box outputs6(0) Unmatched reference(implementation) compare points0(0) Unmatched reference(implementation) primary inputs, black-boxoutputs58(0) Unmatched reference(implementation) unread points----------------------------------------------------------------- Unmatched Objects REF IMPL ----------------------------------------------------------------- Registers 6 0 Constant 0 6 0 *****************************************************************16 Unmatched points (6 reference, 0 implementation):Ref DFF0 r:/WORK/Dsss_TX/CCK_11_MOD1/CdataI_reg[0]Ref DFF0 r:/WORK/Dsss_TX/CCK_11_MOD1/CdataQ_reg[0]Ref DFF0 r:/WORK/Dsss_TX/CCK_55_MOD1/CdataI_reg[0]Ref DFF0 r:/WORK/Dsss_TX/CCK_55_MOD1/CdataI_reg[2]Ref DFF0 r:/WORK/Dsss_TX/CCK_55_MOD1/CdataQ_reg[0]Ref DFF0 r:/WORK/Dsss_TX/CCK_55_MOD1/CdataQ_reg[2][BBNet: multiply-driven netBBox: black-boxBBPin: black-box pinBlock: hierarchical blockBlPin: hierarchical block pinCut: cut-pointDFF: non-constant DFF registerDFF0: constant 0 DFF registerDFF1: constant 1 DFF registerDFFX: constant X DFF registerLAT: non-constant latch registerLAT0: constant 0 latch registerLAT1: constant 1 latch registerLATX: constant X latch registerLATCG: clock-gating latch registerLATTR: transparent latch registerLoop: cycle break pointNet: matchable netPort: primary (top-level) portUnd: undriven signal cut-point]1Reference design is 'r:/WORK/Dsss_TX'Implementation design is 'i:/WORK/Dsss_TX'************************ Matching Results ************************ 7 Compare points matched by name199 Compare points matched by signature analysis0 Compare points matched by topology47 Matched primary inputs, black-box outputs6(0) Unmatched reference(implementation) compare points0(0) Unmatched reference(implementation) primary inputs, black-box outputs58(0) Unmatched reference(implementation) unread points-----------------------------------------------------------------Unmatched Objects REF IMPL ----------------------------------------------------------------- Registers 6 0 Constant 0 6 0 ***************************************************************** Status: Verifying...********************** Verification Results ********************* Verification SUCCEEDED----------------------Reference design: r:/WORK/Dsss_TXImplementation design: i:/WORK/Dsss_TX206 Passing compare points-----------------------------------------------------------------Matched Compare Points BBPin Loop BBNet Cut Port DFF LAT TOTAL ----------------------------------------------------------------- Passing (equivalent) 0 0 0 0 7 199 0 206 Failing (not equivalent) 0 0 0 0 0 0 0 0 *****************************************************************1No failing compare points.1可以看到有6个 unmatched reference compare points, 这6个点只在 reference design 中有，在 implementation design 中没有。