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

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 TechnicianA Contingent Worker at 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 aboveBad 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 issueYou 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 channelThanks.Regards,dlim

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

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 IPThen 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 IPThen 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 sameIf 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 IPWhen 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 hereYup, 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

Aria V Display Port core sometimes disconnected

50 Replies

Alberto_Sykes
Occasional Contributor
5 years ago
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
Regular Contributor
5 years ago
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
  New Contributor
  5 years ago
  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
    Regular Contributor
    5 years ago
    CDR loose lock debug checklist
    Cyclone 10 Transceiver CDR FTA v1.0.xlsx23 KB
Deshi_Intel
Regular Contributor
5 years ago
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
  New Contributor
  5 years ago
  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
    Regular Contributor
    5 years ago
    DP link bandwidth calculation guideline
    DP link BW calculation example.pptx582 KB
Deshi_Intel
Regular Contributor
5 years ago
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
  New Contributor
  5 years ago
  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
New Contributor
5 years ago
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
  New Contributor
  5 years ago
  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
    Regular Contributor
    5 years ago
    
    MSA log dump example
Deshi_Intel
Regular Contributor
5 years ago
Hi,

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 ?
Your DP video bandwidth is sufficient.
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
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
Execute runall.tcl script in NIOS II shell terminal to generate and compile example design
Modify the example design FPGA device OPN and pinout to match with your board then compile design again
Program the DP example design sof file to your board
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
  New Contributor
  5 years ago
  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
Regular Contributor
5 years ago
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
  New Contributor
  5 years ago
  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
  top.v14 KB
  - relsaar
    New Contributor
    5 years ago
    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
Regular Contributor
5 years ago
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
  New Contributor
  5 years ago
  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
    New Contributor
    4 years ago
    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
Deshi_Intel
Regular Contributor
5 years ago
Hi,

What I meant on watch out on all the clock frequency that you supply to DP design is
You have modified DP Sink IP data rate and pixel output mode setting, then I would expect you need to modify the clock frequency supplied to example design accordingly like (DP video clock, NativePHY frequency setting, IOPLL setting and etc accordingly) Else pls revert the setting back and keep the changes min
DP aux channel carry important debug info so you shouldn't remove it. Since you mentioned it's working on your original DP design then you just need to modify the example design
You can learn more about the DP example design in Intel DP user guide chapter 4
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_displayport.pdf

For MSA log dump debug :
Below AN793 (page 20) show you screen shot of MSA log dump example
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/an/an793.pdf
Just wonder after you press "S" and there is no respond from NIOS II terminal ?
Another method to trigger MSA log dump is via triggering "user_pb[0]" signal port in DP example design
If both method also failed then you may want to double check whether your NIOS II is initiated correctly ? From AN793 screen shot, I can see some green wording in NIOS II terminal showing connection setup to NIOS II CPU
You can also try to reprogram the NIOS II elf file again in NIOS II command shell using below command, then repeat the MSA log dump procedure
nios2-download dp_demo.elf
The elf file is located in \av_sk_4k_v15_0\software\dp_demo\

Thanks.

Regards,
dlim
Deshi_Intel
Regular Contributor
5 years ago
Additional note - you may want to cross check to ensure example design QSYS NIOS II clock and reset is supplied correctly.

Thanks.
- relsaar
  New Contributor
  5 years ago
  Hi,
  
  I tried to download the NIOS 2 elf file and got an error (see attached).
  
  then I checked the address of the example design Vs my modified example design and realized the address were changed during the modification process.
  
  I think this is the root cause for NIOS load failure - I'll try to change back the address but if it will faile I'll need to create a new elf - can you please address me to suitable userguide?
  
  by the way I'd like to verify if the AUX signal integrity is cauing the MSA drop, is there any option to redundent the AUX channel in the DP setup GUI?
  
  thanks
  
  Ariel