derived clock versus clock enable

Bruce,

Because you have no synchronous paths crossing into or out of the 8.3 MHz domain, you should be fine with the divided clock. Make sure it is on global routing, which the Fitter is likely doing automatically. Check the "Control Signals" table or the "Global & Other Fast Signals" table in the Fitter compilation report to see whether global routing was used. There's also a compilation message for it. Also make sure the 8.3 MHz clock is driven by a single register, not a combinational signal fed by the state machine state bits.

You would use a multicycle setting if you had a clock enable that is asserted one clock cycle at a time every 18th clock cycle of 150 MHz. With a divided-down clock, you can use a clock setting assigned to the 8.3 MHz clock node. Create the clock setting at "Assignments --> Timing Analysis Settings --> Classic Timing Analyzer Settings --> Individual Clocks". Assign the clock setting to the clock node name listed in the "Control Signals" table.

If you did have synchronous cross-domain paths, you would need a derived-clock setting with the divide by 18. You would leave blanks in the "offset from base absolute clock fmax" and "clock phase shift" fields so that Quartus would calculate the actual offset between the 150 MHz base clock and 8.3 MHz derived clock.

Because you have no synchronous cross-domain paths, it is OK to use an absolute clock setting with the 8.3 MHz entered directly. With the default of "On" for "More Timing Settings --> Cut paths between unrelated clock domains", there would be no need to use "Cut Timing Path" in the Assignment Editor to prevent timing analysis on any asynchronous cross-domain paths.