A suggestion for a new input interface for functions in VHDL: XOR(a0, a1, ...)

Hi Lewis,
I have a suggestion on VHDL function interface.

Here is a point: ('-' is used to simplify the 'downto')
R(63-0) <= a0*b0(63-0) + a1*b1(63-0) + ... + an*bn(63-0);

To finish the output data bus, I have to add function:
BitAndVector(a, b), then the above equation becomes:

R(63-0) <= BitAndVector(a0, b0) + BitAndVector(a1, b1) + ... +
BitAndVector(an, bn);

If we have a new interface like this:
BitAndVectorThenOR(a, b, ...);

The above function can be called like this:
R(63-0) <= BitAndVectorThenOR(a0, b0, a1, b1, a2, b2);
or
R(63-0) <= BitAndVectorThenOR(a0, b0, a1, b1, a2, b2, a3, b3, a4, b3);

The big advantages are: it makes compiler easier to do the best
optimization about the coding and VHDL programmers are easier to call
routine functions.

The compiler will check if a0, a1, ... are the same type of inputs and
if b0, b1, ... are the same type of inputs as R. There must be even
number of input signals and so on.

Another example:
Function XOR(a0, a1, ...);

The following calls are all valid:

XOR(a0, a1, a2);

XOR(a0, a1, a2, a3, a4, a5);

The compiler will check if a0, a1, ... are the same type of inputs.
Any number of input signals more than 1 are allowed and the function
will do the specified XOR operation and so on.

Here is an example of my code to generate a XOR equation from 32 input
signals:
y_xor(0) <= (x(1) xor  x(2) xor  x(3) xor  x(5) xor  x(8) xor  x(9)
xor  x(11) xor x(14) xor x(17) xor x(18) xor x(19) xor x(21) xor x(24)
xor x(25) xor x(27) xor x(30) xor x(32) xor x(36) xor x(38) xor x(39)
xor x(42) xor x(44) xor x(45) xor x(47) xor x(48) xor x(52) xor x(54)
xor x(55) xor x(58) xor x(60) xor x(61) xor x(63));

If there is a new function interface:
y_xor(0) <= XOR(x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
x(58), x(60), x(61), x(63));

Any comments are welcome.

Weng

Good Evening Mr. Tianxiang,
> Hi Lewis,
> I have a suggestion on VHDL function interface.
> 
> Here is a point: ('-' is used to simplify the 'downto')
> R(63-0) <= a0*b0(63-0) + a1*b1(63-0) + ... + an*bn(63-0);

