Node * determined to be a clock

[Altera_Forum]

Hello, 

 TQ gives me these warnings:    --- Quote Start ---  Warning: Node: current_state.r2 was determined to be a clock but was found without an associated clock assignment. Warning: Node: current_state.idle was determined to be a clock but was found without an associated clock assignment.  --- Quote End ---  In fitter report (control signals) I see that they are Latch enable signals for whom fitter uses global clock network.  Before continuing I think i should explain my design a little bit. The troubling part is a SRAM controller - a simple state machine. In the RTL viewer the state machines logic is masked in a block, with outputs corresponding to each state - idle, r1, r2, w1, w2.  But only the r2 acts directly as enable signal to some of the latches, but not the idle signal. So I don't think they're at fault, but honestly I'm pretty lost (not to mention the naming of nodes, nets, etc :/):  When I choose to locate these signals in RTL netlist from Fitter report (control signals), it points to the state machine block, but not to any nets (unlike with other control signals).  Also, if they actually were latch enable signals, why would fitter use global clock network for them?  I'm not sure if I have provided all the necessary information, so please ask if something additional is needed (like the code itself or smth).  Thanks in advance!

[Altera_Forum]

looking at this, it looks like you may have created a clock by actually clocking some logic using the change in state of the state machine. Any chance of posting some code?

[Altera_Forum]

Hi 

Here's the controller code:  -- SRAM --============================================================================================================================ nCE<='0'; nLB<='0'; nUB<='0'; ---------------------------------------------------------- mem <= '1' WHEN wrusedw_fv<100 ELSE '0'; rw <= '0'; ---------------------------------------------------------- SRAM CONTROLER STATE MACHINE next_state <= r1 WHEN current_state=idle and mem='1' and rw='0' ELSE w1 WHEN current_state=idle and mem='1' and rw='1' ELSE r2 WHEN current_state=r1 ELSE w2 WHEN current_state=w1 ELSE idle; -- PROCESS (clk150MHz) IS BEGIN IF rr='1' THEN current_state<=idle; ELSE If clk150MHz'event and clk150MHz='1' Then current_state<=next_state; End If; END IF; END PROCESS; ----------------------------------------------------------VGA Fifo write request WITH current_state select wrreq_fv <= '1' WHEN r2, '0' WHEN OTHERS; ----------------------------------------------------------Write Enable and Output ENABLE WITH next_state select nWE_buf <= '1' WHEN r1 | r2 | idle, '0' WHEN OTHERS; WITH next_state select -- nOE_buf <= '1' WHEN w1 | w2, '0' WHEN OTHERS; -- PROCESS (clk150MHz) IS BEGIN IF rr='1' THEN nWE<='1'; nOE<='1'; ELSE If clk150MHz'event and clk150MHz='1' Then nWE<=nWE_buf; nOE<=nOE_buf; End If; END IF; END PROCESS; nWEout<=nWE; nOEout<=nOE; --Adreses OUT--------------------------------------- WITH next_state select ADDR_val <= ADDR_read WHEN r1, ADDR_write WHEN w1, ADDR_reg WHEN OTHERS; PROCESS (clk150MHz) IS BEGIN IF rr='1' THEN ADDR_reg<=0; ELSE If clk150MHz'event and clk150MHz='1' Then ADDR_reg<=ADDR_val; End If; END IF; END PROCESS; ADDR<=conv_std_logic_vector(ADDR_reg, 18); --Adreses rw--------------------------------------- ADDR_read_temp<=0 WHEN current_state=r1 and ADDR_read=ram_max ELSE ADDR_read+1 WHEN current_state=r1 ELSE ADDR_read; ADDR_write_temp<=0 WHEN current_state=w1 and ADDR_write=ram_max ELSE ADDR_write+1 WHEN current_state=w1 ELSE ADDR_write; PROCESS (clk150MHz) IS BEGIN IF rr='1' THEN ADDR_read<=0; ADDR_write<=0; ELSE IF clk150MHz'event and clk150MHz='1' THEN ADDR_read<=ADDR_read_temp; ADDR_write<=ADDR_write_temp; End If; END IF; END PROCESS; ADDR_read_out<=ADDR_read; ADDR_write_out<=ADDR_write; --Data---------------------------------------------------- WITH current_state select DataIO <= "ZZZZZZZZZZZZZZZZ" WHEN r1 | r2, Data_to_ram WHEN w1 | w2, DataIO WHEN OTHERS; WITH current_state select Data_from_ram<= DataIO WHEN r2, Data_from_ram WHEN OTHERS; ----------------------------------------------------------  I will give some comments on the code if needed in the evening (GMT+2 :))!  Thanks!

[Altera_Forum]

have a look in the RTL viewer, or the post map viewer. follow the idle and r1 lines from the encoded SM register. see what they clock, because I cant see anything too suspicious from this code.

[Altera_Forum]

