I assume your question is, why doesn't Signaltap agree with your oscilloscope.
Quartus Signaltap isn't a simulator, it's an embedded logic analyzer (synthesized into the FPGA configuration, alongside the design under test). It's basically a state machine that captures internal signals and communicates with the Quartus software to display. So unlike simulation, it can capture what's really happening on the FPGA in real time. You could build your own equivalent out of flip-flops and block RAM, and it would have the same kinds of limitations. Like any tool, there are limits to what it can do. But it still has the same limitations as any state machine.
If the power supply is glitchy or underpowered, that affects everything in the FPGA, both your code and the Signaltap code.
If the clock has jitter, that jitter affects everything in the FPGA, both your code and the Signaltap code.
If the FPGA is overheat, affects everything in the FPGA, both your code and the Signaltap code.
If the FPGA is too crowded (so signal routing performance is poor), affects everything in the FPGA, both your code and the Signaltap code.
For observing the RST reset toggling as you described, I believe the oscilloscope is more accurate than the embedded logic analyzer. The embedded logic analyzer would be a better tool for collecting a deep buffer of the logic states of the signals. The oscilloscope is a better tool for observing the actual voltage and timing of external signals.
Use the oscilloscope (and review of the synthesis log files) to validate that the embedded logic analyzer is working correctly, so that you can make use of its deeper and wider buffer and its access to internal signals.
You might want to run
Post-Place-And-Route Simulation to examine why the internal RST signal reported by Signaltap embedded logic analyzer behaves differently than the external RST signal observed by oscilloscope. You might also want to examine the
RTL Schematic and the
Technology Schematic to verify what was actually configured in the FPGA code.