( ESNUG 488 Item 1 ) -------------------------------------------- [03/01/11]
From: [ Enter the Dragon ]
Subject: One user's first eval of Excellicon's ConMan constraints manager
Hi, John,
Please make me and my company anonymous.
I work for a chip company based in California and wanted to give feedback
on a tool that we are evaluating -- Excellicon ConMan -- which stands for
"Constraints Manager".
Background:
Our chips are big with hundreds of primary and generated clocks, several
levels of physical hierarchy with at least 7 different modes of operation.
Currently we are using the 45 nm process.
Our synthesis methodology is bottom up; we close timing on each block, move
up the next level of hierarchy with the block that is closed represented as
an ETM model. Final STA sign-off is done full flat. We suffer from having
to develop and maintain lots and lots of SDC files. Some of them targeting
the P&R tools where we use merged-mode constraints in order to reduce
run-times, while others are used for STA sign-off. Coupling this with
multi-corners, the number of SDC files just explode. Managing them for
consistency and accuracy is a huge problem.
We have a lot of legacy designs that we re-use all the time. Despite this,
we have been suffering from constraints issues enormously, because even
with re-use of IP's, the connectivity of the blocks can change and the
clocking structure is also invariably modified. We also had a few chips
that actually failed because the constraints used were not correct.
Interface timing is always problematic with some guys in our team copying
constraints from previous projects without even eye-balling it. In one
instance, we accidentally tapedout a chip with wrong options set on the
set_multicycle_path command set between two synchronous clocks. The end
result was that the hold time value was unknowingly shifted and we ended
up taping out the chip with half cycle margin (instead of timing the same
edge). Luckily, the chip worked somewhat. Few years back, while working
on a smaller chip where heavy pin MUXing was done between GMII, RGMII,
SGMII, SMII modes, we missed one mode completely. The chip in this case
had timing issues and we had to do a full turn to fix it.
Our tapeout date is almost always affected because of the time spent in
cleaning up the constraints with heavy interactions going between
front-end and back-end teams. To quantify the timing closure time, I would
say, that we spend about:
- 20% of our time on coming up with initial set of constraints that
we use for Design Compiler;
- Another 70% on cleaning up the constraints through PrimeTime/P&R tool
iterations, where we make sure that the correct clocks are propagated
for each mode of the design and paths are timed/optimized correctly;
- The last 10% is simply adding the point-to-point datapath exceptions
for the paths that are not meeting timing.
Our philosophy is to minimize the usage of set_multicycle_path and
set_false_path commands on datapaths as much as possible, so we only use
them sparingly and that too for the timing critical paths (if indeed they
are MCP's or FP's). We essentially wanted to reduce the first 90% of time.
We found out that that here are three kinds of constraints related tools
available in the market today:
1. Constraints Generation -- Most tools (Fishtail, Atrenta, Blue Pearl,
etc.) claim to have this capability, but not so. They will generate
template SDC and user has to fill in the rest. Also, the templates
are not mode based. The constraints management piece is missing, too.
We discarded these tools immediately.
2. Constraints Validation -- Pretty much all tools (Atrenta is all over
the place on this, Fishtail also does this, Synopsys GCA, Blue Pearl,
Cadence?) targeting this space are doing SDC validation. This is good,
however, it's an additional burden to designers in terms of learning
yet another tool. These tools suffer from generating large amount of
noise which user has to filter through. Most people verify their SDC's
using PrimeTime anyway, therefore we don't see the value of using yet
another tool to verify structure of their SDC (except maybe with the
Synopsys GCA which is PrimeTime based - no learning required here).
We evaluated some of these tools but ended up not buying them.
3. Exception Generation -- (Fishtail is the leader, Atrenta, Blue Pearl).
This was first started by Fishtail and now others have jumped on the
band wagon. Exceptions although useful are the least of our problems.
We only need or use exceptions for those paths that are not meeting
timing. If a path meets timing, then why do we care? I'd rather be
safe than to take a risk of applying tool-generated exceptions to my
design. Verifying these exceptions is also a nightmare. On top of
this, all these companies claim QoR improvement. In 65 nm and below,
how much die size area is saved because 10,000 exceptions were used?
In terms of timing QoR exceptions maybe useful, however back-end tools
run time is impacted severely. Not worth it.
Then comes ConMan. It seems that Excellicon is just starting out and their
sales guy approached our CAD dept. Their website claims all the good things
and of course we did not believe it. We had them give a demo. They said
the tool reads in RTL/Gates and delivers a "correct by construction" SDC
file for any level of hierarchy of the design and for any mode. It supports
automated multi-mode clock definitions, merge mode definitions and SDC
validation capabilities, including SDC equivalence, if needed.
ConMan also claims it can align the frontend simulation environment to the
constraints generation. They call it "Design Intent Capturing". In the
past we have made mistakes whereby our frontend group is simulating a design
with one set of timing parameters and the backend group is using a different
one. The only place you can catch this is at the gate level simulations
stage (which sometimes we don't do).
All good things, but we wanted proof.
Evaluation Results:
For our eval, we selected a medium size design (approx 750 K placeable
instances) comprising of several levels of hierarchy. This design we had
taped out in 65 nm TSMC process previously, thus had all timing information
available. We loaded only the RTL at first, along with .lib's for macro's
such as PLL and memories.
ConMan parsed the design in less than 5 minutes and displayed all the clocks
and modes in a nice table.
Based on this information, we quickly identified all the mode pins of the
design and the tool moved these pins to another table. We then created
3 modes, Functional, Bootup and Test and entered the value of each pin
before running extraction. BTW, although we did this at the top level,
the tool can identify modes at any level of hierarchy and propagates the
pin(s) to the top. For example, in our case, we have the test signal
(scan_mode) generated through a specific combination of 3 values set on the
input pads. Upon selecting the scan_mode pin at a lower level of hierarchy,
the tool puts all 3 input pads in the mode table when the top level is
selected in the hierarchy browser.
Once the modes were defined, ConMan went through extraction and all
clocks were properly propagated per mode. The table is pretty intuitive
and provides option to select the values of say clocks coming from
existing SDC (if its been imported) or from simulation data or entered
manually. Whichever method is selected, the value for each clock is
propagated.
Design Intent Capturing:
The next thing we did was to put the "Design Intent Capturing" feature to
test. We selected two blocks in the design for this purpose. One for the
design intent capturing (the clkgen block), and the other for loading the
pre-existing SDC file (the GEMAC block). The idea was to show the
conflicts between simulation timing parameters and the timing coming from
pre-existing SDC. The clkgen block is the top level block containing all
the clocks that are being generated for the SoC. Lots of MUXing is also
done here for the different modes of operation. The GEMAC block is what we
had hardened previously, thus had the full SDC file available. Next we
imported the simulation output of the clkgen block into ConMan. At the
same time we read in the SDC for the GEMAC block (note this sits in at
another level of hierarchy). The clock input of GEMAC was coming directly
from clkgen. We deliberately altered the frequency of one of the clocks
in the SDC file for GEMAC. We saw that ConMan was able to extract all
relevant timing and modes information from the simulation output, as well
as from the SDC file for GEMAC. It then showed us the conflicts that
arose between the clock frequency of clkgen to the clock frequency set in
the SDC file for GEMAC. It highlighted the conflict in red in the table
and upon correcting within the tool, the correct clock frequency was
propagated to not only the GEMAC but all over the SoC.
Modes Evaluation:
Our simulation was done multi-mode with one clock running at low frequency
for the bootup mode and then going to 600 MHz at full functional mode. We
were happy to see that ConMan was able to identify both modes and associate
the right frequencies automatically. It also propagated all these values
throughout the chip so that in the end we could generate complete SDC for
any block of the design for the bootup as well as the functional mode.
The tool also does merged mode constraints. Since we merge the modes only
for backend tools in order to reduce our run-times, we selected one block
and merged the functional and the bootup mode, but kept the test mode
separate. ConMan was able to generate the merged mode constraints for us.
Error Reporting and Noise:
Next we wanted to see the validation capability of the tool. In ConMan
it is done by either typing single commands in the command window or
reading in the whole Tcl file. For the same design we imported multiple
Tcl files (all in one shot) corresponding to different modes. The tool
was able to map the SDC's to the corresponding modes and subsequently
matched all the commands and values to its database. Errors were
highlighted, and extra commands were dumped in the "User Defined SDC" area.
In terms of errors, it pointed to us few mistakes like the incorrect
related clocks defined for some of the bus bits. Since our chips have many
layers of MUXing involved, in the past we used to time the IO's with the
most restrictive clock frequency, however we sometimes ended up with
issues during sign-off. Same situation here. We had used a wildcard for
the set_output_delay on output pads, however due to pin MUXing, the
related clock was not driving all the bits of the output bus. The tool
pointed that out.
Noise wise, we noticed that even with 6 different SDC files for 5 different
blocks, the number of warnings was less than 25.
Excellicon guys told us that unlike other validation tools which perform
formal as well as structural checks on the SDC, ConMan performs the formal
analysis up front on the RTL/Gates and produces a golden database. When
SDC is loaded, only structural checks happen. If the SDC maps to the
golden database, then its correct, otherwise warning/error is issued. This
method reduces noise and run time also.
Debug/GUI features: The tool actually simulates the SDC and presents the
clocks and data as waveforms with arrows showing relationships. All IO
related timing constraints are also simulated and we see timing represented
as waveforms with related clocks. It becomes much easier to see the timing
in the SDC file as waveforms, especially for the IO interfaces like DDR etc.
Clock Map:
Another debug feature is called "clock map". This GUI looks very similar
to Google map. Through clock map, we could visualize the clocking structure
of the whole chip (or any block & down) in one shot. Since our chips have
hundreds of clocks per mode, it is important to see how the clocks
interact with each other and how many flops each clock domain is driving.
Our methodology so far has been to use linting tools to provide us
information of all clocks and resets and based on this, we would create a
Visio diagram. I guess we have changed our methodology now.
Excellicon guys said that there are a few other capabilities that they are
adding, like automatic mode synthesis, exception generation and writing
out guidance scripts for CDC tools. They did not elaborate on the first
one, but told us that with this feature, we will not need to identify the
mode pins manually. Even the mode pin values (the case_analysis values)
will be derived automatically. I don't know how this is possible.
Pros of ConMan
1. Tcl/SDC is supported rather than pure SDC format.
2. GUI based with one central cockpit for managing all data
3. Has a comprehensive rule set for identifying common issues;
for example identifying bad clocking relationships like clocks
defined "sync" at lower level, but defined "async" at top.
4. Supports RTL as well as gates
5. Clicking on any warning message opens up the file with errors
pointed to the exact line number.
6. Coverage analysis per mode (part of reports)
7. Noise free pretty much.
Cons of ConMan
1. The tool crashed on us when we tried to load up a big design in
gates. In RTL, it went through. The gates design was approx 20 M
placeable instances. Apparently, ConMan ran out of memory.
Upgrading the tool to the 64-bit version solved the issue.
2. Datapath timing exceptions are not supported yet. They told us
that the next release will have support for timing exceptions
generation also. They told us that it will be based on critical
path analysis and will be tied to design intent (did not explain
what they meant by this... all they said was that it will be done
such that the exceptions will be more usable in a practical way).
Although, we don't need this capability anyway (for reasons
mentioned above), its good to have just in case.
3. We did find a couple of minor bugs in the SDC which they corrected
within a day and released a new binary.
4. Lack of user documentation. They said that it's being written.
5. Flow commands like set_clock_latency and set_propagated_clock have
to be entered manually in the command window. Same with environmental
commands like set_operating_conditions.
Unknowns of ConMan
1. Other features (untested so far by us) -- Automatic mapping of
multi-mode constraints developed for RTL, to Gates; Identification
of likely async/sync clocks, etc.
Overall ConMan differed from traditional tools like Fishtail Focus, Atrenta
Spyglass-Constraints, Blue Pearl, Synopsys GCA and Cadence's stuff by
providing a complete constraints solution. In addition, none of these tools
solve the real-world issues like timing problem from bad IO constraints, or
providing a mechanism to define the clock to clock relationships like MCP's
and FP's in a meaningful manner. ConMan does.
So far we're impressed with ConMan and although it takes us a long time to
incorporate any new tool in our flow (corporate bureaucracy), most of our
guys are already using it. I am sure we will include it in our EDA
arsenal very soon.
- [ Enter the Dragon ]
Join
Index
Next->Item
|
|
