input delay for an input path

There are timing paths in a design which starts at input pin of the design and then goes into a combinational path and ends at a flipflop D input. Do the synthesis tool report about the timing of that type of path? Please see the attached picture where the name of the design is A and such a oath is shown for an input I.

Yes if you add a constraints like min/max input delay.

I have no experience working with Synopsys Tool. But the delay can be extracted from the input given to the Tool.

Any path delay can be calculated.

For more info on STA on EDA Tools,
http://www.vlsi-expert.com/p/content.html#.UvdmPSPC7RY

rca said:

Yes if you add a constraints like min/max input delay.

Click to expand...

Will not report_timing command itself report the timing of such paths so that there is no necessity of adding such constraints like min/max input delay? Is it mandatory to provide constraints like min/max input delay on top of report_timing command to get such paths as shown in my diagram in my timing report?

Is it report_timing only reports reg-reg paths and not other paths like input-reg or reg-output?

Regards

Any Design will have input delay / output delay as constraint in SDC file , and this constraint are normally 1/2 of clock period on which inputs/outputs are working.

If you have declared set_input_delay on all inputs with respect to clock , then you dont have to think much about this.

Rahul J

Rahul

THE QUERIES THAT IS IN POST NUMBER 1 WAS ASKED IS NOT ANSWERED AND THIS REPLY DOES NOT ADDRESS OUR QUERY.

Regards

HI ,

There are 4 types of timing path which a synthesis tool can understand -
1. input to flop
2. flop to output
3. flop to flop
4. input to output

now suppose you design is A_top (design top level name) , it is coded as below

module A_top (
input din,
input clk,
input reset,
onput y
);

and you have combo logic at din.

assign dtemp = temp & din;

then you are putting a flop.

always @(posedge clk or negedge reset)

---
---
y <= dtemp ; // (Y_FLOP)
end


so this is exactly same as you have described in diagram.

now synthesis tool knows din is input , and synthesis tool will calculate timing from din to Y_FLOP ..

this you can check by giving report_timing -from din -num_paths 10

this will show all paths started from din, ideally there will be only one path , from din to Y_FLOP


let me know if this resolve your question or not.

Thanks
Rahul J

In addition to the explanations above :-

Suppose you just have the design anf you start writing constraints.
Say you declare a clock that goes to all the flops. Another clock goes to the ports.
But since in your WLM/TLU+/ SPEF you just provide for the nets connected from register to register and nothing explicitly is explained for the ports.
If you do report_timing -from PORT XYZ -> it will show that the path is unconstrained, because you have yet not told the tool that how much delay it should expect for the signal coming in through the port. It depends on a lot of factors like board_delay, setup time etc... but you have to declare input, output delays along with load etc.. on the ports (i.e constrain ) so as to make the tool aware about it.
If you dont specify it and just do report_timing -from PORT XYZ -unconstrained -> then you will find the unconstrained path (i.e data path ) from the port to some register/ output port but you will not be able to find the slack as there is no information about the clock to the ports.
The tool might know about the capture clock which is internal to the block but it does not and cannot know about the launch clock unless user-specified and thats exactly what constrints do.

Thanks for summarizing this , yes it is true you need to constraint input/output port to see the timing on those ports , otherwise tool will show you unconstrained ports ..

Rahul J

Suppose there was no input delay constraint defined for the pin named I in the diagram in post number 1. Will the report_timing then also report the timing of such a path while doing synthesis? If no, please write the reason behind such path not being reported without input_delay constraint.

Regards

sun_ray said:

Suppose there was no input delay constraint defined for the pin named I in the diagram in post number 1. Will the report_timing then also report the timing of such a path while doing synthesis? If no, please write the reason behind such path not being reported without input_delay constraint.

Regards

Click to expand...

Tools will need some information on input , to calculate timing , tool will need a starting point. Without constraint toll will not be able to find how much delay input port having from outside logic.

even if you write report_timing without giving constraint, tool will show msg that "path is unconstrained"

sun_ray said:

Suppose there was no input delay constraint defined for the pin named I in the diagram in post number 1. Will the report_timing then also report the timing of such a path while doing synthesis? If no, please write the reason behind such path not being reported without input_delay constraint.

Regards

Click to expand...

