intermittent sysACE hang on ML310

After adding Ethernet core (full) to our ML310 design, (with an Intel 
development PHY board connected through spare GPIO pins on PM1), we are 
seeing intermittent sysACE / Compact Flash lockups in the vxWorks boot.

Through many toils and snares, we have determined that when this lockup 
occurs, the actual hang is occurring on the line:

while (XSysAce_Lock(AcePtr, XFALSE) != XST_SUCCESS);

in the xsysaceblkadapter.c file in the function: 
"XSysAceBlkAdapter_Init(Xuint16 DeviceId, unsigned MaxPartitions)."

It seems that disconnecting our Ethernet cable during the boot-up, makes the 
problem disappear--- and I have no earthly idea how Ethernet 
traffic/interrupts can affect sysACE controller. I'm guessing a timing/FPGA 
build issue, but have no clue where to start on finding/isolating/fixing the 
issue--if indeed it is in the FPGA place/route/timing arena.

The comments in the xsys driver code, are puzzling to me. In particular, it 
says

"This function blocks waiting on a lock from the System ACE controller. If
 a JTAG configuration is in process, this function will block until the
 configuration process is done."

and in the comments for the XSysAce_Lock() function:

"If the user requests a forced lock, the JTAG configuration controller will
 be put into a reset state in case it currently has a lock on the 
CompactFlash.
 This effectively aborts any operation the configuration controller had in
 progress and makes the configuration controller restart its process the
 next time it is able to get a lock.

 A lock must be granted to the user before attempting to read or write the
 CompactFlash device.

Force is a boolean value that, when set to XTRUE, will force the MPU
lock to occur in the System ACE.  When set to XFALSE, the lock is
requested and the device arbitrates between the MPU request and
JTAG requests. Forcing the MPU lock resets the configuration
controller, thus aborting any configuration operations in progress.

return  XST_SUCCESS if the lock was granted, or XST_DEVICE_BUSY if the lock 
was
not granted because the configuration controller currently has access to the 
CompactFlash.

If the lock is not granted to the MPU immediately, this function removes its
request for a lock so that a lock is not later granted at a time when the
application is (a) not ready for the lock, or (b) cannot be informed
asynchronously about the granted lock since there is no such interrupt 
event."

Now this leads me to the following questions:

1) why isn't the initialize function forcing a lock? Would something bad 
happen if it did?

2) I don't understand what will happen in the lock routine if force is true 
when it 'releases the reset'. Does this mean it'll try to re-configure the 
FPGA?

3) Should I put a timer/timeout around the while statement and if it times 
out, call it again with Force=TRUE?

Has anyone else encountered problems like this? I admit is very peculiar and 
troubling that adding an Ethernet core is impacting the sysACE at all.

Thanks,

Paul 

Hi

   Why do you need to add an ethernet core? I think there has alread
been an ethernet core on ML310. I also want to access the ethernet
which is connectted to PCI bus. But I cannot figure out how to acces
it through PCI. Do you have any experience about that?

   Thank you