Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
15332 Discussions

What is the limit on signals in signal tap II

gyuunyuu
New Contributor II
320 Views

The byte blaster cables have a data limit. Signal Tap requires that data be transmitted through the byte blaster on every single trigger event.

How do we know how much bandwidth signal tap is using when we use it?

Can we be sure that signal tap will always transfer data on every trigger event?

Is it possible that a trigger condition is missed because it occurred when signal tap was transferring data from the last trigger event?

When signal tap has more than once instance that is enabled and synthesized, does it reliably capture data from both instances although they use different triggers?

And finally, why doesn't signal tap apply once to copy past instances and signals from one signal tap to another?

0 Kudos
1 Solution
sstrell
Honored Contributor III
228 Views

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.

View solution in original post

13 Replies
sstrell
Honored Contributor III
305 Views

The 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.

gyuunyuu
New Contributor II
291 Views

Thanks, 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
Honored Contributor III
284 Views

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).

Nurina
Employee
269 Views

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
New Contributor II
255 Views

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.

sstrell
Honored Contributor III
235 Views

Again, that's not how Signal Tap works.  As soon as a trigger condition occurs, the logic analyzer buffers the signal data and stops.  It does not continue looking for another trigger.

If you need to see data from two (or more) events that occur in a short period of time, then you need to adjust the trigger conditions as I mentioned to allow for that data to get stored in the buffer before the logic analyzer stops.

Think of it like a bench logic analyzer, not like a bench oscilloscope.

gyuunyuu
New Contributor II
230 Views

This means there is a weakness since the logic will not look for another trigger event until the current data has been pushed out to the computer. This means that certain trigger conditions can get ignored by it if they occur too soon.

sstrell
Honored Contributor III
229 Views

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.

Nurina
Employee
217 Views

Hi @gyuunyuu,

 

Do you have anymore questions related to this issue?

 

Regards,

Nurina

gyuunyuu
New Contributor II
203 Views

Not for now. Please close this SR.

Nurina
Employee
193 Views

Hi,

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

Regards,
Nurina

PS: If you find any comment from the community or Intel Support to be helpful, feel free to give Kudos.

Nurina
Employee
244 Views

Hi,


Can you elaborate where you get the 128 bytes?


Regards,

Nurina


gyuunyuu
New Contributor II
240 Views

The 128 bytes is just a made up number, you could use a smaller number as well like 16 bytes?

Reply