Forum Discussion

BrianSune_Froum's avatar
BrianSune_Froum
Icon for Contributor rankContributor
3 months ago
Solved

Cyclone V SoC 5CSXC6 Series GXB Utilization and Limitations

Dear Intel Altera, I would like to confirm that the 6 channels GXB device: Q1) Do it possible to use all 6 TX / RX GXB Transceivers when Hard PCIe is used. Based on: CV-53004 There are no specifi...
Configuration
Core Logic
Programmable Logic Device
  • CheepinC_altera's avatar
    CheepinC_altera
    21 days ago

    Hi Brian,

     

    Thank you for the update.

     

    Just to clarify, the legacy database I referred to is our internal database for legacy devices. Unfortunately, there is limited information available regarding this wrong data issue. Based on the available info, I believe it was originally initiated from a customer-reported case.

     

    You are also correct that the placement rules are enforced within Quartus. Since these rules are built into the tool, they cannot be overridden through a TCL command.

     

    I apologize for any inconvenience this may cause. 

CheepinC_altera's avatar
CheepinC_altera
Icon for Regular Contributor rankRegular Contributor
21 days ago

Hi Brian,

 

Please see my responses below:

Do you mean the CMU PLL is used by the RX channel in CH1 GXB?
[CP]  To clarify, the CMU PLL utilizes the CDR PLL associated with the CH1 RX channel.

 

Is the wrong data issue caused by CMU PLL reuse? Would a custom TX operating at the same data rate as PCIe, or at a different data rate through the fPLL, also experience the same issue?
[CP] Based on information available in the legacy database, a custom TX operating at a different data rate than PCIe may also encounter the same wrong data issue.

 

Why can wrong data occur on a custom TX at CH1? What is the root cause?
[CP] I reviewed the available legacy database records but was unable to find any information related to the root cause. Therefore, I am unable to provide further comments on this specific behavior. As a best practice, we recommend following the Quartus placement guidelines to ensure proper design functionality.

 

Thank you.

BrianSune_Froum's avatar
BrianSune_Froum
Icon for Contributor rankContributor
21 days ago

CheepinC_altera​ 

OK.

For wrong data, you kept referring to legacy database, this is from internal FAE / staffs only?

Do wrong data reports from customers or internal smoke / sanity tests?

There is no way we can use with newer version no override no tcl command to bypass fitter rules on coexist?

Thanks,

Brian

  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor
    21 days ago

    Hi Brian,

     

    Thank you for the update.

     

    Just to clarify, the legacy database I referred to is our internal database for legacy devices. Unfortunately, there is limited information available regarding this wrong data issue. Based on the available info, I believe it was originally initiated from a customer-reported case.

     

    You are also correct that the placement rules are enforced within Quartus. Since these rules are built into the tool, they cannot be overridden through a TCL command.

     

    I apologize for any inconvenience this may cause. 

  • BrianSune_Froum's avatar
    BrianSune_Froum
    Icon for Contributor rankContributor
    21 days ago

    CheepinC_altera​ 

    I guess we had this more than enough on understanding the whold story.

    I deeply appreciate the sharing and assisting  on this ticket.

    I will close and report as solution.

    So I think 17.x is still worth to keep.

    Thanks,

    Brian