- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
:mad:Hi,
I'm a newbie. And I am in a very annoying situation where I kept adding time constraint to my design and after i recompile, new timing violations popped up. Now my sdc file is looking pretty long and verbose. I don't know how can I put this to an end. Oh this is really driving me crazy. If you ever saw the movie The Butterfly Effect in which the man keeps correcting his past but only find something wrong happens elsewhere. You got what I meant. I guess one of the reason could be that after a tuning in TimeQuest, the some slacks for setup and hold time are still very close 0. Thus in the real compilation, the tool cannot optimize some paths(especially the paths not constrained enough for larger slack) and yield violations. Really appreciate any suggestion here.링크가 복사됨
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
And everytime after i tuned it, it shows no violation in TimeQuest. But after i did the compilation, it shows just a little more of them.
And this happens again and again.- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Hello,
1. Assuming that you have actually written timing exceptions in your .sdc file and did not use the Time Quest Analyzer GUI [using GUI does not insert the statements in you .sdc file, you need to manually insert the timing statement in your .sdc file] Each time you compile the design you the fitter places the registers etc. in different locations, so you may get timing violations if you have very tight timing constraints 2. In "Altera Wiki" Rysc has written a good guide to use Time quest Analyzer that might help you Good luck, AA- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
I'm a little concerned about your flow of seeing an issue, adding a timing constraint(to the .sdc, as alteraaditya points out) and then re-compiling. For the most part, all the constraints like multicycles and false paths should be entered up front to reflect how your hardware behaves. It certainly happens where users miss a constraint and have to add it in the back-end, but usually not too much. Are you sure the constraints being added are correct?
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Yes I also had a flow problem. I think majority of the people go into adding constraints only when an error shows up. I feel this is a very important point.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
What is very important? I woudl recommend entering constraints up front as much as possible. Besides making it easier to meet timing, I think the overall flow is easier. If you do it on the back-end, you need to re-analyze the logic, make sure it really is a multicycle of false path, and then enter the constraint. Instead, while you're designing and explicitly making logic that handles transfers as a multicycle of false path manner, that's when it's easiest to create the constraint. I'm not saying some of them get missed, but I wouldn't save it all for the back-end.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Adding constraints before is important rather than doing it on the back end.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
OK so I should've added most of the constraints before I even started the compiling?
Maybe I could add multicycle path before because I know where is the multicycle path in my design. But how should I constrain the delays and clock uncertainty without compiling first and knowing which path might give me violations?- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
And could you guys give me some hints on how to determing the multicycle path and false path in my design?