Hey, 

 I have looked through both RTL netlist and techonology map, and none of them clocks anything. Only, in the tech. map they both seem to act as latch enable signals, unlike in RTL where only r2 acts directly as latch enable. This coincides with the fitter report. I guess the questions is why would fitter use global clock network for them? To meet timing requirements? And my guess would be that the usage of global clock network makes TQ think that they are clock signals? Can't think of anything else, at least with my small experience :)

[Altera_Forum]

latches are pretty bad. why have you used them? None of the code you posted should create latches.

[Altera_Forum]

Umm, for example, doesn't this create a latch? 

 WITH current_state select Data_from_ram<= DataIO WHEN r2, Data_from_ram WHEN OTHERS;  And I clearly see it in the rtl.  And why are latches bad? I guess I could change this to use reg and mux :/

[Altera_Forum]

If a signal retains its value then it implies memory and in this case a latch. 

 However, it does not explain the warning because latches don't have clock.  It could be you are feeding back some logic tied up from your states into a combinatorial clock.

[Altera_Forum]

The code I posted is the only one containing anything related to SM or states. 

 Also, I tried to comment out parts of code to try to determine which causes the problem. So, if I remove this part:  WITH current_state select Data_from_ram<= DataIO WHEN r2, Data_from_ram WHEN OTHERS;This warning disappears:    --- Quote Start ---  Warning: Node: current_state.r2 was determined to be a clock but was found without an associated clock assignment.  --- Quote End ---  I guess that makes sense, since r2 really was enable signal to that latch.  Further, when I remove this part:  WITH current_state select DataIO <= "ZZZZZZZZZZZZZZZZ" WHEN r1 | r2, Data_to_ram WHEN w1 | w2, DataIO WHEN OTHERS;The other warning regarding current_state.idle disappears. Guess this makes more or less sense, but on the other hand, doesn't really explain the warning in the first place :/  Tomorrow will check what changes in rtl netlist and tech map.  Again, thanks for help

[Altera_Forum]

I didnt read it properly first time. The problem comes because you're connecting data_from_ram and DataIO to themselves when in certain states - this is where the latches come from. Latches are bad because you cannot analyse them with timing analyse and they are highly affected by temperature and subject to glitches. 

 So it is best not to use latches. Either connect them to a constant or something else in the others case, or synchronise them (as would be the prefered option). With synchronised registers for these pins they can be placed in the fast IO registers to make the output timings easier to control.

[Altera_Forum]

Ok, didn't know that, thanks! 

 So, then I will make the bidir part something like this:  http://imageshack.us/a/img717/1227/editpreviewn.png

[Altera_Forum]

--- Quote Start ---  I didnt read it properly first time. The problem comes because you're connecting data_from_ram and DataIO to themselves when in certain states - this is where the latches come from. Latches are bad because you cannot analyse them with timing analyse and they are highly affected by temperature and subject to glitches.  So it is best not to use latches. Either connect them to a constant or something else in the others case, or synchronise them (as would be the prefered option). With synchronised registers for these pins they can be placed in the fast IO registers to make the output timings easier to control.  --- Quote End ---     Hello,  I seem to have a similar problem, being rather unexperienced with Quartus. I too get the warning: Warning (332060): Node: ... was determined to be a clock but was found without an associated clock assignment.  I am writing a controller to process the inputs from the MegaWizard Virtual JTAG node (passed from a PC to the FPGA with the tcl-command "device_virtual_dr_shift"). The value I am interested in is called "challenge". I need to shift it into the controller bit by bit but at the same time I want it to be available at an output of the controller.   Here is the relevant part of my code:  entity controller is generic ( challenge_width : integer := 8 ); port ( ir_in : in std_logic_vector(7 downto 0); tck_in : in std_logic; tdi_in : in std_logic; shift_dr_in : in std_logic; challenge_out : out std_logic_vector((challenge_width-1) downto 0); ); end controller; architecture arch of controller is -- Instruction codes. constant C_PUSH_CHALLENGE : std_logic_vector(7 downto 0) := "00000001"; -- Register. signal challenge_dr : std_logic_vector((challenge_width-1) downto 0); begin challenge_out <= challenge_dr; process(tck_in) begin if rising_edge(tck_in) then if ir_in = C_PUSH_CHALLENGE and shift_dr_in = '1' then challenge_dr <= tdi_in & challenge_dr((challenge_width-1) downto 1); end if; end if; end process; end arch;   As I said above, challenge_dr is causing the warnings:  Warning (332060): Node: controller:control|challenge_dr[0] was determined to be a clock but was found without an associated clock assignment. Warning (332060): Node: controller:control|challenge_dr[4] was determined to be a clock but was found without an associated clock assignment.     Any ideas how to handle this?  Thanks, Linus

[Altera_Forum]

