( ESNUG 333 Item 7 ) --------------------------------------------- [10/20/99]
Subject: ( ESNUG 330 #8 331 #7 ) Have Cadence Pearl & DC Play Nice Together
> We are now in the process of developing a layout flow that is using Timing
> Driven Q-place placement software from Cadence. Being timing-driven, the
> software reads constraint files produced by, you guessed it -- Synopsys.
> The tool that reads and converts the constraint file is: Pearl (Cadence
> static timing analysis tool). We are receiving Synopsys constraint files
> from various Synopsys versions. Almost each time we use Pearl there are
> statements that are not recognised by the tool, and causes it to produce
> erroneous output. ...
>
> - Eran Rotem
> Chip Express (Israel) Ltd. Haifa, Israel
From: "Ed Martinage" <ejm@cadence.com>
Dear John et al:
I'd like to respond "briefly" to some of the issues raised in regard to
providing/translating Synopsys timing constraints into the Cadence
timing-driven design flow.
o Path constraints that utilize the Design Compiler -through construct
As mentioned by your readers, -through is not yet supported in the
timing-driven flow. Cadence is working to provide compatible support
in the flow for this functionality in an upcoming release.
As far as we know, the semantics of -through are only a compatibility
issue for pre-1998.02 versions of PrimeTime. All versions of Design
Compiler and post-1998.02 versions of PrimeTime all interpret:
-through {a b c} -through {x y z}
to be a path
through "any of {a b c}" and "any of {x y z}"
We do not currently see a need to have compatibility switches to support
pre 1998.02 PrimeTime.
GCF 1.3 is the current constraint version standard for the released flow.
This version of the standard does not provide the required syntax to
support a constraint similar to the one above. When the timing-driven
design flow is rev'ed to support -through pins, GCF 1.4 will be deployed
with a new syntax:
(PATHS
(THRU_ALL
(THRU_ANY a b c)
(THRU_ANY x y z)
)
)
Today, for designs with large amounts of -through pin constraints, Cadence
advocates driving our flow with SDF path constraints ( also a suggestion
by one of your readers).
o Lots of warnings from the translator
The goal of the translator is to provide a GCF construct for a specific
Design Compiler constraint that maintains the exact interpretation of the
original constraint. Warnings are issued if the _exact_ interpretation
cannot be achieved. In practice, many "problem" constraints are due to:
- A hierarchical port reference could not be transformed into a leaf
cell reference(s) that maintained the same semantics as the original
constraint (flat references are a requirement in DEF-based P&R
flows). Upcoming support of -through pins should help remedy the
current corner cases.
- Constraints that are "illegal" and end up Design Compiler's ignored
list must also be ignored by the translator. It just makes a bigger
fuss about it.
As you can imagine, making all these determinations is not a simple
problem and requires a "smart" translator (i.e. Pearl with the "a").
o "I've got my GCF file, but I'm still getting lots of warnings ..."
The Cadence flow automatically runs the equivalent of the Synopsys
check_timing command to alert the user to parts of the design that are
not adequately constrained. In practice, this has been due in large part
to insufficient clocking information in the constraint file.
The handoff of a "clean" constraint file is critical to the success of a
timing-driven backend flow. Use the following to examine the ignored
constraints list and the (timing) unconstrained areas of the design:
Design Compiler: report_timing_requirements -ignored
PrimeTime: report_exceptions -ignored
PrimeTime/Design Compiler: check_timing
There still may be some differences between what Pearl sees vs the Synopsys
tools, but doing some up-front sanity checking on the constraints with any
Static Timing Analysis tool can be a big win.
We are committed to providing a smooth path for Design Compiler constraints
into the Cadence timing-driven flow.
- Ed Martinage
DSM Timing Engineering Group
Cadence Design Systems San Jose, CA
|
|
