timing constraints for EHPI DSP to FPGA asynchronous interface

[Altera_Forum]

Hi, I am trying to write timing constraints for connecting a TI DSP, TMS320VC5510A, to a Cyclone IV FPGA. The bus used is EHPI in Multiplexed mode. It looks confusing because the interface is asynchronous, based on HDS / ADS {data and address strobes} which time the latching of data / addresses / control information to/from the DSP/FPGA. I am not sure yet how best to implement the SDC constraints. Does anybody have experience doing this ? 

 I have been using Rsycs excellent User Guide for TimeQuest, but it hasnt yet become clear how to optimally constrain such an asynchronous interface !   Many thanks, DrPositiveLogic

[Altera_Forum]

I haven't looked at the actual device or constraints, but generally with "asynchronous logic", the strobe should be treated as a clock. Note that if it were truly asynchronous, you wouldn't time it. Just because the clock isn't always periodic, you have a max and min relationship between the data and that strobe.  

More often than not, even with the clocks set up, you have setup and hold relationships that are too restrictive, since they assume data is sent on ever edge. So you most likely need to add multicycles to the interface to get the setup relationship and hold relationship correct. (Note that you need to know what it should be before adding multicycles. Then add the MCs to match the requirement). The final thing is adding the -max and -min external delays, which are usually a small component. I "think" this will help, but not having tread the datasheet, may be way off base.

[Altera_Forum]

Hello there and thanks for the reply. I think your analys is spot on. There are two strobes: HAS and HDS. The falling edge of HAS is intended to latch in the HAD (16 bit Multiplexed data bus) on its falling edge. The HDS strobe is intended to latch in the HAD bus (data this time) on its rising edge. There are setup and hold timings given in the TI datasheet for everything, HAS to HDS setup/hold, HAS to HAD setup/hold, HDS to HAD setup/hold etc. 

 My problem is that i dont know really how to implement these constraints in TimeQuest SDC format. I believe i would need to apply :   set_input_delay and set_output_delay (i have been reading your excellent UserGuide here to help: pages 14-29 so far are an aid !)....but should i create a Virtual clock for the HAS and HDS strobe outputs (output from the FPGA) and time all I/O with respcet to them ?   The set_multicycle_path constaint will be needed i think, because the FPGA runs at about 80MHz, and the maximum TCO from the DSP is around 16 ns...ie > 1 clock.   The actual interface inside the FPGA is driven by an FSM, which inherently adds delays (ie one clock wide minimum) to each of the drievn and read signal paths...ie it delays the HDS by a clock after the HAS signal is driven low....and sets up the HAD bus for a write a clock earlye etc. In a way its self timed and self constrained i suppose. BUT this doest help Quartus and TimeQuest, which is why i still need to apply some sensible SDC timing constraints i think.   Many thanks for your help, DR Positive Logic !

[Altera_Forum]

Hi Rysc...what might prove rally helpfull to me would be an example in SDC syntax of constraining a simple sort of async interface ....such as what constraints to apply to the HAD I/O bus (which is Tristatable), how to create the clocks (HAS and HDS) based on the strobes....i assume i would create a couple of Virtual clocks here.....and what sort of MC constrainst i need ? 

 many thanks, Dr+VLogic !

[Altera_Forum]

I probably won't be able to do that, but... 

1) The first thing you need to get is your clocks correct. If the FPGA is sending a clock, then you don't want a virtual clock. You put a generated clock on the output port, where the -source is the output of the PLL. If a register drives the strobe off chip, then you need a generated clock on the register(and the -source of that is the PLL output), and then another generated clock on the output port, where the -source is the register. This tells how the clock gets off chip, and the entire path will be used in timing analysis. 2) For your set_output_delays, the -clock option will use the generated clock you created on the output port.  3) You will have a default setup and hold relationship. For example, let's say both clocks are 80MHz, so you have a 12.5ns setup relationship and 0ns hold relationship. Taking the setup side first, your logic will not send data and strobe it on every cycle. Let's say you send data out on a cycle and the strobe out 3 cycles later. You would need: set_multicycle_path -setup 3 -from [get_clocks {PLL|clk[0]}] -to [get_clocks {strobe_clk}] In this case the -from clock is the PLL driving the 80MHz clock that creates your logic and the strobe_clk would be the name of the generated clock you put on the output port. This would make the setup relationship 37.5ns(I have no idea if this is what you want, it depends on the logic). Finally you would change the -max value on the set_output_delay to account for the Tsu of the other device, as well as board skew. 4) Now do the same for the hold. Since you modified the setup relationship, the default hold is now 25ns. Let's say your system works that the data doesn't change until 1 cycle after the previous strobe. If you add:  set_multicycle_path -hold 3 -from [get_clocks {PLL|clk[0]}] -to [get_clocks {strobe_clk}] I did 3, because it takes 2 cycles to get it back to a 0ns, and a third one to get a -12.5ns hold relationship(the user guide section on multicycles covers all this) 5) Again, change the -min value to account for board delays and Th of the other device.  On the input side, does the clock being sent by the FPGA out the strobe port generate the data coming back, or does something else? If the FPGA's strobe output generates the returning data, then you would use that strobe clock on your set_input_delay constraints, and the -max and -min values would be represent the longest and shortest round-trip delays from the strobe going out to data coming back. If the input data is coming from another source(say the DSP is driven by an oscillator), then you would use a virtual clock.

