Hello,
in one of our designs, we left CLKRUN_EN and EXT_ARB_EN unconnected since the documentation showed internal pulldowns.
Unfortunately, the XIO2001 erratas (scpz008b.pdf) from 2012 tell us that these internal pullodwns do not work. The recommended workaround is to connect external pulldowns to these pins.
But adding these external resistors is no option for all boards already produced, since the we use the XIO2001 in a BGA package.
In contradiction to the errata, even the actual data sheet from 2016 talks about internal pulldowns on these pins (note 1 on page 20):
And until now, we had no issies with the XIO2001 that could be related to CLKRUN_EN or EXT_ARB_EN effects.
Is there perhaps a new chip revision already available that fixes this errata?
When is the status of CLKRUN_EN and EXT_ARB_EN sampled by the XIO2001?
- According to the errata, CLKRUN_EN and EXT_ARB_EN are only sampled at the rising edge of GRST#.
As GRST# is also left unconnected on our boards, does this eliminate the errata as there will never be something like a GRST# "rising edge"? - According to the data sheet,
- CLKRUN_EN is sampled when PERST# is high, or at the rising edge of PERST#? The text in the data sheet is a bit unclear:
When PERST is de-asserted and if a pullup resistor to VDD_33 is detected on pin C11 (CLKRUN_EN), the clock run feature is enabled. - EXT_ARB_EN is sampled at the rising edge of PERST#:
When PERST is deasserted, the logic state of the EXT_ARB_EN pin is checked. - all static control inputs are latched at the rising edge of GRST# and at the rising edge of PERST#:
When the rising edge of GRST occurs, the bridge samples the state of all static control inputs and latches the information internally.
When the rising edge of PERST occurs, the XIO2001 samples the state of all static control inputs and latches the information internally.
- CLKRUN_EN is sampled when PERST# is high, or at the rising edge of PERST#? The text in the data sheet is a bit unclear:
Are CLKRUN_EN and EXT_ARB_EN static control inputs, and when are they interpreted by the XIO2001?
What about the external serial EEPROM?
Is it possible to overwrite the CLKRUN_EN and EXT_ARB_EN settings with an appropriate EEPROM content?
I'm sure a company like Texas Instruments, well known for good chip designs, implemented such an option.
I case there's nothing that can be done about it (worst case) and the CLKRUN_EN and EXT_ARB_EN inputs are really floating, meaning that it's just luck if it works or not, what will happen when
- EXT_ARB_EN is detected high by the XIO2001
In my understanding, this will lead to the scenario that right after PERST# deassertion, the XIO2001 will try to request the bus from the (not exisiting) external arbiter to perform the PCI configuration cycles.
This "bus request" is asserted on the IO pin that connects to the GNT# pin of the connected PCI-Device. This device would have to drive its REQ# pin low to grant the bus to the XIO2001. But this will not happen as the PCI-Device is not setup at all.
Is this correct? - CLKRUN_EN is detected high by the XIO2001
GPIO[0] is also unconnected in our designs.
Is there the possibility that any connected PCI-Device will be damaged?
Is it possible that everything runs find for a while and then fails after a random time?
I am looking forward to your answers.
Regards, Niels
