( ESNUG 567 Item 4 ) -------------------------------------------- [03/01/17]

Subject: A user details 5 major differences between Fishtail and Excellicon

    - User benchmarks Fishtail, Ausdia, Atrenta, and Excellicon

From: [ The Bourne Identity ]

Hi, John,

Please keep me and my company anonymous for fear of backlash.

I liked the way this author made a distinction between "SDC Linters" and
"SDC Analyzers".  It is so true.  The fact that we don't always rely on
SDC correctness and use additional tools and custom in-house scripts for
design data mining, is a proof that linting by itself is not sufficient.

For example, finding all half-cycle paths in the design, or snake paths,
or derating effects on paths etc. are independent of SDC -- but still
could cause major headaches when closing timing. 

Anyway, since original author compared 7 vendors, he omitted many additional
technical details on his final choices. 

We focused our final eval only between Fishtail and Excellicon, and compared
all features between them.  The two are close, but we choose Excellicon over
Fishtail because of these five specific differences.


FIRST, SOME BACKGROUND

I work in a design services company based in Asia and we go through a few
dozen full chip tapeouts a year.  With any design services company, the user
constraints are always a big issue where we spend majority of our time
passing the SDC back and forth between the customers and ourselves. 

Before we adopted Excellicon tools to generate constraints (for customers
who want to use us for RTL-to-GDS2), we used to code our SDC's for all modes
by hand.  We would use PrimeTime to qualify the correctness of constraints.
This method had many problems:

  1. This was an iterative process and often the main cause for project
     delays.  The extended turn-around time between the customer and
     ourselves was very painful.

  2. We had to use expensive PrimeTime licenses to validate the correctness
     of our SDC's.  Obviously not a best scenario.

  3. Manually coding SDC's for many MCMM modes was getting impractical.
     Most of our designs have several hierarchical physically partitioned
     blocks.  Writing SDC's for each block and the top level for all modes
     was error prone and required man-months to clean up the constraints.

  4. Often the customer would change the design parameters, which impacted
     the SDC.  For example, if the clock frequency changed it meant editing
     all the SDC's. Thus SDC management also became a burden.

We had no option but to start looking for SDC tools to solve this problem.
Due to resource limitation we decided ahead of time to only evaluate the
two topmost EDA vendors in this space.

