Problem with Data Integrity & Clock between 2 FPGAs

--- Quote Start ---

I hoped that half of clock cycle is sufficient for all delays

--- Quote End ---

Why hope when you can "design"?

Did you create a TimeQuest .SDC file? If not, its time to learn.

The synthesis tool will make no attempt to meet external timing if you do not provide it the information it needs to understand what the external timing requirements are.

Cheers,

Dave

Thanks Dave

Well, actually I have the .SDC constraint file, but I constrained only clocks & clock uncertainties, not input & output delay constraints (using set_input_delay & set_output_delay).

Since I used Fast Input/Output Registers in my design, The t_co & t_su should be minimal (how much minimal? I don't know how to utilize TimeQuest for this parameter, but according to an_366 I don't think it will be more than 1 ns).

PCB delays should be about 166*0.5=83 ps at most. Summing up all delays I get at most 2 ns delay. Comparing with 10 ns (half of 50 MHz clock period) it is negligible. So I think input & output delay is not required. Am I right? Did I illustrate my point?

--- Quote Start ---

Did I illustrate my point?

--- Quote End ---

Yes. However, you should never "assume" anything. The tool *can* analyze the interface timing, so you *should*.

My recommendation is to write an SDC file that includes the FPGA I/O timing requirements. Here's an outline for you ...

#  Timing parameters
set data_tsu     1.0
set data_th      1.0
set data_tco_min 0.0
set data_tco_max 6.0
#  Timing constraints
set data_input_delay_min    $data_tco_min
set data_input_delay_max    $data_tco_max
set data_output_delay_min  -$data_th
set data_output_delay_max   $data_tsu
#  Bidirectional buses
set data_io 
}]
#  Inputs
set data_i 
}]
#  Outputs
set data_o 
}]
#  Bidirectional buses
set_output_delay 
    -clock vclk_50MHz 
    -min $data_output_delay_min 
    $data_io
set_output_delay 
    -clock vclk_50MHz 
    -max $data_output_delay_max 
    $data_io
set_input_delay 
    -clock vclk_50MHz 
    -min $data_input_delay_min 
    $data_io
set_input_delay 
    -clock vclk_50MHz 
    -max $data_input_delay_max 
    $data_io
#  Inputs
set_input_delay 
    -clock vclk_50MHz 
    -min $data_input_delay_min 
    $data_i
set_input_delay 
    -clock vclk_50MHz 
    -max $data_input_delay_max 
    $data_i
#  Outputs
set_output_delay 
    -clock vclk_50MHz 
    -min $data_output_delay_min 
    $data_o
set_output_delay 
    -clock vclk_50MHz 
    -max $data_output_delay_max 
    $data_o

You'll need to edit this to define data_i, data_o, and data_io correctly. You'll also need to define your clocks correctly, eg., the output clock you generated. Take a look at this DE0-nano SDRAM example

http://www.alteraforum.com/forum/showthread.php?t=45927

There's an SDC file in that project that defines the SDRAM clock, and SDRAM I/O timing parameters. Since an FPGA data sheet does not really have a fixed set of timing parameters, use the ones I've given you above to start with, and then iterate as needed.

The other thing you can do is to look at the signals with a scope.

NOTE: You will need two different SDC files, one for each FPGA project.

Cheers,

Dave

Thanks a lot.

I will do so and get back (hopefully to tell my problem is resolved!).

I applied input_delay & output_delay constraints, thanks to your SDC guidelines.

In Cyclone III spreadsheets, t_su is negative. I inserted its value as a positive value.

t_h is copied from spreadsheet.

t_co is calculated according to Method-2 of AN-366.

After synthesis & programming FPGAs, still I have problem with data corruption.

What could cause problem?

Is sending out clock from a normal IO pin a good design practice?

One more question: Isn't it better that I feed FPGA-1 with clk1, instead of clk2? i.e. without 180 degree phase shift? is this phase shift in compliance with our constraints?

What about output currents? is there a guideline to set output current? specially for clocks?

Thanks

--- Quote Start ---

I applied input_delay & output_delay constraints, thanks to your SDC guidelines.

In Cyclone III spreadsheets, t_su is negative. I inserted its value as a positive value.

t_h is copied from spreadsheet.

t_co is calculated according to Method-2 of AN-366.

--- Quote End ---

