signal controlled by multiple IFs in same process block

[syedshan]

As the toppid suggest, I have some questions related to this

First of all look at the example..

Note the signal 'b' about which I am talking !

process(clk, rst)
if(rst = '1') then
b<='0';
...

elsfi(rising_edge(clk)) then
  if(abcd) then
   b <= "001";
else b < ='0';
end if;

 if(b= "001" and xyz = "11") then
  b<= b + '1';
 elsif(...)
 b<= b - '1';
 else
 b <= (others => '0');
 end if;

end if;

1. How is the design in terms of good-design? I don't know how to rephrase it since English not my native language :grin:
2. What effects are on the signal. Since it is in the same clock domain and same process block, hence it is completely valid according to my knowledge...

Any other comment please mention.
Since my design has some situations like this hence I am concerned about final result

 

[TrickyDicky]

1. no problems. But might confuse some people.
2. Remember how signal assignments work, the final assignment is used.

So the following code:

op <= 100;

if a then
  op <= 0;
end if;

if b then
  op <= 1;
end if;

if c then 
  op <= 2;
end if;

is exactly the same as:

if c then
  op <= 2;
elsif b then
  op <= 1;
elseif a then
  op <= 0;
else
  op <= 100;
end if;

The problem with your code is that the 2nd if statement has an else clause, so it will always assign b to something from the 2nd if-then-else. So the first one is completly redundant.

- - - Updated - - -

PS. What is this b := b + '1'. Thats not standard VHDL.

 

[syedshan]

Thank you for your reply

last first

PS. What is this b := b + '1'. Thats not standard VHDL.

It is b <= b + '1'; where if b is std_logic_vector then this is standard VHDL addision using std_logic_unsigned package...!!!

What if I use HIGH IMPEDANCE in any of the case...
Will it have the highest impact. Also in most of the codes I have seen I never saw HIGH IMPEDANCE.

 

[TrickyDicky]

std_logic_unsigned is not a standard VHDL package. It was created by synopsys and finalised in 1992. Each vendor then made their own version of the library. Since then IEEE has standardised (and revised) the numeric_std package, which should be used instead of std_logic_unsigned/signed and arith. If you really insist on doing arithmatic with std_logic_vector (why would you - a std_logic_vector is just a collection of bits, not a number) then vhdl2008 has the new packages numeric_std_signed and numerc_std_unsigned for this very purpose.

And for high impedance - it would only be appropriate if b was connected to an output pin. And then, you might fall foul of the template for tri-stated outputs. YOur clocked process should drive an enable instead, with the actual pin driven with the following code (outside of a process):

op <= a when op_en = '1' else 'Z';

 

[syedshan]

You have me all confused !!! since I am using it thru out my code.
I am using ISE and hence its own synthesizer and every thing... But it works fine...!

If I use the ieee.numeric_std.all then get the following error while synthesizing

found '0' definitions of operator "+", cannot determine exact overloaded matching definition for "+"

while using ieee.std_logic_unsigned .all do not...Hence I concluded that std_logic_unsigned is valid for logic_vector where as numeric_std does not work....:-( (just did it before re-posting)

Also if you notice that the package lies inside the ieee library... ieee.std_logic_unsigned .all

(why would you - a std_logic_vector is just a collection of bits, not a number)

I use it as a counter and/or address increment etc. (BTW seeing you comment How do you to the increments....!)

It is new thing for me(ur answer) hence waiting for reply. Since it is opposite to my experience

 

[TrickyDicky]

all vendors have adopted support for std_logic_unsigned, and it has become a defacto standard (because everyone has been using it) but it is not part of the VHDL standard.
The whole point of VHDL is strong typing, so using std_logic_vector as a number goes against this idea. std_logic_vector was intended as "a collection of bits", so on first glance you have no idea if its signed/unsigned or just some random bus containing a load of control signals.

for arithmatic you are supposed to use the signed/unsigned types contained in the numeric_std library. You can also use these types on ports to save you having to do type conversions all the time.

You refer to counters an addresses - what are they addressing into? if it is an array, why not just use a constrained integer?

 

[syedshan]

Thanks again!

You refer to counters an addresses - what are they addressing into? if it is an array, why not just use a constrained integer?

It is the memory, infact the continous locations of memory. (or as you said array). (actually address for DDR3 memory using MIG)

hence it goes like this...

--positve clk..
..
..
app_add <= add_reg;

..
..
--where 
if(...) then
add_reg <= add_reg + const_increment;
..

hence I defined all vectors as the std_logic_vector primarily, even the Counters were like this, since integer would generate 32-bit and hence would take much FPGA elements and also might increase power/reduce clk speed etc... hence even counters were taken as std_logic_vecto(15 downto 0);

 

[TrickyDicky]

you can limit the size of the integer by declaring it with a range:

signal a : integer range 0 to 2**16-1;

but if you connect to a Xilinx interface, you're better off sticking with std_logic_vector.

 

[syedshan]

great... why I never thought of it for integer although I limit integer at many occasions !!!.

Thank you for your time.

- - - Updated - - -

Can I ask this...

but if you connect to a Xilinx interface, you're better off sticking with std_logic_vector.

why? Just curious