( ESNUG 558 Item 11 ) --------------------------------------------- [03/29/16]
Subject: What Real Intent missed in its CDC/SDC/constraints/linting survey
"For SDC timing exceptions and constraints management,
what 'pain points' exist for you?"
constraints checking : ################ (32%)
exception verification : ######### (17%)
constraints creation : ########## (21%)
SDC consistency : ############### (30%)
- Graham Bell of Real Intent, Inc.
http://www.deepchip.com/items/0552-03.html
From: [ Himanshu Bhatnagar of Excellicon ]
Hi, John,
The flaw with this survey is Graham has constraints checking, exceptions,
and creation separated into 3 questions -- which is consistent with the way
most EDA companies may develop tools -- but not how engineers handle the
design and validation of timing constraints. The top three survey items for
constraints are tied together, but the essence of timing constraint issues
are not captured in the Real Intent survey.
THAT CHECKING THING
In fact the top three items are indeed of the same problem and root cause.
From Dean Drako's ESNUG 520 #1 post, in 2013, 68% of new designs were based
on previous versions of an existing design or IP. I'm willing to bet with
the new larger design sizes, that percentage has grown to around 80% in the
past 3 years.
From a timing point of view it means a great majority of IP come with some
kind of timing constraints as a starting point. The issue an engineer faces
is the questionable quality of these inherited legacy constraints file. For
painful experiences, most chip designers don't have very much confidence in
legacy constraints -- especially if integrated into a larger design -- since
these legacy SDC files are often incomplete. Hence a call for "constraints
checking" and "SDC consistency". Engineers do this because nobody knows
how the first SDC's were created.
constraints checking : ################ (32%)
It's been my experience that most engineers use the word "checking" very
loosely. What checking is really is a mix of syntax checks, consistency
checks with respect to hierarchy, equivalence checks, gate-to-RTL EC as well
as RTL-to-gate checks, etc. The marketing departments in EDA companies
will often fragment the word "checking" based on their own tools such as
linting, exception checker, hierarchy propagation scripts, etc. -- and not
mention the types of checking they lack.
For most designers, SDC development is done "after the fact". Once their
chip (or part of the chip) is completed, the designers often attempt to
cobble together a series of inherited SDC files from the old IP mixed in
with some of their own new SDC coding -- to come up with final overall
timing constraints of the design. In most cases this results in SDC's
that are missing and incomplete. Our engineer then must manipulate 100's
of files manually while at the same time he is forced into propagating
timing constraints file-by-file by hand -- which then in turn requires a
massive amount of checking and validation.
BAD INGREDIENTS MAKE BAD SOUP
What Graham glossed over in his survey with just a throw away mention was:
constraints creation : ########## (21%)
When and how constraints creation is done is the root problem of bad SDC's.
It's because the SDC's were not created during the RTL stage; and in context
of the chip right from the design start. Trying to clean up a hodgepodge of
SDC's -- some good, some sketchy -- at the end of your design cycle is
asking for trouble. Instead, if the design team carefully checked the SDC's
of each IP before they used it, and the SDC's on each design block while
they were writing the RTL for each block -- the chances go way up (90%) that
their final overall SDC timing constraints file will be golden. A slow
methodical test-each-part one-by-one approach may be tedious, but it works.
Trying to find and fix massive amounts of dodgy timing constraints 2 weeks
before tapeout is not a way to live. Constraint checking & SDC consistancy
testing are meant to catch minor forgotten errors. They're not meant for
doing major last minute SDC brain surgery to save your chip.
If you start with bad ingredients, you're going to make a bad soup.
HANDLING EXCEPTIONS
Finally the Exceptions, the lowest item on the survey responses on Graham's
constraints questionnaire that surprised Graham:
exception verification : ######### (17%)
"We were a little surprised at the low number for 'exception
verification'. Customers have told us incorrect exceptions
have caused them costly respins".
- Graham Bell of Real Intent (10/08/15)
Again, engineers use the term "exceptions" loosely. Graham was correct in
his comment about costly respins, but he needs to dig a little deeper.
About 70%-80% of exceptions in a design are of the "Timing Intent" flavor.
But tools today can only verify the structural exceptions or, 20%-30% of
a chip's exceptions. This leaves the backend PnR engineer stuck doing
manual analysis of "Timing Intent" while the design intent knowledge lies
with the front-end engineer (and is usually not captured early on.) The PnR
engineers often end up with defining 90%+ of the exceptions by hand.
Most engineers aren't very impressed by the current generation of CDC tools
because they only look at structural clock exceptions -- a very narrow part
of the timing exception validation problem. (My company, Excellicon, has a
tool, "ET", that handles timing exception checking in a general way, but I
don't want to turn this into a product pitch.)
---- ---- ---- ---- ---- ---- ----
SDC CONSTRAINTS SYNTHESIS IS A COMING!
Another reason for the low 17% response on exceptions is it's encompassing
the entire space; compared to a few years ago when the exceptions were the
main headache.
I believe we are getting to a point we need for "SDC Constraints Synthesis",
because the complexity is mushrooming out of control. I think SDC design
is where logic synthesis was about 25 years ago on the functional side;
which led to much more complex designs as opposed laying gates down by hand.
The time for manual constraints development is ending. Some kind of SDC
synthesis is becoming a necessity to capture design intent and to generate
correct-by-construction timing constraints right from the RTL code at very
early design stages.
Because engineers have to validate each step after power optimization, DFT,
CDC, FPGA, STA, PnR, etc. -- I believe a correctly created SDC early in the
design cycle will be the defacto standard to give the necessary seed info for
these downstream tests.
For example, to perform vectorless power analysis, engineers need info about
appropriate timing windows. This info is readily available in correct and
complete SDC files. The problem is that the SDCs usually come too late in
the design flow.
Another example is setup for CDC. The engineer needs clock definitions,
clock groups, synchronous relationships, or even mode info about the design;
which is again all available in well made SDC files. In fact if SDC is done
right (and early) it lets you automatically create high quality setup files
many other downstream tasks and tools.
---- ---- ---- ---- ---- ---- ----
CDC & LINTING
Since Graham had deeper data on the CDC problem, I want to take this topic
a bit further.
"What issues have you encountered with your current
CDC or Lint tool?"
tool performance : #################### (40%)
noisy reports : ######## (15%)
capacity : ########## (19%)
waivers : ############# (26%)
What is interesting is when the results on noisy reports; 15%, and waivers;
26%, are combined for total of 41%, which is practically the same percentage
on linter/CDC tool performance, 40%.
The interplay between these 3 factors is tricky. For example, the tool can
very quickly identify many CDC issues, but a dangerously painful CDC issue
may be completely lost in the noise of the report between 100's and 1,000's
of CDC/linting warnings not noticed by the designer.
Unfortunately noise is inherent to any CDC or linting tool. The reason is
not because of the tool has problem, but fact that data generated by the
analysis today is only as good as data fed to it. Garbage in garbage out.
As a result almost all CDC tools have a strong focus on manual setup and
setup checks to ensure good quality setup prior to running CDC analysis.
Often the setup process takes a 1-2 weeks or more as the designer input;
which is scattered all over the place, is needed to properly configure a
CDC tool. A poor setup then results in poor tool performance, which 1/2
of the survey respondents complained about.
A high quality SDC available early enough in the design flow in context to
actual RTL design can automate and fix these setup process headaches; and
also enable full hierarchical and multimode analysis.
The CDC and SDC are tightly coupled. CDC deals with functional issues with
respect to clocks and the correctness of data between registers. SDC deals
timing issues as part of implementation. However when performing clock
analysis there is little connection between the functional and the timing
side of chip -- resulting in a repetition of tasks and gaps in knowledge
transfer. Automation through SDC can solve this issue and save everyone
a great deal of time.
---- ---- ---- ---- ---- ---- ----
WAIVERS ARE DANGEROUS!
One observation that I liked that Graham went into was waivers.
"What is surprising is the Waivers response. Waivers are a
dangerous design method in sign-off since they disable the
rules and good practices based on the designer's knowledge
or intuition (right or wrong) that the circuit in question
is good. Unfortunately it is easy to get bitten by special
cases and exceptions."
- Graham Bell of Real Intent (10/08/15)
Waivers are nothing more than a crutch for an engineer compensating for poor
overall CDC tool analysis performance. To eliminate waivers, the noise has
to significantly drop. For noise to drop, the setup has be done perfectly.
For a perfect setup -- the human factor has to go. The clocking and mode
data has to be automatically extracted from the design itself; which is all
available in a auto generated SDC file extracted from RTL.
Again, automation through SDC generation as the seed input for CDC analysis
will lead into more comprehensive CDC analysis by extracting setup for any
mode and any layer of hierarchy in minutes as opposed to days.
---- ---- ---- ---- ---- ---- ----
IT'S COMING
Imagine a design with 2 layers of hierarchy, with 2 modes, and 10 process
corners. This lead to over 45 constraints which a designer has to write,
verify, and manage -- not even counting for number of IPs at each hierarchy.
The amount of data an engineer has to decipher through and analyze before
sign-off is a nightmare. So SDC management, and SDC generation/validation
automation (or "SDC synthesis") is becoming a "must have" in the not too
distant future.
- Himanshu Bhatnagar
Excellicon Laguna Hills, CA
---- ---- ---- ---- ---- ---- ----
Related Articles
User benchmarks Fishtail, Ausdia, Atrenta, Excellicon, Blue Pearl
Atrenta frustrated by user's flawed eval of 7 constraints tools
Real Intent DAC'15 survey on CDC bugs, X propagation, constraints
Join
Index
Next->Item
|
|
