• 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. How to get the database address of the subModule?

Stats

  • Locked Locked
  • Replies 4
  • Subscribers 90
  • Views 14020
  • 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

How to get the database address of the subModule?

archive
archive over 18 years ago

In GUI design bowser, I can see the level ONE sub-module, I know dbgTopCell return the top level Module address. Now in my scripts, I need the database address of these cells, How can I get this ?


Originally posted in cdnusers.org by aidans
  • Cancel
  • archive
    archive over 18 years ago

    I mean, How can we get the database address of these Level ONE sub-Module.


    Originally posted in cdnusers.org by aidans
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    It depends on whether you want to the pointer to the instantiation of the Level ONE sub-module -or- the master cell of the sub-module.

    If the Verilog netlist looks like this:

    module top(clk);
    input clk;
    wire net;
    a i_a(.clk(clk), .out(net));
    b i_b(.clk(clk), .in(net));
    endmodule

    module a(clk,out);
    input clk;
    output out;
    DFFX1 i0(.CK(clk), .Q(out));
    endmodule

    module b(clk, in);
    input clk;
    input in;
    DFFX1 i0(.CK(clk), .D(in));
    DFFX1 i1(.CK(clk), .D(in));
    endmodule

    Then you could access the instantiation of module a ("i_a") with this:

    encounter 2> set hinst [dbGetHInstByName i_a]
    0x15c06d84

    Or if you wanted to look at the master cell "a" you could access it like this:

    encounter 3> set cell [dbGetCellByName a]
    0x15964ec8

    Whether you work with the instantiation -or- the master cell depends on what data you're trying to access or manipulate. Feel free to follow-up with an additional post if further clarification would be useful.

    Hope this helps,
    Bob


    Originally posted in cdnusers.org by BobD
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    Thank you for your in-time response to my post.
    By dbGet*ByName do retrieve the DB address of the NAMED Objects. To use these kind of command, I must know the hierarchical topology of my verilog netlist, which means I must know the sub-modules’ name.

    Of cause I can open the Design Browser, and type the sub-modules’ name into my scripts. But this is not a good way to do things, since my scripts are also used by other Block-level designers. (we use hierachical design method to implement the back-end design flow), It’s better to get the sub-module names automatically.

    I come across this question while I writing scripts to get the sub-module related IO Pins.
    dbForEachCellFTerm [dbgTopCell] ftermPtr { } get all the PINs.
    If I use this scripts structure, I have lots of pain to decide which sub-module of particular PIN belongs to. So if I can get the Level ONE sub-module names, then I can report the IO Pins related to this sub-module in a neat way:
    dbForEachCellFTerm $subModuleCellPtr ftermPtr { }


    Originally posted in cdnusers.org by aidans
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    I got the answer


    dbForEachHInstHInst [dbCellHInst [dbgTopCell]] hinstPtr {
    if [dbIsHInstHInst $hinstPtr] {
    puts [dbHInstName $hinstPtr]
    }
    }


    Originally posted in cdnusers.org by aidans
    • 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