# Logic OR reset and clear?

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?

• Is this meant to be for synthesis in an FPGA? Sep 16 '20 at 4:16
• Yes, this is meant to be used as part of a GPS receiver. The Gold Codes I'm generating are mixed with the incoming signal to see if they match. The delay/clr signals are used to search through all phases of the code at any one time. Sep 16 '20 at 13:25

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
elsif Rising_edge(clk) then
if sync_clr = '1' then  -- sync clear
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

• This is fantastic, thank you. the signal clr in my design is in fact a signal synchronous to clk but not to code_clk. I'm guessing since clk is nowhere near this process, that the tool will consider it to be asynchronous for the design and be unable to fully make use of this ALM. This is the kind of thing they should be teaching at the last year of college. Sep 16 '20 at 13:21
• One more question, however. I see that lots of people are saying that my way (logic derived clocks) are bad in that they create clock domains, but I can't see this to be the case. I feel like this is just creating a bit of delay for clk to head to code_clk and then my logic happens. Is this standard practice? I actually am basing this off another project where the same idea was used. Sep 16 '20 at 13:23
• If asynchronous set is needed, the aclr signal can usually be used, with the output treated as active low rather than high, and the upstream and downstream logic adjusted to account for the change. Sep 16 '20 at 15:28
• @comccmoc, see fpga clock strategy Sep 16 '20 at 15:32
• @cmoc-cmoc Your question about logic derived clocks would make an excellent posted question, rather than a comment. The answer would get quite involved. Sep 17 '20 at 9:04