TPS65983B: Support request for single-port, self-powered AR device with TPS65983B, cont.

Somebody locked my thread so this may get a little confusing.  We got the self-powered AR LP to work with properly configured firmware.  Thanks for the assistance.  

Unfortunately we’re having PCIe enumeration problems on PC hosts (NUC, Dell, etc).  Mac is OK.  After DUT powers up TB3 always connects but PCIe fails to enumerate properly half the time.  The host always sees the Intel vendor ID on the bridge.  But half the time the PCIe core in our FPGA (Spartan-6, 1x1, Gen1) fails to complete link-training and thus fails to update the IDs.  That occurs around half way through its state machine making it fail to initialize config space with our vendor and device IDs.

We’ve made a few crude attempts to delay and re-assert DG_RST_L (from the TPS65983B).  We’ve seen no data integrity errors so we’ve ruled out SI.  The DUT has passed pre-cert PCIe and CIO tests.  When PCIe does initialize successfully we can repeatedly unplug/plug and it always enumerates after that (unless we power cycle the DUT).  In comparing the signaling between success vs. failure cases we see no difference in timing of power sequencing, resets, etc. from the PD and AR.

We’re using the latest versions of the TI and Intel base images.  We’ve tried enabling hot swap in the Intel firmware - unsuccessful.  We suspect it may be a timing issue where the PC may be expecting the AR bridge and our device to be available too soon.  What kicks off the sequence is the PD firmware de-asserting DG_RST_L to AR.  Is there a register we can tune to delay de-assertion of DG_RST_L?

Could you please review the above info and provide feedback?  Any known errata which might explain what we're seeing?  Our timeframe is immediate (blocker!).  Thanks.