( ESNUG 450 Item 3 ) --------------------------------------------- [01/25/06]
From: Gzim Derti <derti=usr domain=agere hot mom>
Subject: User resents Secret Ambush Changes in how DC Fundamentally Works
Hi John,
Consider this note an additional pet peeve about something that happens w/
DC from time-to-time... and also a discussion about something that HAS
changed in DC 2005.09XG.
My pet peeve is when Synopsys R&D, in their infinite wisdom, makes a change
to the way the DC works from one version to another, but don't really think
that the change will be noticed by the user population at large. Or more
correctly Synopsys R&D thinks the change won't EFFECT the user population
at large, they make the change, and we're left to figure out what's going
on when things aren't working the way we're used to...
It's the old, "it USED to work this way. Am I nuts? What's going on?" idea.
You sit for a couple of days wondering what you possibly changed in your
scripts that could be causing problems. Then finally you figure out that DC
has just decided to up and work in a different way than it used to!
The reason that I was reminded of this issue is that the way that DC 2005.09
works w/ critical_range has changed, and in particular will effect people
with more than a single clock in their design... Gee, couldn't be that many
people could it???
It used to be that after you'd create your clocks:
create_clock clk -period 10
create_clock clk_d2 -period 20
and then did a
set_critical_range 0.5 # or to whatever value you deem necessary
DC would merrily go along and fix the timing on as many paths as it could
that were within your "critical range" setting regardless of the domain on
which they existed.
Using the latest version (2005.09) it seems that if you have a domain in
your design that has a path that can't meet timing, ALL other domains and
paths are now NOT worked on. You can end up with scads of failing paths,
in a design that when using the previous version of DC, compiled quite
happily...
The best way I've found, in my limited time for testing right now, to get
around this problem is to force the tool to split up the clocks into
different "path groups". The easiest way to achieve this is to change the
above create_clock commands to:
create_clock clk -period 10 -name clk
create_clock clk_d2 -period 20 -name clk_d2
Or to manually get in there and perform "group_path" commands if you want
to write them as per-the-latest-guides as the 4 major path groups:
inputs to flops
flops to flops
flops to outputs
inputs to outputs
And if you've got inputs that can be associated between multiple clock
domains, you're in for a whole lot of fun. (Not to mention the issues
that might crop up if some of your inputs can be captured on the rising OR
falling clock edge -- but that discussion is for another time.)
When you do the "path group" defines, implicitly or explicitly, DC now
seems to handle and work on the domains separately and will try to
follow your critical_range settings without stopping due to a path in
a group that can't be fixed as is.
Anyway, like I said, I just wanted to add my 2 cents to that wonderful
practice of "if we think we can make it better, let's change how it works
under-the-hood" that Synopsys R&D blesses us with from time to time.
- Gzim Derti
Agere Systems Allentown, PA
Index
Next->Item
|
|
