• 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. Get all register related to ONE clock?

Stats

  • Locked Locked
  • Replies 5
  • Subscribers 90
  • Views 15536
  • 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

Get all register related to ONE clock?

archive
archive over 18 years ago

    we have ECLK and MCLK in my design, I now want to list all the registers related each of the clock. Here is the porblem I met.

Approach One:
dbForEachCellInst [dbgTopCell] instPtr {
    set cellPtr [dbInstCell $instPtr]
    if {[dbIsCellStdCell $cellPtr]} {
      if {[dbIsCellSequential $cellPtr]} {
        dbForEachInstTerm $instPtr termPtr  {
        dbIsTermClk $termPtr
        ......

But I can know which clock this term is connect to

Approach Two:
dbForEachHeadClock [dbgHead] clockPtr {
        set sel [dbIsClockSel $clockPtr]
        set name [dbClockName $clockPtr]
        puts "$name"
}
setClockDomains -sClk ECLK -dClk ECLK  -fromType register -toType register e

I now want to use this command, dbForEachClockDomainInst, but I don't know the syntax since the Encounter Database Access Command Reference did tell use how to used it.

Any suggestion and feedback is welcome! Thanks 


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

    Great question- I'm glad you asked it.

    In FE, there's a couple of different ways to probe the db. The long-standing mechanism I call "FE-TCL"- commands like "dbIsTermClk" and "dbForEachClockDomainInst" are FE-TCL commands. They've been around forever and are great for probing things in the physical realm. However, for information that falls in the timing realm there's CTE-TCL (Common Timing Engine-TCL) commands. These are relatively new within the FE environment (within the 6.1/6.2 timeframe), but what's nice about the CTE-TCL commands is that they provide the ability to query timing efficiently. The example task you're asking about here fits better within the CTE-TCL commands. FE-TCL and CTE-TCL commands are all available at the regular encounter prompt- they're complimentary sets of functionality.

    So, with a netlist like this:
    module testcase (clk1, clk2);
    input clk1;
    input clk2;
    wire net1;
    wire net2;
    wire net3;
    DFFX1 i0(.CK(clk1), .Q(net1));
    DFFX1 i1(.CK(clk1), .D(net1));
    DFFX1 i2(.CK(clk2), .Q(net2));
    DFFX1 i3(.CK(clk2), .D(net2), .Q(net3));
    DFFX1 i4(.CK(clk2), .D(net3));
    endmodule

    ...and a SDC like this:
    create_clock -period 1 -name clk1 [get_ports clk1]
    create_clock -period 1 -name clk2 [get_ports clk2]

    You could get the registers associated with each like this:
    encounter1> report_timing
    encounter 6> all_registers -clock clk1
    i0 i1
    0x8
    encounter 7> all_registers -clock clk2
    i2 i3 i4
    0x9

    Have a look at the "Timing Constraint Commands" section in "fetxtcmdref.pdf" for more information on commands like this.

    Let me know what you think of this and whether it would be OK with you to operate with these CTE-TCL commands instead of FE-TCL for probing timing-related information like this.

    Hope this helps,
    Bob


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

    Great question- I'm glad you asked it.

    In FE, there's a couple of different ways to probe the db. The long-standing mechanism I call "FE-TCL"- commands like "dbIsTermClk" and "dbForEachClockDomainInst" are FE-TCL commands. They've been around forever and are great for probing things in the physical realm. However, for information that falls in the timing realm there's CTE-TCL (Common Timing Engine-TCL) commands. These are relatively new within the FE environment (within the 6.1/6.2 timeframe), but what's nice about the CTE-TCL commands is that they provide the ability to query timing efficiently. The example task you're asking about here fits better within the CTE-TCL commands. FE-TCL and CTE-TCL commands are all available at the regular encounter prompt- they're complimentary sets of functionality.

    So, with a netlist like this:
    module testcase (clk1, clk2);
    input clk1;
    input clk2;
    wire net1;
    wire net2;
    wire net3;
    DFFX1 i0(.CK(clk1), .Q(net1));
    DFFX1 i1(.CK(clk1), .D(net1));
    DFFX1 i2(.CK(clk2), .Q(net2));
    DFFX1 i3(.CK(clk2), .D(net2), .Q(net3));
    DFFX1 i4(.CK(clk2), .D(net3));
    endmodule

    ...and a SDC like this:
    create_clock -period 1 -name clk1 [get_ports clk1]
    create_clock -period 1 -name clk2 [get_ports clk2]

    You could get the registers associated with each like this:
    encounter1> report_timing
    encounter 6> all_registers -clock clk1
    i0 i1
    0x8
    encounter 7> all_registers -clock clk2
    i2 i3 i4
    0x9

    Have a look at the "Timing Constraint Commands" section in "fetxtcmdref.pdf" for more information on commands like this.

    Let me know what you think of this and whether it would be OK with you to operate with these CTE-TCL commands instead of FE-TCL for probing timing-related information like this.

    Hope this helps,
    Bob


    Originally posted in cdnusers.org by BobD
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

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