Forum Discussion

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

Timequest and external intefaces

I am running a Timequest timing analysis on our design and it is failing both setup and hold requirements for external interfaces to a video decoder and video encoder. In both cases the clock is coming into the FPGA from the external device. In one case the data is fpga->device, in the other the data is device->fpga.

I am new to Timequest and I have tried to follow the Altera Source Synchronous Interface online training to create the constraints and then fix the timing problem. However, the fix suggested is to adjust the phase shift of the clocks using a PLL but neither external clock goes into a PLL, they just drive the logic directly.

Is this a poor design? Should I have all external clocks going into separate PLLs in the fpga?

If not, then is there another way to handle timing constraints when the clock is an fpga input rather than an fpga output?

The constraints that I have are:

set_input_delay -clock tvp_dataclk -max 35.1 [get_ports {tvp_yout*}] -add_delay

set_input_delay -clock tvp_dataclk -min 34.7 [get_ports {tvp_yout*}] -add_delay

set_output_delay -clock adv_clk -max 18.3 [get_ports {adv7171_d*}] -add_delay

set_output_delay -clock adv_clk -min -18.3 [get_ports {adv7171_d*}] -add_delay

n.b. tvp_dataclk is 14.31818MHz, adv_clk is 27MHz

7 Replies

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

    Is it Double-Data Rate or Single Data Rate? In general you want to "phase-shift" the clock so that it transitions in the middle of the data eye. Note that only one side needs to do this. For example, if you receive the clock phase-shifted, then you don't have to do it. Or on the flip-side, if the device you're sending data to wants them edge-aligned, then it means they're doing the phase-shift. So you want to phase-shift if the other device isn't doing it.

    The reason for doing this is that, besides the shift, you try to match your clock and data delays as closesly as possible. That way they vary together over PVT. If you shift doesn't occur, then regular delays need to be added to get the clock centered on the data, which will vary. For example, with a 10ns data eye, you would need to add 5ns of delay to the clock. To center it, you would probably add something like 7ns in the slow corner, which might be 3ns in the fast corner(making the numebrs up). But as you can see, delays vary over PVT, which cuts into your margins. A PLL phase-shift does not vary over PVT, so if you add 5ns, it will be that way in both timing models.

    Now, if your design is single-data rate, then you don't need a PLL, just invert the clock going off chip, or invert the clock driving the data register. Assuming 50/50 duty cycle, this is the same thing as a 180 degree phase-shift. (For DDR interfaces, you want a 90 degree phase shift to center the clock, and this can only be done with a PLL).

    Once you do the phase-shift, re-time your design. In fact, set you -max and -min values to 0 as a placeholder, and retime them. What you should see is that your setup requirement is half the data window and your hold requirement is the other half(it will be negative). Then as you increase your -max value from 0, and decrease your -min value, it will cut into this default requirement. Play with it a little to see how it affects setup and hold.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Thanks for your reply Rysc. Both devices are definitely single data rate. As you recommended I ran TimeQuest again with zero max and min input/output delays:

    set_input_delay -clock tvp_dataclk -max 0 [get_ports {tvp_yout*}] -add_delay

    set_input_delay -clock tvp_dataclk -min 0 [get_ports {tvp_yout*}] -add_delay

    set_output_delay -clock adv_clk -max 0 [get_ports {adv7171_d*}] -add_delay

    set_output_delay -clock adv_clk -min 0 [get_ports {adv7171_d*}] -add_delay

    This made absolutely no difference to the slack values in the setup and hold summary reports, for both sets of constraints the results were:

    Summary (Setup)

    adv_clk slack=-10.730 End Point TNS=-2884.669

    tvp_dataclk slack=-6.053 End Point TNS=-144.271

    Summary (Hold)

    adv_clk slack=-1.859 End Point TNS=-139.715

    tvp_dataclk slack=-1.859 End Point TNS=-135.955

    I don't understand this result. Surely the slack values are determined by the actual timing and the constraints applied. If I don't change the design, but I do change the constraints, I would expect the setup and hold slacks to change. Is that thinking flawed?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Your spot on in your thinking. I do that all the time. (Note that you only showed the Summary reports, whereby if your worst case path isn't on one of these I/O, then the summary slacks would be the same). If you do a report_timing on the paths, you should see line items that are labeled as iExt or oExt(i.e. the external delays you entered) and you should see they are part of the slack calculation. So if your changing the numbers, either this number isn't changing, or something else is changing in tandem(which doesn't really make sense). Anyway, do the original report_timing on the paths in question and write it out to a .txt file or do a screen shot. Then modify the .sdc to this newer version, reset the design and re-run the report_timing, and then compare the two. That should point to what's going wrong.

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

    Thanks agains Rysc. It seems the more I do with Timequest the less I understand :)

    I did a report_timing on the path from tvp_dataclk to tvp_yout* with:

    report_path -from [get_keepers {tvp_dataclk}] -to [get_keepers {tvp_yout[0] tvp_yout[1] tvp_yout[2] tvp_yout[3] tvp_yout[4] tvp_yout[5] tvp_yout[6] tvp_yout[7] tvp_yout[8] tvp_yout[9]}] -npaths 10 -panel_name "Report Path"

    The result was:

    Info: Report Path: No paths were found

    I can't understand this. tvp_dataclk is the clock coming into the fpga from the external device and tvp_yout* is the data bus again coming into the fpga from the device. I have verilog with statements such as:

    always @(posedge tvp_dataclk)

    result <= tvp_yout[6];

    Surely this will create a path from tvp_dataclk to tvp_yout[6] that can be constrained?

    Perhaps someone can explain the foolish mistake I must be making!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Not sure. I never use report_path(since it isn't a constraint, just a probing tool of how long is this path). (although your first sentence says report_timing, which I would not expect to work, since it's not on the datapath) If you run:

    report_timing -setup -from [get_ports tvp_yout*] -panel_name "s: tvp_yout Inputs"

    what happens? That's the type of report I would run. (And if tvp_yout were an output bus, I would change the -from to -to)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Thanks again for your reply. I used the command that you recommended and the report showed that there was no problem with those paths. I think I have been misunderstanding the summary setup and hold report errors.

    I've attached my sdc file and a text file with a report from a failed path in the setup summary, generated using:

    report_timing -to_clock {this_organon_sopc|the_pll|the_pll|altpll_component|auto_generated|pll1|clk[0]} -setup -npaths 10 -detail full_path -panel_name {Setup: this_organon_sopc|the_pll|the_pll|altpll_component|auto_generated|pll1|clk[0]} -file "setup_summary_clk0"

    It would be great if someone could explain the steps to take having got this setup summary error. Should I be looking to reduce the fpga clock frequency or have I specified a constraint incorrectly? I hope that once I understand timequest enough to remove one of these errors I will be able to remove them all!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    I like doing -detail full_path when doing report_timing on I/O paths, just because the clock path is so important(in internal paths the clock tree pretty much cancels out between source and destination paths). Not a big deal though.

    Anyway, your clock launches at time 0ns and latches at time 7.812ns, which is pretty much your clock constraint and looks correct. In essence, if the external delay were 0ns, you would be asking for a 7..812ns Tco. But, your external delay is 8.5ns. So you need to get your data across in 7.812ns, but the external delay is 8.5ns, so it's pretty much an impossible constraint. You can see this -8.5 subtracted directly as oExt. Now, I don't know what you want it to be, but that's impossible to meet.

    Secondly, the -clock in your set_output_delay is the PLL clock. This is incorrect. TimeQuest knows what clock drives the output register. You need to specify the clock externally. I recommend doing a virtual clock like so:

    create_clock -period 7.812 -name flash_clk_ext

    Then do:

    set_output_delay -clock flash_clk_ext 1.0 [get_ports flash_data*]

    I made up the 1.0, but if your default requirement is 7.812ns, then subtract the external delay from that for whatever you need the FPGA to do.

    (If you need something slower than 7.812, i.e. multicycles, then do something like:

    set_multicycle_path -setup -to [get_ports flash_data*] 2

    set_multicycle_path -hold -to [get_ports flash_data*] 1

    That would make your default setup requirement 2*7.812 and your hold requirement would be 0ns.)

    Then in your analysis script do:

    report_timing -setup -npaths 30 -detail full_path -to [get_ports flash_data*] -panel_name "s: To flash_data*"

    report_timing -hold -npaths 30 -detail full_path -to [get_ports flash_data*] -panel_name "h: To flash_data*"