Hi David,
you can constrain the paths with the 'set_net_delay' command from sdc_ext package. I wrote a tcl wrapper for it:
proc set_q_fanout_net_delay {src delay} {
set_net_delay -max $delay -from -to *
}
# and use it like this:
set_q_fanout_net_delay *my_module_0|my_registered_signal "5 ns"
To see the if the constrints were met you can run the command 'report_net_delay' in timequest. Note that the default timing analysis script will not check these constraints so you have to run this command to see if they're met.
You can make quartus run the 'report_net_delay' command automatically with following recipe:
1. put this in a tcl file (eg. report_net_delay.tcl) :
report_net_delay -panel {Net Delay Constraints}
2. add this to your .qsf file:
set_global_assignment -name TIMEQUEST_REPORT_SCRIPT "../scripts/report_net_delay.tcl"
Next time you run Quartus compile you should see an entry under Timequest in the reports pane.
However, I think the most important thing is that you let quartus know that your clock domains are asynchronous and that you have the synchronizer chain detection on.
Regards
Magne