XIO2001: Malfunction when using an external arbiter

Hello Conor,

Thank you for reaching out about this observation.

1. We are aware of Errata #5 in the XIO2001 Errata document, though your observation does not appear to exactly match this errata.
   • Which power rail is being used to pull up EXT_ARB_EN? The EXT_ARB_EN pin will only be sampled when GRST# is de-asserted.
2. I am not aware of any register settings which are required. You've noted that you are aware of the REQ# / GNT# connections which differ depending on the arbiter mode. Are the un-used REQ# pins on the XIO2001 pulled up to the clamping rail (V_CCP) as recommended by data sheet Section 9.2.1.2.1?
3. The only documents that I am aware of with details on this description are the XIO2001 Implementation Guide and device data sheet.

Could you help me to better understand the use of the external arbiter in your system vs. the internal arbiter of the XIO2001?

Best,
David

Hi David,

David Waier said:

Which power rail is being used to pull up EXT_ARB_EN? The EXT_ARB_EN pin will only be sampled when GRST# is de-asserted.

GRST# is open (PU not implemented), and I am expecting an internal PU. I expect it to be sampled when the power is turned on.

Extracted from the table on Datasheet P14 Miscellaneous Pins (continued)

Note: The GRST input buffer has both hysteresis and an internal active pullup. The pullup is active at all times.

CLAMP RAIL: VDD_33_COMBIO

Are there any problems with this connection?

David Waier said:

I am not aware of any register settings which are required. You've noted that you are aware of the REQ# / GNT# connections which differ depending on the arbiter mode. Are the un-used REQ# pins on the XIO2001 pulled up to the clamping rail (V_CCP) as recommended by data sheet Section 9.2.1.2.1?

We have recognized that the operation may be affected by the clamp rail (VCCP, PCIR) that should be on the secondary (PCI) side. We will continue to check.

David Waier said:

Could you help me to better understand the use of the external arbiter in your system vs. the internal arbiter of the XIO2001?

The product uses an external arbiter (because 7-master support is required).
Operation checks with the internal arbiter were conducted solely for research purposes, to confirm the impact of the arbiter.

Thanks,

Conor

Hello Conor,

Conor said:

GRST# is open (PU not implemented), and I am expecting an internal PU. I expect it to be sampled when the power is turned on.

Extracted from the table on Datasheet P14 Miscellaneous Pins (continued)

Note: The GRST input buffer has both hysteresis and an internal active pullup. The pullup is active at all times.

CLAMP RAIL: VDD_33_COMBIO

If I am understanding you correctly, EXT_ARB_EN is clamped by VDD_33_COMBIO. Is this correct?

If this is the case, what I am thinking could be happening is that EXT_ARB_EN is rising at the same time as GRST#, which may be causing the pin to be sampled incorrectly when GRST# is de-asserted. I would recommend pulling EXT_ARB_EN up using the VDD_33 power rail, if this is not the case already.

Conor said:

The product uses an external arbiter (because 7-master support is required).

Thank you for confirming.

1. Could you please help to share the schematic of your implementation to help us to better understand the XIO2001's configuration in your system? You can share this here, or over E2E private message if you'd prefer.
2. Could you share a waveform of your power-up sequence showing VDD_33, VDD_15, PCIR, and GRST#?

Please note that with the upcoming US holidays, I will be out of the office starting tomorrow and returning on December 30. So, responses will be delayed for a period of time. Apologies for any inconvenience.

Best,
David