Need Help to Verify Timing Constraints On Output Pins to External Device

[Altera_Forum]

Hi,  

 I'm relatively new in FPGA designing, so forgive me if my question seem simple.  The project I am working on involves using a Cyclone V to control 4 external DDS chips (AD9915). So I'm using the FPGA pins to send data to the DDS chips. I wish to clock my design at 156.25 MHz (which is period of 6.4 ns).   These DDS chips supply the 156.25 MHz clocks that I am using to clock my design in the FPGA. The DDS chip requires a setup time of 2 ns and hold time of 0 ns. (http://www.analog.com/static/imported-files/data_sheets/ad9915.pdf [pg 6])    I have read many reference online that specifies that a virtual clock has to be created for the 'set_output_delay' command to reference to. So just taking four pins from my design as an example, the SDC file looks like this. i have just attached a register with a constant value to these output ports just to verify the sdc file, also i put a 0 ns for setup and hold for the external device just to verify.  // These are the actual clock coming into the FPGA from the DDS create_clock -name {ddsclk1} -period 6.400 -waveform { 0.000 3.200 } [get_ports {dds_clk_1}] create_clock -name {ddsclk2} -period 6.400 -waveform { 0.000 3.200 } [get_ports {dds_clk_2}] create_clock -name {ddsclk3} -period 6.400 -waveform { 0.000 3.200 } [get_ports {dds_clk_3}] create_clock -name {ddsclk4} -period 6.400 -waveform { 0.000 3.200 } [get_ports {dds_clk_4}]  // These are virtual clocks I set up create_clock -name {ddsclk1_ext} -period 6.400 -waveform { 0.000 3.200 }  create_clock -name {ddsclk2_ext} -period 6.400 -waveform { 0.000 3.200 }  create_clock -name {ddsclk3_ext} -period 6.400 -waveform { 0.000 3.200 }  create_clock -name {ddsclk4_ext} -period 6.400 -waveform { 0.000 3.200 }   // and then the setup time and hold time (I have set them to 0 just to verify) set_output_delay -clock { ddsclk1_ext } -max 0.000 [get_ports {func_pin_1[0]}] set_output_delay -clock { ddsclk1_ext } -max 0.000 [get_ports {func_pin_1[1]}] set_output_delay -clock { ddsclk1_ext } -max 0.000 [get_ports {func_pin_1[2]}] set_output_delay -clock { ddsclk1_ext } -max 0.000 [get_ports {func_pin_1[3]}] ......... and the same thing for ddsclk2,3,4_ext for func_pin_2,3,4      set_output_delay -clock { ddsclk1_ext } -min 0.000 [get_ports {func_pin_1[0]}] set_output_delay -clock { ddsclk1_ext } -min 0.000 [get_ports {func_pin_1[1]}] set_output_delay -clock { ddsclk1_ext } -min 0.000 [get_ports {func_pin_1[2]}] set_output_delay -clock { ddsclk1_ext } -min 0.000 [get_ports {func_pin_1[3]}] ......... and the same thing for ddsclk2,3,4_ext for func_pin_2,3,4   I have also set the false paths between the four clock domains. However, when I compile my very simple design and run TimeQuest, TimeQuest reports that my setup slacks for ddsclk1,2,3,4_ext are negative. I find these strange and would expect Cyclone V to be able to run at much faster speed than 156.25 MHz, moreover my design now is just a reg to the output port.  http://www.alteraforum.com/forum/attachment.php?attachmentid=10148&stc=1   So, I am suspecting that I did not constrain the design properly. Hope anyone can give their two cents on the way I did the timing constraints.  Thanks in advance!

[Altera_Forum]

SDC constraints are a description of how your design is supposed to work, so there are no hard and fast rules without knowing the actual design. 

1) If your design treats transfers between these domains as synchronous and if they don't behave that way then the design won't work, then the design won't work(this is by far the most common case). But some systems are designed to treat them as asynchronous, in which case it's fine. For example, a user may have IP with asynch FIFOs between the domains, and so it can handle them being different domains, but the user just so happens to hook them up to the same(or synchronous) domains. In that case they could be treated asynchronous and the design will work. 2) No. I have seen cases where the user drives the same clock into two different clock pins and treat them as synchronous(I don't remember why). But in that case the source input port is different, but the true source outside of the FPGA is the same, which is why it works. Some users don't like to put asynchronous clock assignments between asynchronous clocks though. Instead, they put a false_path between any transfers that go between these domains. The benefit is if a designer hooks something up incorrectly and passes between domains but doesn't realize it, there won't be a false path on that path and it will most likely fail timing. They'll then analyze the failing path, see there is a mistake in the code and fix it. (This works most of the time but not all the time. Let's say the design has two 6ns clocks coming from different sources, so they have no phase relationship and must be treated as asynchronous. In the TimeQuest description they will have a 6ns setup and 0ns hold, and an errant path hooked up between them might actually pass timing and therefore not show up in red.)

