Timequest: Tri-state node assumed to be a clock

[Altera_Forum]

I am having a bit of trouble understanding why Timequest/Quartus is reporting an issue with one of my tristate node signals on a flash interface 

 The warning it is giving me is   node: fmrc:fmrc_i|bus_tri_d was determined to be a clock but was found without an associated clock assignment.  node flash_re_n is being clocked by fmrc:fmrc_i|bus_tri_d  Bus_tri_d is my enable for the tri-state buffer on flash_re_n (This is a Flash chip interface RE/CLE/ALE etc...) I can't see why Quartus thinks that flash_re_n is being clocked by bus_tri_d. When I look at the technology   viewer, it doesn't appear to be doing that. I have attached the tech viewer picture.  Quartus help says    [h=3]Node: <node name> was determined to be a clock but was found without an associated clock assignment.[/h] (id: 332060)      CAUSE: This can be caused in two ways: 1) A clock assignment was determined to be invalid, so its source objects no longer have a clock associated with them. 2) When analyzing the netlist, the node was found feeding a clock port with no other clocks feeding it.   ACTION: Use the derive_clocks command to automatically find all clock nodes in the design. Also, for any clocks that were ignored, review the warning or error message associated with the command to prevent the clock from being ignored.     I don't see how it fits any of them .  Any ideas  C

[Altera_Forum]

Strange. I've had a similar situation where I don't know why it thinks it's a clock and in TimeQuest, will manually run: 

create_clock -period 10.0 -name not_a_clock {fmrc:fmrc_i|bus_tri_d} report_timing -setup -detail full_path -npaths 20 -to_clock "not_a_clock" -panel_name "to not_a_clock" report_timing -setup -detail full_path -npaths 20 -from_clock "not_a_clock" -panel_name "from not_a_clock"  If any paths show up, then look at what's being clocked by that. (From the screenshot you sent, I can't imagine what this would catch. I'm just saying this has worked for me. In my case it was a node with a large fanout and lots of logic, and somewhere in the many pieces of code it was actually used as a clock, so this just helped me find it quickly)

[Altera_Forum]

Thanks Rysc. I appreciate your advice. 

 I did the report and found 6 setup paths. They are from bus_tri_d to my generated virtual clock.   slack from node to node launch clock latch clock relat. clock_skew data_delay -20.747 fmrc_i|bus_tri_d|q flash_ce_n not_a_clock Nand_flash_wr_strobe 5.000 0.000 5.597  I noticed when I was writing my SDC constraints for this interface that Timequest was complaining that I had not constrained   the bus_tri_d node. For a tristate signal I did not believe this was necessary. Here are my sdc write memory constraints. Is there some   not quite right in here that is making Timequest get a bit upset  # Read memory access time  set tREH_min 10 # Read memory hold time set tREA_max 20 # Create write strobe signal maximum 25MHz but use 50MHz just incase. This is the virtual clock  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}] # Constrain command latch cycle set_output_delay -add_delay -clock { Nand_flash_wr_strobe} -min -5.00 [get_ports {flash_cle}] set_output_delay -add_delay -clock { Nand_flash_wr_strobe} -max 10.00 [get_ports {flash_cle}] set_output_delay -add_delay -clock { Nand_flash_wr_strobe} -min -5.00 [get_ports {flash_ce_n}] set_output_delay -add_delay -clock { Nand_flash_wr_strobe} -max 20.00 [get_ports {flash_ce_n}] set_output_delay -add_delay -clock { Nand_flash_wr_strobe} -min -5.00 [get_ports {flash_ale}] set_output_delay -add_delay -clock { Nand_flash_wr_strobe} -max 10.00 [get_ports {flash_ale}] set_output_delay -add_delay -clock { Nand_flash_wr_strobe} -min -5.00 [get_ports {flash_wp_n}] set_output_delay -add_delay -clock { Nand_flash_wr_strobe} -max 10.00 [get_ports {flash_wp_n}] set_output_delay -add_delay -clock { Nand_flash_wr_strobe} -min -5.00 [get_ports {flash_data[*]}] set_output_delay -add_delay -clock { Nand_flash_wr_strobe} -max 10.00 [get_ports {flash_data[*]}] 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 # set false path on tri-state enable and cut timing paths between bi-dir pads that don't require timing now set_false_path -from {fmrc:fmrc_i|bus_tri_d*} -to {flash_*} set_false_path -from [get_clocks {Nand_flash_wr_strobe}] -to [get_clocks {dctu_i|a_uniphy_i|a_uniphy_inst|pll0|pll_afi_clk}]  Essentially what I am doing here is creating a virtual clock that represents the write strobe signal that clocks in the data to the NAND flash   device. I then create setup and hold constraints for the signals that are sampled by the write strobe line. I also add a multicycle constraint to   open up the size of the timing window. I finally do some cutting on some paths. You can see I have cut the path between bus_tri_d and all flash   signals. Below is what my verilog looks like   //tristate flash bus signals when not in use    assign flash_cle = (bus_tri_d) ? 1'bz : cle_d;   assign flash_ale = (bus_tri_d) ? 1'bz : ale_d;   assign flash_ce_n = (bus_tri_d) ? 1'bz : ce_n_d;  assign flash_we_n = (bus_tri_d) ? 1'bz : we_n_d;  assign flash_re_n = (bus_tri_d) ? 1'bz : re_n_d;  Any guidance you can provide would be most appreciated  C

