--- Quote Start ---
Hi Kaz,
I think I agree with you that the hold should be 0 for this case. However, I don't believe there should be a timing violation for this case.
To check the hold time, the data arrival time should be greater than the the data required time. The data required time is calculated by Latch Edge + dst_clk_dly as shown in the screen capture.
https://alteraforum.com/forum/attachment.php?attachmentid=14283&stc=1 In the case, because the data is feedback to its own input, the dst_clk_dly or any clock uncertainly should be removed, which means the required time is only the latch edge plus the uTh. So the require time is 0.212, not 0.712. The data arrival time is 0.658. So there's violation.
https://alteraforum.com/forum/attachment.php?attachmentid=14284&stc=1 This make sense to me, because the input data and the clock are related to each other now. The input to this register only changes after its own clock changes. And both changes are referred to the same time (latch time =launch time). So all kinds of dst clock delay and clock uncertainly should also be applied to the data input, or don't use the delay and the uncertainly at all.
Since it is for the same node (clk_out). I think it's better to assign a node to node false path.
--- Quote End ---
Again I disagree, the tool is mature enough to do the job and not depend on user to rectify it. clock uncertainty is still relevant but common clock path pessimism will be removed.
Honored Contributor
