Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
13 years ago

Signal Tap II Sampling Clock problem

Hi,

I am trying to tap a few signals and my design clock i.e. 100MHz using Signal Tap II. To tap the clock, i have used a separate sampling clock, in-phase with my design clock but double the frequency of design clock i.e. 200MHz.

But in signal tap II waveform window, the signals that i updated on posedge(in my RTL) are updated on negedge of design clock and vice-versa...

Is it wrong selection of sampling clock or some skew in the design clock causing this???

any help is greatly appreciated!!

1 Reply

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Let's accept the sampling clock is (correctly) in phase with the system clock as intended. Here is a simplified example of how you can get your observed behaviour:

    A fast signal arrives at its destination register only 3 ns after the last rising edge of the 100 MHz clock. The destination register (clocked at 10 ns intervals) will only register the transition of the signal after another 7 ns, on the next rising clock edge.

    In the mean time the same signal also travelled to a second destination register, clocked at 200 MHz. Assuming the delays of the two paths are the same (to keep the example simpler), the fast destination register registers transition 2 ns after it arrived - on the 5 ns interval. This is on the first rising edge of the 200 MHz signal, which coincides with the falling edge of the 100 MHz signal. The fast register (clocked at 200 MHz) is part of the Signal Tap instance, of course.

    There may therefore be nothing wrong with the picture you see, only with the interpretation. The signal you think is changing on the falling edge actually changed on the previous rising edge of the 100 MHz clock. Signal Tap only "sees" this change after registering it on the next rising edge of the 200 MHz clock, which coincides with the falling edge of the 100 MHz clock.

    Signals viewed in Signal Tap are actually always delayed by between zero and one clock cycle of the Signal Tap clock. We can only see the signals after they have been registered by the Signal Tap registers.

    The problem gets more complex when timing closure is not achieved. I often have a design which achieves timing closure - until I add the Signal Tap instance. Paricularly when one has a tight timing specification on input pins this can easily happen. If the Signal Tap clock as asynchronous with the signals this will also happen. If timing closure is not achieved around the Signal Tap instance, you can of course not believe the detail timing relationships you see in Signal Tap. There may still be useful information in the picture, though.