Forum Discussion

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

Timing constraints dont appear to work on Strobed outputs

Hello,

I have the following SDC constraints defined, which are just a test

to constrain three signals from my FPGA feeding a TI DSP :

Output signals from FPGA to DSP: had[1], had[0], hrnw

# create setup hold board delays from TI DSP datasheet:

# DSP Setup & Hold timing HAS Strobe low before HCNTL[1:0] and hrnw

set HAS_Setup 5

set HAS_Hold 3# set max and min est DSP to FPGA delays

set Max_fpga2dsp 2

set Min_fpga2dsp 1

set HASOutputDelayMax [expr $HAS_Setup + $Max_fpga2dsp]

set HASOutputDelayMin [expr $HAS_Hold + $Min_fpga2dsp]

# Setup clocks

# Set period for EHPI base clock

set ehpi_base_period 25.201# create constraint for input clock pin to PLL

create_clock -name inclk0 -period $ehpi_base_period [get_ports inclk0]

derive_pll_clocks

set_clock_groups -asynchronous

-group {inclk0

EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0]

}# Create Generated Clock for STROBE write output HAS# create_generated_clock -name HAS_STROBE -source EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0] [get_ports has_n]

create_generated_clock -name HAS_STROBE -source [get_pins {EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0]}] [get_registers {bidir_interface:uut|has_n}]

derive_clock_uncertainty

# Setup output constraints on three output signals: had[1], had[0], hrnw

# *************************************************************************************************************# Constrain EHPI to DSP CTRL strobed output paths# *************************************************************************************************************# Output MAX delay on HAS bus : using EHPI Virtual Address strobe

set_output_delay -clock HAS_STROBE -max $HASOutputDelayMax [get_ports {had[0] had[1] hrnw}]# Output MIN delay on HAD bus : using EHPI Virtual Address strobe

set_output_delay -clock HAS_STROBE -min $HASOutputDelayMin [get_ports {had[0] had[1] hrnw}]

I compiled the design...run TimeQuest....and get the following report after generation of all reports :

report_timing -setup -npaths 100 -detail full_path -to_clock HAS_STROBE -panel_name "HAS_STROBE||setup"

Info: Report Timing: No setup paths were found

Info: -to_clock [get_clocks {HAD_STROBE}]

Info: -setup

Info: -npaths 100

Info: -detail full_path

Info: -panel_name {setup}

0 0.000

I was expecting to see three setup paths here ....anybody know what is wrong ?

Also, how would i tell TimeQuest that the Strobe clock usues a negative edge ?

Many thanks for your help ! :)

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    As far as I know, Timequest checks the tSU/tH on any path between two internal fpga registers.

    Though an external device input registers or external device output registers are part of the same RTL chain from designer perspective but timequest does not report on these external paths as violations but rather as tSU/tH on fpga input registers or tCO on its output registers and it is left up to you to check if it is ok.

    Thus many designs may seem passed timing falsley if you enter wrong external requirement figures. This is very common...

    The same applies to recovery/removal and unless reset is generated internaly then timequest has no idea about when it changes. Though I think there is a way to inform it using max/min input delay on reset pin.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi Kaz,

    Yes thanks for the response....and i get your drift ! You have to be careful to extracty the rigt timing values form the datasheet , and know how to apply them correctly in SDC format. Its very easy to misinterpret this data and get it wrong, so the FPGA passes tming analysis but because the constraints dont match reality, it still fails in the ral world.

    cheers :)