Stats

  • Locked Locked
  • Replies 3
  • Subscribers 92
  • Views 2045
  • 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

Are the -add and -master_clock constraints needed in an MMMC setup?

Domi Hammerfall

Dear community

I am working on a design that distinguishes between six different operational modes in its MMMC setup, i.e. there are six different SDC files. For simplicity, let us assume that there are only two modes: the normal mode and the test mode. Please consider the following circuit diagram of a module called clk_mgr:

Whether or not the design is in its normal mode is decided by the external signal op_mode. If this signal is logical 1 then the design is operating in the normal mode. It operates in the test mode otherwise.

The instance clk_mgr outputs four clocks. In the normal mode, they are driven by their respective clock input. In the test mode, all four are driven by the main clock clk. clk_ext1 and clk_ext2 are additional, external clocks running at a lower frequency. The special thing about clk_ext2 is that its pin is shared, i.e. in the test mode, no clock signal is applied to that pin; instead, it becomes a normal data path.

When a pin can be driven by multiple clock signals, textbooks suggest to define both clocks using the -add argument. For example, one could define the clock at if_clk_ext1 as follows

create_clock -name "if_clk_ext1_normal" -period 62.2 [get_pins MUX1/Q]
create_clock -name "if_clk_ext1_test" -period 83.3 [get_pins MUX1/Q] -add

Alternatively, one can define a generated clock. Here, the master_clock argument is used to specify which of the clocks reaching the specific source object should be used for deriving the characteristics of the generated clock:

create_clock -name "clk" -period 62.2 [get_ports clk]
create_clock -name "clk_ext1" -period 83.3 [get_ports clk_ext1]
create_generated_clock -name "if_clk_ext1_normal" -divide_by 1 -source [get_ports ???] -master_clock clk [get_pins MUX1/Q]
create_generated_clock -name "if_clk_ext1_test" -divide_by 1 -source [get_ports ???] -master_clock clk_ext1 [get_pins MUX1/Q] -add

The textbook examples I can find usually use sequential elements to define their clocks - not combinatorial elements like MUXs as in my example. Hence, I am unsure what to put as the source object (as inicated by the 3 question marks). Using [get_ports clk] and [get_ports clk_ext1], which might be the most reasonable option, seems redundant to me. Also, the master_clock argument might not be needed at all in this case.

For purely combinatorial paths, there is also the -combinational argument which could be used as follows:

create_clock -name "clk" -period 62.2 [get_ports clk]
create_clock -name "clk_ext1" -period 83.3 [get_ports clk_ext1]
create_generated_clock -name "if_clk_ext1" -combinational -source [get_ports clk] [get_pins MUX1/Q] # normal mode
create_generated_clock -name "if_clk_ext1" -combinational -source [get_ports clk_ext1] [get_pins MUX1/Q] # test mode

Here, my understanding is that the -add option does not work.

Whether any of these 3 options is correct I do not know. Also, is any of this necessary when there are multiple SDC files as in a MMMC setup?

Here is how I would constrain this design:

SDC file of the normal mode

set_case_analysis 1 [get_ports op_mode]
create_clock -name "clk" -period 62.2 [get_ports clk]
create_clock -name "clk_ext1" -period 83.3 [get_ports clk_ext1]
create_clock -name "clk_ext2" -period 250.0 [get_ports clk_ext2]
create_generated_clock -name "if_clk_ext1" -divide_by 1 -source [get_ports clk_ext1] [get_pins MUX1/Q]
create_generated_clock -name "if_clk_ext1_n" -divide_by 1 - invert -source [get_ports clk_ext1] [get_pins MUX2/Q]
create_generated_clock -name "if_clk_ext2" -divide_by 1 -source [get_ports clk_ext2] [get_pins MUX3/Q]
create_generated_clock -name "if_clk_ext2_n" -divide_by 1 - invert -source [get_ports clk_ext2] [get_pins MUX4/Q]

SDC file of the test mode

set_case_analysis 0 [get_ports op_mode]
create_clock -name "clk" -period 62.2 [get_ports clk]
set_input_delay -clock [get_clocks clk] -add_delay 5.0 [get_ports clk_ext2]
create_generated_clock -name "if_clk_ext1" -divide_by 1 -source [get_ports clk] [get_pins MUX1/Q]
create_generated_clock -name "if_clk_ext1_n" -divide_by 1 - invert -source [get_ports clk] [get_pins MUX2/Q]
create_generated_clock -name "if_clk_ext2" -divide_by 1 -source [get_ports clk] [get_pins MUX3/Q]
create_generated_clock -name "if_clk_ext2_n" -divide_by 1 - invert -source [get_ports clk] [get_pins MUX4/Q]
Technically, the tool should be able to infer the correct clock source based on the operational mode and the set_case_analysis constraint, right? Also notice that clk_ext2 gets an input delay constraint since it is a normal data path now. 
I would be thankful for an explaination on which solution is correct and why.
Parents Reply Children
  • in reply to DimoM

    Dear Dimo

    Thank you very much for the provided article, very helpful!

    If I understand everything correctly, the following concise constraints are sufficient:

    SDC of the normal mode

    set_case_analysis 1 [get_ports op_mode]
    create_clock -name "clk" -period 62.2 [get_ports clk]
    create_clock -name "clk_ext1" -period 83.3 [get_ports clk_ext1]
    create_clock -name "clk_ext2" -period 250.0 [get_ports clk_ext2]

    SDC of the test mode

    set_case_analysis 0 [get_ports op_mode]
    create_clock -name "clk" -period 62.2 [get_ports clk]
    set_input_delay -clock [get_clocks clk] -add_delay 5.0 [get_ports clk_ext2]
    The tool will now be able to detect which clock propagates to the four output ports if_clk_ext1, if_clk_ext1_n, if_clk_ext2, and if_clk_ext2_n.
    Two quick follow up question:
    1. When I omit the generated clocks alltogether, does it matter where the clocks are defined? I.e. can I simply use the clock pins as written above (and the tool will calculate any propagation delay to the point where it starts to build the clock tree) or should I use the most outer point (the output of the multiplexer in my case ) as the clock source?
    2. My understanding is that above's constraints will cause the tool to balance the three clock domains in the test mode (because their fan out runs with the same clock) since there is no logically/physically exclusive or fals_path constraint. Isn't that an overconstrainment? In our case, the domains clk, clk_ext1, and clk_ext2 are not physically or logically exclusive, but the domain transitions are done with a handshake protocol that does not require special timing checks, i.e. it can handle asynchronous signals. In other words, it would be possible that the three domains are not balanced to each other, which might give the tool more freedom when building the clock tree.
  • in reply to Domi Hammerfall

    Best is to define the clocks as far in the fanin as possible, i.e. on your ports. By doing so, all the nets on the clock are defined and recognized as part of the clock network for CTS.

    Regarding the balancing, you will have to see how the results are and take action accordingly. if necessary you can add skew groups.

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.