[Altera_Forum]

Hi Rysc, thanks for your second response, which i have been trying to implement...here s my SDC file so far, copied below. The HAS_STROBE and HAD_STROBE are both defined as clocks, HAS is the address strobe and clocks out HAD pins 0 and 1, a 2 bit address reg select to the DSP. HAD strobe clocks out the 16 bit data bus. 

 When i compile my design and then run 'report all I/O timings' i get the follwoing messagese for TimeQutes:   Info: Report Timing: No setup paths were found Info: Report Timing: No hold paths were found Info: Report Timing: No recovery paths were found Info: Report Timing: No removal paths were found Info: Report Timing: No setup paths were found Info: Report Timing: No hold paths were found Info: Report Timing: No setup paths were found Info: Report Timing: No hold paths were found   ...i wonder what i am doing wrong ! It seems just about everything so far !   thanks for your help:oops:  # Define TMS320TLV5510 Timing Parameters set DSP_Tsu 4 set DSP_Th 4 set DSP_TcoMax 16 set DSP_TcoMin 6# set max and min est DSP to FPGA delays set Max_fpga2dsp 2 set Min_fpga2dsp 1# set max / min OUTPUT delays set OutputDelayMax [expr $DSP_Tsu + $Max_fpga2dsp] set OutputDelayMin [expr $DSP_TcoMin + $Min_fpga2dsp]# set max / min INPUT delays set InputDelayMax [expr $DSP_TcoMax + $Max_fpga2dsp] set InputDelayMin [expr -1*$DSP_Th + $Min_fpga2dsp]# Set period for EHPI base clock set ehpi_base_period 12.82# create constraint for input clock pin to PLL create_clock -name inclk0 -period $ehpi_base_period [get_ports inclk0] derive_pll_clocks derive_clock_uncertainty 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]# Create Generated Clock for STROBE write output HAD create_generated_clock -name HAD_STROBE -source EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0] set_multicycle_path -setup 0 -to [get_clocks HAS_STROBE] set_multicycle_path -setup 0 -to [get_clocks HAD_STROBE]# *************************************************************************************************************# Set Multicycles on EHPI to DSP data output bus : 2 clocks# ************************************************************************************************************* set_multicycle_path -from [get_ports {had [*]}] -to [get_registers {bidir_interface:uut|hdata [*]}] -setup -end 2 set_multicycle_path -from [get_ports {had [*]}] -to [get_registers {bidir_interface:uut|hdata [*]}] -hold -end 1# *************************************************************************************************************# Set Multicycles on DSP to EHPI data input bus : 2 clocks# ************************************************************************************************************* set_multicycle_path -from [get_registers {bidir_interface:uut|hdout [*]}] -to [get_ports {had [*]}] -setup -start 2 set_multicycle_path -from [get_registers {bidir_interface:uut|hdout [*]}] -to [get_ports {had [*]}] -hold -start 1 # *************************************************************************************************************# Constrain DSP to EHPI Input ports# *************************************************************************************************************# input MAX delay on HAD bus : using EHPI Virtual Data Strobe  set_input_delay -clock { HAD_STROBE } -max $InputDelayMax [get_ports {had [*]}]# input MIN delay on HAD bus : using EHPI Virtual Data Strobe  set_input_delay -clock { HAD_STROBE } -min $InputDelayMin [get_ports {had [*]}]# input MAX delay on HAS bus : using EHPI Virtual Address strobe set_input_delay -clock { HAS_STROBE } -max $InputDelayMax [get_ports {had[0] had[1]}]# input MIN delay on HAD bus : using EHPI Virtual Address strobe set_input_delay -clock { HAS_STROBE } -min $InputDelayMin [get_ports {had[0] had[1]}]# input MAX delay on RDY, D2H ACK and D2H REQ lines : using EHPI Data Strobe  set_input_delay -clock { HAD_STROBE } -max $InputDelayMax [get_ports {h2dack_n[0] h2dack_n[1] d2hreq[0] d2hreq[1] hrdy[0] hrdy[1]}]# input MAX delay on RDY, D2H ACK and D2H REQ lines : using EHPI Data Strobe  set_input_delay -clock { HAD_STROBE } -min $InputDelayMin [get_ports {h2dack_n[0] h2dack_n[1] d2hreq[0] d2hreq[1] hrdy[0] hrdy[1]}]# *************************************************************************************************************# Constrain DSP to EHPI Output ports# *************************************************************************************************************# Output MAX delay on HAD bus : using EHPI Virtual clock  set_output_delay -clock { HAD_STROBE } -max $OutputDelayMax [get_ports {had [*]}]# Output MIN delay on HAD bus : using EHPI Virtual clock  set_output_delay -clock { HAD_STROBE } -min $OutputDelayMin [get_ports {had [*]}]# Output MAX delay on control signals hds,has,hcs : using EHPI Data Strobe  set_output_delay -clock { HAD_STROBE } -max $OutputDelayMax [get_ports {has_n hcs_n[0] hcs_n[1] hds_n hrnw d2hack_n[0] d2hack_n[1]}]# Output MIN delay on control signals hds,has,hcs : using EHPI Data Strobe  set_output_delay -clock { HAD_STROBE } -min $OutputDelayMin [get_ports {has_n hcs_n[0] hcs_n[1] hds_n hrnw d2hack_n[0] d2hack_n[1]}]# Output MAX delay on HAS bus : using EHPI Virtual Address strobe set_output_delay -clock { HAS_STROBE } -max $OutputDelayMax [get_ports {had[0] had[1]}]# Output MIN delay on HAD bus : using EHPI Virtual Address strobe set_output_delay -clock { HAS_STROBE } -min $OutputDelayMin [get_ports {had[0] had[1]}]

