Honored Contributor
Honored ContributorSetup checks only check that your data is at the latch register before the clock. It's the hold check that will determine if it's too fast.
Is this the worst case path? Note that DDR has some paths that can be ignored. For example, your set_output_delay constraints describe two sets of registers capturing data outside of the FPGA. So when the rising edge register in the FPGA launches data at time 0, it sends data to two registers, one which captures it on the falling edge and has a half cycle requirement, and a second one capturing it on the rising edge, and has a full cycle. TimeQuest will time this second path, and it could meet timing by more than a half cycle. Note that it's technically a false path, since the data is captured by the falling edge register, and new data is sent before the next rising edge data is ready to capture, but TimeQuest doesn't know this, and it just times the paths it sees. I used to recommend false pathing this, but it gets complicated, as this rise to rise is a false path for setup, but it's valid on the hold check. In essence, this setup is just less restrictive, and as long as the tighter path is being analyzed, I just ignore the looser one. (I don't know all the details of your clock relationships, so the rise/fall names I've used might be slightly off...)
