Aria V Display Port core sometimes disconnected

[relsaar]

Hi All

We have a PCB board we designed with AMD 8860 GPU that sends DP video to Aria V Display Port core (Qsys). In some of our boards we sometimes have DP connection issues.

The video signal goes to altera_xcvr_native_av and when RX is out of lock we see multiple retries on the DP AUX channel.

We came across this bug:

https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base/ip/2019/why-does-the-intel--displayport-receiver-ip-with--enable-gpu-con.html

in our case the enable GPU is not checked.

Can anyone confirm this issue is also applicable to Aria V Display Port?

Thanks

Ariel

[Alberto_Sykes]

relsaar, Thank you for posting in the Intel® Communities Support.

In reference to your inquiry, in order for us to be able to provide the most accurate assistance for this scenario, I will transfer your thread to the proper department, they will further assist you with this matter.

Regards,

Albert R.

Intel Customer Support Technician

A Contingent Worker at Intel

[Deshi_Intel]

Hi Ariel,

I looked at the KDB link. You can see at the top, it mentioned the affected FPGA family is just Arria 10 and Stratix 10 which means Arria V is not affected by this issue.

• Anyway, I always recommend user to upgrade to latest Quartus Standard edition version if possible to mitigate the risk of known issue from older Quartus version.

Btw, you mentioned Rx loose lock. Are you referring to Rx channel CDR locked to data signal or some other status signal ?

• Common factor that will caused CDR to loose lock are like below
  • high PPM different on CDR refclk - checked your on board crystal or clock generator quality.
  • Bad signal integrity on CDR refclk - same debug approach as above
  • Bad signal integrity on data transfer on Rx channel - reduce your video resolution to reduce the DP bandwidth from 5,4G to 2.7G or even 1.67G to help isolate signal integrity issue
• You can also use DP example design to dump the MSA log to check if you observe high bit error rate (BER) on the 4 DP channel or 2 DP channel

Thanks.

Regards,

dlim

[relsaar]

Hi dlim

Thank you for your fast and detailed response.

I understand the Arria V and 10 Display Port IP core is different and the bug report I mentioned earlier is not relevant for our problem. (please confirm)

Regarding your suggestion to migrate to a new version of Quartos - our Display port core was bought from Bitech (which was later bought by Altera) and is not supported above Quartos 16.0.

We tried to compile on Quartos 20.1 the reference design of current display port core  but could not get an evaluation *.sof file. If migrating will solve the issue we will be happy to purchase a license or maintenance.

the lock signal I mentioned earlier is the output of the Arria V Transceiver Native PHY. The setting of this core has a PPM detector threshold that is set to 1000 PPM (similar to reference design) while our reference clock Oscillator is +/- 20PPM (see attached spec).  I figure high value on the PPM detector makes the design more robust?

Our video resolution BW is already 1.62G and the signal looks good on debug monitor while it is locked, however the reference clock seems a bit noisy when we probe it with a deferential probe (see attached image). do you recommend to add "Input Termination" at "OCT 100 Ohms" in the assignment editor?  Our differential  ref clock pin is currently set to I/O Standard LVDS. Please see clk ref schematics image attached below, the right side nets "DP REF CLK+" and "DP REF CLK-"  are connected directly to the Arria V FPGA.

We tried to check the reference design for dumping the MSA log but it is not clear how to apply it (Please send link or more info on this issue)

Thanks

Ariel 

[Deshi_Intel]

CDR loose lock debug checklist

[Deshi_Intel]

Hi,

I think the first thing we need to clarify is which DisplayPort IP that you are using here ? Are you using Bitec DisplayPort IP or Altera DisplayPort IP ?

• If you are using Bitec DisplayPort IP
  • Then my suggestion to you will be to engage back Bitec for better issue support
  • I also share same concern with you on IP upgrade capability. Since this is not Altera IP, Intel Engineering won't support IP migration to latest Quartus version. Bitec should has their own IP migration strategy. Pls consult Bitec accordingly