[Altera_Forum]

Are your generated clocks working? I see a space in the -source clock name, which would break it, and I don't see it applied to anything. I would expect something like: 

 create_generated_clock -name HAS_STROBE -source EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0] [get_ports HAS_STROBE] (I don't know the name of the port, but guessing HAS_STROBE) If the generated clock isn't correct, then it all falls apart and I would expect it to not have any timing, since you use those clocks for the rest of the design. Does the PLL drive the strobes directly, or does it drive a register that drives the strobe? If the latter, you need to put a generated clock on the register from the PLL, and then one on the output port where the source is the register. When you run report_timing -setup -npaths 100 -detail full_path -to_clock HAS_STROBE -panel_name "HAS_STROBE||setup" report_timing -hold -npaths 100 -detail full_path -to_clock HAS_STROBE -panel_name "HAS_STROBE||hold" Make sure the data required path shows the entire clock path from inclk0, through the PLL, through the register(if there is one) and out the port. If it doesn't, that needs to be fixed before worrying about multicycles and what values for -min/-max.

[Altera_Forum]

Hi Rysc, Thanks again for your brilliant help :) 

 I see what you mean about my generated clock error ( although i didnt quite get what you meant about a space in the name ?)...i see i have missed off the get_registers / get_ports commands).   In the design the REG hds_ni is driven from the PLL clock output :   EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0]   The output pin is : hds_n, which is fed by the REG output. hds_ni ...so now i have created the following constaints :  # Create Generated Clock for STROBE from PLL driving REG create_generated_clock -name HAD_STROBE_REG -source EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0] [get_registers hds_ni]# Create Generated Clock for STROBE to output pin create_generated_clock -name HAD_STROBE -source HAD_STROBE_REG [get_ports hds_n]   Does this look remotley correct ?   When i run your report commands though i still get zero setup and hold paths for these paths.   many thanks

[Altera_Forum]

Looks correct. Look at the messages when reading in the .sdc and updating the netlist. I'm guessing there's a warning or two.

[Altera_Forum]