[Altera_Forum]

--- Quote Start ---  I strongly believe it is possible for DDR to have slacks more than half period (UI) for either setup or hold and that is direct outcome of setting false paths between unrelated edges. You should not think of DDR clock as equivalent to SDR at double rate clock in which case it is not possible. The DDR will have two registers to de-interleave data and so changes are ignored by one edge or the other.  --- Quote End ---   OK. I think this makes sense. I wasn't taking into account the topology of the DDR cell. So now I'm a bit more sure (or less unsure) that it's possible to have slacks greater than UI (but less than period). I will try to do my analysis/tests again having this in mind. I'll post the results.    --- Quote Start ---  Regarding same edge Vs opposite edge latching, you are free to try either and see which one passes. Once you choose one case then your design must be aware of it. Remember a stream of Hdata => Ldata if sampled on same edge will retain the sequence and if you decide on opposite edge transfers then the sequence becomes Ldata => Hdata and as long as you interleave/deinterleave back correctly then it should work.  --- Quote End ---   I'm ok with this. The external device has a parity check that can be used to see if it's receving the data in the right way or not. If not, I can swap Ldata with Hdata to align it correctly.    --- Quote Start ---  If you don't set false paths on irrelevant edges then slack must be less than UI and this is unrealistically too restrictive.  --- Quote End ---   Thanks!

[Altera_Forum]

Hi Ryan, Hi Everybody,  

 thanks alot for your answer. The guides written by you and your comments are helping me understand Timing issues.   In the document "TimeQuest User Guide" there is a very interesting example with the clock groups, page 12 "Quick tip for writing set_clock_groups constraint". I am not sure about some parts of the example.   1) The clock system_pll|..|clk[2] with 50 MHz is asynchronous to the pll outputs 125 MHz system_pll|..|clk[0] and system_pll|..|clk[1]. That's ok for me.  But why is the_adc_pll|..|clk[1] with 200 MHz and the_adc_pll|..|clk[1] with 300 MHz (in the example even 300.03 MHz and 3.333 ns) in the same clock group?  2) I have a pll with clock input 25 MHz. The clock outputs are  - 75 MHz (in the "Clocks Summary" shown as 75.0 MHz, 13.333 ns) and  - 150 MHz (150.02 MHz, 6.666 ns).  Are the 25 MHz, 75 MHz and 150 MHz clocks in the same clock group? Actually I think that they should be synchronous, because 25 Mhz x 3 = 75 MHz. But how can the periods of 40 ns and 13.333 ns be synchronous?  Thanks alot! With kind regards!

[Altera_Forum]

Didn't even notice that. Yeah, a 200Mhz and 300Mhz clock would not be related. 

In some instances it's clear from the clock frequencies that they just can't be related. But it's also design dependent. Let's say you bought IP that had two clocks that could be asynchronous, and you feed it with a 100Mhz and 50Mhz clock that are aligned, you could still cut timing between them because the design treats them that way. In your case: - Have the PLL output 25MHz too. Don't use the 25MHz before the PLL as that will be a different phase than if it goes through the PLL. - Does your design have paths between 25MHz and 75MHz? If so, does it treat them as synchronous? They can be synchronous because they do have similar edges. By default you will have a 13.333ns setup relationship between the domains. But from a transfer perspective, you have 3 clocks of the 75MHz for every 1 clock of the 25MHz, so make sure it can handle this. If passing "data", it can be difficult. If passing control signals that are slow, then it might be fine.