Do I need to synchronize the the PCS# input according to the errata if the client circuit is clocked by BCLK?
In an ENI bus cycle, the PACK* signal, as driven by the NET+ARM in acknowledgement of an externally driven PCS* active low at the start of a new cycle, has been observed to hang (stuck at active low) indefinitely, or until a terminating condition occurs (for example, PCS* going back to high). This problem manifests itself when PACK* is configured in RDY mode, and seems to be a random failure that may not be observed for many hours at a time, or at all. Workaround - Synchronization of the external PCS* input with the negative edge of BCLK through a dual-rank flip-flop should ensure a proper hold time on the PCS* signal. NetSilicon uses shared memory without this hardware work-a-round. It is re-started under code control. The answer in short is yes.
Dear Muscleman, I have met this problem too. The client suspends to run frequently while writing ENI interface. However I think the workaround is a little simple. Could you provide more information on the workaround: 1. What is the dual-rank flip-flop? does it mean the D type flip-flop chip such as TI SN74LVC74? it would be better if the actual solution circuit schematic is provided. 2. Do I need to disconnect ENI PACK signal? Thanks