SignalTapII reliability

[Altera_Forum]

Hi All, 

I ahve a question / doubt about Signal Tap II (STII) reliability : I'm doing some tests on a Stratix II GX FPGA mounted on a custom board, which is receiving datas from an optical connection. I have some parameters of interest to be displayed in my STII file, but the software is acting weird.  For example in my design I am using a PLL with 40 Mhz input and 2 outputs: 40 and 80 Mhz, both at 50% duty cycle. Also these waveforms are to be displayed in the STII file. WHen I start acquiring data, the clocks are acting in a not contstant way: sometimes the duty cycle represented is not 50%, sometimes I have 1 of these 2 clocks shown as a constant signal. I routed them to 2 output pins of my board and probed them with a oscilloscope: they seem to be correct!  But apart the clock, my problem is that I don't know how much to trust the other signals in the STII file: other simple signals (just 1 bit flags) act differently but with the same programming file (.sof)! I just reprogram the FPGA and obtain 2 different results! How much can be reliable all the other (more complex) signals? I am using a terasic blaster cable (clone of USB blaster)  thanks since now   C.

[Altera_Forum]

You can trust SignalTap to a high degree, but it seems to me, that you didn't yet consider the effect of sampling SignalTap input data with the resepctive sampling clock. All described effects are obvious results of this sampling, to my opinion. 

 To see actual clock waveforms, you have to use multiple oversampling. Your said oscilloscope is sampling the data with 2 to 5 GHz, I guess. A similar time resolution can be never achieved with SignalTap.  There be cases, where SignalTap isn't reliable, when you ignore setup and hold time requirements. But you will get respective warnings in Timing Analysis.

[Altera_Forum]

hi FvM, 

you are right at all when you say "..it seems to me, that you didn't yet consider the effect of sampling SignalTap input data with the resepctive sampling clock..." In fact I didn't describe this setup in my STII file: I am using a 160 Mhz clock to sample my data lines. Do you think it is not enough? Anyway as soon as possible I will try to recompile my project with a higher freq. sampling clock.  thanks for your answer  C

[Altera_Forum]

160 MHz sampling clock may be too low, when you are acquiring an 80 MHz signal that hasn't exactly 50 % duty cycle, or if setup and hold times of the receiving register are slightly level dependant. I have used up to 360 MHz sampling clock at a Cyclone II, Stratix II should be able to go even higher.

[Altera_Forum]

Hi again FvM, 

as wrote in my previuos post I made the samplig clock faster (240 Mhz) but I have the same problems. One of these problems is that the "weird-shown" signals, for example the clocks, are shown with a duty cycle different that 50% when they were supposed to be 50% (at least, from the megafunction setup)  If I had a constant error (like the clock duty cycle for example) I was almost sure that everything is caused by an error in my code, but what is leaving me with lot of doubts is that with the same .sof and .stp file (same compilation, no changes at all) programming in 2 different moments my FPGA (or running the STII in differnent moments) I get different results...  anyway, thanks again for your help!  C

[Altera_Forum]

The said behaviour can indicate, that the PLL looses lock after device configuration respectively an asynchronous reset. In this case, the configured phase relation of PLL output clocks isn't valid any more. If so, the problem doesn't only affect SignalTap. 

 Another possible reason would be, that setup- and hold times for the SignalTap acquisition are violated. SignalTap may sample arbitrary levels then, possibly changing with small temperature or supply voltage modfications.  Generally, I don't think that SignalTap is able to measure clock duty cycles with the intended accuracy. I also don't see a reason to doubt the configured duty cycles, that are defined by very basic parameter settings, that can be always checked in the fitter report.

[Altera_Forum]

Your duty cycle will be a function of your sampling period, so witha 4ns sampling clock, you're edges will look like that jump around by 4ns(they aren't in hardware, it's just that your sampling makes it look like this.) 

If your PLL only has two outputs, 40MHz and 80MHz, is your sampling clock asynchronous to these domains? If so, your data capture is going to be corrupt. In generaly, I would sample the data with the 80MHz clock, and know that every tick is one period. There's no real reason to sample the clocks since, as I said, each tick is a clock edge and static timing analysis makes sure all your data meets setup and hold requirements. If you really were concerned there was something wrong with your clocks, my suggestion would be to route them out and sample them with a scope, which you've already done and verified that they look good. Maybe there's some information that you're trying to get that I don't understand.

[Altera_Forum]

Hi Rysc, 

my PLL has 3 outputs: 40, 80 and 200Mhz (this latter is my sampling clock, raised after reading the first posts of this thread). I am sampling the clocks just as an "extra" information, the signals of interest are (of course) others but they have the same weird behaviour: the clocks were just an example. Another example is that I have to check the LSB of a 16 bit word (it has to flip continuosly): also there, same compilation but different "programming runs" with STII leads me to 2 different results. Thanks for your answers,  C

[Altera_Forum]

I generally agree with Rysc's statement to use the fastest system clock as SignalTap II sampling clock. That's also what I do normally. When I used a higher sampling clock, I wanted to check the timing of an external data bus, that's processed synchronously in the design. 

 If you have a counter continuously incremented by your 80 MHz clock, it should perfectly show up when sampled with the same clock, unless you have serious timing violations in your design.

[Altera_Forum]

Very strange indeed. Are you using TimeQuest? The path where you sample the clock should be treated by the "clock as data" analysis that TimeQuest can do. If you're not sure or not analyzing this path, it's not overly surprising that your clock-as-data could have timing violations. It's not like your other paths where the clock delays to source and destination registers cancel out and you have a 0ns hold requirement and you just need short data delays to meet setup requirements. If you've already shown with a scope that your 40 and 80MHz clocks are clean, sampling the clock and inspecting it is probably more trouble than it's worth. (And of course, an 80MHz clock period doesn't evenly go into a 200MHz sampling clock. With periods of 12.5ns and 5.0ns, every othe sample will be in the middle of a data change, so all data in that domain should be ignored if you're sampling with that clock).