set_multicycle_path -setup & -hold for the flash_data[*] or set_max_delay or set_input_delay ?

[Knug]

I have a PFL (within CPLD MAX V) interfacing with the flash device and FPGA (Cyclone V)

Do we need to set_multicycle_path -setup & -hold for the flash_data[*] ?

Does it take multiple clock cycles to perform each operation ?

eg 

set_multicycle_path -setup -to [get_ports {flash_data[*]}] 4
set_multicycle_path -hold -to [get_ports {flash_data[*]}] 3

Note: Numbers used above are arbitrary.

If yes, How do I determine how many cycles it takes for each operation?

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_pfl.pdf

1.4.2.4. Summary of PFL Timing Constraints Table 7. PFL Timing Constraints

flash_data

Normal read mode: set_false_path • Burst read mode: set_input_delay

https://www.intel.com/content/www/us/en/programmable/documentation/sss1411439280066.html

1.4.2.4. Summary of PFL Timing constraints

flash_data

Read mode (PFL to Flash ROM) set_max_delay -from <port> to pfl_clk Write mode (Flash ROM to PFL) set_false_path

2 docs above (as raised in another private message wrt other PFL signals too) show differences in constraints suggestions. 

So far chosen the 2nd document (sss1411439280066.html) suggestion.

But maybe Multicycle paths should be used instead. Please comment here for both write mode and read mode cases.

[Kenny_Tan]

Any reason that you want to set Multi cycle? Usually, we do that because we have hard time closing timing.

You can check the waveforms behavior in your timing analyzer after setting it, It would be same as gate level simulation.

[Kenny_Tan]

any update?

[Kenny_Tan]

We do not receive any response from you to the previous question that we have provided. Please post a response in the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you with your follow-up questions.