Unpredictable Signaltap behavior (QPPro 20.2, Cyclone 10GX)

[NWein]

I'm debugging a Cyclone 10GX design, and we are doing a lot of work with Signaltap.  I've been using Signaltap for years and year, and it's always been solid and predictable.  Now, however, with my first C10GX design, each new build is a roll of the dice whether Signaltap will work correctly or not.

I'm not doing anything fancy; using mostly default settings for Signal Configuration, other than increasing Sample depth to 512 or 1K usually.  Not typically sampling much more than about 100 total signals.

What I mean by "working correctly" is that Signaltap will obey my trigger conditions, and collect a full buffer worth of samples.  When it does not work correctly, then it will always trigger immediately regardless of what trigger conditions I set, and the waveform that appears will start exactly at t=0, with nothing captured beforehand, regardless of the trigger position.  See attached image.  For this grab, I set to trigger on rising edge of AV_PRE.  It triggered immediately despite AV_PRE being steadily low, and no samples were collected prior to t=0.

Each build from Quartus will (mis)behave repeatably.  The build I took that sample from will do that every time I load it.  If I change the set of signals in the .stp file, I might get lucky and the next build will work normally.  But it's particularly miserable form of trial and error, and I am burning a lot of time trying to build over and over again just to get a working signaltap.

I have no ideas here.  Any input would be appreciated.

[sstrell · Accepted solution]

Is your design meeting timing?  If you're failing timing, that could be causing the issue.  

Check that you have selected the correct sampling clock and that it is functioning correctly (if possible).

Do you have any of the storage qualification features turned on?  This could be the cause of missing samples from what you expect.

If you start the logic analyzer running again from this point (after it ran incorrectly the first time), does it run correctly for subsequent runs?  I think you may be saying that subsequent runs do not work correctly until you recompile, but I wanted to clarify.

Can you show the configuration tab to see the trigger conditions and the configuration settings for the logic analyzer?

[RichardTanSY_Intel]

Hi,

Do you able to solve the issue based on Sstrell's suggestion?

[NWein]

I've tweaked my timing constraints a bit, and it may or may not be fixed.  Results are still inconclusive, but I should have a better idea in the next day or two.  I will report back.

Thanks,

Neil

[NWein]

It does indeed look like it was timing related in the SignalPath logic.  After adjusting my constraints things seem to be working more reliably.

If it starts breaking again I'll report back.

Thanks,

Neil

[gyuunyuu]

Could you kindly specify how you were able to constrain the design to fix this problem?

[NWein]

I had put in some set_false_paths for the Signaltap paths, because some of them crossed clock domains and were generating all kinds of timing errors for me (that I didn't care about).  Apparently those set_false_paths were breaking Signaltap, because when I removed them it started working again.