create_clock on timing path using primetime or design compiler

[csjiang]

Dear all:
When using synopsys' tool primetime or design compiler, I found that if I create_clock on one point that is in the timing path, the clock source point becomes the endpoint of the data path, and will be unconstrained. For example, I set_input_delay on port A of my design, and create_clock on the C pin of IO cell of port A.

(IO cell)
____________ _______
A | PAD ------ C|---*----------------- | DFF |
/ --------------- / |______|
(set_input_delay) (create_clock)


Then the path from A to DFF becomes unconstrained. Does anyone know how to make the path from A to this DFF still has the input_delay constraint?

Thank you.

 

[rca]

you cannot add input delay on clock path.

 

[csjiang]

Thank you.

For my case, the input port is functional input in case A, and is also a clock input in case B. On this port, I need to set input delay for case A function on input port, and set clock source for case B simultaneously. So I need to set input delay on clock path.

I found if i set the clock source on C pin of IO cell, and set input delay on PAD pin of IO. It makes the timing path stop on C pin of IO cell. But when I set the clock source on PAD pin of IO cell, which is the same point of clock source, the timing path no more stopped.

If in some case, I need to set the clock source on the C pin of IO cell, but set_input_delay on PAD of the same IO, how can I make the timing path not to be stopped on the point of clock source?

Thank you.

 

[rca]

You should create two modes, and do your backend flow in multi-modes.
Each mode as his own SDC, as you describe before.

 

[rahul.achates]

use clock_latency , its additional delay added in source clock path.

 

[csjiang]

Dear RCA:
Is it a normal way to set multi-modes for a multifunction of IO pins? When timing closure, we must handle several operation corners. If we set multiple mode for pin functions, there will be many many extra modes to be handled. For example, on smic's 55nm process, we have to handle 16 corners. Besides, we have a mode for scan and a mode for no-scan. So there are 32 modes need to be taken care. If we add one mode for pin function, there will be 48 modes. So our backend engineer shall be break down. I think it is so uneconomical. So I doubt is it a general way to handle multi-function pins?