Forum Discussion
The "asynchronous" inputs are actually from another state machine inside the FPGA running on a different clock domain. The clocks are nominally the same frequency, but because they come from external sources this is not guaranteed. I wanted to avoid the exact situation you described, so I put in a request/ack system between the two. The initiating FSM raises a Req signal and waits for the receiving FSM to raise the Ack signal. When the initiating FSM sees the Ack, it lowers the Req signal. When the receiving system sees the Req go low, it lowers the Ack. When the initiating system sees the Ack go low, it continues on and is allowed to initiate a new Req. I also double registered the signals between the two as described above to prevent metastability, but this might be overkill. The delay caused by these registers causes the Req/Ack signals to be held longer than necessary.
Req __------______
Ack ______------__ In the Signaltap I posted previously, you can see the high request line, the raising of the Ack, the request subsequently falling (gated through safe_fabric_transmit_req[1:0]), and the receiving FSM transitioning based on the request line going low (this is where it fails the state change). The Ack goes low as it should, but that is probably just because that signal is based on being in the Ack state, and we have moved into some bad state. I'll look into how I generate this Req signal in the other FSM, and see if I'm doing something that might cause glitching or some other funny business.