ALTDDIO_OUT for clock output of chip

--- Quote Start ---

Dear all,

i have an example FPGA configuration project for a FIFO interface. It is for a Cyclone 5 device and is comprised of a fifo interface, an ALTDDIO_OUT and a pll. The FPGA should act as master interface and for this reason a 100 MHz clock is outputed of the chip to an USB 3.0 slave interface with the clock input and a 32 bit INOUT.

What is the reason that the 100 MHz clock coming out of the chip is routed through the ALTDDIO_OUT ? I know there is an instruction from altera AN433 which basically states there are different ways to output the CLOCK off the chip, but I cannot see a specific reason for choosing the ALTDDIO_OUT?

The ALTDDIO_OUT is instantiated this way:

ddr_inst_to_send_out_clk_to_fx3 : ddr
         port map(
             datain_h   => '0',
             datain_l   => '1',
             outclock   => clk_100,
             dataout    => clk_out
     );        

Is there a way to tap into the clk_out signal with SignalTap II ? It always stays '0', but I can see the clk_100 input clock to the ALTDDIO_OUT. Or is there a problem in SignalTap 2 when working with a high frequency sample clock. In the past I recognized that when I choose for the source clock a frequency of 200 MHz some displayed signals are jittering/changing from 0 to 1 very fast even when they should stay on '1' for some time.

Thank you for your help.

Kind regards

--- Quote End ---

DDIO clock output helps edge align dout with clkout as both data and clk are clocked by same clk 100MHz. For signaltap you need faster sampling to see clk 100 but you don't need to...

--- Quote Start ---

DDIO clock output helps edge align dout with clkout as both data and clk are clocked by same clk 100MHz. For signaltap you need faster sampling to see clk 100 but you don't need to...

--- Quote End ---

Dear kaz,

I think that I'm already doing faster sampling (sampling clock is 300 MHz from pll) because I can clearly see the 100 MHz input clock into ALTDDIO_OUT. Please see attachment below.

https://alteraforum.com/forum/attachment.php?attachmentid=14523&stc=1

Do you think that SignalTap Scope is telling me the truth about dataout ? It always stays 0. :(

The reason for monitoring this signal is because I want to know if I hold the correct timing for all signals in relation to the 100 MHz for a slave fifo interface (cypress fx3) like required by the FX3 datasheet for slave fifo implementation, see second attachment below.

https://alteraforum.com/forum/attachment.php?attachmentid=14524&stc=1

Kind regards

--- Quote Start ---

https://alteraforum.com/forum/attachment.php?attachmentid=14523&stc=1

Do you think that SignalTap Scope is telling me the truth about dataout ? It always stays 0. :(

--- Quote End ---

if signaltap is sampling on 300MHz and you see input clk then yes it is not telling the truth about output clk.

BTW your instant name in signaltap is different from name in design. Could it be your are looking at wrong instance that does not drive output.

--- Quote Start ---

The reason for monitoring this signal is because I want to know if I hold the correct timing for all signals in relation to the 100 MHz for a slave fifo interface (cypress fx3) like required by the FX3 datasheet for slave fifo implementation, see second attachment below.

https://alteraforum.com/forum/attachment.php?attachmentid=14524&stc=1

Kind regards

--- Quote End ---

No you can't measure delays at io using signaltap.

--- Quote Start ---

if signaltap is sampling on 300MHz and you see input clk then yes it is not telling the truth about output clk.

BTW your instant name in signaltap is different from name in design. Could it be your are looking at wrong instance that does not drive output.

--- Quote End ---

Dear Kaz,

no, sorry for this confusion, this is no mistake. I posted the original code from Cypress. In my project the instance name is the one you can see in SignalTap. BTW when outputting clk_out out of the chip into an LED on the Cyclone V GX Starter Board the LED is blinking when I choose relativly low clockrates. Recently I discovered in the datasheet of ALTDDIO_OUT that the output cannot be reused in the FPGA and it is only for outputting. Is this the reason SignalTap which is implemented on the FPGA as part of the FPGA configuration cannot look at this signal? I wonder if anybody else here experienced sometimes this problem in the past.

--- Quote Start ---

No you can't measure delays at io using signaltap.

--- Quote End ---

Why not? Is not SignalTap telling me in relation to the sample-time at which point of time (sample) signals will be driven? The only problem I see is because of too low sample rates that the signal will be HIGH before the next edge tells me it is gone HIGH.

Kind regards and thank you so far.

--- Quote Start ---

Why not? Is not SignalTap telling me in relation to the sample-time at which point of time (sample) signals will be driven? The only problem I see is because of too low sample rates that the signal will be HIGH before the next edge tells me it is gone HIGH.

Kind regards and thank you so far.

--- Quote End ---

Regarding sampling clkout in signaltap, the tool should tell you if that node is valid for signaltap or not.

Signaltap can sample a signal at clock edge but can't tell you delay values in any resolution apart from clock resolution.

If you are after tCO ...etc then you can't get that from signaltap but from timing report.

--- Quote Start ---

Recently I discovered in the datasheet of ALTDDIO_OUT that the output cannot be reused in the FPGA and it is only for outputting. Is this the reason SignalTap which is implemented on the FPGA as part of the FPGA configuration cannot look at this signal?

--- Quote End ---

The output clock is inside the IO element so I am not surprised you were unable to monitor it with SignalTap. I would recommend using the Chip Planner and Resource Property Editor in Quartus to learn about the architecture looks and how your design is implemented.

--- Quote Start ---

Why not? Is not SignalTap telling me in relation to the sample-time at which point of time (sample) signals will be driven? The only problem I see is because of too low sample rates that the signal will be HIGH before the next edge tells me it is gone HIGH.

--- Quote End ---

There are several reasons. If you want a perfect picture of the timing you need to connect an oscilloscope on the physical pins, as opposed to SignalTap which works inside the FPGA fabric. For example, you will miss delays introduced by the delay elements in the IO elements, package bonding, etc. Assuming you are sampling with an unrelated clock, the delay from the monitored signals to the SignalTap core will differ from signal to signal and distort the picture. There are probably several other reasons why this is a bad idea.

Another point is that process, temperature and voltage variations play a big role in the delays you observe. (If you study the waveforms in TimeQuest reports you will see that a lot of the margin is lost to uncertainties.) Hence, even if you compile a design and measure the timing to be perfect on one board with an oscilloscope, you could get very different results on a different board. The way to do this is therefore to make SDC constraints in accordance with AN433 rather than do measurements. If this is done right and timing analysis passes, the interface is guaranteed to work.

Note that it doesn't matter if you use the DDIO element for the clock or not as long as you define the correct timing constraints and timing passes. The idea with the DDIO element is to make meeting timing easier for the tool.

Thank you both, perchrc and kaz, for clarifying this issue. It helped to get a bigger picture of this most critical timing stuff and now I now which application notes I have to study.

Kind regards.