Signal Tap effects design / state machine behavior on an Arria 10

[Altera_Forum]

Hi All, 

 So I am currently having an issue with a design that interfaces the EMIF IP block on an Arria 10.  In simple terms data is captured in clock domain A, passes through a FIFO into the EMIF user clock domain where it is stored in DDR Memory, this data is later recalled, processed in clock domain C (again after passing through FIFO), and then returned via another FIFO and stored into memory again. Eventually, data is recalled for a final time and output via a FIFO to a USB interface.  When I use Signal Tap to observe the state machine is that interfaces to the EMIF memory block the design appears to work as expected, however, if we remove the signal tap the design gets stuck in a Valid state (looks like it counts more data out for processing than it gets back to gets stuck waiting for more data to return from processing)  I have made sure that all signals into the State machine are registered into the right clock domain and I have declared all of the clock signals into different groups and I have no failing paths on Timequest.  Has anyone seen anything like this before? I'm struggling even to visualise what's going on that could cause these symptoms, let alone how to resolve it.  It seems to me that it must be timing based - signal tap is causing something to be interpreted differently when Altera does timing analysis? but how and why?  Thanks for any insight that anyone may have, and please let me know if you require any more information.  Ben

[Altera_Forum]

What signals are you tapping in Signal Tap? Are you using the clock provided by the IP for clocking your user logic (the state machine)? 

 Yes, this seems like it would be tricky to debug. You might need to simulate the design.

[Altera_Forum]

I have heard of people running into this and it's typically caused by a timing bug in the hardware design. When you add signaltap you are adding resources to the design, and as a result changing the place and route of the logic which will cause timing changes. If your statemachine takes in inputs from the I/O then make sure those paths are constrained because Timequest cannot analyze those paths without constraints since it doesn't know anything about your board timing without them.  

 Without constraints what could happen is an input flip flop fails timing but when you add signaltap that FF gets pulled further into the FPGA fabric and ends up capturing data one cycle later. So this would be a valid timing failure that Timequest may not catch if the I/O are not constrained.