Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎05-31-2019

Do you declare Constants within the vhdl process sensitivity list of a combinatorial process ? I think no. Any comments?

Jump to solution

I am using constants as follows and have the following vhdl combinatorial process (not showing the whole code here, only relevant bits of the code).

val_in is the only signal that changes with time, so I declared this in the sensitivity list of the combinatorial process. I did not declare any constants (ie k30-k38 or B or C) within the process sensitivity list. Is this ok? Experienced few issues with PostSynthesis simulation compared to RTL simulation which currently investigating. This may not be the issue but worth asking? Do you normally not declare constants within the process sensitivity list of a combinatorial process?

constant k30 : integer := -2048;
constant k31 : integer := -1776;
constant k32 : integer := -1297;
constant k33 : integer := -751;
constant k34 : integer := -273;
constant k35 : integer := 273;
constant k36 : integer := 751;
constant k37 : integer := 1297;
constant k38 : integer := 1776;
constant k39 : integer := 2047;

type B_type is array (8 downto 0) of integer range -255 to 255;
constant B : B_type := ((V39-V38)/(k39-k38), (V38-V37)/(k38-k37), (V37-V36)/(k37-k36), (V36-V35)/(k36-k35), (V35-V34)/(k35-k34), (V34-V33)/(K34-k33), (V33-V32)/(k33-k32), (V32-V31)/(k32-k31), (V31-V30)/(k31-k30));

type C_type is array (8 downto 0) of integer range 0 to 65535;
constant C : C_type := (V38, V37, V36, V35, V34, V33, V32, V31, V30);



process (val_in)
    case val_in is
         when k30 to k31-1 =>
              a_mult <= val_in-k30;
              b_mult <= B(0);
              c_add <= C(0);
         when k31 to k32-1 =>
             a_mult <= val_in-k31;
             b_mult <= B(1);
             c_add <= C(1);
         when k32 to k33-1 =>
             a_mult <= val_in-k32;
             b_mult <= B(2);
             c_add <= C(2);
        when k33 to k34-1 =>
             a_mult <= val_in-k33;
             b_mult <= B(3);
             c_add <= C(3);
        when k34 to k35-1 =>
            a_mult <= val_in-k34;
            b_mult <= B(4);
            c_add <= C(4);
       when k35 to k36-1 =>
           a_mult <= val_in-k35;
           b_mult <= B(5);
           c_add <= C(5);
       when k36 to k37-1 =>
          a_mult <= val_in-k36;
          b_mult <= B(6);
          c_add <= C(6);
       when k37 to k38-1 =>
          a_mult <= val_in-k37; 
          b_mult <= B(7);
          c_add <= C(7);
      when others =>
         a_mult <= val_in-k38;
         b_mult <= B(8);
         c_add <= C(8);
   end case;
end process;



0 Kudos
1 Solution

Accepted Solutions
Registered: ‎10-23-2018


Your thought of 'no' is correct. Remember the purpose of the sensitivity list is to be on watch for a 'change' in the signal. As such, a constant will not change.

Hope that Helps
If so, Please mark as solution accepted. Kudos also welcomed. :-)

View solution in original post

0 Kudos
5 Replies
Registered: ‎06-25-2014

No, I never have due to it being static and therefore cannot lead to the creation of a latch.

0 Kudos
Registered: ‎10-23-2018


Your thought of 'no' is correct. Remember the purpose of the sensitivity list is to be on watch for a 'change' in the signal. As such, a constant will not change.

Hope that Helps
If so, Please mark as solution accepted. Kudos also welcomed. :-)

View solution in original post

0 Kudos
Registered: ‎01-22-2015


Officially, “The VHDL sensitivity list is a compact way of specifying the set of signals whose changes cause a process to resume(execute)”.

So, you can tailor the sensitivity list by including signals whose changes will cause the process to execute and by excluding signals whose changes will not cause the process to execute.

Triggering a process to execute does not always mean that something actually happens. For example, suppose the sensitivity list for a rising-edge-clocked process contains both the clock, clk1, and a signal, sig1, used “under the clock”.   Then, changes in sig1 will not actually cause something to happen (because things only happen on the rising-edge of clk1).  However, adding sig1 to the sensitivity list is not an error (ie. adding sig1 causes nothing to happen).

The VHDL sensitivity list is important only for simulation and is not needed by Vivado synthesis.  That is, Vivado synthesis will run correctly, regardless of what you put in the sensitivity list (although an empty list is a syntax error).  Oddly however, Vivado synthesis tries to guess what you should have put in the sensitivity list for simulation – and if it thinks you did not put something in the sensitivity list that is important for simulation then it will issue a warning.

Although the sensitivity list is very important for simulation, Vivado simulation does not try to guess what should be in the sensitivity list - nor will it throw errors/warnings about the sensitivity list.  Instead, Vivado simulation assumes you have correctly specified the sensitivity list.

Starting with VHDL-2008, you can throw caution to the wind and leave the whole sensitivity list issue up to the tools by using “process(all)”.


Tags (1)
0 Kudos
Registered: ‎05-31-2019

Yes, I agree with you 100%.

Even if you try to declare constants to the sensitivity list the tool shows compilation error.

0 Kudos
Registered: ‎08-01-2012

Trying to help with your issue, given your filter co-efficients all appear to be integers, could it be something to do with the conversion of integers to logic?

Is there some overflow happening in hardware that cannot happen in HDL (because you'd get an error). Because integers get converted to bits, could you be creating some value in the hardware that is usually out of bounds in the HDL?

I notice you constrained B type to be -255 to 255. This, for example, will get converted to a 9 bit value, but the HDL range constraint is missing the legal 9 bit value -256 (0x100) but this value would cause an HDL error. I know these are just constant here, but could it be a artifact of some other declaration?

I usually avoid using integers for arithmatic like this because of possibilities like this. Usually better to going with unsigned/signed types (and/or ufixed/sfixed from VHDL 2008) to exactly constrain your bitwidths. In VHDL, integer types are not a fixed width, and are platform specific in width (although all current implementations stick to 32 bits afaik). VHDL 2017 is mandating all integers are 64 bits.

0 Kudos