Honored Contributor
Honored ContributorThanks much for your reply.
--- Quote Start --- 2 or 3 ns is commonly encountered in many devices for clock or data delay (io or internal) so I think you should tackle your timing problem away from this assumption that you must reduce delay. as long as both clock and data are delayed then it doesn't matter what delay is within practical latency range. --- Quote End --- I do agree with you that "as long as both clock and data are delayed then it doesn't matter", after all, routing resources are limited, clock and data may need both to route through a long way. I designed IC long before, i do not remember how fast signal transfers through metal or polysilicon etc, but i do know how fast signal transfers on a FR4 board, that is around 170ps/in, 3ns indicates 17 inch! 17 inch is a very long routing in PCB design! Of course, that is not the key of my problem. My problem is that clock and data are not delayed identically, that is the reason why TQ reporting timing violation and my posting this thread. data arrival path has a large IC delay compared to clock path and clock skew at the source and destination node is either not same. And my another concern is that when i physically put source and destination node together, the IC delay does not decrease at all! and this looks unreasonable to me. according to CV datasheet, there should be lot of local interconnect resource to connect adjacent node. In my problem, DDIO input register in IOE and LAB are driven both by the same 240MHz, TQ reports setup time is violated. Please refer to the attachment to see the waveform. Best Wishes, ingdxdy
