0
\$\begingroup\$

I get a number of Critical Warnings with respect to lpm_ff and lpm_counter:

Below are few:

Rule A102: Register output should not drive its own control signal directly or through combinational logic - Structure 1

App:inst1|Exp_Box:inst2|lpm_ff:ff_Last_Image|dffs[0]
App:inst1|Exp_Box:inst2|_~3
App:inst1|Exp_Box:inst2|lpm_ff:ff_event_HStrig|dffs[0]

App:inst1|Expe_Box:inst2|lpm_counter:cnt_ext_HStrig|cntr_6ik:auto_generated|cout_actual

Can these warnings be ignored? Moreover I am using Altera Quartus 11.1 Web Edition. Could it be because of Open Core Plus?

ff_event_HStrig.clock       =   System_Clock;
ff_event_HStrig.data[]      =   B"1";
ff_event_HStrig.enable      =   (red_HS_trigger OR (dl_enabled AND HS_trig_deglitch)) AND (SW_Con_en OR
                                                    SW_KK_en     OR
                                                    SW_KK_ro_en OR
                                                    SW_Ser_en); 
ff_event_HStrig.aclr        =   !n_Reset OR !HS_trig_deglitch OR fed_gen_ready OR !HW_Con_en_LIHext;    -- reset HS trigger signal
HS_trigger                  =   ff_event_HStrig.q[0];   

cnt_ext_HStrig.clock            =   System_Clock;
cnt_ext_HStrig.cnt_en       =   10kHz_Pulse AND !cnt_ext_HStrig.cout;
cnt_ext_HStrig.aclr         =   !n_Reset OR !ff_ext_HStrig.q[0];
---------------------------------------------------------------------------
ff_ext_HStrig.clock         =   System_Clock;
ff_ext_HStrig.data[]        =   B"1";
ff_ext_HStrig.enable        =   red_HS_trigger; 
ff_ext_HStrig.aclr          =   !n_Reset OR cnt_ext_HStrig.cout;

HS_trig_activated               =   ff_ext_HStrig.q[0]; 
---------------------------------------------------------------------------
cnt_Last_Image.clock        =   System_Clock;
cnt_Last_Image.cnt_en       =   100Hz_Pulse AND ff_Last_Image.q[0] AND !cnt_Last_Image.cout;
cnt_Last_Image.aclr     =   !n_Reset OR HW_Con_en;  


ff_cnt_LIH_out.clock        =   System_Clock;
ff_cnt_LIH_out.data[0]      =   cnt_Last_Image.cout;
ff_cnt_LIH_out.enable       =   B"1";   
ff_cnt_LIH_out.aclr         =   !n_Reset OR HW_Con_en;

cnt_Last_Image_fix.clock        =   System_Clock;
cnt_Last_Image_fix.cnt_en   =   100Hz_Pulse AND ff_Last_Image.q[0] AND !cnt_Last_Image_fix.cout;
cnt_Last_Image_fix.aclr     =   !n_Reset OR HW_Con_en;

ff_Last_Image.clock         =   System_Clock;
ff_Last_Image.data[0]       =   B"1";
ff_Last_Image.enable        =   fed_HW_Con_en AND LIH_en;   
ff_Last_Image.aclr          =   !n_Reset OR (cnt_Last_Image.cout AND (!HS_trigger OR LIH_ro)) OR !LIH_en OR HW_Con_en OR cnt_Last_Image_fix.cout;

LIH_active                          =   ff_Last_Image.q[0];
LIH_activated                       =   LIH_active;

Regards!

\$\endgroup\$
  • \$\begingroup\$ What code are you using? Do you have a register output driving its own control signal? \$\endgroup\$ – Tom Carpenter Mar 31 '16 at 12:51
  • \$\begingroup\$ Unfortunately I have an old code written in AHDL cnt_ext_HStrig.clock = System_Clock; cnt_ext_HStrig.cnt_en =10kHz_Pulse AND !cnt_ext_HStrig.cout; cnt_ext_HStrig.aclr =!n_Reset OR !ff_ext_HStrig.q[0]; Yes. Here the cout is a register output I believe. If this is not allowed I suppose I should change the logic. Or? \$\endgroup\$ – Alex Krish Mar 31 '16 at 13:02
  • \$\begingroup\$ Please add the code to your question and also show the code for ff_Last_Image and ff_event_HString. Cout is a combinational output of the counter. The warnings refer likely to the asynchronous clear aclr which is driven by the registered counter output q[0] as similar depicted in this help page for Rule A102. \$\endgroup\$ – Martin Zabel Apr 1 '16 at 8:33
  • \$\begingroup\$ @MartinZabel I have attached the code above. Yes. You are right. the problem is because of the aclr driven by the counter output. Is there any way how I can resolve this without altering the logic? I tried using a register to drive the output to the aclr. Did not work though. \$\endgroup\$ – Alex Krish Apr 1 '16 at 9:34
1
\$\begingroup\$

Care has to be taken when using the asynchronous clear input of flip-flops:

  • The reset pulse must be long enough as defined in the datasheet, to reliably reset the flip-flop.

  • Reset pulses shorter than the minimum pulse width may lead to an unknown state. Thus, asynchronous inputs should not be driven from combinational logic because the output of the combinational logic (which drives the asynchronous clear) may toggle several times until it settles to the final value, also known as glitch.

  • The asyncronous clear should also not be connected to the output Q of the flip-flop because when Q rises (after a clock edge) and reaches the threshold for logic high, a reset is applied and Q falls again. This leads to short reset pulses which may violate the minimum pulse width.

A good design practice is to connect the asynchronous clear only to a global reset signal which is de-asserted synchronously to the active edge of the clock. Then the asynchronous clear of all connected flip-flops are released at the same time, and enough time before the next active clock edge. Timing constraints are required to ensure this.

To de-assert the reset synchronously, you should use a reset synchronizer which is composed of two flip-flops connected in series:

signal reset_ff : std_logic_vector(1 downto 0) := "00"; -- low-active
signal reset_global : std_logic; -- high-active

process(n_Reset, System_Clock)
begin
  if n_Reset = '0' then
    reset_ff <= (others => '0');
  elsif rising_edge(System_Clock) then
    reset_ff <= reset_ff(0 downto 0) & '1'; -- release reset
 end if;
end process;

reset_global <= not reset_ff(1); -- high-active

More information can be found in the paper Asynchronous & Synchronous Reset Design Techniques - Part Deux from Cliff Cummings (Sunburst Design) et.al. .

The reset synchronizer would allow to reset the design only globally, e.g., from an external input (button). To reset only some flip-flops, one should use the synchronous reset sclr instead. The timing analyzer will check that all contraints are met.

But, you cannot easily replace aclr by sclr because the synchronous clear will not take place until the next active clock edge. Thus, you have to likely issue the synchronous clear in the clock period before.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.