problem on set_output_delay

[Altera_Forum]

Hi ,everyone: 

 I use FPGA to send data DM642 via source-synchronous interface. DM642 uses built-in VPFE module to capture the output from FPGA. The datasheet of DM642 shows that the minimum setup time is 4.5 ns, and minimum hold time is 1 ns.  FPGA output clock is 50MHz. So the output clock period is 20 ns. To satisfy the setup time of VPFE, center-aligned SDR output seems to be a proper way to accomplish the job.  output max delay = clock offset – output skew, where clock offset is half the UI and I assign output skew 1 ns. This makes output max delay 9 ns.   output min delay = – unit interval + clock offset + output, and we can easily calculate output min delay as -9 ns.  My constraints are as follows:   --- Quote Start ---  set_output_delay -add_delay -max -clock [get_clocks {vpfe_pclk}] 9.000 [get_ports {VP_DB[0]}] set_output_delay -add_delay -min -clock [get_clocks {vpfe_pclk}] -9.000 [get_ports {VP_DB[0]}] set_output_delay -add_delay -max -clock [get_clocks {vpfe_pclk}] 9.000 [get_ports {VP_DB[1]}] set_output_delay -add_delay -min -clock [get_clocks {vpfe_pclk}] -9.000 [get_ports {VP_DB[1]}] set_output_delay -add_delay -max -clock [get_clocks {vpfe_pclk}] 9.000 [get_ports {VP_DB[2]}] set_output_delay -add_delay -min -clock [get_clocks {vpfe_pclk}] -9.000 [get_ports {VP_DB[2]}] ...  --- Quote End ---    However, the IO timing report reports setup error: https://www.alteraforum.com/forum/attachment.php?attachmentid=3911   Please somebody tell me the reason to this error. Thank you very much!

[Altera_Forum]

For timing source synchronous outputs using the system method (receiving device timing specified in tSU & tH), I use the following equations: 

 output max delay = external tSU + output skew  output min delay = external -tH + output skew

[Altera_Forum]

Hi, jimbo: 

Thank your very much for your quick reply!  However, the most thing I want to know is what kind of clock and data relation should I use; for example, center-aligned or edge-aligned? According to the parameter of the clock and data, I think choosing center-aligned is the best. Am I correct?

[Altera_Forum]

There's something I missed to mention ---- I use SDR to transfer the output to DSP, and I use a PLL to generate the output clock and data clock. All the manuals on set_output_delay constraint suggest shift the output clock by 90 degree when using DDR.  

 I shifted the output clock by 180 degree, then the IO timing errors vanished. However, the setup slack is 0.28 ns, and the hold slack is 1.72 ns. What else can I do to improve the margin?  What goes worse is clock hold slack has errors. There's the description of the problem: In module1, PLL1 generates clk1;  In module2, clk1 feeds PLL2 to generate clk2, and clk2 generates fifo_address_read signal; clk1 and clk2 are phase aligned; In module3, which constains module 1 and module 2, clk1 and fifo_address_read feed the FIFO instance's read clock pin and read address pin. The error indicates the path between launch clock clk2 and latch clock clk1, from the node fifo_address_read in module 2 to the node read address pin of FIFO instance has hold slack error of -1.952 ns.  It's wierd because I made clk1 and clk2 phase aligned. How can I fix this timing violation? Thank you very much.

[Altera_Forum]

And there's a big problem! 

 I haven't used Altera's Device before. After synthesis, I know that PLL can only be fed by external input clock. So I guess using a PLL to do the phase shift isn't practical because I didn't connect any IO to PLL dedicate inputs (I think they are CLK0~CLK3).  Directly output the data clock seems a way, then it all depends on the fitting to ensure the setup and hold timing meet DSP's needs.  Can any effort be made to save this design ?  =====  My way is to connect input clock to an LPM_INV to generate 180 degree phase shift output clock. The register to output setup and hold slacks are still the same as using PLL to do the 180 degree phase shift. So it all goes back to the second thread ----- How to improve the timing margin?

