ALT2GXB reset sequence without RX Clock

[Altera_Forum]

Hello. I'm creating a reset controller for a new design that utilizes the Arria GX transceivers. I'm targeting PCI Express x1. I'm seeing that the rx_pll_locked signal is incorrectly being asserted by the ALT2GXB block when the gxb_powerdown signal is deasserted although no RX reference clock exists. This causes problems in my state machine because it thinks the RX clock is good although it is really not. If the RX reference clock is good then the rx_pll_locked signal is correctly only asserted later in the reset sequence. 

 I'm essentially stuck at this point so any pointers are very much appreciated.  My two test scenarios are to load the design into the Arria GX Dev Board when the target machine is turned off (no PCIe Ref Clk) vs loading the Arria GX Dev Board when the target machine is turned on.  Please see the attached JPGs for details. The Reset Controller next state table is also attached.

[Altera_Forum]

I am seeing something very similar with SerialLite II on Arria GX. Basically I have nothing coming into the rx lane but the IP core thinks that there is something there. I even get random data coming in on the decoded data output and sometimes the data valid signal is asserted. The other signals (pll lock and company) also behave (intermittently) like something is coming in. 

I am using the Arria GX demo board. If I figure out something, I will let you know - this must be ALTGXB-related, which is common to both protocols. I too need to fix this because it throws my state machine off.

[Altera_Forum]

I have concluded that there is no way to get the ALT2GXB reset sequence working without having a valid RX PLL clock available when the gxb_powerdown signal deasserts. I have therefore configured the CRU to use the Arria GX Dev Kit board's 100 MHz clock as both source for the TX PLL as well as for RX PLL input. I figure that the CRU will first lock to the local 100 MHZ PLL and then switch over to lock to the embedded clock in the PCI Express data once available. The attached JPG seems to indicate that this works okay so far. 

 One question i have is; Why has the MegaWizard configured my custom ALT2GXB MegaFunction's single-wire outputs as 2-wire buses? For instance, see the 'rx_ctrldetect' signal in the attached JPG - i don't know whether to look at bit 0 or 1. For this signal, it seems logical to ignore bit 1 but for other signals both bits [1..0] toggle more frequently.  Edit: After learning some more, i now realize that the [1:0] status bits are such that status of both bytes in the rx_dataout[15:0] bus can be determined.