SignalTapII reliability

Very strange indeed. Are you using TimeQuest? The path where you sample the clock should be treated by the "clock as data" analysis that TimeQuest can do. If you're not sure or not analyzing this path, it's not overly surprising that your clock-as-data could have timing violations. It's not like your other paths where the clock delays to source and destination registers cancel out and you have a 0ns hold requirement and you just need short data delays to meet setup requirements. If you've already shown with a scope that your 40 and 80MHz clocks are clean, sampling the clock and inspecting it is probably more trouble than it's worth. (And of course, an 80MHz clock period doesn't evenly go into a 200MHz sampling clock. With periods of 12.5ns and 5.0ns, every othe sample will be in the middle of a data change, so all data in that domain should be ignored if you're sampling with that clock).