Timequest: Tri-state node assumed to be a clock

Thanks for all your replies Rysc and Kaz. just one more point on this before I do what timequest says :-(

If I comment out the write strobe constraint

create_generated_clock -name Nand_flash_wr_strobe -source [get_nets {dctu_i|a_uniphy_i|a_uniphy_inst|pll0|afi_phy_clk}] -divide_by 3 [get_ports {flash_we_n}]

The unconstrained clock bus_tri_d disappears. I am sure there are a many good reasons why it has (no 1 being that all the output_delay constraints now don't have a latch clock) but I am just starting to question if my constraint for the write strobe is correct or not.

In the async ram, the flash_we_n signal is used to sample the data into the Nand flash. In the RTL code, I have a state machine that outputs the data on to the pins then waits a number of clock cycles before the write strobe is asserted. To constrain this interface, I created a generated clock constraint from the main system clock to create a virtual clock and divided it by 3. I divided it because this is about the fastest it can run limited by the clock cycle delays in the state machine. I then use this generated clock as the latch clock. This is the constraint stated at the start of this message. I then use a multicycle constraint to open the data window between the clocks.

set_multicycle_path -from [get_clocks {dctu_i|a_uniphy_i|a_uniphy_inst|pll0|pll_afi_clk}] -to [get_clocks {Nand_flash_wr_strobe}] -setup -end 6

set_multicycle_path -from [get_clocks {dctu_i|a_uniphy_i|a_uniphy_inst|pll0|pll_afi_clk}] -to [get_clocks {Nand_flash_wr_strobe}] -hold -end 5

I know this doesn't explain what I am seeing but I would like to rule this out from causing problems

C