Forum Discussion

lambert_yu's avatar
lambert_yu
Icon for Contributor rankContributor
5 years ago

About PRESERVE_UNUSED_XCVR_CHANNELfor transceiver application

Hi all , quartus prime 16.0 standard & quartus prime standard 18.0.0 FPGA : arria 10 (10AX115N2F45E1SG) For this subject, I have question : (1) from the link : Why do unused tr...
Deshi_Intel's avatar
Deshi_Intel
Icon for Regular Contributor rankRegular Contributor
5 years ago

Hi Lambert,


Correct. Don't use the qsf preserve command due to v18.0 bug and instead just follow the workaround.


The workaround is stated in the 2nd KDB link that you shared in the forum post earlier. I just copy paste the content and show you again only.

  • Basically the workaround required you to instantiate dummy NativePHY IP in Tx simplex mode
  • Keep Tx VOD to min setting and then send 0 pattern to this dummy Tx simplex NativePHY IP to keep it active to preserve it rather than relying on the qsf preserve command
  • Assign Tx channel to the Tx location of your used Rx simplex pin


Thanks.


Regards,

dlim


  • lambert_yu's avatar
    lambert_yu
    Icon for Contributor rankContributor
    5 years ago

    Hi Deshi,

    Glad to your response.

    But from the later compilation result, I found the problem can not resolve by the above assignment. Just because when I clear all the compilation content and add some new modules into my project, the transceiver works bad for one lane of one link( I have two links, each link @1 simplex Rx IP, four channel for each IP which use bonding mode) using new got pof file, and this case will not change no matter how many times I compiled using 18.0.

    1) Compared to 18.0, if I use the same project (add some new modules), the transceiver work well using the pof compiled by 16.0 ( I didn't add any above assignment).

    2) And I found that after compilation, if some logic unrelated to transceiver path in my project has timing slack problem, the transceiver can works well.

    So, I think

    1) maybe there's risk logic in my code, I can not make sure because some compilation result can work well.

    2) maybe there's route and fitter problem, but from the report, I could't got any useful information for me to found them just because there is no warning information about transceiver and related transceiver logic has no timing issue. Could you provide me some advice for me to get more information about it?

    For the transceiver, I only use its PMA part and fewer PCS part (enhance PCS, more PCS logic is writen by myself). And I check the lane error at the point closely to the IP OUT(parallerl data) (8B/10B decoder, M-PHY protocol, 10Gbps).

    Brs,

    Lambert