cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
7,606 Views
Registered: ‎08-23-2011

hold time violations in MAP report but PAR report is clean ...

Jump to solution

hi,

 

i have a design which im building in ISE 10.1 (win XP).

 

when i look at the post map report, i have some 21 hold violations but 0 setup violations. but ISE did not throw any errors for hold violations on it's own and continued normally.

 

when i run PAR and look at the post route timing report, the timing report is clean without any setup or hold violations.

 

ISE is not throwing any errors in the map stage because of the hold violations.

 

so my questions are -

 

1) is it ok for for ISE to not throw any error for hold violations in MAP? does it only throw errors for setup violation?

2) is it fine for the map timing report to have hold violations but PAR timing to be clean? I guess the hold violations could be removed in PAR due to the routing and buffering. so is my understanding correct? or is something else going on here?

 

please do let me know ...

 

z.

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
9,919 Views
Registered: ‎01-23-2009

Re: hold time violations in MAP report but PAR report is clean ...

Jump to solution

A TIMING_IMPOSSIBLE is determined at map time. Basically, if the tools have found a path where the sum of the component delays alone (i.e. with all routing assumed to be instantaneous) is more than the required time for the path. It is only done on setup checks.

 

So, if you have 200 LUTs on a combinatorial path that has a constraint of 5ns, then it will add up the Tilo delays on the path and come up with a delay of significantly more than 5ns. That means that no matter how it places it and no matter how it is routed, there is no way that this path can meet timing. It "errors out" on the TIMING IMPOSSIBLE instead of wasting 24 hours getting the "best it can".

 

The only reason to set the XIL_TIMING_ALLOW_IMPOSSIBLE is to get the tools to generate the final outputs so that you can investigate the path. It will not, can not, and never will pass timing.

 

Conversely, if the design doesn't have an "impossible path" (one where the component delays alone exceed the requirement), the XIL_TIMING_ALLOW_IMPOSSIBLE has no effect at all. It is completely irrelevent. So, (as others have said), if the tool completes with no timing errors (or even "reasonable" timing failures) then the XIL_TIMING_ALLOW_IMPOSSIBLE is irrelevent - having had it set made no difference to the placer/router/etc... and the results are completely valid.

 

As for post-map hold violations - they are completely meaningless. Before routing, net delays are merely estimates. As a result, the tool does not even attempt to fix (minor) hold time "violations" since the delay of the routing is purely an estimate, and the real routing is going to be different. Even more, the router is going to intentionally take circuitous paths for routes involved in hold time violations to fix them.

 

The post map timing report neither ignores nor acts on setup/hold violations. The report itself is merely a mid-point report for you to look at. The placer is timing aware and does the "right thing" for the placement process (or at least the best it can do), and then generates the map report and assumes that you will then route the design. If the post map (i.e. placed) netlist has potential timing problems then either they will be fixed in PAR (by routing), or they won't, at which point you will get a failure in the real timing report generated after PAR.

 

In general, the only thing the post-map timing report is for is to see if you are in the right ball park, and hence its worth continuing to PAR. If the post-map timing analysis indicates that all paths are within a few percent of passing, then go ahead and run PAR. If the post-map timing analysis tells you that you have a setup violation that is large compared to your requirement (i.e. more than 25%+ of your clock period), then you might as well give up now - PAR won't be able to fix it so don't bother running PAR. Go back and change your RTL code and try again.

 

Avrum

View solution in original post

8 Replies
Highlighted
Scholar
Scholar
7,605 Views
Registered: ‎06-05-2013

Re: hold time violations in MAP report but PAR report is clean ...

Jump to solution

Hello,

 

I would suggest you to please check the post routed timing summary,if it doesnt have any violations then your design is meeting timing.

-Pratham

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Teacher
Teacher
7,591 Views
Registered: ‎03-31-2012

Re: hold time violations in MAP report but PAR report is clean ...

Jump to solution
1) Timing is not final till the finalization of PAR so MAP timing violations (setup or hold) are not errors (except when they are "impossible")
2) Yes, yes, no.
- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Highlighted
Explorer
Explorer
7,587 Views
Registered: ‎08-23-2011

Re: hold time violations in MAP report but PAR report is clean ...

Jump to solution

Thanks for the inputs, it does help clarify the question.

 

But on a related note - 

 

If timing is impossible to meet and if I set the XIL_TIMING_ALLOW_IMPOSSIBLE = 1, then how should the tool behave?

 

1) Should the post MAP and PAR timing reports still show the timing violations and still ISE should complete implementation?

 

 

2) If, with XIL_TIMING_ALLOW_IMPOSSIBLE = 1, post PAR timing report is clean, then does it indicate that the design is fine or does it indicate that the report was not generated properly because the the set environment variable

 

