XIO3130: Proprietary registers

Hi Darren,

Thanks for reaching out about this. Has the customer followed the work-around specified in item #2 of the errata document (relating DNxPERST#)?

I will ask internally about a document describing proprietary registers.

Best,

David

David,

Thanks for commenting. I believe we are properly implementing the working (as described in the errata document SLLZ071A - July 2012 - Revised May 2013).

The EEPROM configuration byte located at location 32h is set to 60h, which sets bit 14 of Downstream Port Configuration Space register 0D4h to '1', which indicates the slot is Hot Plug Capable.

Furthermore, I have confirmed using an oscilloscope that the UP_PERSTn and DN_PERSTn signals are driven with more than 100mS delay (see following image):

In this image, CH1 is UP_PERSTn and CH2 is DN_PERSTn. There is approximately 248 mS from de-assertion of UP_PERSTn to de-assertion of DN_PERSTn.

This is further confirmed by the following image:

Where we see that DN_PERSTn is de-asserted approximately 130 mS after the clock begins oscillating.

If there is something missing in terms of enabling Hot Plug mode properly, please let me know.

Thanks again for your comment.

Steve

If we assume that software is indeed responsible for disabling the clock (on only the 1 downstream port!), does it have to be through the REFCLK_DIS bit of the downstream port's General Control Register (offset 0D4h), or could it be disabled via some power-saving mechanism? In other words, some generic access generated by the upstream device that would have the effect of disabling the downstream port's clock...?

I ask this specific question because we've performed additional testing which appears to isolate the disabling of the downstream clock to the period prior to the PCIe bus enumeration. The only way this would make sense is if, in enabling it's own internal PCIe root complex, an external access was generated (automatically?) that had the effect of disabling the external clock on DN1...

Hi Steven,

To my knowledge, the REFCLK_DISABLE bit cannot be set by the XIO3130 except for in the event of a power fault trigger.

• The SLOT_PFIP (bit 6) field can be used to disable REFCLK during power fault.
• The RC_PF_CTL (bit 15) field can be used to disable REFCLK during power fault.

In Table 5-2, there is a section describing PCIe hot-plug side-band signals that could disable REFCLK, like PRSNT# and PWRGD#. So if any noise or transient on these signals is present, it could cause the REFCLK to be disabled on this port.

I believe this information was already relayed in the prior thread, though. I am not aware of a power-saving mechanism that would disable the REFCLK.

Best,

David

David,

