Home > Community > Blogs > Digital Implementation > how to purge interactive constraints in mmmc mode
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Digital Implementation blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

How To: Purge Interactive Constraints in MMMC Mode

Comments(4)Filed under: Digital Implementation, TCL, Encounter Digital Implementation System 8.1, MMMC, Timing Constraints

These tips are applicable to the Encounter Digital Implementation System.

Back in the good old days, I remember asking designers at the beginning of a silicon virtual prototyping evaluation "Where is your timing constraints file?"  Note the singular form of the word file- was it really that simple?  Didn't seem so easy at the time.  While the complexity of timing constraints in terms of their content has increased, managing the actual files that contain the constraints, how they apply to multiple constraint modes in the tool, and dealing with incremental additions to the active constraint set is increasingly complex.

A scenario came up with a customer I was working with recently that led to a solution that I thought would be good to share.  The designer was using MMMC (multi-mode/multi-corner) timing analysis, and wrote a script to query the timing graph, add timing constraints that would alter the timing graph, and then write out a list of ECOs that needed to be made to the design based on what his script found.  He wanted a way to clear out the interactive timing constraints his script used while retaining the timing constraints associated with each of the views as defined in the viewDefinition.tcl file.

Interactive constraints are simply the constraints entered at the command line (or sourced in a file) that aren't part of the files associated with the create_constraint_mode command:

create_constraint_mode -name common_constraint_mode -sdc_files testcase.sdc

When we're in MMMC mode, and we want to apply a timing constraint at the command line, we need to tell the tool which of the constraint modes we'd like the interactively-entered constraints to apply to:

encounter 2> set_false_path -from i0 -to i1
**ERROR: (TCLCMD-1048): There is no interactive constraint mode. The constraint will be ignored. Please use 'set_interactive_constraint_modes' command.

Tip #1: When I get this message, I find the quickest way to get past it (and ask the tool to consider the constraints I give it for all active views) is to apply the constraints to all the active constraint modes.  This can be time consuming if you need to recall all of the names of the constraint modes via cut and paste, so we can retrieve these modes programmatically like this:

encounter 6> set_interactive_constraint_modes [all_constraint_modes -active]

Now the tool will accept the interactive constraint and apply it to all the active views. My simple design only has 2 registers so if I false_path -from/-to the registers I'll see no constrained paths:

encounter 7> set_false_path -from i0 -to i1                                 
encounter 8> report_timing
No constrained timing paths found.

Tip #2: So now if I wanted to ask the tool to forget this interactive constraint (the false_path) and revert back to the sdc files associated with the constraint_mode, here's how I'd do it.  We can make use of the update_constraint_mode command (which is primarily used to append/delete sdc files to the current list and replaces the unloadTimingCon command when not in MMMC mode).  Specifically, we'll leverage a nuance regarding whether interactive constraints are retained or purged when you reset the sdc files:

encounter 11> update_constraint_mode -name common_constraint_mode -sdc_files testcase.sdc
**WARN: (TCLCMD-1122):  The update_constraint_mode command will reset all interactive constraints for all views. Any interactive constraints entered before this command will be lost.

Let's confirm that the design is again timed as we'd expect it to be:

encounter 12> report_timing
Path 1: MET Setup Check with Pin i1/CK
Endpoint:   i1/D (v) checked with  leading edge of 'clk'
Beginpoint: i0/Q (v) triggered by  leading edge of 'clk'

If we wanted to use this approach to reset the sdc files associated with all of the active views, we could do that.  But again, this could be laborious to keep track of in contemporary designs were we have dozens of modes and even more sdc files.

Tip #3: A better way would be to retrieve the sdc files associated with all of the active views and re-point each constraint mode to the current sdc files (thus purging the interactive constraints as previously described).  Here's how to do it:

foreach constraint_mode [all_constraint_modes -active] {
  set constraint_files [get_constraint_mode $constraint_mode -sdc_files]
  update_constraint_mode -name $constraint_mode -sdc_files $constraint_files
}

Tip 4: To refine things a bit, we could wrap this up into a procedure that we could call any time we wanted to purge the interactive constraints we've entered.  We could share this procedure across other designers we work with:

proc user_purge_interactive_constraints {} {
  foreach constraint_mode [all_constraint_modes -active] {
    set constraint_files [get_constraint_mode $constraint_mode -sdc_files]
    update_constraint_mode -name $constraint_mode -sdc_files $constraint_files
  }
}

I hope this was generally useful in understanding how interactive constraints work in MMMC mode, and in describing an efficient way to manage interactive constraints.


Bob Dwyer

 

Comments(4)

By Rajiv Mittra on November 30, 2009
Hi Bob,

 Thanks for letting us know the clean way of purging the interactive constraints from our active analysis mode.

Could u also let me know how can we purge or reset the sdc files associated with all active views similar to doing "unloadTimingCon" for each active analysis view?

"update_contraint_mode" requires an SDC file as an input.

Thanks,

Rajiv


By BobD on December 1, 2009
Hi Rajiv,
Thanks for your question!  I conferred with R&D about this, and here's what I found...
update/create_constraint_mode don't accept an empty list (ie, "{}") because the thinking is that users always want to have constraint files loaded as part of their multi-mode/multi-corner environment.  Would you (or any one else who comes across this) describe a little more why you'd like to remove all of the timing constraints from the system?  Examples or scenarios would be helpful in perhaps justifying an enhancement in this area.
As a workaround, I think you could "touch empty.file" and point each constraint mode to that file with "update_constraint_mode -name $constraint_mode -sdc_files empty.file".
Best,
Bob

By Rajiv Mittra on December 1, 2009
Hi Bob,
 Thanks for the clarification. I'll try out the workaround as you suggested for clearing the constraints. Now let me give you the histroy behind this requirement. Actually the requirement is not only removing constraints but resetting the entire mmmc modes from the system (someting like reset_mmmc_modes -all) and put the design back in single mode and there are 2 specific examples why we need this!
Actually we have some modes in our design for which there are no MMMC setup, although it can be created but due to legacy reasons they are never created so what we used to do before timing our design in those modes is to comment out "set_rdaInput(ui_view_definition_file)" and then restore the design. There is 1 more reason why we haven't added or created MMMC setup for those modes is that in MMMC even if your different modes shares common constraint files like margins.tcl, libconstraints.tcl, maxTrans.tcl etc. but it is loaded or read everytime for each analysis mode hence our MMMC setup takes 20 to 30 minutes to complete.
Also whenever we save our design in MMMC mode then all of the constraint information is not properly saved that's why we see lot of ERRORS if we restore back the design so to be on safer side what we used to do is comment out the "set rda_Input(ui_view_definition_file)" line from the conf file and run the MMMC setup once again. All this is a manual process (commenting line in conf file) so I was looking for a clean way of doing this.
I found your suggestion to be very useful atleast for removing constraints from the system memory.
Thanks & Regards,
Rajiv

By BobD on December 3, 2009
Hi Rajiv,
Thanks so much for this feedback.  I'll pass it along to our developers for their assessment.  I've heard from at least 1 other user that they'd like a way to reset the tool back into .conf-based timing and clearing out the MMMC views.  We don't have that capability currently, but there are invariably occasions where it would be advantageous to do so.
-Bob

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.