Input signal from other board measures an extra cycle wider on signaltap on Stratix 10 vs Cyclone 5

Hi Adiq,

I was able to sample the FTDI clock and other interface signals with high a 333.33 MHZ clock. The FTDI clock is 66mhz. I see the same behavior is RXF_N is asserted (low) earlier than when valid data is available. This is the same behavior I was seeing in earlier testing. i.e. RXF_N seems to be widened by a FTDI clock cycle. I have attached signaltap snapshot. for the initial input data coming from FTDI.

I am still working on changing the FTDI interface operation to be on negedge of ftdi clock at the input of FPGA..

Please review the attached signaltap snapshot and let me know any suggestions.

Best,

BB

Hi

As suggested here earlier, I changed FTDI interface within the FPGA to operate on the negative edge of FTDI clock. I still see the same issues i.e. RXF_N is asserted (low) and the data on the data bus is not valid data. The FTDI interface along with its clock is sampled with 400 mhz clock.

Best

Bharat

Hi,

If that is the case, I think this also could be a signal integrity issue on the custom board, as the connection between the FTDI board and your Stratix 10 FPGA involves an adapter board and connectors, which likely introduces longer trace lengths compared to the direct on-board connection of the Cyclone V evaluation kit.

Different signals might experience different delays, potentially causing the RXF_N signal to arrive at the FPGA slightly earlier relative to the data signals.

Maybe you can use static timing analysis tools in the Quartus Prime software to analyze the timing of the signals arriving at the Stratix 10 FPGA. Pay close attention to the delays introduced by the board routing and the adapter.

Another method is to use the direct probe by oscilloscope, but as you said, this is not possible for you.

Hi,

Is there any update from you for this issue?

Hi,

We tried using the logic analyzer and the signal quality degraded. I started seeing the FTDI chip missing clock signals.

I agree with your assessment that, mismatch of delays, accumulated over the connector, cable and then board trace would be causing this. When I try to sample the 66MHz FTDI clock and data and control interface, I do see about 2 cycle (5 ns) variation in the data settling to steady value on signaltap. There could be similar variations on the RXF_N signal. I am out of ideas on how to make this work, as to what special consideration I need in the design or if it is just a matter of constraining it. Let me know if you have any suggestions. I am also commuicating with FTDI support. Will update with further development.

Best,

Bharat

Hi Bharat,

Unfortunately, I have no other suggestion so far. I'm not sure if you managed to get any input from FTDI support on this?

Hi Aqid,

Thanks for you help. I did not get any concrete solution from FTDI too. I think its the delay of the board. With OE taking its time to travel and data taking its time to travel back so that makes RXF_N to apper valid for a cycle longer. Anyways. you can close this request.

Thanks

Bharat