• Else if you are using Altera DisplayPort IP
  • Then it only make sense for you to perform IP migration to latest Quartus version.
  • Byright evaluation license should still able to generate sof file but I am not familiar with licensing issue. Perhaps you can contact your local FAE for licensing support ?

I presume you are referring to Rx channel CDR lock monitor signal (rx_is_lockedtodata)

• Attached is the CDR loose lock debug checklist for your reference. It's targeted for C10 GX FPGA but the debug methodology is more or less the same
• If you confirmed CDR is indeed loose lock on your board then there is no point to dump MSA log to debug DisplayPort anymore because your Rx transceiver channel already failed to sample/receive data in the first place before the data is passed to DisplayPort RX IP
• When PPM threshold setting = 1000, it means it allow max PPM drift until 1000ppm while your oscillator ppm is only +-20ppm which is good. So, maybe ppm is not the issue here
• Yup, your 135MHz refclk signal probe result looks bad but I am not sure is it due to your board design issue, or your probing contact issue or oscilloscope bandwidth issue ?
  • Did you manually hold your diff probe or use some tool to hold it or solder the probe tip on board ?
  • Also is your oscilloscope bandwidth at least 3x or 5x of 135MHz ?
  • Lastly, yes. Enable 100ohm OCT insides FPGA should help to improve the LVDS signal termination. Pls try it out.
• You also mentioned your 1.67G Rx data transfer signal quality should be good
  • May I know how do you check it ? Did you run board simulation or use transceiver toolkit to to perform loopback testing on board ?

Thanks.

Regards,

dlim

[relsaar]

Hi dlim

We are using the IP catalog core from Quartos 15.0, I guess it is Intel Altera core but many of the generated files contain the word "bitech" on it. (see attachment). We intend to meet the local FAE tomorrow and check this issue.

Regarding the lock signal I mentioned earlier - I'm sorry for the confusion - I was referring the MSA - lock that can be generated on the QSYS GUI as a trigger(see attached image)

My signalTap also contain the below Transceiver Native PHY signals:

• Rx_is_lockedtoref
• Rx_is_lockedtordata

I assume the first is indicating on ref clock signal integrity and the second on display port data signal integrity?

Regarding the signal integrity issue,

• Scope and probe BW are 4GHz
• Probe was soldered to tips on board and was clumped to the PCB.
• 100ohm OCT was not helpful

Regarding your question on how we verify the video – we output the digital video signal from the Aria V in to external video encoder which convert it to analog screen. I was looking for the transceiver toolkit feature you mentioned but didn’t find such option. Can you please send me more info on how to use this feature?

However after I reviewed the brd file I found out the LVDS clock pins, though short, have no ground plan above or below the clock signals. I suspect it is the root cause for the noise. In order to lower the clock noise I replaced the 162MHz clk with 50MHz clk and use Alt PLL to convert the clock back to 135MHz. It looks like the signal is less noisy now (see attached image).

I’m running some tests to see if the failure is resolved or can be recreated again. Will update as soon as I have some answers.

[Deshi_Intel]

DP link bandwidth calculation guideline

[Deshi_Intel]

Hi,

Since you are using altera_dp IP which means this is Altera DisplayPort IP, not Bitec DisplayPort IP.

• You should be able to upgrade to latest Quartus version after you sort out the licensing issue with your local dFAE support. Pls try out Quartus Standard v20.1 if possible
• The reason you are seeing a lot of Bitec design internally is due to Altera previously purchased Bitec DisplayPort IP, modified and repackage into Altera DisplayPort IP

Now while you are reviewing your board design, let's sort out the debug step to capture the right debug status signal first in order to determine the right debug direction.

