Home > Community > Forums > Logic Design > LEC report additional FF

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

 LEC report additional FF 

Last post Fri, Aug 17 2012 2:43 PM by affaqq. 7 replies.
Started by theodoredj 01 Mar 2012 07:33 PM. Topic has 7 replies and 4433 views
Page 1 of 1 (8 items)
Sort Posts:
  • Thu, Mar 1 2012 7:33 PM

    • theodoredj
    • Not Ranked
    • Joined on Fri, Mar 2 2012
    • Posts 4
    • Points 80
    LEC report additional FF Reply
    We have a huge design with many redundant FFs.
    It's impossible to clean up the RTL as they are coming from many different IP vendors.

    Synopsys DC optimized out all those redundant FFs as their outputs go to nowhere. However,
    LEC doesn't see this and failed on RTL VS Netlist check.

    We tried to turn on and off many flatten mode options, as -seq_constant, -gated_clock, -seq_redundant, -LIB_SEQ_Redundant etc.
    Nothing works.

    LEC passed when we set some options in DC to keep those redundant FFs.
    But we really don't want to keep them.

    Any suggestions? Thank you!
    Filed under:
    • Post Points: 35
  • Thu, Mar 1 2012 8:46 PM

    • croy
    • Top 500 Contributor
    • Joined on Fri, Jul 11 2008
    • <?xml version="1.0" encoding="utf-16"?> <string>HOME, PA</string>
    • Posts 32
    • Points 385
    Re: LEC report additional FF Reply

     Hi

     

    Did you try 'analyze setup'/'set analyze option -auto'?

     

    Chrystian

    • Post Points: 20
  • Wed, Aug 15 2012 9:22 PM

    • theodoredj
    • Not Ranked
    • Joined on Fri, Mar 2 2012
    • Posts 4
    • Points 80
    RE: LEC report additional FF Reply
    Hi Chrystian,

    Thanks for your reply in your previous email, it solved the problem I reported.

    However, the same issue comes out again in my current project.

    First of all, please let me refresh the issue:

    Basically there’re redundant FFs in the design, DC was able to optimize them out but LEC can’t.

    These redundant FFs cause un-equivalent for other compare points.

    I think because fan in cone of the compared point is too huge, LEC just give up at the first test vectors and claim un-equivalent because inputs are different.

    Here’s the register definition in RTL code:

    ================================

       reg [7:0] ec_dma_cpu_reg [511:0];

    ================================

    Here’s DC log: As you can see, some bits are optimized out as early as when DC reads in the RTL.

    ===============================================================================================================

    |                    Register Name                    |   Type    | Width | Bus | MB | AR | AS | SR | SS | ST |

    ===============================================================================================================

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   7   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   7   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   7   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   7   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   6   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   7   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   4   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   7   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   8   |  Y  | N  | Y  | N  | N  | N  | N  |

    |                 ec_dma_cpu_reg_reg                  | Flip-flop |   4   |  Y  | N  | Y  | N  | N  | N  | N  |

    ……………………………….

    ……………………………….

    ……………………………….

    ……………………………….


    Here’s the LEC unmapped point report:

    =======================================================

    Unmapped point (not-mapped):

      (G)   58700      Z    /u_ec_dma_cpu_reg/ec_dma_cpu_reg[77][7]

    Unmapped point (not-mapped):

      (G)   58701      Z    /u_ec_dma_cpu_reg/ec_dma_cpu_reg[77][6]

    Unmapped point (not-mapped):

      (G)   58702      Z    /u_ec_dma_cpu_reg/ec_dma_cpu_reg[77][5]

    Unmapped point (not-mapped):

      (G)   58703      Z    /u_ec_dma_cpu_reg/ec_dma_cpu_reg[77][4]

    =======================================================

     
    Here’s the diagnose report:

    // Command: diagnose 1318 -golden // gate XO_CPU_HRDATA[31]

    Diagnosis for Non-equivalent key points:

      (G) + 1318       PO   /XO_CPU_HRDATA[31]

      (R) + 1318       PO   /XO_CPU_HRDATA[31]

    There is an extra but mapped key point in this logic cone

    ================================================================================

              ID        Type                Name

    --------------------------------------------------------------------------------

       (G) + 1657      'DFF'               /u_ec_dma_cpu_reg/r_queue_read_ptr_reg[4]

    ================================================================================

     

    There is an extra unmapped key point in this logic cone

    ================================================================================

              ID        Type                Name

    --------------------------------------------------------------------------------

       (G)   58700     'Z':'NET'           /u_ec_dma_cpu_reg/ec_dma_cpu_reg[77][7]

    ================================================================================

     
    Non-equivalent signal and its error candidates

    ================================================================================

         ID (R)       Type            Likelihood  Name

    --------------------------------------------------------------------------------

         1318         'PO'                        /XO_CPU_HRDATA[31]

    ------- Candidates -------------------------------------------------------------

    1:   259049       szd_sbufx20     1.00        /u_ec_dma_cpu_reg/U43505

    2:   259052       szd_sbufx14     1.00        /u_ec_dma_cpu_reg/U28294

    3:   259053       szd_sivx8       1.00        /u_ec_dma_cpu_reg/U28249

    4:   259056       szd_sbufx14     1.00        /u_ec_dma_cpu_reg/U28298

    5:   259057       szd_snr3x16     1.00        /u_ec_dma_cpu_reg/U42294

    6:   259059       szd_sbufx20     1.00        /u_ec_dma_cpu_reg/U43440

    7:   259060       szd_sbufx20     1.00        /u_ec_dma_cpu_reg/U43259

    8:   259061       szd_sbufx4      1.00        /u_ec_dma_cpu_reg/U15466

    9:   259070       szd_sivx6       1.00        /u_ec_dma_cpu_reg/U34475

    10:  259071       szd_sbufx10     1.00        /u_ec_dma_cpu_reg/U34472

    ================================================================================

     
    Here’re the options I used in my script:

    ================================================================================

    set flatten model -nodff_to_dlat_zero

    set flatten model -nodff_to_dlat_feedback

    set flatten model -seq_constant

    set flatten model -gated_clock

    set flatten model -NOLATCH_Fold

    set flatten model -LATCH_Transparent

    set mapping method -name first

    set analyze option -auto

    set wire resolution wire -both

    add ignore rtlcheck -all

    ================================================================================


    Any suggestions?

    Thank you.

     
    Regards,

    Jun Dong
    • Post Points: 20
  • Wed, Aug 15 2012 10:12 PM

    • AyCaramba
    • Not Ranked
    • Joined on Thu, Mar 29 2012
    • Posts 1
    • Points 20
    Re: RE: LEC report additional FF Reply

    You have type 'Z' as an unmapped in the golden. By default that's how LEC treats undriven signals. DC would ground them. Are you using 'set undriven signal 0 -golden' so LEC matches DC?

     

    • Post Points: 20
  • Thu, Aug 16 2012 11:32 AM

    • theodoredj
    • Not Ranked
    • Joined on Fri, Mar 2 2012
    • Posts 4
    • Points 80
    RE: RE: LEC report additional FF Reply
    Hi,

    It works, thank you.

    Regards,

    Jun Dong
    • Post Points: 20
  • Thu, Aug 16 2012 11:52 AM

    • tstark
    • Top 200 Contributor
    • Joined on Mon, Jul 28 2008
    • San Jose, CA
    • Posts 40
    • Points 455
    LEC report additional FF Reply

    Glad to read that your design is now EQ. 

    Please note that

    'set undriven signal 0 -golden' 

    is a global constraint and can change the design behavior from RTL simulations. If the RTL has undriven signals, ideally they are fixed in the RTL to be driven. If that is not possible, it is safer to drive specific signals rather than globally forcing them.

    If driving unconnected signals is temporarily needed for an unfinished design then echo statements in the dofile can help warning the user that temporary constraints have been added. 

    There is a nice Solution article on this 

    http://support.cadence.com/wps/mypoc/cos?uri=deeplinkmin:ViewSolution;solutionNumber=11345198

     It makes for an interesting read.

     

    -ps 

    • Post Points: 20
  • Fri, Aug 17 2012 2:41 PM

    • theodoredj
    • Not Ranked
    • Joined on Fri, Mar 2 2012
    • Posts 4
    • Points 80
    RE: LEC report additional FF Reply
    Hi,

    This is a very interesting article, thank you very much!

    I do have a question regarding the undriven signal definition.

    I noticed that some unused ports on hierarchy module are also defined as undriven signal because they are defined as output ports.

    Is there anyway to filter them out?

    Thank you.

    Regards,
    Jun Dong
    • Post Points: 5
  • Fri, Aug 17 2012 2:43 PM

    • affaqq
    • Not Ranked
    • Joined on Mon, Apr 2 2012
    • Torino, Turin
    • Posts 13
    • Points 110
    Re: RE: LEC report additional FF Reply
    I am on vacations so might not be able to respond timely. I will get back to work from 2nd Sept, 2012.


    Ciao!

    Affaq Qamar
    Mob:+3280294862
    • Post Points: 5
Page 1 of 1 (8 items)
Sort Posts:
Started by theodoredj at 01 Mar 2012 07:33 PM. Topic has 7 replies.