Thank you for pointing out these fields. In our application (and as per TI's recommended settings) the values of both bit fields you indicate (SLOT_PFIP and RC_PF_CTL) are programmed to '0'. In this case, would that not prevent the device from disabling the downstream clock if the signals are a bit noisy?

• SLOT_PFID = bit 6 of register D4h, loaded from offset 31h (DN1) of EEPROM: Default value = 10h
• RC_PF_CTL = bit 15 or register D4h (8-bit register D5h), loaded from offset 32h of EEPROM: Default value = 60h

Is there anything else that could occur on the primary interface that would result in the downstream clock being disabled? According to our latest testing, we now believe the low-level code is doing sort sort of access to the device resulting in the clock on that one port being disabled... We do not understand how or what access is being performed, and the code is essentially a "black box": We have no access to the source code and have no control over its' operation. To say that debugging this issue is difficult would be an understatement...

Thanks for your help and comments.

Regards,

Steve

Hi Steven,

I would have expected these values to prevent the device from disabling DS REFCLK.

Is it possible that the reference clock is not stable for some period of time?

Are you able to read back the SLOT_PFIP and/or RC_PF_CTL bit fields after the reference clock is disabled? These two bits can be reset by PERST#, so I'm wondering if there is something happening on PERST# (though it doesn't appear so in your scope captures).

I am curious - what values do the SLOT_PRSNT and RCVR_PRSNT_EN bit fields return after the reference clock becomes disabled?

Best,

David

David,

I agree the default values contained in the EEPROM should prevent the downstream REFCLK from being disabled (I'm glad we're on the same page wrt THAT, at least... ).

With regards to your other questions, the following is a dump of the configuration Space registers for the entire chip (Upstream Port - Bus 2, and Downstream Ports 1, 2 and 3 (3:0.0, 3:1.0 and 3:2.0, respectively). This dump is performed while the downstream reference clock is disabled:

do_pci_scan_bridge for PCI: 02:00.0
PCI: pci_scan_bus for bus 03
ALGNOTE: Dumping PCI config space
PCI: 02:00.0 configuration space dump:
0000: 8232104C 00100000 06040002 00010000
0010: 00000000 00000000 00FF0302 00000101
0020: 00000000 00010001 00000000 00000000
0030: 00000000 00000050 00000000 000000FF
0040: 00000000 00000000 00000000 00000000
0050: FE037001 00000008 00000000 00000000
0060: 00000000 00000000 00000000 00000000
0070: 00808005 00000000 00000000 00000000
0080: 0000900D 3130102B 00000000 00000000
0090: 00510010 00008001 00192000 00064411
00A0: 10110140 00000000 00000000 00000000
00B0: 08A00000 00000024 00000001 00000000
00C0: 00000000 0007FBCC 02000001 00000000
00D0: 32140000 00000002 00000000 00000002
00E0: 3130102B 00000002 00043F24 00000000
00F0: 00000000 00000000 00000000 00000000
PCI: 03:00.0 configuration space dump:
0000: 8233104C 00100000 06040002 00010000
0010: 00000000 00000000 00000006 00000101
0020: 00000000 00010001 00000000 00000000
0030: 00000000 00000050 00000000 000001FF
0040: 00000000 00000000 00000000 00000000
0050: FE437001 00000008 00000000 00000000
0060: 00000000 00000000 00000000 00000000
0070: 00808005 00000000 00000000 00000000
0080: 0000900D 3130102B 00000000 00000000
0090: 01610010 00008FC1 00112000 011E4C11
00A0: 10010140 00000060 015803C0 00000000
00B0: 00000000 00000000 00000000 00000000
00C0: 00000000 00000000 06000001 00000000
00D0: 32140000 00006092 00000000 00000000
00E0: 00000000 00000000 00000000 0000001A
00F0: 00000000 00000000 00000000 00000000
PCI: 03:01.0 configuration space dump:
0000: 8233104C 00100000 06040002 00010000
0010: 00000000 00000000 00000000 00000101
0020: 00000000 00010001 00000000 00000000
0030: 00000000 00000050 00000000 000001FF
0040: 00000000 00000000 00000000 00000000
0050: FE437001 00000008 00000000 00000000
0060: 00000000 00000000 00000000 00000000
0070: 00808005 00000000 00000000 00000000
0080: 0000900D 3130102B 00000000 00000000
0090: 01610010 00008FC1 00102000 021E4C11
00A0: 30110140 00000060 015803C0 00000000
00B0: 00000000 00000000 00000000 00000000
00C0: 00000000 00000000 00080001 00000000
00D0: 32140000 00006090 00000000 00000000
00E0: 00000000 00000000 00000000 0000001A
00F0: 00000000 00000000 00000000 00000000
PCI: 03:02.0 configuration space dump:
0000: 8233104C 00100000 06040002 00010000
0010: 00000000 00000000 00000000 00000101
0020: 00000000 00010001 00000000 00000000
0030: 00000000 00000050 00000000 000001FF
0040: 00000000 00000000 00000000 00000000
0050: FE437001 00000008 00000000 00000000
0060: 00000000 00000000 00000000 00000000
0070: 00808005 00000000 00000000 00000000
0080: 0000900D 3130102B 00000000 00000000
0090: 01610010 00008FC1 00102000 031E4C11
00A0: 10010140 00000060 001803C0 00000000
00B0: 00000000 00000000 00000000 00000000
00C0: 00000000 00000000 00100001 00000000
00D0: 32140000 00006090 00000000 00000000
00E0: 00000000 00000000 00000000 0000001A
00F0: 00000000 00000000 00000000 00000000
PCI: 03:00.0 [104c/8233] bus ops
PCI: 03:00.0: REFCLK is disabled. Initial link state is 0x0001. Enabling REFCLK now.

The note in orange indicates that our software had detected the downstream clock is disabled and needs to be re-enabled..

The General Control Registers (Offset D4h) for downstream ports 1 and 2 are highlighted in RED - as you can see, the REFCK_DIS bit is set on DN1, but not on DN2.

• SLOT_PFIP = '0' on both ports.
• RC_PF_CTL = '0' on both ports.

As for the other fields you name:

• SLOT_PRSNT = '1' in both cases
• RCVR_PRSNT_EN = '0' in both cases.

If you look a the image below, you'll see an illustration of the initial activity on the downstream clock (approx. 2 sec), the period during which the downstream REFCLK is disabled (approx. 1.4 sec), and the moment at which it is re-enabled. Once re-enabled, the clock remains stable.

• Channel 1 (YELLOW): DN_PERSTn
• Channel 2 (CYAN): DN_REFCLKp/n

The notation of 120 mS is the approximate delay between the downstream REFCLK being stable and the removal of the downstream PERSTn.

Please let me know if you have any other comments/questions.

Regards,

Steve

Hi Steve,

Thanks for providing this info. Good to know that those bit fields are constant in both cases. I've looked through the configuration space register dump and can't discern anything different that would impact these ports.

My only other thought at the moment is that somehow the device is entering a low-power state that is disabling the reference clock of the downstream output port. Do you have the ability to measure the CLKREQ signal? I'm thinking it may be possible that this downstream port's ASPM L1 is enabled, causing the clock to drop (though I'm not sure if this would explain the initial REFCLK output, then drop of REFCLK after ~2 seconds).

Best,

David

Hi David,

I know - everything seems consistent ... except the fact that the clock drops for some unexplained reason!!!

Just to be clear, you would like to see the CLKREQ signal of the downstream device? It doesn't much make sense to measure the CLKREQ# pin of the XIO3130, since we know this clock doesn't stop.

The CLKREQ# signal of the downstream device is pulled high and not connected to anything, so if it does something, it would indicate the clock is being stopped as a result of some PCIe transaction on the downstream bus...

Hmmm...

Let me check that - I'll get back to you...

Regards,

Steve

Hi Steven,

Yes, I was thinking of the CLKREQ# of the DS device.

Keep me updated on any results you may see.

Best,

David

Hi David,

Unfortunately, nothing unexpected here.

When the downstream device's PERSTn rises, the device's CLKREQ# signal falls and remains low for all time - no glitches or subsequent transitions at all.

Regards,

Steve

Hi Steve,

Thanks for the feedback about CLKREQ#. I'll have to think about this one a bit more, there aren't any major differences between each downstream port that are standing out to me right now.

Best,

David