Subject: Re: JIM_P2, Proposal: Logic Operators Array with Bit
From: Rob Anderson (rob@reawebtech.com)
Date: Mon Sep 30 2002 - 19:12:46 PDT
Jim,
I agree with the utility, the typecasts are a nuisance. I'd
go along if we are able to get rid of them more generally
here and we do not end up needing more qualifiers.
The question is: how do we decide what
belongs with numeric_std and what belongs with std_logic_1164.
In other languages the operators would be inherited, maybe
the inheritance idea makes sense here.
Assume A and B are type signed, here was my question, which is
from the conservative VHDL-centric side:
>>Also, if you replace A and B with integers the "OR" and "AND"
>>operations make no sense. I think they should be related back
>>somehow.
>>
>>Is this something you really want to do with std_logic_vector
>>types, using a typecast?
>>
On the other hand it makes sense to do a lot to avoid the
typecasts here.
Are there other operators we are missing, to alleviate typecasts
generally?
Would it make sense to create a separate package with all these
"inherited" functions? (numeric_1164.pkg ?)
--Rob
Jim Lewis wrote:
> Rob,
> Yes, there is a trivial work around for the example given,
> but it is not the same. It implements a multiplexer rather
> than AND-OR logic. In addition, it does not propagate X's.
>
> Now consider if you have more than one select signal:
>
> Y <=
> (A and ASel) or (B and BSel) or
> (C and CSel) or (D and DSel) ;
>
> AND-OR logic is fundamental to hardware design. It is
> currently difficult to code without these functions.
>
> As you start to complicate it more, it gets more difficult to
> code. What happens when you have a register with four load
> enables with separate data signals:
>
> FourLoadReg : process
> begin
> wait until Clk = '1' ;
> if (ASel or BSel or CSel or DSel) = '1' then
>
> LoadReg <=
> (A and ASel) or (B and BSel) or
> (C and CSel) or (D and DSel) ;
> end if ;
> end process ;
>
>
> AND-OR logic is better for multi-level multiplexers as
> the lowest levels resolve to AND-OR logic and the upper
> levels resolve to OR gates. Resolving to OR gates allows
> the upper level to be restructured in a simple manner
> based on layout.
>
> Note, this proposal was already accepted by std_logic_1164.
>
> Cheers,
> Jim
>
> Rob Anderson wrote:
>
>>Hi Jim,
>>
>>I'm not totally convinced on this, I usually code
>>
>>Y<= A when (ysel='1') else B;
>>
>>Why have both ASEL and BSEL when the target is Y? I
>>have not seen that before.
>>
>>Also, if you replace A and B with integers the "OR" and "AND"
>>operations make no sense. I think they should be related back
>>somehow.
>>
>>Is this something you really want to do with std_logic_vector
>>types, using a typecast?
>>
>>BTW, what is the status of 1164?
>>
>>--Rob
>>
>>Jim Lewis wrote:
>>
>>
>>>Alex and group,
>>>
>>><JIM_P2>
>>>I would like to propose that the following 24 functions
>>>be added to numeric_std and corresponding functions
>>>according to 1076.3 conventions (same result for operands
>>>containing only '0' and '1' values) to numeric_bit. Std_ulogic
>>>will be replaced by bit for numeric_bit.
>>>
>>>For odd numbered functions below, the std_ulogic type operand
>>>is interpreted as having the value, (R'range => L). Likewise,
>>>for the even numbered functions below, the std_ulogic type
>>>operand is interpreted as having the value, (L'Range => R).
>>>
>>>-- L.15
>>> function "and" (L: STD_ULOGIC; R: UNSIGNED) return UNSIGNED;
>>>
>>>-- L.16
>>> function "and" (L: UNSIGNED; R: STD_ULOGIC) return UNSIGNED;
>>>
>>>-- L.17
>>> function "or" (L: STD_ULOGIC; R: UNSIGNED) return UNSIGNED;
>>>
>>>-- L.18
>>> function "or" (L: UNSIGNED; R: STD_ULOGIC) return UNSIGNED;
>>>
>>>-- L.19
>>> function "nand" (L: STD_ULOGIC; R: UNSIGNED) return UNSIGNED;
>>>
>>>-- L.20
>>> function "nand" (L: UNSIGNED; R: STD_ULOGIC) return UNSIGNED;
>>>
>>>-- L.21
>>> function "nor" (L: STD_ULOGIC; R: UNSIGNED) return UNSIGNED;
>>>
>>>-- L.22
>>> function "nor" (L: UNSIGNED; R: STD_ULOGIC) return UNSIGNED;
>>>
>>>-- L.23
>>> function "xor" (L: STD_ULOGIC; R: UNSIGNED) return NUSIGNED;
>>>
>>>-- L.24
>>> function "xor" (L: UNSIGNED; R: STD_ULOGIC) return UNSIGNED;
>>>
>>>-- L.25
>>> function "xnor" (L: STD_ULOGIC; R: UNSIGNED) return UNSIGNED;
>>>
>>>-- L.26
>>> function "xnor" (L: UNSIGNED; R: STD_ULOGIC) return UNSIGNED;
>>>
>>>
>>>-- L.27
>>> function "and" (L: STD_ULOGIC; R: SIGNED) return SIGNED;
>>>
>>>-- L.28
>>> function "and" (L: SIGNED; R: STD_ULOGIC) return SIGNED;
>>>
>>>-- L.29
>>> function "or" (L: STD_ULOGIC; R: SIGNED) return SIGNED;
>>>
>>>-- L.30
>>> function "or" (L: SIGNED; R: STD_ULOGIC) return SIGNED;
>>>
>>>-- L.31
>>> function "nand" (L: STD_ULOGIC; R: SIGNED) return SIGNED;
>>>
>>>-- L.32
>>> function "nand" (L: SIGNED; R: STD_ULOGIC) return SIGNED;
>>>
>>>-- L.33
>>> function "nor" (L: STD_ULOGIC; R: SIGNED) return SIGNED;
>>>
>>>-- L.34
>>> function "nor" (L: SIGNED; R: STD_ULOGIC) return SIGNED;
>>>
>>>-- L.35
>>> function "xor" (L: STD_ULOGIC; R: SIGNED) return SIGNED;
>>>
>>>-- L.36
>>> function "xor" (L: SIGNED; R: STD_ULOGIC) return SIGNED;
>>>
>>>-- L.37
>>> function "xnor" (L: STD_ULOGIC; R: SIGNED) return SIGNED;
>>>
>>>-- L.38
>>> function "xnor" (L: SIGNED; R: STD_ULOGIC) return SIGNED;
>>>
>>>
>>></JIM_P2>
>>>
>>>Comments:
>>>The driving factor for this request is the existence of a select
>>>signal (output of a decoder) that needs to AND-OR logic together.
>>>With the addition funcitons the code is a follows:
>>>
>>> signal ASel, BSel : std_ulogic ;
>>> signal Y, A, B : unsigned(7 downto 0) ;
>>> . . .
>>>
>>> Y <= (A and ASel) or (B and BSel) ;
>>>
>>>
>>>Without these type of functions, the code is more cumbersome:
>>>
>>> signal vASel, vBSel : unsigned(7 downto 0) ;
>>> vASel <= (others => ASel) ;
>>> vBSel <= (others => BSel) ;
>>> Y <= (A and vASel) or (B and vBSel) ;
>>>
>>>Or even better would be the following, but some tools seem to think
>>>it is ok and others don't:
>>> Y <= (A and (A'range => ASel)) or (B and (B'range => BSel)) ;
>>>
>>>Unfortunately most do not know the trick, give up with the first
>>>attempt and do the following:
>>> Y <=
>>> A when ASel = '1' else
>>> B when BSel = '1' else
>>> (others => '0') ;
>>>
>>>This results in priority select logic. For terms of 3 or more,
>>>priority select logic is inferior (Quality of Results) to
>>>Multiplexers or AND-Or logic.
>>>
>>>Realistically I don't think I need anything outside of "and", but for
>>>consistency, I included them all. Implementation of "and" can be
>>>as follows:
>>>
>>> FUNCTION "and" ( l : unsigned; r : std_ulogic )
>>> RETURN unsigned IS
>>> VARIABLE result : unsigned ( l'Range );
>>> BEGIN
>>> FOR i IN result'RANGE LOOP
>>> result(i) := and_table (l(i), r);
>>> END LOOP;
>>> RETURN result;
>>> END "and";
>>>
>>>
>>>
>>>
>>>
>
This archive was generated by hypermail 2b28 : Mon Sep 30 2002 - 19:11:58 PDT