Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

use less resources when checking for a logic '0'?

Status
Not open for further replies.

gbounce

Junior Member level 3
Joined
Mar 28, 2012
Messages
25
Helped
2
Reputation
4
Reaction score
2
Trophy points
1,283
Activity points
1,438
When creating a counter, or just any old if statement, does the either version of the code use less resources? Is comparing against 0 a special case, or does it not matter?

Compare against 0:

Code:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use ieee.std_logic_unsigned.all;

entity counter is
  port (
    clk   : in std_logic;
    rst_n : in std_logic
    );
end counter;

architecture rtl of counter is
  
  signal cnt : integer range 0 to 7;
  
begin
  -----------------------------------------------------------------------------
  -- count process
  -----------------------------------------------------------------------------
  process (clk, rst_n)
  begin
    if (rst_n = '0') then
      cnt <= 7;
    elsif rising_edge(clk) then
      -------------------------------------------------------------------------
      -- compare against 0
      -------------------------------------------------------------------------
      if (cnt /= 0) then
        cnt <= cnt - 1;
      -------------------------------------------------------------------------
      -- rollover at 0 to 7
      -------------------------------------------------------------------------
      else
        cnt <= 7;
      end if;
    end if;
  end process;
end rtl;

Compare against 7:
Code:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use ieee.std_logic_unsigned.all;

entity counter is
  port (
    clk   : in std_logic;
    rst_n : in std_logic
    );
end counter;

architecture rtl of counter is
  
  signal cnt : integer range 0 to 7;
  
begin
  -----------------------------------------------------------------------------
  -- count process
  -----------------------------------------------------------------------------
  process (clk, rst_n)
  begin
    if (rst_n = '0') then
      cnt <= 0;
    elsif rising_edge(clk) then
      -------------------------------------------------------------------------
      -- compare against 7
      -------------------------------------------------------------------------
      if (cnt /= 7) then
        cnt <= cnt + 1;
      -------------------------------------------------------------------------
      -- rollover at 7 to 0
      -------------------------------------------------------------------------
      else
        cnt <= 0;
      end if;
    end if;
  end process;
end rtl;
 

It should be the same.
But you should check for yourself...synthesize it with Quartus or ISE and compare the synthesis reports and RTL viewer results.
 

Checking for zero is always the quickest in assembly, I see where you are coming from, I'd like to know! I suppose it is in the compiler's authors hands but a "JZ" (jump for zero) loop is always quicker than a "JNE (value)" because the processor subtracts the comparation value and then jumps for zero, just a clock or two extra, but ramspace wise I have no idea, until you find out!!!
Cool indeed :)
NEAL
 

Zero comparison is most likely faster in a microprocessor because they can include digital logic that automatically compares the results of operations with zero and sets a condition flag. If you want to compare something against a different value, an additional subtraction step is required.

In an FPGA or ASIC, there should be no difference because you are essentially defining the automatic comparison step yourself. In the microprocessor case, you could imagine that someone might design a processor that had a fast "jump if value equals 37" instruction if there was a good reason to optimise for such a case.

Anyway, it would be educational for you to try both and compare the resource utilisation and the resultant technology schematics!
 
VHDL also will pick up cnt <= cnt mod 8; This will work for power-of-two sized counters. Then there is no logic for the comparison. Really, the synthesizer might also notice that already.

for other sizes, you can also play some small games. eg, for a 10 element count, choose 1100 - 0011 - 0100 - 0101 - 0110 -0111 - 1000 - 1001 -1010 - 1011 as the sequence. the terminal condition only requires the 2 msb's be checked. of course it is better to avoid this level of optimization up-front, as it makes the code hard to read.
 
checking for zero can use less logic, because you can build it simply by oring all the bits of the counter.
checking for another value requires anding each bit with the same bit from the check number.
 
checking for zero can use less logic, because you can build it simply by oring all the bits of the counter.
checking for another value requires anding each bit with the same bit from the check number.

That'll depend on the technology. In an FPGA, an 8-bit reduction OR or an 8-bit AND gate (against a check number) will both just synthesise to LUTs. I confirmed this by synthesising a test file with if (|inbits == 1'b0), if (inbits == 8'd0) and if (inbits == 8'd5). The resulting technology schematic was the same - a LUT6 and a LUT3.

On an ASIC or with discrete logic gates, then certainly there will be differences though.
 
I have yet to breach the FPGA jump, am sure I will soon, its good to know somewhere that knows practical level stuff on this ,

I love the idea of
that had a fast "jump if value equals 37" instruction
... That makes me think I need summa that one day!!! :)
NEAL
 

Thanks for this.

It was something I was told when I worked on my first FPGA. Of course, the guy had an ASIC background. He was extremely sharp though and why I asked even though I haven't seen anything different in synthesis.
 
Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top