Forum Discussion

ZVdP's avatar
ZVdP
Icon for New Contributor rankNew Contributor
4 years ago

CycloneV GT transmitter Electrical Idle not working

I'm having some issues with the electrical idle mode of the Cyclone V GT transmitters.

I currently have a working design with 4x 5Gbps duplex transceiver channels that I'm now trying to extend to 8 TX + 4 RX. The fitter didn't complain and everything compiled nicely. But when I hooked up the transmitters of the extended design to an oscilloscope, there was no electrical idle to be seen.

So I started digging, and I noticed that when I instantiate a TX-only PHY (Transceiver Native PHY, basic mode) the 'tx_std_elecidle' signal is not connected to anything in the RTL viewer, in contrast to a TX/RX duplex PHY instance:

For a duplex PHY, the electrical idle signal goes to 'av_hssi_common_pld_pcs_interface_rbc' where it's connected to the 'CYCLONEV_HSSI_COMMON_PLD_PCS_INTERFACE' primitive, while for a TX-only PHY, the signal goes to 'av_pcs_ch:ch[0].inst_av_pcs_ch' where it is left unconnected and doesn't go to the 'CycloneV_HSSI_TX_PLD_PCS_INTERFACE' block.

(see attached screen captures)

Some options I tried/considered already:

*Tried latest version of Quartus Prime Lite 21.1 and earlier version 16.0

*Create duplex PHY instances with the 4 RX's I don't need kept in reset. However I need 2 groups of 4 transmitters each with a separate reference clock per group, and the fitter can't place this in my current device with 9 transceiver channels. (I think the 2 TX PLLs can't both be placed since the fPLLs can't be used at 5Gbps)

*Use a larger device with 13 channels, but parts are hard to find at the moment.

*Use Cyclone 10 instead of V; here the RTL viewer does show 'tx_std_elecidle' connected in TX-only mode. However the max 1000mV diff output amplitude is not optimal compared to the 1200mV swing of Cyclone V.

None of these are ideal, so I was wondering if there is a workaround to connect tx_std_elecidle in a TX-only PHY instance?

4 Replies

  • Kshitij_Intel's avatar
    Kshitij_Intel
    Icon for Frequent Contributor rankFrequent Contributor
    4 years ago

    Hi Zjef,


    Have you enable the tx_std_elecidle?


    When you enable this option, you will have an extra input port (tx_std_ elecidle). When this signal is asserted, it forces the transmitter to electrical idle. This signal is required for the PCI Express protocol and you need to control it.




    For detailed info sharing resources. Please go through this.


    Cyclone V Device Handbook: Volume 2: Transceivers


    V-Series Transceiver PHY IP Core User Guide


    Hope it will help you. Please feel free to ask any further question.


    If still facing issue, please share your project and i will resolve the issue, if any at my end.


    Thank you

    Kshitij Goel





    • ZVdP's avatar
      ZVdP
      Icon for New Contributor rankNew Contributor
      4 years ago

      Hi K**bleep**ij,

      Yes, the tx_std_elecidle port is enabled.

      I have attached a minimal setup showing the issue.

      The top level contains two Transceiver Native PHY Cyclone V instances. The first one has only the transmitter path enabled (PHY_TXonly), the second one both transmitter and receiver (PHY_TXRX).

      Both have their tx_std_elecidle port controlled by a top level input port. However when you look in the technology map viewer, the idle input of the PHY_TXonly instance is synthesized away.

      I have also included a Modelsim simulation that shows that the tx_std_elecidle input of PHY_TXonly has no effect, while the one of PHY_TXRX works as expected (simulation/modelsim/msim_setup.do should set up everything).

      Thanks,

      Zjef

      • Kshitij_Intel's avatar
        Kshitij_Intel
        Icon for Frequent Contributor rankFrequent Contributor
        4 years ago

        Hi Zjef,

        When tx_std_elecidle [<n>-1:0](input) is asserted, it tries to enable a circuit to detect a downstream receiver. But you are not using any receiver for PHY_TX only. So, it is having no effect. And this signal must be driven low when not in use because it causes the TX PMA to enter electrical idle mode with the TX serial data signals in tristate mode. Enabling of this signal is required only for the PCI Express protocol.

        Application of the tx_std_elecidle signals stops transmission of any TX data, but the output remains terminated to Vcm through the on chip TX termination to Vcm. The TX termination is typically 50R. And this is relatively low impedance, tristate would be high impedance.

        The PCI Express specification defines “Electrical Idle” as “The state of the output driver in which both lines, D+ and D-, are driven to the DC common mode voltage.”

        So the word “driven” also reinforces the belief that we don’t “tristate” the TX buffer. To tristate the TX buffer, we would need to switch off TX termination which we do not support dynamically.

        Sure the Tx buffer is tristated but the termination remains in place.

        You should be careful about the term “tristate” for the TX Pins in the userguide. This function was designed for PCI Express.

        It is true that we tristate the buffer when asserting tx_std_elecidle(Native PHY) and tx_forceelecidle(Custom PHY). However, the TX Termination to Vcm remains in place, so there will still be a steady state voltage on the Tx pins. Depending on what you connect your transmitter to, this termination may create a potential divider.

        The termination is typically 50R. This termination cannot be switched off.

        Thank you

        Kshitij Goel

  • Kshitij_Intel's avatar
    Kshitij_Intel
    Icon for Frequent Contributor rankFrequent Contributor
    4 years ago

    Hi Zjef,


    As We do not receive any response from you to the previous reply that I have provided. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.