DDR Output Constraining - "too positive" slack

[Altera_Forum]

Hi, 

 I hope someone knows the solution to the problem that kept me really busy lately :(  I have to connect to an RGMII PHY that has the following parameters:  tCLK = 8 (ns) TskewR (Data to Clock input Skew) (at the PHY) : min 1.0 max 2.6 (ns) (from the RGMII datasheet)  I am supposed to meet the PHY requirements without the use of PLLs.  The problem I have is that Quartus gets a "too positive" slack - of more than 1/2 of tCLK - and still reports this slack as correct. In practice this kill sme since data would be captured with the wrong edge. Is there a way to specify a maximum slack? Are my constraints incomplete?  Attached is a TimeQuest wave report.  I used the following constraints: # ################ # derive_pll_clocks # # derives the pll_out[0] that will be used as output clock create_generated_clock -name mtx_clk_ddr -offset 0 -source {pll_out[0]} [get_ports {mtx_clk_pad_o}]  set outclk "pll_out[0]" set outclk_ddr "mtx_clk_ddr"  set_false_path -rise_from $outclk -fall_to $outclk_ddr -setup set_false_path -fall_from $outclk -rise_to $outclk_ddr -setup set_false_path -rise_from $outclk -rise_to $outclk_ddr -hold set_false_path -fall_from $outclk -fall_to $outclk_ddr -hold  set_output_delay -clock $outclk_ddr -max 2.6 [get_ports {mtxd_pad_o [*] mtxen_pad_o}] set_output_delay -clock $outclk_ddr -min -1.0 [get_ports {mtxd_pad_o [*] mtxen_pad_o}] set_output_delay -clock $outclk_ddr -clock_fall -max -add_delay 2.6 [get_ports {mtxd_pad_o [*] mtxen_pad_o}] set_output_delay -clock $outclk_ddr -clock_fall -min -add_delay -1.0 [get_ports {mtxd_pad_o [*] mtxen_pad_o}]   Thanks!

[Altera_Forum]

Setup 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...)

[Altera_Forum]

Hi again! 

 Rysk, should I understand from your comment that too big slack is allowable? Attached to this post I have an oscilloscope capture of the mentioned signal against the clock. The signal (pink wave, TX_EN) should be sampled with the rising edge of the clock... here I see the clock some 1.6 ns ahead of the data so wrong edge will sample it...  The slack is for the slow device operation. And... I have the same huge positive slack for the falling edge of the signal too (coming from thesecond register) so I guess the 1st/2nd path case does not apply in this case...  Can you please direct me how to correct this behaviour? I am quite new to TimeQuest and constraining... :confused:

[Altera_Forum]

dipling, 

 Check this: http://www.altera.com/literature/an/an477.pdf  As mentioned on that note, most PHY devices have an option to center-align the clock. Without a PLL to shift the clock at the FPGA, it would be very difficult to meet timing otherwise. This is valid both for the transmitter side and the receiver side (as in your other post).

[Altera_Forum]

If your launch register is feeding two external registers, then the latter might have a lot of slack, which is fine. It's the tighter constraint that is th one you want analyzed. If this is the tighter path, than something seems incorrect, as there should be a path to the falling edge register with a requirement of 4.444ns. 

I'm guessing your false paths are incorrect. For example, you have a false-path with "-setup -from rise_from -to fall_to", so in essence you're cutting the path I'm talking about. I would comment out/remove those false paths and try again. (Those false paths are usually for ignoring timing on the less restrictive paths, i.e. the launching edge has a setup requirement of 4.444ns to the falling edge register and 8.888ns to the rising edge one. The latter can be ignored, but it also doesn't hurt to leave it in, since you know if you meet timing to hte 4.444ns, you'll meet the 8.888ns requirement.)  Finally, analyze what it's saying. When a clock comes into the FPGA, the clock delay to the source register is 3.592ns and the data delay out is 3.981ns, so it takes 7.573 to get the data out, while the clock takes 6.759ns. This is the "latest" the data could get out compared to the clock. You'll also need to analyze -hold to see the earliest it could get out. This at least should give you a better sense of what things look like.

[Altera_Forum]

--- Quote Start ---  dipling,  Check this: http://www.altera.com/literature/an/an477.pdf  As mentioned on that note, most PHY devices have an option to center-align the clock. Without a PLL to shift the clock at the FPGA, it would be very difficult to meet timing otherwise. This is valid both for the transmitter side and the receiver side (as in your other post).  --- Quote End ---    Thanks for the reference, I already read this several times :-D but as I said, PLLs are not an option. I will have a number of 8 phys connected to the FPGA and at most 2 available PLLs... besides, each tx clock will range between 2.5 and 125 mhz so... I am "constrained" to a maximum of 0 PLLs :-D

[Altera_Forum]

125MHz should work without a PLL...

[Altera_Forum]

--- Quote Start ---  Thanks for the reference, I already read this several times :-D but as I said, PLLs are not an option.  --- Quote End ---    You are misunderstanding my point. The phy device can center-align the clock for you, at least most PHY have that capability. My point was that if you don't use a PLL to shift the clock, then you should enable the clock delay on the PHY. And that with none of them (no PLL shift in the FPGA, and no clock delay at the PHY), then meeting timing would be very difficult.  Regarding your exact TimeQuest issue, I think you are missing the multicycle exception statement (Rysc would correctly if I'm wrong). But again, constraints would be completely different with or without the PHY clock delay.

[Altera_Forum]

--- Quote Start ---  125MHz should work without a PLL...  --- Quote End ---    Are you sure? I made a small test and I couldn't meet timing.  Note that per RGMII specs, the clock must be delayed and center aligned. To comply with the specs without a PLL (and without enabling the PHY clock delay), I had to insert a bunch of LCELLS before the clock output. Then I could meet timing at either the slow or fast model, but not at both.  The main problem seems to be that the PVT variation of the LCELL delay-chain is too much. And the fact that he is using a Cyclone II without hardware DDIO support doesn't help. But it was a quick test, I might have missed something.

[Altera_Forum]

Thanks guys for the help!  

 I was able to fix the RGMII input without a PLL by inserting LCELLs but that is not a reliable solution. Quartus does not add such delays when simply constraining tSU/tH (gives up and reports negative slack), they have to be added manually and they can only meet fast or slow device... and the case here was that the system was unstable over time... Perhaps one can play with the delays for a single FPGA-PHY combination and find the "perfect" delay parameters, but for a larger volume with faster and slower FPGAs...   I gave up with RGMII, most likely will go with GMII PHYs.

[Altera_Forum]

--- Quote Start ---  I gave up with RGMII, most likely will go with GMII PHYs.  --- Quote End ---    Did you consider adding 1 pipeline cycle and swapping the data for high and low clock edges?  I don't recall all the (r)GMII details, but IIRC you can insert an extra cycle on the transmitter pipeline. The idea is to transmit on the opposite edge of the clock. This way you wouldn't need to delay the clock, because data would naturally be delayed with respect to the clock.

[Altera_Forum]

--- Quote Start ---  Did you consider adding 1 pipeline cycle and swapping the data for high and low clock edges?  I don't recall all the (r)GMII details, but IIRC you can insert an extra cycle on the transmitter pipeline. The idea is to transmit on the opposite edge of the clock. This way you wouldn't need to delay the clock, because data would naturally be delayed with respect to the clock.  --- Quote End ---    And inverting the output clock... data is edge sensitive in RGMII. yes, that was taken into account. Decision involved some other factors as well. Thanks for the help!