Logic OR reset and clear?

Question

I am trying to figure out the best practice for implementing a reset (async applied, sync cleared) and a clear input. I have a process that must run off a logic-derived clock (NCO) that is called code_clk, slower but synchronous to the actual clk. The process involves a Linear Feedback Shift Register that must reset to all 1's to begin a code generation sequence after the reset is lifted. However, throughout operation the process should also reset to all 1's when a new set of taps (T1 and T2) are selected for the output, of course in order to reset the code generation sequence and make sure the new code is valid with the new taps. This is done with a separate, synchronous clr input that gets held high for a single system clock cycle while the taps are moved around.

Here is my code:

  process(code_clk, reset, clr)
  begin
    if(reset='0' or clr='1') then
      -- EARLY LFSR
      EG1(1 to 10) <= (others => '1');
      EG2(1 to 10) <= (others => '1');
      early_code   <= '0';
      delay_os     <= '0';
    elsif(falling_edge(code_clk)) then
      if(delay_os='0') then
        -- LFSR feedbacks for early code
        EG1(2 to 10) <= EG1(1 to 9);
        EG2(2 to 10) <= EG2(1 to 9);
        EG1(1) <= EG1(3) xor EG1(10);
        EG2(1) <= EG2(2) xor EG2(3) xor EG2(6) xor EG2(8) xor EG2(9) xor EG2(10);
        early_code <= EG1(10) xor EG2(T1) xor EG2(T2); -- C/A output of early LFSR
      else
        -- delay of code chips commanded - do not shift this time
        delay_os <= '0';
      end if;
      late_code   <= early_code; -- one half chip delay from prompt code
    elsif(rising_edge(code_clk)) then 
      prompt_code <= early code; -- one half chip delay from early code
    end if;
  end process;

The conditional if(reset='0' or clr = '1') kind of jumps out at me as being bad style. It just seems like one of those situations where synthesis will produce unnecessary logic or timing delay because the reset path is not as straightforward. Can I do this or should I try something else? The clear needs to happen immediately so I'd either need to make the process run off of the system clock or something else. Is this considered good practice?

Answer 1

Your instincts for the conditional if are correct. Some synthesis tools may understand what you are trying to do, but many will not as what you have written is not an established pattern so the tools may not infer what you want in the way you want it. The standard (if there is such a thing)/ accepted way to write what you are trying to achieve is like this:

process(clk, reset)
begin
  if reset = '1' then  -- async reset
    -- your code here
  elsif Rising_edge(clk) then
    if sync_clr = '1' then  -- sync clear
      -- your code here
    end if;
  end if;
end process;

I note that your reset is active low which tends to be frowned upon within the FPGA (more to do with code readability than actual architectural issues).

But wait! Why does any of this actually matter?

This comes down to the individual architecture of the FPGA you are using. Below is a snippet of the block diagram for a Cyclone V Adaptive Logic Module.

Looking at the registers you can see that they only have a single control - CLR. At the top of the diagram you can see the signals aclr[1:0] coming into the ALM. When you infer an async reset, this is what is set. Note that this ALM has 4 registers but only 2 reset signals that are shared by the pairs. This has an implication for how many ALMs are used.

You can also see a synchronous clear signal (sclr) and a synchronous load signal (syncload) coming into the ALM. These are shared by all 4 registers. These circuits will be used if inferred in code. The diagram is detailed enough to be able to understand how the signals work.

sclr is intended to be active high. It is inverted and ANDed with data that feeds the D input of the registers. That means when high, 0 is fed to the D input and Q updates to 0 on the next clock cycle.

syncload drives a multiplexor which selects either the outputs from the LUTs or datae0 which originates outside the ALM.

Note how there is no asynchronous set. If you wrote this, then the tools would be unable to match this to the device architecture and instead implement using LUTs. This is the same for every control that is not part of the devices architecture.

Xilinx have a white paper that explains this in a lot more detail: https://www.xilinx.com/support/documentation/white_papers/wp275.pdf