Most of our customers give us gate netlists that have been checked by
Atrenta's Spyglass-Constraints tool -- yet the quality of SDC we receive
from it is rarely good.  Also based on my past experience at another
company, Spyglass-Constraints is very noisy even with the use of GuideWare,
which is nothing but a collection of rules.  (See ESNUG 538 #3.) 
So we decided to choose alternate SDC tools. 

We decided to try Excellicon because of the article someone had published
in DeepChip in March 2011.  (ESNUG 488 #1)  The second SDC vendor we chose
was Fishtail because it is well known in the industry for its exception
generation capability and we know some companies who are using it. 


FIRST DIFFERENCE -- Handling Multi-Mode Constraints

The author of the orginal banchmark that compared 7 companies failed to
mention the main difference in SDC generation between the two companies.
Fishtail does not generate multi-mode constraints while Excellicon does.
Here is why:

Above if there are two clocks merging to a MUX, Fishtail will identify both
clocks and propagate both of them by creating the generated versions of the
primary clocks.  In contrast, Excellicon has 4 options:

  1. Single clock to be propagated, while blocking all others
  2. Selected multiple clocks to propagate, while blocking all others
  3. Fastest clock to propagate, while blocking all others
  4. All clocks to be propagated, no blocking of others

When more than one clock propagates, similar to Fishtail, Excellicon also
introduces additional generated clocks at the output of a combo cell.

Fishtail's method works, but only valid for optimization engines such as for
RTL synthesis, or P&R.  Mode-based SDC's are critical to today's SoC's where
a chip needs timing for many modes and corners.  At minimum the 2 modes are:
"standard functional" and "test".

The single mode SDC's are very important because they are used for Primetime
sign-off.  Without single mode SDC, the STA result will always be more
pessimistic due to SI effects incurred between the 2 clocks before the MUX.
Single mode SDC is also used for writing out SDF for gate-level sims, or for
vectorless power analysis, etc.

Both SDC tools can merge multiple modes and write out a single merged mode
SDC.  At first, the Excellicon merged mode SDC was not as comprehensive as
Fishtail's, but after working with them, it now matches that of Fishtail's.
In addition, Excellicon's merged mode SDC now provides *selective* merging
capability that cannot be done with Fishtail.


SECOND DIFFERENCE -- Handling Clocking Logic Clouds

This is one the most critical shortcoming of Fishtail.  Fishtail works at
the individual clock cells as opposed to Excellicon working at the whole
combinational cloud in the clock network.  Both tools build a formal
representation of the control inputs that influence the clock propagation;
however because Fishtail can only do one cell at a time, its usefulness is
limited.  On simple clock network, you will get meaningful information,
however I have never seen simple clock network.  Our clock networks comprise
of all sorts of MUXing, with AOI cells, gating logic, etc. and going through
each cell one at a time to find out the select value to be set is very
timing consuming.  We might as well fire up Verdi and use that.

Above, Fishtail reports all possible values for "ctrl1" for a given value on
the select pin of the first MUX.  Then you have to go to the second MUX and
do the same to find out all possible values of "ctrl2".  These values are
shown in a big truth table with values assigned to variables that represent
the start-points signals.  Thus for each cell, you will end up with a big
truth table listing all possible values.

As you can imagine, this method is very time consuming & not very intuitive.

Secondly, a bigger problem exists with this method.  It's unusable because
the two MUXes should not be treated as individual components.  The clock
propagation is dependent on combined value of "ctrl1" and "ctrl2".  In
isolation, you may end up with a value that may propagate a clock through
the first MUX, but blocks it at downstream MUX.

In contrast, Excellicon builds a formal representation of the whole combo
logic cloud on the clock network.  The Excellicon folks calls this their
"Mode Synthesis" where it considers all the logic elements in your clock
network and builds a formal representation of the whole cloud.

It then synthesizes the "ctrl1" and "ctrl2" values simultaneously based on
the clock(s) specified.  Mode Synthesis works across the logic hierarchy.
You can choose a single clock or multiple clocks to propagate.  You can
even block any clock(s) you want.  Furthermore, you can even choose the
polarity of the clock to propagate through the combo logic cloud.  The
case analysis values are automatically synthesized and are applied on all
of the start-points which could be input ports or output pin of registers.

Excellicon's approach is much more practical because it targets the clock
propagation over control signals.  After all, in order to create a mode,
say functional mode, we choose functional clocks to propagate and not the
test clocks and for the test mode we do the opposite.  Thus, our goal is
to propagate desired clock(s) and not to plough through logic in order
to determine the case_analysis values.

Also, their Mode Synthesis is not just limited to clock networks.  We also
use it deriving the case analysis values for configuration registers that
are controlling the Memory BIST. 


THIRD DIFFERENCE -- Handling Structural and Timing Intent Exceptions

There are two types of exceptions: Structural and Timing Intent ones

  1. Structural timing exceptions are design structure dependent.

     For example, a path from startpoint to endpoint that cannot
     be stimulated no matter what.  Thus it is a false path (FP).

     Or there's a structural timing exception when a reg1/CP to
     reg2/D path is a multi-cycle path (MCP) because the left
     side input control signals are holding the data for more
     than 1 clock cycle. 

  2. Timing Intent exceptions are generaly not design structure
     dependent.

     For example, I want to declare a path as false if it's
     starting from a RESET input pin to all RST pin of all
     registers -- it's an exception because I don't want to see
     it in my STA timing report.

     Or, I want to put an MCP exception of 2 on a path for timing
     relaxation purposes because I know that my design behaves
     this way.  (That is, it has a known CDC issue between regA
     and regB1 because they're on different clk_a & clk_b clocks.)

     And another Timing Intent exception occures on configuration
     register banks.  Yes, they *can* change values; but the truth
     is for 99.9999999999% of the chip's life, they won't change
     values once set.

     All these types of Timing Intent exceptions are, of course,
     failed by any formal engine analysis.

Both of these SDC tools, Fishtail and Excellicon, can formally verify the
structural exceptions for FP and MCP reasons.  However, Excellicon has also
added a Timing-Intent-based exception qualification.

On structural exceptions, Fishtail's formal engine output report shows the
failure in terms of equations with variables corresponding to the nets as
terms of the equation.  On the other hand Excellicon shows the stimuli
pointing to why for example an MCP is 3 cycles instead of 2, or why a
specific path is false. 

From the reporting perspective, we prefer Excellicon's approach as it's
easier to understand the stimuli values affecting the path rather than
understand huge equations.  After all, the simulation that we do is all
stimuli based anyway.  Equations, although good for automated verification,
are not intuitive for humans to follow.

In our customers' SDCs, true structural exceptions are are -- 99% percent of
their exceptions are the "timing intent" type -- but it's still nice to see
a comprehensive exception verification that can be performed in one shot.


FOURTH DIFFERENCE -- Handling SVA Assertions

One of the biggest differences we saw between the two SDC tools is how the
System Verilog Assertions, or SVA's are generated by both vendors.  The
purpose of the SVA's is to independently verify your SDC formal engine's
results using a 3rd party simulation tool (like VCS/Questa/Incisive).

Here, Fishtail uses a very bad approach.  The same equations that are used
to formally verify the exceptions in Fishtail are simply translated to SVA
format.  Thus, if Fishtails's formal passes an exception, the corresponding
SVA will always pass.  No checking is going on!  The whole purpose of SVA is
to *independently* verify your SDC tool's formal engine results -- but with
this approach, Fishtail is not verifying anything.

In contrast, Excellicon SVA's do not use the equations that are based on the
control signals, but rather their SVA's use the data values instead.  Thus,
their SVA's are decoupled from Excellicon's formal engine.  A true check.


FIFTH DIFFERENCE -- Doing Equivalence Checking

Both vendors can do equivalence checking.  However Fishtail requires two
tools: Confirm and Refocus, whereas Excellicon only one: ConCert. 

Using the Fishtail "Confirm" tool, you generate signatures for both the
constraints to be analyzed and then use Fishtail "Refocus" to compare
the differences.

Nobody cares about 1 tool vs. 2 tools until you look at runtime.

For runtime, Excellicon did 3X faster here.  On a 50M instances design,
Excellicon ConCert finished the equivalence checking in 16 minutes total,
versus Fishtail Confirm + Refocus took 46 minutes.  (Note: we did not do
a thorough evaluation on the QOR of Fishtail's EC results so cannot comment
on it.  We just ran Excellicon ConCert and since it correctly pin pointed
the equivalences in a very short time we did not bother closely looking at
the final Fishtail EC result.)


CONCLUSION

The original SDC tool benchmark author already touched upon all the other
tool features so I am not going to repeat it here.  I wanted to emphasize
on Excellicon's GUI that the original author mentioned.  It is unique and
a key component that we use for design analysis and debug.  It has some
cool features that we use for what-if-analysis, clock propagation analysis,
mode discovery, understanding unknown IP's, clocking structure, etc.  I
wanted to show pictures of it and give full explanation but decided against
it as it would give my company identity away.  

We obviously went with Excellicon.

    - [ The Bourne Identity ]

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

Related Articles

    User benchmarks Fishtail, Ausdia, Atrenta, Excellicon, Blue Pearl
    Atrenta frustrated by user's flawed eval of 7 constraints tools
    One user's first eval of Excellicon's ConMan constraints manager

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)