# VHDL: Optmize signal comparisons for synthesis

As a preface, there are certain coding styles used in VHDL/Verilog which help the synthesis tools infer different hardware(some better in perfomance than the other). For example using an if-else-if ladder would infer a series of mux'es whereas a case statement would infer a single wide multiplexer. These coding styles are not significant when doing only functional simulation, but substantial when targeting the RTL for ASIC or FPGA implementation. In case of FPGAs the CLB(configurable logic block) architecture defines the capabilities achieved using RTL(like the LUT input width).

Coming to the Question, I have seen many instances where two n-bit wide signals might have to be compared in VHDL. And I need some advice on the hardware inference. I will use the following code snippet to further narrow the question.

signal counter_a: unsigned(31 downto 0);
signal counter_b: unsigned(31 downto 0);
signal clk, trigger_en, count_b_en : std_logic;

counter_a_gen: process (clk) begin
if(rising_edge(clk)) then
counter_a <= counter_a + 1; -- free running counter
end if;
end process;

counter_b_gen: process (clk) begin
if(rising_edge(clk)) then
if(count_b_en = '1') then
counter_b <= counter_b + 1;
else
counter_b <= (others => '0');
end if;
end if;
end process;

-- compare the counters to generate some logic
trigger_gen: process (clk) begin
if(rising_edge(clk)) then
if(counter_a = counter_b) then
trigger_en <= '1';
else
trigger_en <= '0';
end if;
end if;
end process;


The above snippet has two 32 bit counters counter_a and counter_b, which have to be compared in a sequential block. If I consider a 4-input LUT in an FPGA, the comparison would need multiple levels of logic. Such a path would be make it hard to meet timing because of the huge combinatorial delays. So my question is how do we make it optmized? In this case to increase the perfomance?

• a case statement would infer a single wide multiplexer. Only if you add the parallel case synthesis directive. Default it is also treated as if-then-else-if. – Oldfart Mar 31 '18 at 6:01
• May be. But I guess synthesis tools should also be intelligent enough to infer parallelism in circuits based on user specified directives/constraints rather than RTL attributes. – electro_sm11 Mar 31 '18 at 6:47
• I would expect the tools to place the logic such that it can use a high speed carry chain so it may not be as bad as you think. Another possibility is to tweak things to get the tool to utilise whatever sort of DSP block your part comes with, device dependent code, but the DSP48E1 for example has magnitude comparison as one of its 'ALU' party tricks, you could probably get one of the counters out of the same block. If you need ultimate speed you generally have to write at least somewhat to the part you are targeting. – Dan Mills Mar 31 '18 at 11:06
• How do we infer dsp elements from coding styles? Or do we need to manually instantiate the element for comparison? – electro_sm11 Apr 1 '18 at 3:14
• Xilinx Tools don't use carry chains in that case. The PoC Library offers several IP cores that perform better than standard synthesis. – Paebbels Apr 1 '18 at 9:34