TimeQuest trouble

What you have is a source synchronous center-aligned output case. If the $clk_125_p90 is the clock out of the PLL, you need to create another generated clock (e.g. clk_125_p90_out) and assign it to the output port that drives the clock out of the FPGA. This is the clock you will use to constrain your outputs to. I would suggest using set_output_delay constraints as follows:

set_output_delay -max OMD -clock {clk_125_p90_out} -add_delay [get_ports {data_out*}]

set_output_delay -min OmD -clock {clk_125_p90_out} -add_delay [get_ports {data_out*}]

where OMD = external device's tSU + max board clock-data skew,

OmD = external device's -tH + min board clock-data skew,

and data_out* are the data output port names for the data that goes with the output clock.

If this DDR, then you will also need to constrain to the falling edge of the clock.

set_output_delay -max OMD -clock {clk_125_p90_out} -add_delay -clock_fall [get_ports {data_out*}]

set_output_delay -min OmD -clock {clk_125_p90_out} -add_delay -clock_fall [get_ports {data_out*}]

One last thing. If this is DDR, then you will be using same edge capture, so you will need to add some set_false_path statements:

set_false_path -setup -rise_from [get_clocks {clk125}] -fall_to [get_clocks {clk_125_p90_out}]

set_false_path -setup -fall_from [get_clocks {clk125} -rise_to [get_clocks {clk_125_p90_out}

set_false_path -hold -rise_from [get_clocks {clk125}] -rise_to[get_clocks {clk_125_p90_out}]

set_false_path -hold -fall_from [get_clocks {clk125}] -fall_to[get_clocks {clk_125_p90_out}]

Of course... I've just looked at the Data path and I realized that I have to constrain everything including the I/O buffer delays.

What's worse, both clk125 and clk125_p90 are fed through muxes, so the clock network delay is pretty high (considering it's using interconnect now for clock routing)...

Thanks!

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.

Ok, I think I understood well, but I read the datasheet for Marvel and it's really written badly - no options for timings, so I guess it has to be like this (btw, this is GMII interface, not RGMII - it doesn't trigger on both edges). However, setup and hold times are fairly loose, so I just needed to know how to constrain them in TimeQuest.

The I/O buffer I was talking about is the delay of the FPGA I/O pin itself + interconnect delay to it (and it ain't little - ~2.5 ns, maybe even 3 ns), so I was thinking I can use create_generated_clocks and constrain the real output clock and data with set_output_delay. This way, Quartus can make sure that external timing constraints are met.

The PLL is another thing. As I said, I have a PLL generating clk125 and clk125_p90. Ok, so we have 90 deg phase shift between. The problematic part is that both of these two clocks are fed to Nios (MAC) and PHY through 2to1 muxes (because in GMII mode, for TX lines, PHY is producing 10/100 clocks, while MAC is supposed to generate 1 Gbit clock back to the PHY). Now, constraints for my analysis should start after these muxes (interconnect delay could kill the phase shift, or make it bigger), so that everything should be ok.

I think I've got it. I'll give it a go tomorrow, and I'll post back if something's wrong. Thanks guys.

Hi,

use ALTCLKCTRL for clock muxing instead of general logic.

The constrains need to describe what's going on and what you need at the FPGA's pins, in terms of timings.

Then it's up to the tools to synthetize a design that meets them.

Don't try to control the timing in the FPGA "manually".