TimeQuest trouble

I believe the RGMII spec(if that's what you're doing) doesn't ask for a 90 degree phase-shifted clock, but actually wants them edge aligned coming out of the transmitter, and then the board is supposed to be laid out whereby the clock trace is 90 degrees(2ns) longer than the data path. The benefit of this is that the clock that is being sent out is the same one that clocks out the data, hence it goes through the same mux and all those delays cancel out.

I have seen numerous people miss this part of the spec and not do that on their boards. Luckily many PHYs have an option to say the clock and data are coming in edge aligned, and hence the PHY will actually shift the clock. (I even think the RGMII spec was updated to have this as a second option)

I'm not sure what you mean by having to constrain the I/O buffer delays. If set up correctly(i.e. listen to Jimbo), then all the internal delays will be handled for you. One thing to make sure if is that your generated clock's source is generally the output of the PLL driving it. When you do timing analysis, i.e.:

report_timing -setup -npaths 100 -detail full_path -to [get_ports {doutname[*]} -panel_name "TSE outputs||setup"

report_timing -hold -npaths 100 -detail full_path -to [get_ports {doutname[*]} -panel_name "TSE outputs||hold"

Note that I put in -detail full_path. be sure to look at the Data Arrival Path and make sure it captures the entire path through the FPGA to create the clock.

One final thing is that the RGMII spec(and probably GMII) tell you what the transmitter needs to do, i.e. it doesn't give a setup/hold requirement on the receiver, so you can't directly use the equations above to calculat OMD and OmD. It's important to understand what's going to happen:

You've phase-shifted the latch clock 90 degrees(2ns), so you will have a setup relationship of 2ns and hold relationship of -2ns. Check this in the report_timing commands I entered. That basically means your data can be skewed by +/-2ns compared to the clock coming out of the FPGA. Your OMD and OmD say how much of that skew is used externally, so if you set those to +/-750ps, that would mean the FPGA is left with +/-1.25ns that it can skew the data in relation to the clock. I find this relationship important to understand. The setup relationship is determined by your clock relationships. That is how much the data can be skewed later than the clock and still make timing. Then the OMD takes a chunk out of that, and the rest is left over for the FPGA. The converse is true for the hold relationship and OmD.