Forum Discussion

cblixt1's avatar
cblixt1
Icon for Occasional Contributor rankOccasional Contributor
1 month ago

Timing models don't match measured delays

I am working with an Agilex 7 I-series device in Quartus Prime Pro 25.3.  The device is fully supported by that QPP version and has final timing models.

Since I am working with precise timing, I need to find out the propagation delay from internal clock to output on a pin with as good precision as possible. I am trying to use the Timing Analyzer (TA) to do this. The results do not match my expectations though.

The TA reports paths for five operating conditions for this device: fast/vid1/100C, fast/vid1a/100C, fast/vid1a/0C, slow/vid1b/100C and slow/vid1/100C. My expectation is that one of them corresponds to the shortest propagation delay (used for hold analysis) and one the longest (used for setup analysis) and that my measured delay should therefore fall somewhere between these extremes. It does not.

To test this, I have added two registers to my design, both clocked by the same clock, both toggling at every clock edge. I have instructed Quartus to preserve these and don't merge them. These two registers drive two outputs that I can measure on the board. Then I control the placement of the two registers to get different propagation delay to their pins.

I start out by calibrating the setup. Placing the two registers in the same LAB close to the relevant I/O bank results in very nearly the same path delay to both pins according to the TA. As expected, I also measure a very small difference between the edges (around 100 ps). This shows that there is no significant difference between the board traces or measurement cables.

Then I move one of the registers a bit, 271 LABs in the X direction to be exact. According to the TA, this design should have the following propagation delay differences between the pins for the five operating conditions:

Fast vid1 100C3.134 ns
Fast vid1a 100C3.138 ns
Fast vid1a 0C2.795 ns
Slow vid1b 100C3.028 ns
Slow vid1 100C3.011 ns

However, I measure just 2.32 ns. This is lower than even the 0C model, which must be the fastest timing that is used to guarantee hold timing. How can this be?

Timing

3 Replies

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor
    1 month ago

    How are you gathering the numbers in the table from the TA?  Are you using data arrival times from whatever is driving these registers and from these registers to the output pins?

    I guess it's not clear what design you are using and what is actually driving these registers.  Also not clear is your clocking setup.  Are you using a PLL that's driving a global clock resource or are you driving the registers directly?

    I think more detail on your setup and how you are getting these numbers is needed.

    • cblixt1's avatar
      cblixt1
      Icon for Occasional Contributor rankOccasional Contributor
      1 month ago

      So, with this design, I can control the placement of the two registers sta_test1 and sta_test2 to get different internal propagation delays from clock to pin. At first I actually ensured once and for all that the clock skew was small, and only considered the clock to output paths. I have now checked the clock skew for all models and cases and it is never more than a few ps. I calibrate the setup by placing both registers in the same ALM, which results in almost equal propagation delay to both outputs, within 100 ps for all OCs.

      Then I place the two registers in different ALMs. I let sta_test1 stay in X79,Y328 and move sta_test2 to X350,Y328. I run path analysis in the TA with the following command:

      report_path -rise_to [get_ports {master_tod_top_0_pulse_per_second master_tod_top_0_pulse_per_second_raw}] -npaths 10 -panel_name {Report Path} -split_by_corner

      The -rise_to is because I'm only interested in and measuring the rising edges. Then I take the reported propagation delay for the two pins and subtract one from the other, for each OC.

      Now I should mention that I have recently revised my measurement methodology, the oscilloscope I was using turned out to do bad averaging of channel to channel delay. Visually averaging it on the display resulted in a higher number. Switching to using a time and frequency counter and adjusting the trig levels also had an effect in the same direction. Finally, the slight clock skew also worked in the same direction. So with that taken into account, the STA reports this: 

      Fast vid1 100C3.126 ns
      Fast vid1a 100C3.133 ns
      Fast vid1a 0C2.788 ns
      Slow vid1b 100C3.018 ns
      Slow vid1 100C2.998 ns

      I now measure 2.784 ns. This means that I reach the fastest model, so I'm within the envelope. I still think it is a bit strange that my measurement corresponds to the 0C model when I know for a fact that the die temperature is around 70C, but the differences are small. A 100 ps offset in calibration would explain it fully.

      I think we can leave it at that.

  • cblixt1's avatar
    cblixt1
    Icon for Occasional Contributor rankOccasional Contributor
    1 month ago

    For all practical purposes, this is my design:

    module ghrd_agilex_top (
  input   wire  fpga_clk_100,
  output  wire  master_tod_top_0_pulse_per_second,
  output  wire  master_tod_top_0_pulse_per_second_raw
);

  (* dont_merge *) reg sta_test1;
  (* dont_merge *) reg sta_test2;
  always @(posedge fpga_clk_100 or negedge system_reset_n) begin
    if (~system_reset_n) begin
      sta_test1 <= 1'b0;
      sta_test2 <= 1'b0;
    end
    else begin
      sta_test1 <= ~sta_test1;
      sta_test2 <= ~sta_test2;
    end
  end
  assign master_tod_top_0_pulse_per_second     = sta_test1;
  assign master_tod_top_0_pulse_per_second_raw = sta_test2;
endmodule

    Of course the design actually contains a lot more, but it does not affect the issue at hand, which is that the STA for this part does not seem to match the measured results.