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

[BKB]

Hi,

I am trying to interface the FTDI601 USB Bridge (https://ftdichip.com/products/ft601q-b/) to the Stratix 10 1SG10MHN3F74C2LG_U1/U2 FPGA on our design board. The reference clock for the interface is comes from the FTDI chip along with data/command signals.  The signal RXF_N that indicates data coming from the FTDI chip appears one cycle wider when looked through signaltap on Stratix 10. The signal is asserted (active low) a cycle before the valid data.

To verify that the software driving the FTDI chip and interface to FPGA is correct, We tested the example designs based on Cyclone V (https://ftdichip.com/wp-content/uploads/2024/08/cyclonev_mst_fifo32_1.2.zip) provided by FTDI (https://ftdichip.com/wp-content/uploads/2020/07/AN_421_FIFO_Bus_Master_For-FT60x.pdf).

The design waveform as seen on signaltap is correct and the terminal data reading for the loopback design but for Stratix 10 has the RXF_N signal is wider (asserted one cycle earlier than data)

For the working cyclone design the FTDI chip and the Cyclone V FPGA are on the same evaluation board (https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=830) and have a direct connection on board.

For our design we have the FTDI board (https://ftdichip.com/products/umft601a-b/) with HSMC adapter connected to the Stratix 10 FPGA through an adapter board and connector on the FPGA.  The image of the adapter is attached.

I have attached signaltap image for both cyclone and Stratix.

Please help figure what could cause the widening of RXF_N on Stratix device. The same loopback design and software is used on the same FTDI chip. 

[Farabi]

Hello,

Just checking with your observation on the extra cycle wider , do you observe any failure symptom? If yes, can you explain what is the failure?

regards,

Farabi

[AqidAyman_Intel]

Hello,

May I know if you have any updates on clarification needed?

[BKB]

Hi,

The issue still persists. There is no failure symptom or mechanism other than RXF_n signal from FTDI chip through the board is widened by a cycle.

Best,

Bharat

[Farabi]

Hello,

When W_OOB is asserted to high, the FIFO master reads from the FIFO and discards data as long as RXF_N is asserted. RXF_N may assert multiple times while W_OOB is asserted. In streaming mode, the master read and master write data count sequence is reset depending on the corresponding OOB signal assertion.

From the diagram, the RXF_N is not controlled by Cyclone V FPGA. RXF_N may get asserted multiple times while W_OOB is asserted. So you control the W_OOB signal.

regards,

Farabi

[Farabi]

Diagram from FTDI user guide: 

[FvM]

Hi,

looking at FT601 bus timing requirements in datasheet, I believe the problem could be caused by setting FPGA generated signals (in this case OE_N, RD_N) on the wrong clock edge. The problem doesn't appear with slow Cyclone V which produces sufficient output delay to still fulfill FT601 input signal hold requirement of 4.8 ns. Faster Stratix 10 apparently doesn't. Output delay constraints seem not to work as intended.

100 MHz clocked Signaltap isn't able to visualize the problem. A sufficient fast oscilloscope or LA can.

Regards
Frank 

[BKB]

Hi Frank,

Thanks for looking into this. I will reconfirm the clock edge. I did notice about the delay constraints not working as intended in Stratix. The chip is capable of 100MHz but I am using it at 66 MHz.

Best,

Bharat

[AqidAyman_Intel]

Hi Bharat,

Do you have any updates on the clock edge? Have you check it as suggested?

Regards,

Aqid

[AqidAyman_Intel]

As we do not receive any response from you on the previous question/reply/answer that we have provided. Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

[BKB]

Hi,

As suggested above the issue seems to be stemming from the fast IOs of Stratix while cyclone is providing enough delay for hold time, I think. The design is working on positive edge which might causing the suggested hold time violations. I still fail to understand how this would affect just the RXF_N signal widening it but there are no data bus errors. I would have imagined if there were such hold time issues, then the 32bit wide data bus would have been more susceptible to bit errors. 

In any case, the other suggestion using the oscilloscope to view the signals is not possible as the board is in a remote location with no access to oscilloscope.  Somebody had suggested to use a higher frequency clock to sample the complete FTDI interface along with the FTDI clock and it might give some idea about whats happening. I will give it a try and share what I see. .

Also, will give try to convert the design to negative edge at the FTDI IO Signals,.

Best,

Bharat

[AqidAyman_Intel]

Hi Bharat,

Any updates on the issue?

[BKB]

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

 

[BKB]

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

[AqidAyman_Intel]

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.

[AqidAyman_Intel]

Hi,

Is there any update from you for this issue?

[BKB]

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

[AqidAyman_Intel]

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?

[BKB]

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