Hi Rysc....i'm getting there (I think !)....but i see this warning during project compilation fro Quartus: 

 Warning: Ignored filter at AlteraIOTiming_Strobed_TestProject.sdc(35): hds_ni could not be matched with a register   # Create Generated Clock for STROBE from PLL driving REG create_generated_clock -name HAD_STROBE_REG -source EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0] [get_registers hds_ni]   Even though hds_ni is a register in my design driving output pin : hds_n   Not sure what is happening here !   cheers

[Altera_Forum]

Is it a top-level register? I would normally assume there is a hierarchy path to it. (Note that I recommend get_keepers over get_registers. Either should work, but get_registers isn't a true .sdc command and was added by Altera, where get_keepers is more standardized). In TimeQuest go to View -> Name Finder and use that try and whittle down why it isn't matching. Or go to the Technology Map viewer and look for it there. There's a chance it got synthesized out or something, but most likely it's just a name matching issue. Another thought is to run: 

report_path -to [get_ports hds_n] -panel_name test and see what is driving it.

[Altera_Forum]

Hi Rysc, 

It was buried.....when i did a node search and changed the constraint to this:  # Create Generated Clock for STROBE from PLL driving REG create_generated_clock -name HAD_STROBE_REG -source EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0] [get_registers {bidir_interface:uut|hds_ni}]   ....it now works....and i beleive i now have some working (at least syntactically !) constaints. If i run the report IO timing i get lots of failling paths ...well at least thats better than none before ...so progress ..:)   Many many thanks for your help !

[Altera_Forum]

Your well on your way. I spend a lot of time looking at the report_timing results. Note that report_timing -setup generally has only two numbers that come from your .sdc, the setup relationship and the external delay(oExt or iExt). The external delays are pulled directly from your -max/-min values. The setup relationship comes from your clock descriptions and multicycles. For now, ignore whether it meets timing or not, and just look at those two values and see if they're what you want. Same goes for hold. If your constraints are correct, THEN look at why it's failing. (And remember that you may have to re-compile once they're correct, as the place-and-route you're looking at is based on incorrect constraints). Good luck.

[Altera_Forum]

Hi Rysc, 

I have a few other questions about constraing the EHP interface, which reference how to apply sensible constaints in TimeQuest.   The thing that throws me is this: An FSM drives the following signals out to the DSP via a top level module ...the top level module instantiates the actual EHPI driver VHDL module, so this is a 2 tier hierarchy :   1) hcs_ni : REG : directly drives output port : hcs_n 2) has_n : REG : directly drives output port : has_n 3) hds_ni : REG : directly drives output port : hds_n 4) hrnw : REG : directly drives output port : hrnw  5) had_oe : port is driven as follows: had_oe <= (ha_ena or ha_ena_d);  where ha_ena and ha_ena_d are both REGS  had_oe is the Tristate control for the Bidirectional data/addr/cotrol bus  to the DSP.   6) had_rddata : 16 bit input bus from top level, REGISTERED in EHPI module 7) had_wrdata : 16 bit outputbus to top level and DSP HAD bus   In the top level module which instantiates the EHPI driver module the  top level BIDIR I/O HAD bus is driven as so:     -- Read Data always reflects the INPUT BUS had_rddata <= had; -- write control for HAD bus had <= had_wrdata when had_oe_r = '0' else (others => 'Z');   8) I also have a few feedback and handshaking signals from the DSP  a) hrdy : DSP ready line  b) h2dack_n : DSP acknowledge of a transfer complete...  c) d2hreq : DSP request for service..   These sre all used by logic interal to the EHPI driver....basically  in parts of the FSM, but they are all REGISTERED before use.   Now my questions are:   1) For the actual interface signals:  a) hcs_n (EHPI DSP chip select, active low) is asserted by the FSM  a couple of clocks before any action takes place, ie before any read or  writes start.  b) has_n (address / control strobe, DSP latches HAD[1:0] on falling edge). This signal is asserted a clock after chip select and a clock before hds_n has been asserted.  c) hds_n (data strobe, DSP latches data from the FPGA HAD[15:0] bus on the rising edge  d) hrnw : Read not write : this signal is asserted two clocks before chip select by the FSM   So as you can see in a way this interface is self timed,,,,because of the FSM control states which assert and de-assert each of the interface signals in a well defined sequence, with whole clock delays between state changes.   The tristate control is another worrying part....because it has some OR logic after the pair of registers driving the actual Tristate contro port signal, had_oe. How is best to constrain this type if siganlling ...would i be best to add a REG like so:     ADD CLOCKED REGISTER : had_oe_reg <= ha_ena or ha_ena_d);   then async apply : had_oe <= had_oe_reg;       But i still need to apply sensible constraints to all the EHPI to/from DSP signals so that TimeQuest can optimize the design and generate sensible reports.   So Is my current approach sensible and best practice for this type of interface do you think ?   Many many thanks for your help :)

