Forum Discussion
ContributorWhat is the limit on signals in signal tap II
Again, using a state-based trigger or other options I mentioned, you can capture data from multiple subsequent events before the logic analyzer stops, limited by the size of the buffer.
Super ContributorThe limit on signals used to be 2048 per instance, but I think it may be greater now.
Bandwidth is not an issue. Remember that the captured data is stored on the device in block RAM when a trigger occurs before being transferred over your programming cable so there is no bandwidth requirement. Data is always transferred with the logic analyzer is triggered or you can transfer it manually with one of the control buttons just above the instance manager.
Each new trigger clears the block RAM. If you're saying that you are looking at multiple trigger events one after another and want to see signal levels for each, then you'll need a more complex logic analyzer setup, such as using a state-based trigger where you can capture multiple triggers and progressively fill up the buffer or use multiple instances of the logic analyzer.
Multiple instances are independent from each other (unless you link them with trigger in/trigger out) and will all work simultaneously (shift-click to start multiple instances simultaneously).
I don't understand your final question.
ContributorThanks, my last question has wrong wording. What I want to know is, why does Signal Tap II not allow user to copy signals from one instance to another? Also, copy a whole instance from one signal tap to another?
In my case when signal tap has captured a lot of complex data, I just save the signal tap instance with a different name and then analyse it later. Is this the correct approach?
By bandwidth I mean, is it possible that when there are so many signals in the signal tap II instance and trigger events occur at very high frequency, the programmer cable will not be able to transmit all data before the next trigger event? I am sure this is possible to happen.
- sstrell
Copying signals: simply not a feature that's in the tool. You could request it perhaps.
Again, when a trigger occurs, the logic analyzer stops and buffers the data. The situation you mention does not happen. If you're talking about multiple trigger "conditions" (the condition columns in the tool) the logic analyzer only stops and captures data when the final trigger condition column is true. It does not capture data from the previous trigger condition columns. That's why I said that if you want to capture data from multiple trigger events that occur close to each other, you'd need a state-based trigger (to manually control when data is stored in the buffer so you could store data from each event) or multiple logic analyzer instances.
There's only one buffer for each instance of the logic analyzer and it gets sent to your computer only when the trigger conditions have all occurred. So again, there would never be a bandwidth issue because there is no urgency in sending out the buffer data since you'd have to start the logic analyzer manually to look for the trigger conditions again (at which point the buffer is empty again anyway).
NurinaRegular Contributor
Hi @gyuunyuu,
Did the above reply help you with your problem? Let me know if you have anymore questions.
Regards,
Nurina
P/S: If you find any comments by the community or Intel Support to be helpful, feel free to give Kudos.
- gyuunyuu
Yes this has been helpful. However, I still have a doubt.
Lets suppose that there is 2k buffer depth and the signals on the screen come to 128 bytes. When the trigger condition occurs, all of 2k*128 bytes of data shall be transmitted to the screen and appear on the screen. This is 250kB of data.
If the trigger condition occurs every microsecond, we would need to transmit 250kB of data every microsecond. This shall give 10^6 transfers of 250kB of data per second. This comes to (2000*128)*10^6/(1024^3) GB/s which is about 238.42 GB per second. I am sure that the byte blaster is not capable of transmitting so much data.
I hope that the source of my confusion is clear now.
