Subject: Re: re CP-003 vector/scalar logical operators
From: Lance Thompson (lancet@us.ibm.com)
Date: Mon Feb 17 2003 - 12:01:25 PST
I'm going to weigh in here...
First, our choice of implementation should not be dictated by tool bugs or
limitations.
Second, I like option 1 because the expression is explicit, unambiguous and
reasonably compact. I find that I learn the most about
the intent of the expression a and (a'range => asel).
Third, if we find we need to be even more compact AND we are going to urge
the base 1076 standard in this direction, I would choose
option 2 for the implementation. That is, for the logical operators, the
scalar side is repeated to the width of the vector side. By the way, I
implement the overloads so that the scalar can be on either side of the
expression. I would definately tie this to the base standard definition
of the logical operators. That is, if 1076 does not create vector/scalar
logical operators, 1164 should not as well. To do so would create, in
my opinion, unnecessary confusion.
Cheers,
Lance
Jim Lewis
<Jim@synthworks.c To: Std_Logic 1164 <vhdl-std-logic@eda.org>
om> cc:
Sent by: Subject: Re: re CP-003 vector/scalar logical operators
owner-vhdl-std-lo
gic@eda.org
02/17/2003 01:29
PM
I am in favor of option 2. Here are my thoughts on all.
As far as the three options go:
1) Status Quo
In this one, the RTL designer looses. The reason is
the following is not accepted by all synthesis tools:
signal ASel, BSel : std_logic ;
signal Y1, Y2, Y3, A, B : std_logic_vector(7 downto 0) ;
signal vASel, vBSel : std_logic_vector(7 downto0) ;
Y1 <= (A and (A'Range => ASel)) or (B and (B'Range => BSel)) ;
This would not be so bad if it were portable. However,
since it is not, I can't use it. So this leaves me
with either:
vASel <= (A'Range => ASel) ;
vBSel <= (B'Range => BSel) ;
Y2 <= (A and vASel) or (B and vBSel) ;
---- OR alternately ----
Y3 <= (A and std_logic_vector'(A'Range => ASel)) or
(B and std_logic_vector'(B'Range => BSel)) ;
Y3 would would not be so bad if std_logic_vector could be
abbreviated as slv instead. Note, in either case above,
there is a significant amount of typing.
3) Extend the scalar value with zeros to form a vector operand
In the above example this means to understand '1' as "00000001".
This makes sense for numeric operations.
Logic operators are intended to control something.
This interpretation makes the primary effect of these
operations on the right-most bit. From a designers
perspective, this is of limited use and potentially
confusing.
2) Replicate the scalar value to form a vector operand. This
is CP-003 as it currently stands.
In the previous example this means to understand '1' as "11111111"
Sure this would not make sense for numeric operations,
however, for logic operators, this not only makes sence,
it is useful.
signal ASel, BSel : std_logic ;
signal Y, A, B : std_logic_vector(7 downto 0) ;
signal vASel, vBSel : std_logic_vector(7 downto 0) ;
Y <= (A and ASel) or (B and BSel) ;
This is the primary use I have for this. This is
common logic to use for readback logic. Especially
considering the hardware issues with creating larger
multiplexers that are not a size = 2**n.
Without this, people tend to write the following priority
select logic:
Y <= A when ASel = '1' else B when BSel = '1' else ... ;
Ok when number of choices is 2. Not so bad when number of
choices is 3. Bad when number of choices is 4 or more.
I have also had a use with the XOR operator. Assuming I
can also use the XOR for signed consider the following
adder subtracter.
signal AddSub : std_logic ;
signal Y : signed(8 downto 0) ;
signal A, B : signed(7 downto 0) ;
-- Easy to write (and read) coding style:
Y <= (A(7) & A) + B when AddSub = '1' else (A(7) & A) - B ;
Unfortunately in synthesis, not all tools are efficient
in creating the above logic. Coding that seems to create
effective logic across different synthesis tools is the
following:
Y <= (A(7) & A) + (B xor not AddSub) + not AddSub ;
Without the vector/scalar logic operators, this becomes:
vAddSub <= (others => AddSub) ;
Y <= (A(7) & A) + (B xor not vAddSub) + not AddSub ;
One of the objectives of VHDL-200X is to make the
language more consise and user friendly. This is
one place we can help.
Note, VHDL already has an extensive set of expression
rules and overloading that it asks us to remember.
The following are just some of these
Expression Size of Y
---------- ---------------------------
Y <= A ; A'Length
Y <= A and B ; A'Length = B'Length
Y <= A > B ; Boolean
Y <= A + B ; Maximum (A'Length, B'Length)
Y <= A + 10 ; A'Length
Y <= A * B ; A'Length + B'Length
What I am asking in this proposal (and the similar one
I requested of 1076.3 for "+") is that you remember an
additional set of properties:
For logic operators,
'1' becomes "111 ...1"
'0' becomes "000 ...0"
For math operators,
'1' becomes "000 ...1"
'0' becomes "000 ...0"
Yes, using arrays with bits does add some non-orthagonality
to the operator overloading, but this is engineering and
non-orthagonality is a normal part of life.
Cheers,
Jim
Peter Ashenden wrote:
> Dear colleages,
>
> Since there was no clear consensus on CP-003, we need to decide how to
> proceed. It seems there are three options:
>
> (1) Status quo - don't provide array/scalar operators. This is the
> default option if we can't reach consensus.
>
> (2) Replicate the scalar value to form a vector operand. This is
> CP-003 as it currently stands.
>
> (3) Extend the scalar value with zeros to form a vector operand.
>
> All options are technically feasible. Arguments in favor of one or
> another have been based on perceptions of what is more common (hard for
> us to measure), easier to understand (subjective) or leads to greater
> simplification (also subjective).
>
> I propose to allow further discussion on the email list to allow members
> to argue their positions, and subsequently to call for a further vote
> among the three options. If no clear consensus arises, we'll end up
> with the default.
>
> Note that the VHDL-200x process may also consider vector/scalar logical
> operators for bit_vector and bits. If we adopt the status quo (either
> explictly or by default) and VHDL-200x comes up with a clear winner, it
> would make sense for us to subsequently follow suit.
>
> So, who would like to lead off...
>
> Cheers,
>
> PA
>
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787
Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Mon Feb 17 2003 - 12:03:06 PST