3) How can I unset the XIL_TIMING_ALLOW_IMPOSSIBLE = 1? I've tried unset(<env variable>), set <env variable> 0 etc. but how can I confirm if this variable is being reset and not interfering with the build anymore.

 

Thanks,

Z.

 

0 Kudos
Highlighted
Teacher
Teacher
7,583 Views
Registered: ‎03-31-2012

Re: hold time violations in MAP report but PAR report is clean ...

Jump to solution
1) It's been a while since I run ISE so I am not sure what it does if PAR reports timing not met.
2) If post PAR timing is clean, it means timing is clean. This variable does not interfere with the quality of results after PAR.
3) Depends on how you set it. If you manually set it, just kill your shell and open another one. If it is in your shell init, remove it and open a new shell. Setting it to zero may not work.
- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Highlighted
Explorer
Explorer
7,579 Views
Registered: ‎08-23-2011

Re: hold time violations in MAP report but PAR report is clean ...

Jump to solution

Thanks for the replies.

 

I set the XIL_TIMING_ALLOW_IMPOSSIBLE variable in the TCL window in ISE.

 

I tried to unset this in the TCL shell, cleaned the project, restarted the machine etc. to clear out this variable. Im not sure if it's taken effect or not.

 

If XIL_TIMING_ALLOW_IMPOSSIBLE = 1, then will it ignore hold time violations? Or does the post MAP timing report ignore hold and/or setup violations in general? 

 

I guess what I'm trying to ask is - what is considered a timing constraint impossible to meet - setup/hold violations or something else?

0 Kudos
Highlighted
Teacher
Teacher
7,575 Views
Registered: ‎03-31-2012

Re: hold time violations in MAP report but PAR report is clean ...

Jump to solution
As far as I know impossible means that the logic delay is longer than the period which obviously can't be fixed by PAR. This suggests only setups can be impossible.

Also I don't see any reason not to run with this variable at all times as you need to check for the post PAR timing results anyway.
- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
Highlighted
Guide
Guide
9,920 Views
Registered: ‎01-23-2009

Re: hold time violations in MAP report but PAR report is clean ...

Jump to solution

A TIMING_IMPOSSIBLE is determined at map time. Basically, if the tools have found a path where the sum of the component delays alone (i.e. with all routing assumed to be instantaneous) is more than the required time for the path. It is only done on setup checks.

 

So, if you have 200 LUTs on a combinatorial path that has a constraint of 5ns, then it will add up the Tilo delays on the path and come up with a delay of significantly more than 5ns. That means that no matter how it places it and no matter how it is routed, there is no way that this path can meet timing. It "errors out" on the TIMING IMPOSSIBLE instead of wasting 24 hours getting the "best it can".

 

The only reason to set the XIL_TIMING_ALLOW_IMPOSSIBLE is to get the tools to generate the final outputs so that you can investigate the path. It will not, can not, and never will pass timing.

 

Conversely, if the design doesn't have an "impossible path" (one where the component delays alone exceed the requirement), the XIL_TIMING_ALLOW_IMPOSSIBLE has no effect at all. It is completely irrelevent. So, (as others have said), if the tool completes with no timing errors (or even "reasonable" timing failures) then the XIL_TIMING_ALLOW_IMPOSSIBLE is irrelevent - having had it set made no difference to the placer/router/etc... and the results are completely valid.

 

As for post-map hold violations - they are completely meaningless. Before routing, net delays are merely estimates. As a result, the tool does not even attempt to fix (minor) hold time "violations" since the delay of the routing is purely an estimate, and the real routing is going to be different. Even more, the router is going to intentionally take circuitous paths for routes involved in hold time violations to fix them.

 

The post map timing report neither ignores nor acts on setup/hold violations. The report itself is merely a mid-point report for you to look at. The placer is timing aware and does the "right thing" for the placement process (or at least the best it can do), and then generates the map report and assumes that you will then route the design. If the post map (i.e. placed) netlist has potential timing problems then either they will be fixed in PAR (by routing), or they won't, at which point you will get a failure in the real timing report generated after PAR.

 

In general, the only thing the post-map timing report is for is to see if you are in the right ball park, and hence its worth continuing to PAR. If the post-map timing analysis indicates that all paths are within a few percent of passing, then go ahead and run PAR. If the post-map timing analysis tells you that you have a setup violation that is large compared to your requirement (i.e. more than 25%+ of your clock period), then you might as well give up now - PAR won't be able to fix it so don't bother running PAR. Go back and change your RTL code and try again.

 

Avrum

View solution in original post

Highlighted
Explorer
Explorer
7,568 Views
Registered: ‎08-23-2011

Re: hold time violations in MAP report but PAR report is clean ...

Jump to solution

Brilliant!

 

Thanks avrumw and muzzafer. This clarifies everything! 

 

kudos to you both!

 

z.

0 Kudos