How do your propose to handle the case where someone
wrote an expression to get the bit one to the left of
the leftmost bit:

    Y <= A(A'left - 1) ;

Golden Rule:
You can't change the language in a way that breaks code that is
currently valid.

Also note, in VHDL, "*" is multiply and "+" is add.  Is that
what you mean or are using it as a short hand for "and" and "or".


> To finish the output data bus, I have to add function:
> BitAndVector(a, b), then the above equation becomes:
> 
> R(63-0) <= BitAndVector(a0, b0) + BitAndVector(a1, b1) + ... +
> BitAndVector(an, bn);
> 
> If we have a new interface like this:
> BitAndVectorThenOR(a, b, ...);
> 
> The above function can be called like this:
> R(63-0) <= BitAndVectorThenOR(a0, b0, a1, b1, a2, b2);
> or
> R(63-0) <= BitAndVectorThenOR(a0, b0, a1, b1, a2, b2, a3, b3, a4, b3);
> 

Is this the same AND-OR logic we talked about when you wrote
your conference paper?  The overloaded "and" function I showed
you then has been integrated into the language with Accellera 3.0 draft
of VHDL.  For the time being, you can use the following package:



library ieee ;
use ieee.std_logic_1164.all ;

package TempPkg is

   ------------------------------------------------------------
   function "and" (
     l : std_logic_vector ;
     r : std_logic
   ) return std_logic_vector ;

   ------------------------------------------------------------
   function "and" (
     l : std_logic ;
     r : std_logic_vector
   ) return std_logic_vector ;

end TempPkg ;

-- ==============================================================
package body TempPkg is

   ------------------------------------------------------------
   function "and" (
     l : std_logic_vector ;
     r : std_logic
   ) return std_logic_vector is
     variable result : std_logic_vector(l'range) ;
   begin
     for i in  l'range loop
       result(i) := l(i) and r ;
     end loop ;
     return result ;
   end ; -- "and"

   ------------------------------------------------------------
   function "and" (
     l : std_logic ;
     r : std_logic_vector
   ) return std_logic_vector is
     variable result : std_logic_vector(r'range) ;
   begin
     for i in  r'range loop
       result(i) := r(i) and l ;
     end loop ;
     return result ;
   end ; -- "and"
end TempPkg ;


With this package, you can write your equations as:
   R(63 downto 0) <= (a0 and b0) or (a1 and b1) or ... or
                     (an and bn);

Hey, I even saved you enough typing that you don't have to be
overly concerned about having to use "downto".


Alternately you can use the following:
     signal Y, A, B : std_logic_vector(7 downto 0) ;

     Y <=
         (A and (A'range => ASel)) or
         (B and (B'range => BSel)) ;


Note I have portability concerns with the above code as at one point in
time Synopsys did not support it.  If they still do not support it,
and you use their tools, report it as a bug (if you need help
convincing it is a bug, drop me an email).


> Another example:
> Function XOR(a0, a1, ...);
> 
> The following calls are all valid:
> 
> XOR(a0, a1, a2);
> 
> XOR(a0, a1, a2, a3, a4, a5);
> 
> The compiler will check if a0, a1, ... are the same type of inputs.
> Any number of input signals more than 1 are allowed and the function
> will do the specified XOR operation and so on.
> 
> Here is an example of my code to generate a XOR equation from 32 input
> signals:
> y_xor(0) <= (x(1) xor  x(2) xor  x(3) xor  x(5) xor  x(8) xor  x(9)
> xor  x(11) xor x(14) xor x(17) xor x(18) xor x(19) xor x(21) xor x(24)
> xor x(25) xor x(27) xor x(30) xor x(32) xor x(36) xor x(38) xor x(39)
> xor x(42) xor x(44) xor x(45) xor x(47) xor x(48) xor x(52) xor x(54)
> xor x(55) xor x(58) xor x(60) xor x(61) xor x(63));
> 
> If there is a new function interface:
> y_xor(0) <= XOR(x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
> x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
> x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
> x(58), x(60), x(61), x(63));

Write yourself a function that accepts std_logic_vector as an input and
add an extra set of parentheses to the call:
   y_xor(0) <= XOR(( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
                     x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
                     x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
                     x(58), x(60), x(61), x(63) ));

Now the function sees one input argument that is an array aggregate :).

Good Luck to You,
Jim Lewis
SynthWorks VHDL Training

I think Synopsys has problems with not knowing the type of the
expression (A'range => ASel). Other vendors seem to be able to figure
it out, but I've never tracked down whether it is legal per LRM.

Weng, would you rather have to type all that garbage out, or just
write a function:

...
temp := '0';
for i in x'range loop
  temp := temp xor x(i);
end loop;
return temp;

Andy

On Mar 26, 8:54 pm, Jim Lewis <j...@synthworks.com> wrote:
> Good Evening Mr. Tianxiang,
>
> > Hi Lewis,
> > I have a suggestion on VHDL function interface.
>
> > Here is a point: ('-' is used to simplify the 'downto')
> > R(63-0) <= a0*b0(63-0) + a1*b1(63-0) + ... + an*bn(63-0);
>
> How do your propose to handle the case where someone
> wrote an expression to get the bit one to the left of
> the leftmost bit:
>
>     Y <= A(A'left - 1) ;
>
> Golden Rule:
> You can't change the language in a way that breaks code that is
> currently valid.
>
> Also note, in VHDL, "*" is multiply and "+" is add.  Is that
> what you mean or are using it as a short hand for "and" and "or".
>
> > To finish the output data bus, I have to add function:
> > BitAndVector(a, b), then the above equation becomes:
>
> > R(63-0) <= BitAndVector(a0, b0) + BitAndVector(a1, b1) + ... +
> > BitAndVector(an, bn);
>
> > If we have a new interface like this:
> > BitAndVectorThenOR(a, b, ...);
>
> > The above function can be called like this:
> > R(63-0) <= BitAndVectorThenOR(a0, b0, a1, b1, a2, b2);
> > or
> > R(63-0) <= BitAndVectorThenOR(a0, b0, a1, b1, a2, b2, a3, b3, a4, b3);
>
> Is this the same AND-OR logic we talked about when you wrote
> your conference paper?  The overloaded "and" function I showed
> you then has been integrated into the language with Accellera 3.0 draft
> of VHDL.  For the time being, you can use the following package:
>
> library ieee ;
> use ieee.std_logic_1164.all ;
>
> package TempPkg is
>
>    ------------------------------------------------------------
>    function "and" (
>      l : std_logic_vector ;
>      r : std_logic
>    ) return std_logic_vector ;
>
>    ------------------------------------------------------------
>    function "and" (
>      l : std_logic ;
>      r : std_logic_vector
>    ) return std_logic_vector ;
>
> end TempPkg ;
>
> -- ==============================================================
> package body TempPkg is
>
>    ------------------------------------------------------------
>    function "and" (
>      l : std_logic_vector ;
>      r : std_logic
>    ) return std_logic_vector is
>      variable result : std_logic_vector(l'range) ;
>    begin
>      for i in  l'range loop
>        result(i) := l(i) and r ;
>      end loop ;
>      return result ;
>    end ; -- "and"
>
>    ------------------------------------------------------------
>    function "and" (
>      l : std_logic ;
>      r : std_logic_vector
>    ) return std_logic_vector is
>      variable result : std_logic_vector(r'range) ;
>    begin
>      for i in  r'range loop
>        result(i) := r(i) and l ;
>      end loop ;
>      return result ;
>    end ; -- "and"
> end TempPkg ;
>
> With this package, you can write your equations as:
>    R(63 downto 0) <= (a0 and b0) or (a1 and b1) or ... or
>                      (an and bn);
>
> Hey, I even saved you enough typing that you don't have to be
> overly concerned about having to use "downto".
>
> Alternately you can use the following:
>      signal Y, A, B : std_logic_vector(7 downto 0) ;
>
>      Y <=
>          (A and (A'range => ASel)) or
>          (B and (B'range => BSel)) ;
>
> Note I have portability concerns with the above code as at one point in
> time Synopsys did not support it.  If they still do not support it,
> and you use their tools, report it as a bug (if you need help
> convincing it is a bug, drop me an email).
>
>
>
> > Another example:
> > Function XOR(a0, a1, ...);
>
> > The following calls are all valid:
>
> > XOR(a0, a1, a2);
>
> > XOR(a0, a1, a2, a3, a4, a5);
>
> > The compiler will check if a0, a1, ... are the same type of inputs.
> > Any number of input signals more than 1 are allowed and the function
> > will do the specified XOR operation and so on.
>
> > Here is an example of my code to generate a XOR equation from 32 input
> > signals:
> > y_xor(0) <= (x(1) xor  x(2) xor  x(3) xor  x(5) xor  x(8) xor  x(9)
> > xor  x(11) xor x(14) xor x(17) xor x(18) xor x(19) xor x(21) xor x(24)
> > xor x(25) xor x(27) xor x(30) xor x(32) xor x(36) xor x(38) xor x(39)
> > xor x(42) xor x(44) xor x(45) xor x(47) xor x(48) xor x(52) xor x(54)
> > xor x(55) xor x(58) xor x(60) xor x(61) xor x(63));
>
> > If there is a new function interface:
> > y_xor(0) <= XOR(x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
> > x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
> > x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
> > x(58), x(60), x(61), x(63));
>
> Write yourself a function that accepts std_logic_vector as an input and
> add an extra set of parentheses to the call:
>    y_xor(0) <= XOR(( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
>                      x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
>                      x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
>                      x(58), x(60), x(61), x(63) ));
>
> Now the function sees one input argument that is an array aggregate :).
>
> Good Luck to You,
> Jim Lewis
> SynthWorks VHDL Training

Andy
> I think Synopsys has problems with not knowing the type of the
> expression (A'range => ASel). Other vendors seem to be able to figure
> it out, but I've never tracked down whether it is legal per LRM.

Formally when you run into a situation where one tool accepts code
and another does not, you enter a bug (interpretation) request to
VHDL's Issues Screening and Analysis Committee (ISAC) via:
    http://www.eda-stds.org/vasg/#Enhancements

In this case select:  Report a BUG on an IEEE VHDL revision

Then ISAC will issue a response.  The following is the ISAC
resolution to the above issue (recently ISAC Approved):
     http://www.eda.org/isac/IRs-VHDL-2002/IR2097.txt

> Weng, would you rather have to type all that garbage out, or just
> write a function:
> 
> ...
> temp := '0';
> for i in x'range loop
>   temp := temp xor x(i);
> end loop;
> return temp;

Note that he is calculating several parity terms (such
as in SECDED logic) and each incorporates different, not necessarily
contiguous pieces of the array.  I also note that in my final equation,
I had ment to give the function call a different name than XOR as you
would not want to use the operator name in this case:

   y_xor(0) <= XOR_Reduce(( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
                     x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
                     x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
                     x(58), x(60), x(61), x(63) ));

You can either code your own XOR_reduce or use the one from synopsys'
package, std_logic_misc (IIRC).


Cheers,
Jim

On Mar 27, 8:48 am, Jim Lewis <j...@synthworks.com> wrote:
> Andy
>
> > I think Synopsys has problems with not knowing the type of the
> > expression (A'range => ASel). Other vendors seem to be able to figure
> > it out, but I've never tracked down whether it is legal per LRM.
>
> Formally when you run into a situation where one tool accepts code
> and another does not, you enter a bug (interpretation) request to
> VHDL's Issues Screening and Analysis Committee (ISAC) via:
>    http://www.eda-stds.org/vasg/#Enhancements
>
> In this case select:  Report a BUG on an IEEE VHDL revision
>
> Then ISAC will issue a response.  The following is the ISAC
> resolution to the above issue (recently ISAC Approved):
>      http://www.eda.org/isac/IRs-VHDL-2002/IR2097.txt
>
> > Weng, would you rather have to type all that garbage out, or just
> > write a function:
>
> > ...
> > temp := '0';
> > for i in x'range loop
> >   temp := temp xor x(i);
> > end loop;
> > return temp;
>
> Note that he is calculating several parity terms (such
> as in SECDED logic) and each incorporates different, not necessarily
> contiguous pieces of the array.  I also note that in my final equation,
> I had ment to give the function call a different name than XOR as you
> would not want to use the operator name in this case:
>
>    y_xor(0) <= XOR_Reduce(( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
>                      x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
>                      x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
>                      x(58), x(60), x(61), x(63) ));
>
> You can either code your own XOR_reduce or use the one from synopsys'
> package, std_logic_misc (IIRC).
>
> Cheers,
> Jim

Hi Jim,
Thank you for your response.

> Also note, in VHDL, "*" is multiply and "+" is add.  Is that
> what you mean or are using it as a short hand for "and" and "or".

Yes.

> Y <= A(A'left - 1) ;

OK, XOR_Recude(A'left - 1, A'left - 2);

It doesn't change any original VHDL definitions or rules, but only add
a '...' as a unlimited input signal that means user can add any number
of input signals as required by the function to do the same operation
as designed with variable number of input signals.

Which is better:
Introduction:
AndOR(a0, b0, ...);

With this package, you can write your equations as:
   R(63 downto 0) <= (a0 and b0) or (a1 and b1) or ... or
                     (an and bn);

In my presentation, it will become:

R(63 downto 0) <= AndOR(a0, b0, a1, b1, a2, b3, ..., an, bn);

The best thing is the AndOR function will be optimized by compiler
companies, because its definition is clear to do AND, then OR
operations on pair of input signals one pair after another.

> Write yourself a function that accepts std_logic_vector as an input and
> add an extra set of parentheses to the call:
>    y_xor(0) <= XOR(( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
>           x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
>           x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
>           x(58), x(60), x(61), x(63) ));

What I want to introduce a new type of input signal '...' is not to
write any type of this function any more, no matter how many signals
are there, a library function can be called. It should be much better
than several functions XOR(a0, b0) that are included in some library.

If a compiler company provides a XOR_Reduce(a0, a1, ...) in its
library or VHDL standard library includes such functions, VHDL users
would never have to write it again and again. Because in this type of
function XOR_Reduce(a0, a1, ...), the number of input signals can be
varied without concerning to write an 8 input signals, 9 input signals
or others. The function XOR_Reduce(a0, a1, ...) is applied to all XOR
operators with any number of input signals. In current situations, for
function XOR(a0, a1), it has only 2 input signals, far leg behind the
real need such that I don't think XOR(a0, a1) is useful, even though
XOR operators are used widely in any projects.

Weng

Mr Tianxiang,
Your first mission needs to be to read and study a good
VHDL syntax book, such as Peter Ashenden's
"Designer's Guide to VHDL", on subprograms and in particular
subprograms with unconstrained arrays.

When all the elements are the same, such as std_logic,
then a subprogram that accepts an unconstrained std_logic_vector
can be used - although you need an extra set of parentheses.
As shown in my example that I posted previously:

>>    y_xor(0) <= XOR_Reduce(( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
>>                      x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
>>                      x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
>>                      x(58), x(60), x(61), x(63) ));



Please also read my paper on Accellera VHDL standard 3.0.  Read up
on the unary usage of operators such as XOR.
Unfortunately due to overloading it will need a type qualifier, but
you will be able to use it as:

 >>    y_xor(0) <= XOR std_logic_vector'( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
 >>                      x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
 >>                      x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
 >>                      x(58), x(60), x(61), x(63) );


> AndOR(a0, b0, ...);
To use a similar technique, the repeated arguments would need
to be part of a record and then you would need an array of the
record.   The call syntax would be:

AndOr ( ((a0, b0), (a1, b1), (a2, b2), ... ) ) ;

Personally I would not go to this trouble as I expect that
synthesis vendors do very well on And-Or type logic.

> If a compiler company provides a XOR_Reduce(a0, a1, ...) 
Did you look for the package I suggested existed (std_logic_misc (IIRC))?

Don't get too attached to it as like I noted, XOR will be able
to handle this functionality in the future.

Cheers,
Jim Lewis
SynthWorks VHDL Training

"Jim Lewis" <jim@synthworks.com> wrote in message 
news:130it10cdc7ocbf@corp.supernews.com...
> Mr Tianxiang,
Mr. Jim,
I wonder, should it be Mr. Weng? Perhaps, given his manifest interest in 
languages, the Mr. OP can instruct us on the correct etiquette?
Cheers, Mr. Syms.
http://en.wikipedia.org/wiki/Chinese_name

"Jim Lewis" <jim@synthworks.com> wrote in message 
news:130it10cdc7ocbf@corp.supernews.com...

> Please also read my paper on Accellera VHDL standard 3.0.  Read up
> on the unary usage of operators such as XOR.
> Unfortunately due to overloading it will need a type qualifier, but
> you will be able to use it as:
>
> >>    y_xor(0) <= XOR std_logic_vector'( x(1), x(2), x(3), x(5), x(8), 
> >> x(9), x(11), x(14),
> >>                      x(17), x(18), x(19), x(21), x(24), x(25), x(27), 
> >> x(30), x(32), x(36),
> >>                      x(38), x(39), x(42), x(44), x(45), x(47), x(48), 
> >> x(52), x(54), x(55),
> >>                      x(58), x(60), x(61), x(63) );

Or I think I'd prefer:

  y_xor(0) <= xor (x and X"B4D1B4D14B2E4B2E");

Because it's much less typing.

      -Ben- 

Weng,

I applaud your serious desire to improve the vhdl language, as
evidenced by your many posts on suggested enhancements.

However, improving it does not always mean "expanding it so that it
will do this..."

The strength of a good language lies in its consistency and
simplicity, and ability to have user added functionality.

VHDL already has the capability to do what you want, just not with the
syntax the way you want it. The problem is, VHDL already has a
consistent syntactical footprint, one that your suggestion would make
significantly less consistent if added.

Perhaps the strongest capability of VHDL is its ability to handle
unconstrained array type parameters, so that most functions need only
be written once (whether as part of a standard package, or by the
user), but can operate on any size array. Jim and Ben have already
shown efficient ways to implement the functionality you want, within
the existing language, with no real disadvantage over what you
suggested (Ben's solution is actually far superior!), other than it
doesn't "feel" the same as what you asked for. However, what they
suggested has a common feel that most practiced users of vhdl are
already comfortable with.

Andy

On Mar 27, 1:48 pm, "Weng Tianxiang" <wtx...@gmail.com> wrote:
> On Mar 27, 8:48 am, Jim Lewis <j...@synthworks.com> wrote:
>
>
>
> > Andy
>
> > > I think Synopsys has problems with not knowing the type of the
> > > expression (A'range => ASel). Other vendors seem to be able to figure
> > > it out, but I've never tracked down whether it is legal per LRM.
>
> > Formally when you run into a situation where one tool accepts code
> > and another does not, you enter a bug (interpretation) request to
> > VHDL's Issues Screening and Analysis Committee (ISAC) via:
> >    http://www.eda-stds.org/vasg/#Enhancements
>
> > In this case select:  Report a BUG on an IEEE VHDL revision
>
> > Then ISAC will issue a response.  The following is the ISAC
> > resolution to the above issue (recently ISAC Approved):
> >      http://www.eda.org/isac/IRs-VHDL-2002/IR2097.txt
>
> > > Weng, would you rather have to type all that garbage out, or just
> > > write a function:
>
> > > ...
> > > temp := '0';
> > > for i in x'range loop
> > >   temp := temp xor x(i);
> > > end loop;
> > > return temp;
>
> > Note that he is calculating several parity terms (such
> > as in SECDED logic) and each incorporates different, not necessarily
> > contiguous pieces of the array.  I also note that in my final equation,
> > I had ment to give the function call a different name than XOR as you
> > would not want to use the operator name in this case:
>
> >    y_xor(0) <= XOR_Reduce(( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
> >                      x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
> >                      x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
> >                      x(58), x(60), x(61), x(63) ));
>
> > You can either code your own XOR_reduce or use the one from synopsys'
> > package, std_logic_misc (IIRC).
>
> > Cheers,
> > Jim
>
> Hi Jim,
> Thank you for your response.
>
> > Also note, in VHDL, "*" is multiply and "+" is add.  Is that
> > what you mean or are using it as a short hand for "and" and "or".
>
> Yes.
>
> > Y <= A(A'left - 1) ;
>
> OK, XOR_Recude(A'left - 1, A'left - 2);
>
> It doesn't change any original VHDL definitions or rules, but only add
> a '...' as a unlimited input signal that means user can add any number
> of input signals as required by the function to do the same operation
> as designed with variable number of input signals.
>
> Which is better:
> Introduction:
> AndOR(a0, b0, ...);
>
> With this package, you can write your equations as:
>    R(63 downto 0) <= (a0 and b0) or (a1 and b1) or ... or
>                      (an and bn);
>
> In my presentation, it will become:
>
> R(63 downto 0) <= AndOR(a0, b0, a1, b1, a2, b3, ..., an, bn);
>
> The best thing is the AndOR function will be optimized by compiler
> companies, because its definition is clear to do AND, then OR
> operations on pair of input signals one pair after another.
>
> > Write yourself a function that accepts std_logic_vector as an input and
> > add an extra set of parentheses to the call:
> >    y_xor(0) <= XOR(( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
> >           x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
> >           x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
> >           x(58), x(60), x(61), x(63) ));
>
> What I want to introduce a new type of input signal '...' is not to
> write any type of this function any more, no matter how many signals
> are there, a library function can be called. It should be much better
> than several functions XOR(a0, b0) that are included in some library.
>
> If a compiler company provides a XOR_Reduce(a0, a1, ...) in its
> library or VHDL standard library includes such functions, VHDL users
> would never have to write it again and again. Because in this type of
> function XOR_Reduce(a0, a1, ...), the number of input signals can be
> varied without concerning to write an 8 input signals, 9 input signals
> or others. The function XOR_Reduce(a0, a1, ...) is applied to all XOR
> operators with any number of input signals. In current situations, for
> function XOR(a0, a1), it has only 2 input signals, far leg behind the
> real need such that I don't think XOR(a0, a1) is useful, even though
> XOR operators are used widely in any projects.
>
> Weng

On Mar 28, 4:56 am, "Andy" <jonesa...@comcast.net> wrote:
> Weng,
>
> I applaud your serious desire to improve the vhdl language, as
> evidenced by your many posts on suggested enhancements.
>
> However, improving it does not always mean "expanding it so that it
> will do this..."
>
> The strength of a good language lies in its consistency and
> simplicity, and ability to have user added functionality.
>
> VHDL already has the capability to do what you want, just not with the
> syntax the way you want it. The problem is, VHDL already has a
> consistent syntactical footprint, one that your suggestion would make
> significantly less consistent if added.
>
> Perhaps the strongest capability of VHDL is its ability to handle
> unconstrained array type parameters, so that most functions need only
> be written once (whether as part of a standard package, or by the
> user), but can operate on any size array. Jim and Ben have already
> shown efficient ways to implement the functionality you want, within
> the existing language, with no real disadvantage over what you
> suggested (Ben's solution is actually far superior!), other than it
> doesn't "feel" the same as what you asked for. However, what they
> suggested has a common feel that most practiced users of vhdl are
> already comfortable with.
>
> Andy
>
> On Mar 27, 1:48 pm, "Weng Tianxiang" <wtx...@gmail.com> wrote:
>
>
>
> > On Mar 27, 8:48 am, Jim Lewis <j...@synthworks.com> wrote:
>
> > > Andy
>
> > > > I think Synopsys has problems with not knowing the type of the
> > > > expression (A'range => ASel). Other vendors seem to be able to figure
> > > > it out, but I've never tracked down whether it is legal per LRM.
>
> > > Formally when you run into a situation where one tool accepts code
> > > and another does not, you enter a bug (interpretation) request to
> > > VHDL's Issues Screening and Analysis Committee (ISAC) via:
> > >    http://www.eda-stds.org/vasg/#Enhancements
>
> > > In this case select:  Report a BUG on an IEEE VHDL revision
>
> > > Then ISAC will issue a response.  The following is the ISAC
> > > resolution to the above issue (recently ISAC Approved):
> > >      http://www.eda.org/isac/IRs-VHDL-2002/IR2097.txt
>
> > > > Weng, would you rather have to type all that garbage out, or just
> > > > write a function:
>
> > > > ...
> > > > temp := '0';
> > > > for i in x'range loop
> > > >   temp := temp xor x(i);
> > > > end loop;
> > > > return temp;
>
> > > Note that he is calculating several parity terms (such
> > > as in SECDED logic) and each incorporates different, not necessarily
> > > contiguous pieces of the array.  I also note that in my final equation,
> > > I had ment to give the function call a different name than XOR as you
> > > would not want to use the operator name in this case:
>
> > >    y_xor(0) <= XOR_Reduce(( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
> > >                      x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
> > >                      x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
> > >                      x(58), x(60), x(61), x(63) ));
>
> > > You can either code your own XOR_reduce or use the one from synopsys'
> > > package, std_logic_misc (IIRC).
>
> > > Cheers,
> > > Jim
>
> > Hi Jim,
> > Thank you for your response.
>
> > > Also note, in VHDL, "*" is multiply and "+" is add.  Is that
> > > what you mean or are using it as a short hand for "and" and "or".
>
> > Yes.
>
> > > Y <= A(A'left - 1) ;
>
> > OK, XOR_Recude(A'left - 1, A'left - 2);
>
> > It doesn't change any original VHDL definitions or rules, but only add
> > a '...' as a unlimited input signal that means user can add any number
> > of input signals as required by the function to do the same operation
> > as designed with variable number of input signals.
>
> > Which is better:
> > Introduction:
> > AndOR(a0, b0, ...);
>
> > With this package, you can write your equations as:
> >    R(63 downto 0) <= (a0 and b0) or (a1 and b1) or ... or
> >                      (an and bn);
>
> > In my presentation, it will become:
>
> > R(63 downto 0) <= AndOR(a0, b0, a1, b1, a2, b3, ..., an, bn);
>
> > The best thing is the AndOR function will be optimized by compiler
> > companies, because its definition is clear to do AND, then OR
> > operations on pair of input signals one pair after another.
>
> > > Write yourself a function that accepts std_logic_vector as an input and
> > > add an extra set of parentheses to the call:
> > >    y_xor(0) <= XOR(( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
> > >           x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
> > >           x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
> > >           x(58), x(60), x(61), x(63) ));
>
> > What I want to introduce a new type of input signal '...' is not to
> > write any type of this function any more, no matter how many signals
> > are there, a library function can be called. It should be much better
> > than several functions XOR(a0, b0) that are included in some library.
>
> > If a compiler company provides a XOR_Reduce(a0, a1, ...) in its
> > library or VHDL standard library includes such functions, VHDL users
> > would never have to write it again and again. Because in this type of
> > function XOR_Reduce(a0, a1, ...), the number of input signals can be
> > varied without concerning to write an 8 input signals, 9 input signals
> > or others. The function XOR_Reduce(a0, a1, ...) is applied to all XOR
> > operators with any number of input signals. In current situations, for
> > function XOR(a0, a1), it has only 2 input signals, far leg behind the
> > real need such that I don't think XOR(a0, a1) is useful, even though
> > XOR operators are used widely in any projects.
>
> > Weng- Hide quoted text -
>
> - Show quoted text -

Hi Jim, Andy,
Thank you for your inputs.

Weng