Subject: RE: re CP-003 vector/scalar logical operators
From: Joanne DeGroat (degroat@ee.eng.ohio-state.edu)
Date: Tue Feb 18 2003 - 11:21:35 PST
I also agree.
VHDL is verbose as it is and anything to lessen that verboseness (that
makes sense)
is a welcome addition.
Joanne
At 08:35 AM 2/18/2003 -0500, Jayaram Bhasker wrote:
>Jim:
>
> >> Y3 would would not be so bad if std_logic_vector could be
> >> abbreviated as slv instead.
>
>This can be fixed simply by creating an alias called slv in the 1164 package.
>I will second if you propose.
>
>Let me offer some of my other thoughts of this. What Jim is asking for is a
>perfectly reasonable functionality. I am disagreeing with his implemenation.
>
>BTW, the AT&T synthesis tools used to offer a similar functionality, but
>we used
>to offer a function called "FAN" or "FANOUT" (dont recall exactly what it
>was called now).
>Based on this, I would suggest that we define a new function FANOUT that
>simply expands a
>scaler bit into a vector operand by replicating the bit.
>
>So the example would become:
>
>Y1 <= (A and FANOUT(ASel, A'RANGE)) or (B and FANOUT(BSel, B'RANGE)) ;
>
>- bhasker
>
>------
>J. Bhasker, eSilicon Corp
>1605 N. Cedar Crest Blvd, Ste 615, Allentown, PA 18104
>jbhasker@esilicon.com, 610.439.6831, 610.770.9634(fax)
>
>
>-----Original Message-----
>From: Jim Lewis [mailto:Jim@synthworks.com]
>Sent: Monday, February 17, 2003 2:30 PM
>To: Std_Logic 1164
>Subject: Re: re CP-003 vector/scalar logical operators
>
>
>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-4787
>
>Expert 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 : Tue Feb 18 2003 - 11:21:32 PST