• DP Rx data flow from GPU -> FPGA (FPGA Transceiver Rx channel -> DP Rx Sink IP)
• That's why I mentioned earlier if Transceiver Rx channel can't capture/sample the Rx data properly then the data will break/corrupt in transceiver channel before reaching DP Rx IP. No point to debug DP RX IP anymore.
• We can monitor "Rx_is_lockedtodata" signal to check whether Rx channel CDR is in locked mode or not. Ignore "Rx_is_lockedtoref" as you are not using it. Both are status signal of CDR but it's meant for different CDR operation mode. You should be referring to "Rx_is_lockedtodata"
• CDR lock indicated the data rate speed is correct and Rx channel can sample data at the correct data rate speed. (but we won't know the correct data content is receive or not)
  • So, can you tell me whether "Rx_is_lockedtodata" stay high or de-asserted in your video test failure scenario ? Pls share with me the signal_tap file result
• Then next is to check whether correct video data content is sample correctly at DP Rx IP or not. You can monitor via MSA lock signal (which you already did)
  • You mentioned MSA loose lock. One of the possibility is due to data corruption due to high "bit error rate (BER)", bad signal integrity on the board - either on the refclk source or the DP Rx channel itself.
  • We can monitor DP soft 8b/10B decoder IP status signal like *code_err" and "disp_err" to verify whether it's related to high BER or not. Can you try to find these status signal in your signal_tap and capture them in failure condition ?
• Another possibility that I can think of is there is limitation of DP bandwidth transfer.
  • From your DP Rx sink IP setting, you configure it to 1.62G with 1 lane count only
  • May I know what exact video resolution and bit per colour that you set in your GPU ?
  • Attached is the DP BW calculation guideline to help you verify you video data transfer doesn't exceed DP link BW
• Another thing I noticed is your "pixel output mode" = single.
  • This may put some pressure on your design timing closure as you need higher DP operating frequency
  • May I know is your design timing closed at Quartus Timequest ?
  • Also, maybe you can consider to change the setting to "quad" to relax the design timing requirement

Thanks.

Regards,

dlim

[relsaar]

Hi dlim

I was able to recreate the msa_lock fail and during this event Rx_is_lockedtodata looks stable (attached SignalTap image). I guess the problem is not the ref clock.

As you suggested I monitored DP soft 8b/10B decoder IP status signal like “code_err" and "disp_err" and those signals look very noisy even during normal operation

(attached SignalTap image). During failure those error signal looks the same.

Can we assume the problem is due to display port poor signal integrity?

Regarding your inquire for video resolution and bit per color that was set in our GPU, please see calculation below:

720 X 576 X 25Hz X 16 bps = 165,888,000 bps

I assume this is a very low channel capacity since we have 1.62 GHz bit per second hence the "pixel output mode" = single is not an issue. I think we tried using  "quad" and it complicated the clocks in the design. Let me know if you disagree my assumptions.

We don’t have any special constrains for those IPs, only defaults that were applied after we added the IP. However after I ran Report Top Failing paths I got:

qsta_utility::generate_top_failures_per_clock "Top Failing Paths" 200

No failing paths found

Thanks

Best Regards,

Ariel Saar

FPGA Design Engineer

[relsaar]

Hi dlim
I'd like to test our findings by comparing the display port BER between 2 boards. a board that tends to fail with a board that is usually stable.
1. Is there a signal that I can add to the SignalTap to give numerical value for BER or shall I accumulate disp_err or code_err toggles per time unite?
2. What is the threshold for a reasonable BER?

[relsaar]

Hi,

I checked disp_err and code_err signals on a system that never had msa_lock toggles and saw the same toggles on those signals (similar to the photo I attached before)

also we only use one lane of display port but in the signalTap all 4 of them are noisy. it looks like we can't trust this BER detection/debug signal.

I tried to connect disp_err or code_err as enable of a counter to quantify the BER and check if the the first board has more toggles on that indicates higher BER but unfortunately those signals comes from encrypted module and can't be used.

thanks

Ariel Saar 

[Deshi_Intel]

MSA log dump example 

[Deshi_Intel]

Hi,

1. Regarding Quartus timequest report.

• You shouldn't need to run additional timing analysis. By default. once you compile your design with STA optional enable. You should be able to view the Timequest compilation summary. Do you see any red wording highlight in compilation summary indicating timing violation in your design ?

1. Your DP video bandwidth is sufficient.
2. Ya, your error signal toggling looks weird. Let's use MSA log dump from Intel FPGA DP example design to better confirm your BER number. DP IP internally has coded some BER threshold value, once error assertion hit the threshold limit then MSA lock will be de-asserted

Below is the steps to generate MSA log file

1. Locate AV DP example design in your Quartus installation folder. Example path below

• C:\intelFPGA\16.1\ip\altera\altera_dp\hw_demo\av_sk_4k

1. Execute runall.tcl script in NIOS II shell terminal to generate and compile example design
2. Modify the example design FPGA device OPN and pinout to match with your board then compile design again
3. Program the DP example design sof file to your board
4. Launch NIOS II shell terminal again, press "s" to capture MSA log file

Share with me the MSA log file for both passing board and failing board then we can further analyze your failure issue.

Thanks.

Regards,

dlim

[relsaar]

Hi 

I  opened the NIOS II shell terminal and navegated example design location then I executed the tcl:

Ariel@Ariel /cygdrive/d/altera/15.0/ip/altera/altera_dp/hw_demo/av_sk_4k
$ quartus_sh -t runall.tcl

then I got:

Info: *******************************************************************
Info: Running Quartus II 64-Bit Shell
Info: Version 15.0.0 Build 145 04/22/2015 SJ Full Version
Info: Copyright (C) 1991-2015 Altera Corporation. All rights reserved.
Info: Your use of Altera Corporation's design tools, logic functions
Info: and other software and tools, and its AMPP partner logic
Info: functions, and any output files from any of the foregoing
Info: (including device programming or simulation files), and any
Info: associated documentation or information are expressly subject
Info: to the terms and conditions of the Altera Program License
Info: Subscription Agreement, the Altera Quartus II License Agreement,
Info: the Altera MegaCore Function License Agreement, or other
Info: applicable license agreement, including, without limitation,
Info: that your use is for the sole purpose of programming logic
Info: devices manufactured by Altera and sold by Altera or its
Info: authorized distributors. Please refer to the applicable
Info: agreement for further details.
Info: Processing started: Tue Jan 05 13:02:26 2021
Info: Command: quartus_sh -t runall.tcl
------------------------------------------------
can't read "QUARTUS_ROOTDIR": no such variable
while executing
"export PATH=`cygpath -u $QUARTUS_ROOTDIR/bin64`:$PATH"
(file "runall.tcl" line 24)
------------------------------------------------
Error (23031): Evaluation of Tcl script runall.tcl unsuccessful
Error: Quartus II 64-Bit Shell was unsuccessful. 1 error, 0 warnings
Error: Peak virtual memory: 4361 megabytes
Error: Processing ended: Tue Jan 05 13:02:28 2021
Error: Elapsed time: 00:00:02
Error: Total CPU time (on all processors): 00:00:01

I added my path : %QUARTUS_ROOTDIR%\bin64 but was not helpful. Also tried to open an empty project add the content of av_sk_4k and run it from tools -> Tcl scripts , but it failed as well.

any idea how to proceed?

Please advise if I can run system console Transceiver toolkit to sample the display port "eye" and derive the signal quality from it? it it' s applicable please refers me suitable user guide or send instructions.

Thanks

Ariel 

[Deshi_Intel]

Hi,

Don't use quartus_sh command to execute runall.tcl script in NIOS II terminal

Use below command instead then it should works.

• source runall.tcl

Let me know if you still face issue in generating the example design then I will generate and share it with you via Intel FTP server. The example design file size is quite big (~300MB). Hence, can't be shared as file attachment in this forum community.

I won't recommend to jump into debugging board SI issue until we verify it using MSA log from DP example design.

• Anyway, feel free to learn more about transceiver toolkit info in below link
• https://www.intel.com/content/www/us/en/programmable/products/design-software/fpga-design/quartus-prime/features/swf-transceiver-toolkit.html
• You can download toolkit example design and also easily google for transceiver toolkit short youtube video to get a feel on how it works. You can only verify the data integrity using PRBS generator/checker build in FPGA transceiver channel but don't expect to see fancy eye diagram from toolkit

Thanks.

Regards,

dlim

[relsaar]

Hi dlim

I managed to create and compile successfully the example project. since my PCB has only one lane of DP Rx I had to make some changes and customize the example design. attached are updated top.v, pinout table and Qsys GUI settings.  

Also since we don't have an external Bidirectional buffer on the board I added "arriav_io_ibuf" internally  (see aux_buf_iobuf_bidir_nho_i at top.v) - in my legacy design we also used Bidirectional buffer on those signals.

Finally I created a SignalTap with some signals to verify if the example design gets any input video signal.

The design was compiled without any errors but it looks like the display port Rx does not receive any signal since there is no MSA lock (only occasional negative pulses on Rx Aux In - see attached image)

when I program my legacy design I get steady msa lock most of the time and I'm using the same application to configure the GPU to generate same DP signal.  Can you please help me find out what is wrong?

• did I forget any important pin assignment or pinout?
• did I change any settings that disrupted the design to receive DP?

  Please let me know if you need more data.

Thanks

Ariel

[relsaar]

Hi dlim

Also when running the example design, I opened the NIOS shell command and type "s" as you instructed, unfortunately it was not recognized as a valid command (see attached image)

Please advise if there was precursory action that I had to perform before typing "s"?

Thanks

Ariel 

[Deshi_Intel]

Hi,

There are a lot of design changes that you made. It's hard for me to comment whether everything is done correctly or not.

• The goal is we want to stay as close as to original example design with min changes
• I noticed you changes the DP Rx link rate and pixel output mode.
  • Actually it's fine to stay with default setting due to you are using example design and you don't need to worry about the clock frequency changes. DP link training will just down train from 5.4G to 1.62G
  • But now you need to watch out on all the clock frequency that you supply to DP design.
  • Pls revert back to match original DP example design if you still encounter failure in hardware testing later

Regarding the MSA log dump

• Sorry, my bad. I miss out one step.
• In NIOSII shell terminal, type nios2-terminal to enter NIOS console first
• Then press "s" to print MSA log

Thanks.

Regards,

dlim

[relsaar]

Hi,

all of the changes I made to the example design were mandatory:

1. we have no 100M clock available on the board so I had to generate one with current PLL also our DP ref clock is derived from 162MHz so I had to change it as well.

2. the DP Aux channel should be Bidirectional and since our board has no such external IC I had to add it to the example design (unless the Aux channel can be entirely removed some how??)

3. our board has only one lane of Rx DP so I cancel all other lanes - I can add it back but I see no point.

I can revert back to 5.4G if you think it may help.

I'm not sure what did you mean by: 

• But now you need to watch out on all the clock frequency that you supply to DP design.

Please explain

I tried to get a BER report from the NIOS command shell by typing nios2-terminal as you suggested but then the command line was locked to further typing (please see attached image) I verify the USB bluster is detected properly in the device manager (please see attached image)

Please advise how can we proceed?

Thanks

Ariel 

[relsaar]

Hi, 

I got some assistent from a local SW FAE on how to properly load the NIOS2 processor, however it did not work out on our boards.

So I managed to get an Arria V evaluation board and a bitech doughter display port extender . I connected the evaluation board Rx to my docking display port output and the evaluation board Tx to my monitor(see photo).

When power up the board my windows 10 detect a new monitor on the display settings and during the SOF and .ELF  load I got file transfer positive feedback (those werethe genuin files from the example design), however after I type: NIOS2-terminal I got no response and S or s command are not recognized then the new monitor detection was disappear. I also opened a secondary NIOS2 command shell to read NIOS messages but noting was printed. (see shell print capture)

Please advise how can we proceed?

Thanks

Ariel Saar