[SOLVED] How to define SDC constraints for two clock domains fed by single source?

Here is a simplified version of my problem. I have two set of registers as shown. They are operated at different times and there is no path between them. They are clocked by a single clock port. The set of red registers are few in number with not much logic between them and are operated at 320MHz. Blue set of registers are operated at 80MHz.

If I use create_clock on clk port with frequency of 350MHz, the blue set of registers including the large part of clock tree that will never be operated at more than 80MHz gets unnecessarily optimized.

I defined two clocks on the same pin with create_clock, made them physically_exclusive with set_clock_groups and set_false_path between the 350MHz clock and the blue set. But the tool (Genus) still tells there are multiple clock waveforms driving the blue registers (both set). I also tried putting a create_generated_clock with -divide_by 4 on common clock fanout point of the 80MHz domain. The 350MHz constraint is still propogating everywhere.

How do I stop the 350MHz clock definition from propagating to the 80MHz domain?

Try to make all paths multi-cycle paths (4 clock cycles) in the blue region.

One minute.....

In the attached pic, I see the clk signal feeding all the red and blue registers. Is that correct?

In the text you are talking about 2 clock domains. I find the two contradicting.

dpaul said:

One minute.....

In the attached pic, I see the clk signal feeding all the red and blue registers. Is that correct?

In the text you are talking about 2 clock domains. I find the two contradicting.

Click to expand...

Different clock domain in the sense that the two set of registers are operated at different times having their own set of inputs and outputs with no interaction between them. The clock pin is supplied with two different frequencies depending on which operation is to be performed.

Regards,
Pramod B

What if the frequency is not integer multiple of the other? Say Higher frequency is 350MHz and Lower frequency is 80MHz.

Pramod_B said:

What if the frequency is not integer multiple of the other? Say Higher frequency is 350MHz and Lower frequency is 80MHz.

Click to expand...

Is this a question related to my suggestion about multi-cycle paths?
If so, I think you should accept some over-constraining. With 350 MHz and 4 cycles multi-cycle the blue region will be constrained to 87.5 MHz.

std_match said:

Is this a question related to my suggestion about multi-cycle paths?
If so, I think you should accept some over-constraining. With 350 MHz and 4 cycles multi-cycle the blue region will be constrained to 87.5 MHz.

Click to expand...

Yes, Sorry.
So I would constrain the primary inputs that are launched with respect to the clock port to the 350MHz clock and set a multi cycle of 4 on them. But the clock tree to the blue registers will still be optimized for 320MHz right?. A slightly different question, I know we have separate clock tree specification file, but will the constraints put in the sdc not affect the clock tree building later?

The clock pin is supplied with two different frequencies depending on which operation is to be performed.

Click to expand...

That means theoretically there is a clock_MUX sitting before the clk signal.

Did you try telling the tool that a clock_MUX is there?
You can define in the constraints file according to the clock_MUX select line data.

Pramod_B said:

Here is a simplified version of my problem. I have two set of registers as shown. They are operated at different times and there is no path between them. They are clocked by a single clock port. The set of red registers are few in number with not much logic between them and are operated at 320MHz. Blue set of registers are operated at 80MHz.

If I use create_clock on clk port with frequency of 350MHz, the blue set of registers including the large part of clock tree that will never be operated at more than 80MHz gets unnecessarily optimized.

I defined two clocks on the same pin with create_clock, made them physically_exclusive with set_clock_groups and set_false_path between the 350MHz clock and the blue set. But the tool (Genus) still tells there are multiple clock waveforms driving the blue registers (both set). I also tried putting a create_generated_clock with -divide_by 4 on common clock fanout point of the 80MHz domain. The 350MHz constraint is still propogating everywhere.
View attachment 149777
How do I stop the 350MHz clock definition from propagating to the 80MHz domain?

Click to expand...

you need some external controllable signal to define when clk is runnign at 350 or when it is running at 80. then in your sdc with the help of set_case_analysis, you can select the clock domains accordingly.

Yes, Sorry.
So I would constrain the primary inputs that are launched with respect to the clock port to the 350MHz clock and set a multi cycle of 4 on them. But the clock tree to the blue registers will still be optimized for 320MHz right?. A slightly different question, I know we have separate clock tree specification file, but will the constraints put in the sdc not affect the clock tree building later?

Click to expand...

I saw this post today also in the Xilinx forum.
A very experienced member there has raised questions similar to what I have mentioned here in my post #8.
This is also mentioned in post #9.

This issue needs to be addressed first -- a clock MUX and its constraining.

I wonder if the clock mux is outside this users logic and they are trying to synthesize only their portion of the design independent of the clock mux.

It would probably be easier if this is the case to have two clock inputs into their module. Let the top level integrator of the code put the clock mux output onto both clock pins. Then it's really easy to constrain just their portion of the design separately without the clock mux being there.

No, there is no clk mux in the design. That clock port is a direct pin to the chip. Clock is supplied from externally to the chip to this pin.

The clock soirce shown is a direct clk port to the chip. There is no control input for clock selection and it has to be done externally.

Pramod_B said:

The clock soirce shown is a direct clk port to the chip. There is no control input for clock selection and it has to be done externally.

Click to expand...

This is a terrible idea.

Then do what I've already said, make two clock ports on anything that has this seriously flawed design and make them separate clocks everywhere, then output both clocks on a top level file. Do everything based on having two clocks i.e. synthesis, etc.

Once all that is done use a wrapper file around your top level file that just takes a single pin and splits it into the two clocks. Not entirely sure the tools you use will even allow you to do this kind of hack. Once this is done, you're still going to be in a world of hurt once you try to do anything on the backend and have to do any kind of timing on the design after layout.

This should be addressed before you get that far...like a design change right now, because the problem is just going to be even worse (and more expensive) later. Depending on the size and financials of the company you work for this could end up costing everyone their jobs.

This is a classic example of a novice doing system engineering and the results of that inexperience becoming an issue.

The clock soirce shown is a direct clk port to the chip. There is no control input for clock selection and it has to be done externally.

Click to expand...

Are you sure this thread is SOLVED?

Multiple experienced members have pointed out what can be done.

Are you someone who is just entrusted to do the SDC, with no idea of the design?
If yes, then you should be seriously taking to the person who has done this design.

Do you have access to the complete design?
In my opinion you should be looking at multiple levels above this design (so as to say have an idea about the DUT arch) and then judge what needs to be done for SDC in such cases.