Re: SignalTap Advanced Triggering problem

SparkyNZ · ‎05-06-2021

I am trying to catch a write operation for address (A) values greater than 3c0h

Unfortunately SignalTap keeps triggering when the address is only 140h. I'm not sure if this is caused because of the transition from 4dxxxh to 140h. I tried moving my trigger so that it would trigger on WRITE_SET_ADDRESS instead of WRITE to give it an extra clock cycle between but it is still triggering. Is this a known bug? Is this perhaps what the latency settings are for on the GreaterThan comparison operator?

Here is my Advanced Trigger setup. I tried adding a LessThan condition too but it still isn't working as expected. The other conditions for my AND are all set to 1 - I just enable them at runtime when I need them.

sstrell · ‎05-07-2021

Do you have a storage qualifier enabled? It doesn't look like it from your waveform, but it's the only thing I can think of as to why the trigger sample at 0 does not match your trigger condition.

Have you tried a comparison trigger instead of this complicated advanced trigger? Choose comparison instead of advanced for the trigger condition column. You can set a range of values for the address bus to trigger on, like what you have here. But again it doesn't explain what you're seeing.

I presume you're using a mnemonic for sr_A that's named ADDRESS since sr_A doesn't appear in your trigger condition.

Is the DATA qualification of 0202h necessary?

Just throwing stuff out here to look at.

SparkyNZ · ‎05-10-2021

@sstrell just to answer your questions:

1) No storage qualifier

2) Comparison trigger - no - I need to avoid recompilation (which takes ages) when I'm trying to debug so I have the complicated advanced trigger in place that I can tweak at runtime

3) Yes, ADDRESS is an alias for sr_A

4) Data comparison for 0202h was necessary as I was trying to work out what is writing this data when it shouldn't be

Just some background - I have 2 8bit SRAM chips sharing the same address lines so that I can store 16 bits of data with the same address. When I was writing to 140h, I found that 4140h also contains the same data - so I've been trying to work out why. Seemed like a problem with address line 14 (the 4xxxh) but I still haven't worked it out yet. Time is short when it comes to my hobby, so apologies in the time it took to respond to your questions.

I haven't figured it out yet but I will keep investigating when I can. I don't think it's related to my FPGA code. I have 2 identical chips so I'm going to try a similar exercise with an Arduino and then repeat with the chips I'm using now.

Nurina · ‎05-10-2021

Hi,

Did the above reply help solve your problem?

Regards,

Nurina

SparkyNZ · ‎05-10-2021

Hi @Nurina and @sstrell. There some good suggestions, yes. I solved it by taking 3 address lines 16, 17, 18 and comparing them to 0 since I'm only interested in 16-bit addresses at the moment. That did the trick.

Nurina · ‎05-16-2021

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