No, you've misunderstood the procedure. FPGA I/O cells have programmable delay elements, so there is no data sheet values for tsu/th/tco. The data sheets have "micro" parameters uTsu/uTh/uTco. Rather than try to calculate the delays by hand, you enter reasonable constraints, as I have above, and let Quartus/TimeQuest try to meet those constraints. For example, if the tco constraint above was too small, then TimeQuest would fail to meet that requirement. In that case, you would enter a slightly larger value (based on the failed result) and iterate. The above values were determined from a Stratix II FPGA design.

If you have to increase the tco from both Cyclone IIIs to meet the output timing, then you would edit the SDCs for both projects. The TimeQuest analysis of the inputs would then change, reflecting the increase in the delay on the other FPGA output. If you re-synthesize the design, then the programmable input delays will be adjusted, centering the setup/hold margin.

--- Quote Start ---

After synthesis & programming FPGAs, still I have problem with data corruption.

What could cause problem?

--- Quote End ---

Poor PCB layout. Did you look at the clock waveform using an oscilloscope?

--- Quote Start ---

Is sending out clock from a normal IO pin a good design practice?

--- Quote End ---

No, in general you should try to use a dedicated PLL output pin. Quartus will warn you that your use of a general I/O will result in excessive jitter. At 50MHz you should be fine though.

--- Quote Start ---

One more question: Isn't it better that I feed FPGA-1 with clk1, instead of clk2? i.e. without 180 degree phase shift? is this phase shift in compliance with our constraints?

--- Quote End ---

TimeQuest analysis will answer this. Try with a common clock, and if timing cannot be met, see if the phase of the clock needs to be adjusted to meet timing. If that is the case, then use a PLL to adjust the phase. The SDRAM design I referred to has an example of this.

--- Quote Start ---

What about output currents? is there a guideline to set output current? specially for clocks?

--- Quote End ---

It depends on your board design. Look at the clock waveform with a scope and try a few different settings to see if the signal integrity gets better or worse.

Cheers,

Dave

Thanks again.

First, my problem was resolved using IO constraints based on your SDRAM Nano Board template; Thanks.

Probably because my clock was not too high, I got answered though my IO constraints were set without an exact understanding of the problem. Nevertheless your guidelines helped me get out of the trouble.

However for understanding the problem, another question raised in my mind:

You said I should enter reasonable constraints for IO delay constraint. What do you mean by reasonable here?

In my example, assume I want to use clk1 (no phase shift) to feed FPGA-1. How should I set my first trial of IO constraint? More specifically, what are reasonable t_co_min, t_co_max, t_su & t_h values in the SDC file? What are the starting point values?

--- Quote Start ---

However for understanding the problem, another question raised in my mind:

You said I should enter reasonable constraints for IO delay constraint. What do you mean by reasonable here?

In my example, assume I want to use clk1 (no phase shift) to feed FPGA-1. How should I set my first trial of IO constraint? More specifically, what are reasonable t_co_min, t_co_max, t_su & t_h values in the SDC file? What are the starting point values?

--- Quote End ---

You need to learn how to use TimeQuest. The TimeQuest GUI shows you the timing waveforms for your given set of constraints, including by how much you fail. So you could start off with 0ns constraints and see by how much you fail. However, after you've done that once for an FPGA family, you'll know what "reasonable" means, so from that point on, you use reasonable constraints. Take a look at the figures in this document - they show screen captures from TimeQuest

https://www.ovro.caltech.edu/~dwh/correlator/pdf/timequest_quad_spi_flash.pdf

https://www.ovro.caltech.edu/~dwh/correlator/pdf/timequest_quad_spi_flash.zip

Cheers,

Dave

normally, in case fpga outputs to a an ASIC (such as DAC) you will find out tSU/tH of DAC device and include board delays to set output delay constraints.

In your case fpga feeds fpga and so timing responsibility can be shared as both are configurable at io.

thus max output offset of fpga1 + tSU at fpga2 can equal clock period

However in practice you can first set input delays of fpga2 at some convenient values and see report(datasheet) to find out tSU/tH achieved at input pins. Then go to fpga1 and set output delays accordingly taking board delays into account

If this is your first time with TimeQuest, Altera has some free training to get you started. Here's the introductory one:

http://www.altera.com/education/training/courses/odsw1115