[Altera_Forum]

Ugh. You've got a tough one. Let's step back for a second and look at what's occuring. When hcs_n is asserted, it probably has a min/max range that it needs to get out of the FPGA without causing a failure. For example, if hcs_n's delay is a cycle longer than has_n, then even though it is asserted a cycle before, it would go active after has_n.  

For all of the signals above, you might be better off with a "range" rather than using standard synchronous trasfers. For example, you could constrain them all with set_max_delay 12.5 and set_min_delay 0, which is very much like a Tco range of 0ns to 12.5ns. (The User Guide talks about some of the issues with using set_max/min_delay for I/O constraints, but I think it works for you here). The nice thing is that you can tweak the values, i.e. you could make it set_max_delay 14.5 and set_min_delay 2, which shifts everything over by 2ns. Basically you're constraining everything to occur within one period, but you don't care where that period is, because your logic sends them all out on different edges and hence "sequences them". I think you still then want to use has_n and hds_n as clocks for the address/control/data. Since they're latching on the falling edge, you might need to add -invert to the generated clock on these output ports, so the setup relationship will be shifted a half-cycle.

[Altera_Forum]

Hi there Rysc,,,,,brilliant answer ! I have been thinking along similar lines....ie using set min and max delays on each output....but was put off 

a bit by your User guide....which goes into quite some detail about the problems that these constraints can cause. But now you have confirmed its probably ok to use them in this case, i will try them.   The clock inversion is a good tip....the has_n strobe is used to strobe in the HAD bus (used as address and control bus in conjunction with has_n). The hds_n strobe is +ve edge triggered and clock in the data from the same HAD bus.   Here is my current HAS_N strobe clock def:   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}]  How do i invert this ?   many thanks :)

[Altera_Forum]

Hi Rysc: 

Does this sdc file look reasobale to you ? I am now using set_max_delay and set_min_delay and the HAS_STROBE is falling edge triggered ...i have set the HASOutputDelayMax to the clock periof (12.6 ns) for setup and the HASOutputDelayMin to 0 for hold.   On the data path, HADOutputDelayMax is also set to 12.6ns and HADOutputDelayMin:) is set to 0 for hold.   cheers :)  # **********************************************************************************# Golden Constraints file for EHPI to DSP interface# **********************************************************************************# **********************************************************************************# Define all bas clock periods# **********************************************************************************# # Set period for EHPI base clock#  set ehpi_base_period 25.201# set virtual DSP clock used to sample EHPI generated ctrl, strobes and data set dsp_clk_period [expr $ehpi_base_period/2]# DEFINE Timing constraints from TI Datasheet set DSP_Th 4 set DSP_TcoMax 16# set max and min est DSP to FPGA delays set Max_fpga2dsp 2 set Min_fpga2dsp 1# set max output delay for signals sampled by DSP from has_n strobe set HASOutputDelayMax $dsp_clk_period# set min Output delay for signals sampled by DSP from has_n strobe set HASOutputDelayMin 0# set max output delay for signals sampled by DSP from hds_n strobe set HADOutputDelayMax $dsp_clk_period# set min Output delay for signals sampled by DSP from has_n strobe set HADOutputDelayMin 0# set max INPUT delays for DSP to FPGA transfers based on EHPI MASTER CLOCK set InputDelayMax [expr $dsp_clk_period/2] # [expr $DSP_TcoMax + $Max_fpga2dsp]# set max INPUT delays for DSP to FPGA transfers based on EHPI MASTER CLOCK set InputDelayMin 0# [expr -1*$DSP_Th + $Min_fpga2dsp]# create constraint for input clock pin to PLL create_clock -name inclk0 -period $ehpi_base_period [get_ports inclk0] derive_pll_clocks derive_clock_uncertainty# Create Generated Clock for STROBE write output HAS create_generated_clock -invert -name HAS_STROBE -source [get_pins {EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0]}] [get_registers {bidir_interface:uut|has_n}]# Create Generated Clock for STROBE to output pin create_generated_clock -name HAD_STROBE -source [get_registers {bidir_interface:uut|hds_ni}] [get_ports hds_n] set_clock_groups -asynchronous   -group {inclk0   EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0]   HAS_STROBE   HAD_STROBE   }  # *************************************************************************************************************# 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}] set_max_delay -to [get_ports {had[0] had[1] hrnw}] $HASOutputDelayMax # 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}] set_min_delay -to [get_ports {had[0] had[1] hrnw}] $HASOutputDelayMin# *************************************************************************************************************# Constrain DSP to EHPI Input ports# *************************************************************************************************************# input MAX delay on HAD bus : using EHPI Virtual Data Strobe # set_input_delay -clock HAD_STROBE -max $InputDelayMax [get_ports {had [*]}] set_max_delay -from [get_ports {had [*]}] $InputDelayMax# input MIN delay on HAD bus : using EHPI Virtual Data Strobe # set_input_delay -clock HAD_STROBE -min $InputDelayMin [get_ports {had [*]}] set_min_delay -from [get_ports {had [*]}] $InputDelayMin# *************************************************************************************************************# Constrain DSP to EHPI Output ports# *************************************************************************************************************# Output MAX delay on HAD bus : using EHPI Virtual clock # set_output_delay -clock HAD_STROBE -max $OutputDelayMax [get_ports {had [*]}] set_max_delay -to [get_ports {had[2] had[3] had[4] had[5] had[6] had[7] had[8] had[9] had[10] had[11] had[12] had[13] had[14] had[15]}] $HADOutputDelayMax# Output MIN delay on HAD bus : using EHPI Virtual clock # set_output_delay -clock HAD_STROBE -min $OutputDelayMin [get_ports {had [*]}] set_min_delay -to [get_ports {had[2] had[3] had[4] had[5] had[6] had[7] had[8] had[9] had[10] had[11] had[12] had[13] had[14] had[15]}] $HADOutputDelayMin

