• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Digital Implementation
  3. Encounter/Nanoroute - fixing DRC violations while keeping...

Stats

  • Locked Locked
  • Replies 4
  • Subscribers 91
  • Views 5293
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Encounter/Nanoroute - fixing DRC violations while keeping critical pre-routes untouched

ccabal
ccabal over 17 years ago

 Hi Folks,

Our design has some timing critical nets, which are being routed in fat metal, and currently my flow is to route these first , fix all DRC violations on these, and then set the "setAttribute -net <net> -skip_routing true" on these nets, so that when I route the rest of the nets, there remain untouched.

 

The problem I am facing is that when I route the rest, I get DRC violations, and these violations sometimes involved the pre-routed fat wires.  If I use the "editDeleteViolations" command, it will then rip out the pre-routes too, something I definitely dont want to happen.  I did a man on  "editDeleteViolations", and it does have a option called:

 

-keep_fixed   Does not delete wires marked FIXED in the DEF file when deleting nets with violations.

 

That option would be useful if I could find a way to mark the wires as "FIXED" in my def, but unfortunately, the  "setAttribute -net <net> -skip_routing true"  attribute does not get saved in the def file.  I cannot find a way within Nanoroute/Encounter to flag a net as "FIXED" and get it saved into the .def so that I could use the -keep_fixed option  

 

I suppose I could just manually hack the def file to add a + FIXED attribute to each wire, but does anyone know of a cleaner flow to doing what I want to get done?

Thanks

 

  • Cancel
  • Kari
    Kari over 17 years ago

     Hi,

    Check the docs for editChangeStatus. I think this may do what you want.

    - Kari 

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • BobD
    BobD over 17 years ago

    First off, welcome to the forums, and thanks for the question!

    There may be a command that does that I'm not thinking of right off, but even if there is, scenarios like this are good opportunities to talk about various ways to approach problems within Encounter.

    The first thing that came to mind when I read your question was dbGet and dbSet.  If you're using version 7.1 or newer of the software, you could use dbSet to do this as follows. I'll show an example operating on a 32 bit bus:

    First, select the nets using "selectNet":
    encounter> deslectAll
    encounter> selectNet DTMF_INST/TDSP_CORE_INST/alu_result*

    Next, use dbGet to query the nets:
    encounter> dbGet selected.?
    net: allTerms box isClock isExternal isFixedBump isGnd isPatternTrunk isPhysOnly isPwrOrGnd isScanNet name numInputTerms numOutputTerms numTerms objType props sVias sWires wires

    This is telling us that all of the objects currently selected are "net" objects, and "net" objects have all of these associated objects and attributes.  "wires" looks interesting, so we can use dbGet to "walk" the database from nets to wires:

    encounter> dbGet $selected.wires
    0x1cca8f70 0x1d5d0768 0x1d5d0744 0x1d5d0720
    <snipped>

    You should see a db pointer echoed to the screen for each wire segment of all the nets you selected. We can again query what attributes wires have with ".?":

    encounter> dbGet $seleted.wires.?
    wire: beginExt endExt layer objType pts status via viaPt width

    "status" sounds helpful, so we can query the status of all the wires with:

    encounter> dbGet $selected.wires.status
    routed routed routed routed

    In your case, it sounds like you'd like to convert "routed" wires to "fixed".  We can do dbSet to do that, but what if you don't know what the tool calls the fixed status?  ie, "FIXED" or "Fixed" or "fixed"?  You can query which enumerated values are valid for the status field:

    encounter> dbGet selected.wires.?h status
    status(settable): enum(cover fixed noshield routed unknown), Wiring status (equivalent to DEF NETS regular wiring status)

    From this we can see that the attribute is settable and that "fixed" is the string used for the "don't move me" status we're looking for.  Now, we can use dbSet as follows:

    First, we'll get the pointers we want to operate on, the wires:

    encounter> dbGet selected.wires
    0x1cca8f70 0x1d5d0768 0x1d5d0744 0x1d5d0720

    Next, we'll set the "status" attribute to "fixed" with dbSet:

    encounter> dbSet [dbGet selected.wires].status fixed

    Query success with:

    encounter> dbGet selected.wires.status
    fixed fixed fixed fixed

    When you defOut these attributes should be retained.

    If you're using a version earlier than 7.1, there is a script in the "gifts" directory that could help with this.  The gifts directory resides here:

    <install_path>/share/fe/gift/scripts/tcl/

    There is a script called "userSetSelWireStatus.tcl" which would do the same:

    encounter> source userSetSelWireStatus.tcl
    encoutner> selectNet *
    encounter> userSetSelWireStatus Fixed

    There is also an FE-TCL command called "dbSetNetWireStatus" that would be helpful if dbGet isn't available to you.  It is an older style of TCL scripting that is a little more difficult to use than dbGet but certaintly has been useful for many years:

    dbSetNetWireStatus <netPtr> <status>

    Between these solutions I hope you find one of them meets your needs.

    Thanks,
    Bob

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • BobD
    BobD over 17 years ago

    Kari's suggestion is absolutely right.  That's the easiest way to this.  Important to note that the nets need to be selected with "editSelect -nets <net_name_search_string>" and *not* selectNet in order for editChangeStatus to work.

    Thanks for that, Kari!

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • ccabal
    ccabal over 17 years ago

     THanks alot for the help!

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information