No if you do not constrain it, it will not give a timing report.
Reason :-
Timing report means calculating slack of your data based on the launch clock and capture clock. In the diagram you can see a capture clock for the register but not a launch clock, because it is not in the block. That path is coming from a reg outside the block which definitely has a clock. You have to inform the tool about that clock and also the delays that the data will incur in travelling from its Q pin to the register you see in the diagram through the port ( this is constraining). Once you do it only then can tool calculate an arrival time and a required time and thus give a slack.

Ro9ty

ro9ty said:

No if you do not constrain it, it will not give a timing report.
Reason :-
Timing report means calculating slack of your data based on the launch clock and capture clock. In the diagram you can see a capture clock for the register but not a launch clock, because it is not in the block. That path is coming from a reg outside the block which definitely has a clock. You have to inform the tool about that clock and also the delays that the data will incur in travelling from its Q pin to the register you see in the diagram through the port ( this is constraining). Once you do it only then can tool calculate an arrival time and a required time and thus give a slack.

Ro9ty

Click to expand...

So somehow if input delay is not specified for an input, the synthesis tool will not report the path and its timing in report_timing. How to take care of such situation such that after RTL synthesis or PnR the generated netlist can be caught of timing violation if there is any timing violation in such a path as depicted in the picture in post no 1?

Regards

sun_ray said:

So somehow if input delay is not specified for an input, the synthesis tool will not report the path and its timing in report_timing. How to take care of such situation such that after RTL synthesis or PnR the generated netlist can be caught of timing violation if there is any timing violation in such a path as depicted in the picture in post no 1?

Regards

Click to expand...

We have come round the circle.
You can report_timing by writing the constraints.
The design team will provide you a documentation. You have to have the ability to dig into RTL and find the points where clocks are specified. Thereafter for other constraints like board delay and external clock in order to compute input and output delays you will have to find the load and slew values from documentation of the external device. For ex: if you have a path from some external memory to our digital b- read the docs for the memory and find out the clock which is going into the reg sending that signal.
Consult your foundry for docs related to delay for the interconnects.

Ro9ty

ro9ty said:

We have come round the circle.
You can report_timing by writing the constraints.
The design team will provide you a documentation. You have to have the ability to dig into RTL and find the points where clocks are specified. Thereafter for other constraints like board delay and external clock in order to compute input and output delays you will have to find the load and slew values from documentation of the external device. For ex: if you have a path from some external memory to our digital b- read the docs for the memory and find out the clock which is going into the reg sending that signal.
Consult your foundry for docs related to delay for the interconnects.

Ro9ty

Click to expand...

This does not reply my last query.

Regards

sun_ray said:

This does not reply my last query.

Regards

Click to expand...

I explained you how to arrive on the delay constraint for an io2reg path. Without constraint you cannot find the violation with netlist alone.
Maybe if you could explain a bit more on what specifically your query is, i could add something.

Ro9ty

ro9ty said:

I explained you how to arrive on the delay constraint for an io2reg path. Without constraint you cannot find the violation with netlist alone.
Maybe if you could explain a bit more on what specifically your query is, i could add something.

Ro9ty

Click to expand...

We want a solution of a solution where violation may be present in a io2reg path where the input for that particular path was not constraint.

Regards

sun_ray said:

We want a solution of a solution where violation may be present in a io2reg path where the input for that particular path was not constraint.

Regards

Click to expand...

It is quite evident from the replies above that without constraining a path you cannot have timing reports. Without timing reports you cannot know whether it is violated or not.
Could you please explain a situation where you had a violation without constraining the path and also why you chose to not constrain it.
I think GLS can also find out about the violations in the io2reg paths but for that also you will need constraints.

Regards

pdude said:

It is quite evident from the replies above that without constraining a path you cannot have timing reports. Without timing reports you cannot know whether it is violated or not.
Could you please explain a situation where you had a violation without constraining the path and also why you chose to not constrain it.
I think GLS can also find out about the violations in the io2reg paths but for that also you will need constraints.

Regards

Click to expand...

Is there any way to get to know if some paths are not constraint so that after seeing the unconstraint path it can be constrained and synthesis can be run again.

How can GLS resolve this?

Regards

By default all input/output are unconstrained. Execute any timing command from/to the ports and they will state it is unconstrained.
You can assume it to be your first step before synthesis, although many times if the design is not so timing critical (expected) the you can go ahead with the synthesis without it and worry about closing the timing in STA phase later.
It is just like - You cannot start an auction unless you have mentioned the base price. You constrain it loosely and then as your design progresses and you observe violations (if any) you constrain it tighter.

GLS cannot help unless you constrain it too.

Ro9ty