TimeQuest时序分析.ppt

* * * * If you must report the timing of the asynchronous signals, you could add the constraint. It is just used to report, not the design. * Instead of resetting the state machine back to your idle state, you send it to some other state, possibly an illegal one. * Now we are going to fo through most of the paths you will have in your design and see check what SDC timing constraints we would apply to these situations. * Example, you have a path that is part of test logic. The only reason the path is used, is when you are in a test mode in which the clock frequency is actually lower than the design frequency. These paths you would want to fitter to exclude from analysis. * * * * * Now we are going to fo through most of the paths you will have in your design and see check what SDC timing constraints we would apply to these situations. * * * * * * * * * * * * In the case of the source synchronous interface, instead of giving you a device’s external clock-to-output times, you are given an output waveform diagram (or similar) that reflects the relationship of the incoming clock to the incoming data. Your inputs must then be able to receive the data transmitted correctly. To do this, you must derive your set_input_delay –max -min settings. * If they want to see it derived: (1) input delay max = Board Delay – Board clock skew + Tco(max) (2) slack = required time - data arrival time If slack is set to zero, then: (3) data required time = data arrival time Thus, (4) latch edge – Ttotal_tsu = launch edge + input delay max And (5) Input delay max = latch edge – launch edge – Ttotal_tsu For hold (3) still applies: (3) Data required time = data arrival time Thus (6) Latch edge + Ttotal_th = launch edge + input delay min Since latch and launch are typically 0 (7) Input delay min = Ttotal_th * If they want to see it derived: (1) input delay max = Board Delay – Board clock skew + Tco(max) (2) slack = required time - data arrival time If slack is set to zero, then: (3)