timing constraints for EHPI DSP to FPGA asynchronous interface

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.