--- Quote Start ---  Hello,  I seem to have a similar problem, being rather unexperienced with Quartus. I too get the warning: Warning (332060): Node: ... was determined to be a clock but was found without an associated clock assignment.  I am writing a controller to process the inputs from the MegaWizard Virtual JTAG node (passed from a PC to the FPGA with the tcl-command "device_virtual_dr_shift"). The value I am interested in is called "challenge". I need to shift it into the controller bit by bit but at the same time I want it to be available at an output of the controller.   Here is the relevant part of my code:  entity controller is generic ( challenge_width : integer := 8 ); port ( ir_in : in std_logic_vector(7 downto 0); tck_in : in std_logic; tdi_in : in std_logic; shift_dr_in : in std_logic; challenge_out : out std_logic_vector((challenge_width-1) downto 0); ); end controller; architecture arch of controller is -- Instruction codes. constant C_PUSH_CHALLENGE : std_logic_vector(7 downto 0) := "00000001"; -- Register. signal challenge_dr : std_logic_vector((challenge_width-1) downto 0); begin challenge_out <= challenge_dr; process(tck_in) begin if rising_edge(tck_in) then if ir_in = C_PUSH_CHALLENGE and shift_dr_in = '1' then challenge_dr <= tdi_in & challenge_dr((challenge_width-1) downto 1); end if; end if; end process; end arch;   As I said above, challenge_dr is causing the warnings:  Warning (332060): Node: controller:control|challenge_dr[0] was determined to be a clock but was found without an associated clock assignment. Warning (332060): Node: controller:control|challenge_dr[4] was determined to be a clock but was found without an associated clock assignment.     Any ideas how to handle this?  Thanks, Linus  --- Quote End ---    your problem isn't in the piece of code given above. challenge_dr must have been used somewhere else as clock.

[Altera_Forum]

Hello Kaz, 

 and thanks for your reply!  challenge_dr is just used as internal signal in controller. As my code snippet shows, it is passed out of controller through challenge_out.  challenge_out[3..0] and challenge_out[7..4] are each used as select-inputs of two 16-bit MUXes.  Interestingly, I only get the warning for challenge_dr[0] and challenge_dr[4]. So is the MUX causing the waring? Here is its code:  -------------------------------------------------------------------- -- -- MUX Parameterized Megafunction -- INCLUDE "lpm_mux.inc"; PARAMETERS ( WIDTH, WIDTHS = CEIL(LOG2(WIDTH)) ); SUBDESIGN mux ( data : INPUT; sel : INPUT; result : OUTPUT; ) BEGIN result = lpm_mux(.data=data, .sel=sel) WITH (LPM_WIDTH = 1, LPM_SIZE = WIDTH, LPM_WIDTHS = WIDTHS); IF !USED(result) GENERATE result = GND; END GENERATE; END;

[Altera_Forum]

--- Quote Start ---  Hello Kaz,  and thanks for your reply!  challenge_dr is just used as internal signal in controller. As my code snippet shows, it is passed out of controller through challenge_out.  challenge_out[3..0] and challenge_out[7..4] are each used as select-inputs of two 16-bit MUXes.  Interestingly, I only get the warning for challenge_dr[0] and challenge_dr[4]. So is the MUX causing the waring? Here is its code:  -------------------------------------------------------------------- -- -- MUX Parameterized Megafunction -- INCLUDE "lpm_mux.inc"; PARAMETERS ( WIDTH, WIDTHS = CEIL(LOG2(WIDTH)) ); SUBDESIGN mux ( data : INPUT; sel : INPUT; result : OUTPUT; ) BEGIN result = lpm_mux(.data=data, .sel=sel) WITH (LPM_WIDTH = 1, LPM_SIZE = WIDTH, LPM_WIDTHS = WIDTHS); IF !USED(result) GENERATE result = GND; END GENERATE; END;   --- Quote End ---    challenge_out is wired to challenge_dr and is viewed as same node for clocking purpose. So check that challenge_out is used as clock

[Altera_Forum]

--- Quote Start ---  challenge_out is wired to challenge_dr and is viewed as same node for clocking purpose. So check that challenge_out is used as clock  --- Quote End ---    You are right! challenge_out goes as select into the MUX. The MUX selects the outputs of different ring oscillators whose edges are counted by a counter. (See the attached image for explanation of Ring-Oscillator Physically Unclonable Functions.) The counter's input is indeed defined as clock:   entity counter is port ( -- Input ports clk : in std_logic; reset : in std_logic; start_counter : in std_logic; stop_counter : in std_logic; -- Output ports count : out std_logic_vector(127 downto 0) ); end entity counter; architecture logic of counter is signal tmp_count : std_logic_vector(127 downto 0) := (others => '0'); signal run_counter : std_logic := '0'; begin process(clk,reset) begin if reset = '1' then tmp_count <= (others => '0'); elsif rising_edge(clk) then if run_counter='1' then tmp_count <= tmp_count + 1; end if; end if; end process; process(start_counter,stop_counter) begin if start_counter='1' then run_counter<='1'; elsif stop_counter='1' then run_counter<='0'; end if; end process; count <= tmp_count; end architecture logic;    So should I ignore the warning or is there a way to suppress it via more explicit code?  Thanks, Linus

[Altera_Forum]

you might do better using clock mux core of altera as otherwise you get timing problems.

[Altera_Forum]

I should also say that the mux may not be the issue rather it is the gated clock(from counters). You can use one fast proper clock then use counters as clock enable at its rate.