Why do we need a SignalTapII that stores data on FPGA instead of...

[Altera_Forum]

transmitting it to the PC directly? 

I am sure that if a system is designed with the idea of interrupts sent to PC through JTAG, than all those thousands of samples can just be transmitted to the PC instead of being stored on the FPGA. I find this rather strange that when an FPGA has such limited resources, we should use them to store our data along with the actual design itself.  Why not design the device to send the data to the PC directly?

[Altera_Forum]

Because the rate at which data can be transfered to the PC is very slow by comparison with the rate at which data can be written to internal memory.

[Altera_Forum]

JTAG typicaly operates at 8 or 24MHz on Altera boards so factor in overhead that doesn't leave much bandwidth to sample in realtime. Normally if you need real time capture of data you use an external logic analyzer which is capable of keeping up with the data rate. Pumping that much data continuosly over JTAG makes about as much sense as draining a pool using a milkshake straw :)

[Altera_Forum]

A hand calculation should answer the question. Presume a SignalTap instance acquiring 256 signals at 100 MHz. Makes not less than 26 GBit/s netto data rate. No PC can receive it, not talking about the interface.

[Altera_Forum]

I see. Related to this is the question regarding which tool is more popular and why among: 

SignalTapII logic analyzer, Logic Analyzer interface editor, and In-System sources and Probes editor. I know something about the first one but not the other ones.

[Altera_Forum]

Here are some thoughts: 

SignalTap is most popular especially for beginners who can view their achievement for real. It is easy, but needs care with clock(s) and fpga fmax. Practically not useful for large project testing but only minor debugging. sources and probes is useful if you want to debug without changing fpga build (for build sensitive cases). logic analyser Interface editor: never used it but sounds it is external analyser instead of signaltap and so must be far more more powerful and does not need changing fpga build

[Altera_Forum]

If you have build-sensitive issues signal tap doesn't help much - since adding the 'tap' points requires a rebuild (unless you had the forsight to add the tap points in exactly the right places when the design was originally done). 

We had some issues with M9K blocks not returning 'OLD_DATA', but failed to trace the error occuring so can't be 100% certain we've actually fixed it (although we finally found out why it was failing - the OLD_DATA request was being silently ignored (well it might have been hidden the the 1000s of warning message) because the SOPC builder passing in two clocks and one of them had an associated 'clock enable').