Xilinx PACKER warning bout carry

Are you sure you need > (greater than) operator here? This requires a subtraction and a carry chain, so your counter needs two carry chains and won't pack. Can you use not-equal instead?

(This also applies to < (less than) operator)

Alan Nishioka

If you use an integer subtype for count_int and check for "not(count_int - 1 < 0)" or "not (count_int + 1 > max)" then the carry out of the incrementor and decrementor can be shared with the respective comparison (and/or similarly optimized). That's also assuming max = 2**N-1 for positive integer N. Don't try this with SLV or UNSIGNED.

Andy

The fitter feels guilty about one of the LUTs it used. It's just a warning. Unless I were short on LUTs I would not spend time on it.

The code looks ok to me. You could combine the up/down input.

-- Mike Treseler

Thanks Alan,

if(up='1' and count_int/=max)then ... elsif( down='1'and count_int/=0) then ... got rid of the warnings and a considerable numbers of slices.

The only difference I can see is that my start_value had better be "in range" which is OK for my aplication.

Brad

Hi Andy, I could see where this might save a lot of hardware by using the carry flag, however, all my variables in my example were std_logic_vector inputs and the max need not be 2**N-1.

Brad Smallridge

Thanks Mike,

I am using this code to adjust a value for a menu display and I have pushbuttons controlling its value. One pb for up and another for down. Having separate up and down inputs was the first thing that occurred to me, although that isn't usually how an up/down counter is ported, is it. The enable is controlled by the "cursor" position.

Brad Smallridge Ai Visi>> What does this "PACKER" warning

I saw a reduction from 28 to 27 ALUTs with /= for limits of 1 and -1+2**16 using quartus.

No warnings and 17 registers in either case.

I might keep the original description as clearer and very slightly safer.

Interesting example.

-- Mike Treseler

Ahh. I see. How do you debounce?

Well, two inputs is two inputs and there aren't really any LS191's inside anyway :)

Sounds like fun.

-- Mike Treseler

I am not sure what is going on Mike. I cleaned up my code to post here below called count_test. Count_test has quite a few LUTs because I guess all the inputs are variables. Count_wrap wraps Count_test and holds max and start to constant values, a situation that I think would be the most likely use. Here the less/greater than packed better than not equal. Go figure. I then ran my top level again to see if my original results were wrong. They were not. The not equal version ran better. I'm thinking that the clutter in the design may effect how well the counters versions are synthesized.

------------- FFlops 4inLUts Slices Warnings count_test /= 16 65 41 15 count_wrap /= 16 32 17 0 count_wrap 16 30 16 0 top /= 415 479 451 top 414 535 493

There are three counters presently in top, more to come.

Brad Smallridge Ai Vision

library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity count_test is port( clk : in std_logic; reset : in std_logic; enable : in std_logic; up : in std_logic; down : in std_logic; start : in std_logic_vector(15 downto 0); max : in std_logic_vector(15 downto 0); count : out std_logic_vector(15 downto 0) ); end count_test;

architecture beh of count_test is

signal count_int : std_logic_vector(15 downto 0);

begin

count_int_proc:process(clk) begin if(clk'event and clk='1')then if(reset='1')then count_int up, down => down, start => "0000000000000001", max => "1000000000000101", count => count );

end beh;

The ML402 has some RC debounce but it wasn't to good. Lots of skips. I corrected it just yesterday with this code:

library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity debounce is port( clk : in std_logic; -- 100MHz reset : in std_logic; button_in : in std_logic_vector(4 downto 0); button_out : out std_logic_vector(4 downto 0)); end debounce;

architecture beh of debounce is

signal button_1 : std_logic_vector(4 downto 0); signal button_2 : std_logic_vector(4 downto 0); signal stable_count : std_logic_vector(20 downto 0);

begin

debounce_proc:process(clk) begin if(clk'event and clk='1')then button_1

...

The difference is your max limit value. My version is below.

-- Mike Treseler _________________________________________

library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all;

entity updown is generic (vec_len : natural := 16); port (clk : in std_ulogic; reset, enable, up, down : in std_ulogic; out_of_range : out std_ulogic; count : out std_logic_vector(vec_len-1 downto 0)); end updown;

architecture synth of updown is begin main : process(clk, reset) constant up_limit : natural := 2**vec_len-1; constant dn_limit : natural := 2**0; variable cnt_v : unsigned(vec_len-1 downto 0); variable out_of_range_v : std_ulogic; begin template : if reset = '1' then init_cnt : cnt_v := (others => '0'); out_of_range_v := '0'; elsif rising_edge(clk) then if enable = '1' then out_of_range_v := '0'; if up = '1' and cnt_v < up_limit then -- if up = '1' and cnt_v /= up_limit then -- saves one alut cnt_v := cnt_v + 1; elsif down = '1' and cnt_v > dn_limit then -- elsif down = '1' and cnt_v /= dn_limit then -- saves one cnt_v := cnt_v - 1; else out_of_range_v := '1'; end if; end if; end if template; count