[Altera_Forum]

You can invert a generated clock with -invert. 

In reality, that's probably not correct, as it's not really inverted. You could also add -clock_fall to your set_output_delay and it would know it's latching on the falling edge. (The two solutions should give the same analysis in the end). Some other quick thoughts: - I was thinking of still using set_output_delay for the address/data outputs, since the strobes act a lot like a clock. In that case, you don't really have to constrain the strobes themselves, since the data will be constrained in relation to them. What you have now is more of a "I know the strobes will get out between a-b times, and so my data needs to get out between x-y times plus the clock cycle in my desgin..." Note that inverting the output clock doesn't matter if you don't use it(which you're not with set_max_delay), and that even if you did, set_max_delay would ignore that inversion since set_max_delay overrides the calculated setup relationship.

[Altera_Forum]

Hi Rysc, 

Thanks for your further insights ! Currently i have the design constrained and passing timing....using the following constraints. So at the momemt i am using the set_min_delay / set_max_delay on all output signals to the DSP from the FPGA. I have a multicycle constraint on all of the input signals from the DSP to the FPGA, using the set_input_delay -min / max style.   I am not 100% sure these constraints model my physical design however. The set_max_delay is saying : as long as you get out of the FPGA in less than a clock, then we are all happy. This is the external setup to the DSP. The min delay is set to 0 for the DSP hold constraint.   Is this right ? I think this may be unrealistic, and the max output delay should really be ; clock period - [DSP setup + board delays]....   Maybe it would be better then if i use your other suggestion to use set_output_delay:   - then for the HAS_STROBE apply this as a -clock_fall to the ADDRESS / Control signals {had[0], had[1], rdnw}    - for the HAD_STROBE {rising edge clocked) apply the set_output_delay to the had[15:0] data bus signals.   Question: now i have a pair of constraints applied to the had[0] had[1] signals....will TimeQuest analyze i assume both paths and report these two signals setup/hold paths for both strobes ?   Many thanks :)    # *************************************************************************************************************# Set Multicycles on DSP to EHPI data output bus : 2 clocks# ************************************************************************************************************* set_multicycle_path -from [get_ports {had [*]}] -to [get_registers {bidir_interface:uut|hdata [*]}] -setup -end 2 set_multicycle_path -from [get_ports {had [*]}] -to [get_registers {bidir_interface:uut|hdata [*]}] -hold -end 1  # *************************************************************************************************************# 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}] set_max_delay -to [get_ports {had[0] had[1] hrnw}] $HASOutputDelayMax # 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}] set_min_delay -to [get_ports {had[0] had[1] hrnw}] $HASOutputDelayMin  # *************************************************************************************************************# Constrain DSP to EHPI Input ports# *************************************************************************************************************# input MAX delay on HAD bus : using EHPI Virtual Data Strobe  set_input_delay -clock EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0]} -max $InputDelayMax [get_ports {had [*]}]# set_max_delay -from [get_ports {had [*]}] $InputDelayMax# input MIN delay on HAD bus : using EHPI Virtual Data Strobe  set_input_delay -clock EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0] -min $InputDelayMin [get_ports {had [*]}]# set_min_delay -from [get_ports {had [*]}] $InputDelayMin  # *************************************************************************************************************# Constrain DSP to EHPI Output ports# *************************************************************************************************************# Output MAX delay on HAD bus : using EHPI Virtual clock # set_output_delay -clock HAD_STROBE -max $OutputDelayMax [get_ports {had [*]}] set_max_delay -to [get_ports {had[2] had[3] had[4] had[5] had[6] had[7] had[8] had[9] had[10] had[11] had[12] had[13] had[14] had[15]}] $HADOutputDelayMax# Output MIN delay on HAD bus : using EHPI Virtual clock # set_output_delay -clock HAD_STROBE -min $OutputDelayMin [get_ports {had [*]}] set_min_delay -to [get_ports {had[2] had[3] had[4] had[5] had[6] had[7] had[8] had[9] had[10] had[11] had[12] had[13] had[14] had[15]}] $HADOutputDelayMin