[Altera_Forum]

--- Quote Start ---    //tristate flash bus signals when not in use    assign flash_cle = (bus_tri_d) ? 1'bz : cle_d;   assign flash_ale = (bus_tri_d) ? 1'bz : ale_d;   assign flash_ce_n = (bus_tri_d) ? 1'bz : ce_n_d;  assign flash_we_n = (bus_tri_d) ? 1'bz : we_n_d;  assign flash_re_n = (bus_tri_d) ? 1'bz : re_n_d;  Any guidance you can provide would be most appreciated  C  --- Quote End ---    just curious why do you tristate output. I will only do that for bidirectional pin.

[Altera_Forum]

It has another master on the bus

[Altera_Forum]

--- Quote Start ---  It has another master on the bus  --- Quote End ---    It might help to see how the master drives the node flash_re_n. It could be you are clocking it here on bus_tri_d  If you are driving flash_re_n by logic from two other nodes you can just use a mux. Though this does not explain your clock problem  One more question: is your flash synchronised to a clock or is it asynchronous?

[Altera_Forum]

So the analysis you're seeing is "clock as data", whereby something constrained as a clock is then analyzed as data into another domain. An example of this might be a clock you generate with a divide by two register, and then sample it in the higher speed domain so you know edge it's on. It's still not showing you any paths where the tri-state is being used as an actual clock. I don't think you want the analysis it's doing and should get rid of it. I'm not sure why you're getting that original warning and can't tell from the info provided. You may want to file an SR or ignore it, if you know you're analyzing the interface correctly. 

 (My other thought is that you have a signal coming into the FPGA from one of those flash pins that's used as a clock. In that case, it may be looking at the tri-state register wrapping around into that port too. I would have expected it to show up in your report_timing though. Regardless, you don't want to analyze that path as a clock if that's what is going on.)

[Altera_Forum]

Kaz, 

 Thanks for your reply. I have attached a picture showing some extra levels of flash_re_n.  The flash chip is asynchronous relying on data being sampled using a write or read strobe signal.  The setup is that an external microcontroller can read or write to the NAND flash chip. The FPGA   can read or write to the NAND Flash chip as well. This is why I have to use a tri-state so the   lines are freed up during the micro to NAND flash chip communication. The micro can also   read and write to the FPGA but that's a different story.  C

[Altera_Forum]

According to your diagram clearly the bus_tri_d is not clock in the usual sense, neither is there any other register after it. 

so either timequest is going wrong or is misled or may be it has different rules for tristate buffer- just a guess.  I can imagine that a tristate buffer OE will trigger the buffer output (as if like a clock on a register). This is a point of transition that you may need to control its timing. As you have no registers in the flash but constraints required for the flash signals then you might be helped to control the buffer output transition by surrendering to timequest rules and declaring bus_tri_d as clock.

[Altera_Forum]

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

[Altera_Forum]

It looks like you have badly confused timequest and beaten it.  

Moreover your new multicycle does not look right.  What you need is simpler. the flash needs certain timing requirements (this has nothing to do with latching clock as it is asynchronous). All you need a constraint to keep io delays under control and you have plenty of margin I assume.  I suggest you use system clock as your reference and apply set_output_delay relative to it to all your signals.