( ESNUG 382 Item 5 ) -------------------------------------------- [11/15/01]
From: Steve Lamb <slamb@synopsys.com>
Subject: It's Time To Scrub Your Formality Scripts To Speed Up Verification
Hi, John,
This summer we made a significant change was made to the way Formality works.
The 2001.06 release of Formality introduced a combination of flat and
hierarchical verification flows. (I'll skip the details and reference
the interested reader to the "Hier-IQ" white paper we published on our web
site.) From a user's perspective the important thing is that we moved away
from the automatic bottoms up hierarchical flow that had been the default.
As a result some of the variables users have gotten used to setting to
overcome the shortcomings of that approach are no longer needed (and in fact
slow the tool down.) These changes were in the 2001.06 Release Notes, but 5
months later I still see these "legacy" variables in many user's scripts.
I'm now asking Formality users to PLEASE scrub their scripts! Here is a
list of the common culprits:
1) Stop using 'set_parameters -flatten'
To protect users from false negatives due to boundary optimization,
Formality would automatically gradually flatten the design stopping
at each level to recheck the design. A nasty runtime penalty was
paid in those cases. Many users set this "flatten" parameter to take
Formality out of this hierarchical mode and force it to verify the
designs flat. This saved users from occasional long runs but also
prevented them from realizing very quick ones as well, not to mention
always maximizing memory consumption. Many users did not like to be
in the game of predicting which designs to flatten and which to leave
alone and just flattened them all.
In the new methodology, compare points are considered in their entire
(flat) context. So Formality no longer verifies designs bottoms up.
However, it does now make use of some hierarchical information to
achieve the performance and memory advantages of a hierarchical
verification run. The trouble for existing users is that the -flatten
option prevents the tool from taking advantage of this information.
In other words don't set this parameter any more (especially at the
top level of the design.) It can only slow the tool down.
In limited cases -flatten may improve performance if strategically
used on lower-level blocks with extensive boundary optimization.
2) Stop using 'set_equivalence -propagate'
Another shortcoming of the old Formality bottoms up hierarchical flow
is that some times top down knowledge is needed to understand "one to
many" port mappings of the sub-blocks following clock tree insertion
or the buffering of reset and test enable lines. Looking from the
bottom up, the tool would see numerous port mismatches on the sub-
blocks and be forced to gradually flatten the design to understand how
they should be resolved. To get past this problem without having to
flatten the entire design, the user could use the 'set_equivalence
-propagate' command. By setting these at the top level Formality would
essentially pre-verify the buffer trees and note the sub-block port
implications prior to beginning the bottoms up hierarchical flow.
Now that designs are verified in their flat context with the new
technology, this command should no longer be used for top-level
verification since it will merely result in wasted CPU cycles.
The 'set_equivalence -propagate' command is still available for
verification of lower-level blocks in isolation while using the full
design context to propagate constraints.
3) Stop setting up manual hierarchical verifications
Many users got used to the memory required when 'flatten' was set.
As a result, they adopted a manual hierarchical flow. That is, they
did many smaller manual Formality runs instead of one large Formality
run. The process of setting these multiple verifications up is time
consuming and not much fun.
The new Formality uses less memory. Users can now expect to verify
~2K gates/MB of RAM. In other words, somewhere between 6 and 8 million
gates of synthesizable logic can now be verified in a 32 bit machine
with 4 gig of RAM. This means many designers can now verify their
whole chip in one run with minimal user intervention required. Yet I
still see many users taking a manual hierarchical approach. Please
check the memory consumption on your next Formality run; it may be able
to do it in one chunk, saving you lots of work and multiple runs.
If your designs exceed 6-8 million gates, we do have a 64 bit port of
Formality for those that want to acquire those workstations. (Worse
yet, you'll probably butt heads with the physical designers in your
company who are already using every 64 bit machines your company has
already!)
4) Other switches that are no longer needed now that designs are verified
in their flat context:
verification_override_inout_port_direction
verification_block_timeout_limit
verification_remove_passing_subdesigns
These commands are now obsolete and should also be removed from
your Formality scripts.
I hope this letter helps our existing Formality users noticably speed up
their verification runs.
- Steve Lamb
Synopsys, Inc. Marlboro, MA
|
|