[Altera_Forum]

Well, sounds like you have a lot going on here. Let me see if I can address your concerns. 

 The output max delay (OMD) and output min delay (OmD) constraint values I mention above are the proper values for any alignment (edge or center), and for SDR or DDR. The slack calculation will take into account the Setup and Hold Relationships between the launch clock (which TQ knows since it is inside the device) and the latch clock (which you specify in your set_output_delay constraints).  Since you have to meet your 1 ns hold requirement, you may run into an issue using edge aligned, so yes center aligned (or close to that) would give you better timing margin.  Since you are driving the latch clock out of the device with a PLL, you have the ability to balance your setup and hold slack by changing the PLL clock output's offset value. To figure out how much to adjust your offset (from your current 180 degrees), use (hold slack - setup slack)/2.  If you are using any of Altera's newer device families, the PLL must be fed by a dedicated clock input, period. At least that has been my experience.  If you are not relying on the PLL to change clock frequencies for your source synchronous output clock (which it sounds like you are not), then the best way to invert the clock to drive this interface is to connect it to an ALTDDIO_OUT MegaFunction (1-bit width). Connect the clock to the clock input and the HI data input to GND and the LO data input to VCC, and this will not only invert the output clock for you, but will have the added benefit of having the lowest possible skew between your clock and data outputs. Of course the disadvantage of not using a PLL is that you lose the ability to balance your setup and hold slack by adjusting the clock offset.

[Altera_Forum]

--- Quote Start ---   Of course the disadvantage of not using a PLL is that you lose the ability to balance your setup and hold slack by adjusting the clock offset.  --- Quote End ---   If you also drive the data out using ALTDDIO_OUT blocks (connecting the same signal to both the HI and LO data input) then with the proposed inverted clock output your set-up and hold time will be well close to 1/2 clock period and thus quite well balanced. But at 50MHz even without ALTDDIO_OUT for the data and with the inverted clock output you will get plenty set-up and hold time if you can make sure that the output data is registered in the IO-cell (by setting Fast Output Register in the Assignment Editor).

[Altera_Forum]

That is a good point. When I talked about the lowest skew between output clock and data, I was assuming the data was driven out by ALTDDIO_OUT registers as well. This should be done as you say for SDR or DDR for the lowest skew. 

 When you use ALTDDIO_OUT MegaFuntions for your data outputs, you are forcing the use of output registers. Making the assignment of Fast Output Registers does not affect this, nor will making that assignment infer an ALTDDIO_OUT. It will only infer a single register output. The ALTDDIO_OUTs must be instantiated.

[Altera_Forum]

--- Quote Start ---  When you use ALTDDIO_OUT MegaFuntions for your data outputs, you are forcing the use of output registers. Making the assignment of Fast Output Registers does not affect this, nor will making that assignment infer an ALTDDIO_OUT. It will only infer a single register output. The ALTDDIO_OUTs must be instantiated.  --- Quote End ---   Depends:   In case of Cyclone:  ALTDDIO_OUT is done inside the logic fabric, but that doesn't matter as the clock has an equal delay in its path. (I have to check this for Cyclone IV where the ALTDDIO_OUT is done in the IO_cell?) In case of Stratix : ALTDDIO_OUT is done in the IO-cell, but again that doesn't matter as the clock out has equal delay. If no ALTDDIO_OUT is used then the register in the IO-cell is generated when the FAST Output Register is set for this output. Of course you do not need to make the Fast Output Register assignment when using ALTDDIO_OUT.

[Altera_Forum]

Hi: 

 josyb and jimbo, thank you very much for the excellent replies, I use Fast Output Register option in the Assignment Editor and the post-fit timing analysis seems okay. More advanced modification may be needed when I start to verify the design in hardware.  Thank both of you again!