[Altera_Forum]

Note that set_input/output_delay and set_max_delay/set_min_delay work together. For example, if you do a set_output_delay assignment to an I/O, there will be three numbers from your .sdc, the launch edge, the latch edge, and the oExt delay. The launch and latch come from the clock relationships, while oExt comes directly from the -max and -min values. If you then apply a set_max_delay, the launch edge will become 0, the latch edge will become the -max value, but the oExt from your set_output_delay will be used. So you could use the set_output_delay to say what the Tsu of the external device is, and then use set_max_delay like you are now. (You could also just tighten your set_max_delay constraint by the Tsu amount and get the same results).

[Altera_Forum]

:) Hello Rysc, 

thanks for your reply....one insight that comes up with your analysis is that ...in my case of a strobed external interface.....the launch / latch clock relationships are:   1) FPGA clock on the register which clocks in the data HAD_REG a clock before the strobe is generated   2) Latch clock for HAD data bus is hds_n (rising edge) ....   3) FPGA clock on the register which clocks in the data HCTRL_REG bits a clock before the strobe is generated   4) Latch clock for HAD data bus is has_n (falling edge) ....   There appears to be a multicycle constaint here...the HAD_REG and HCTRL_REG are both clocked in by the fSM a couple of clocks before either of the strobes is generated (again by the FSM).   On the READ side (FPGA reads from DSP) the lauch clock is a DSP internal clock, which generates a DSP_READY flag to the FPGA...the latch clock is the hds_n signal, driven by the FPGA FSM after it detects the DSP_READY flag has gone high.   So on the FPGA to DSP side i think these constraints should be OK:   a) using DSP_TSu and FPGA_to_DSP_Delay_Max (estimated board delays) :    set_output_delay -max [expr DSP_TSu + FPGA_to_DSP_Delay_Max]   This is the FPGA to DSP setup requirement   b) using DSP_Th and FPGA_to_DSP_Delay_Min (estimated board delays) :    set_output_delay -min [expr DSP_TSu + FPGA_to_DSP_Delay_Min]   This is the FPGA to DSP hold requirement     For the DSP to FPGA path:   c) set_input_delay -max = DSP_Tco_max + FPGA_to_DSP_Delay_Max   d) set_input_delay -min = DSP_Tco_min + FPGA_to_DSP_Delay_Min   BUT i dont see now how or why i would also need to use a set_max_delay or set_mn_delay constraint...as you implied here:   If you then apply a set_max_delay, the launch edge will become 0, the latch edge will become the -max value, but the oExt from your set_output_delay will be used. So you could use the set_output_delay to say what the Tsu of the external device is, and then use set_max_delay like you are now. (You could also just tighten your set_max_delay constraint by the Tsu amount and get the same results).     cheers