A suggestion for a new input interface for functions in VHDL

[Weng 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);

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

 

[Jim Lewis]

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.

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

 

[Jim Lewis]

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

 

[Weng Tianxiang]

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

 

[Jim Lewis]

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

 

[Ben Jones]

"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-

 

[Andy]

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

 

[Weng Tianxiang]

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

 

[Jim Lewis]

Ben

"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.

I like it. Just if it was more readable.

Jim

 

[Weng Tianxiang]

On Mar 28, 12:46 pm, Jim Lewis <j...@synthworks.com> wrote:

Ben





"Jim Lewis" <j...@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.

I like it. Just if it was more readable.

Jim- Hide quoted text -

- Show quoted text -

Hi Lewis,
Can you tell me which Xilinx ISE version starts to support the new
definition you described in the form of XOR((...))?

Thank you.

Weng

 

[Daniel S.]

Weng Tianxiang wrote:

Or I think I'd prefer:
y_xor(0) <= xor (x and X"B4D1B4D14B2E4B2E");
Because it's much less typing.
I like it. Just if it was more readable.

Jim- Hide quoted text -

- Show quoted text -

Hi Lewis,
Can you tell me which Xilinx ISE version starts to support the new
definition you described in the form of XOR((...))?

Since most of the new syntaxes from this thread come from VHDL 200X
language extension drafts, chances are that none of these new extensions
will be included/supported in/by standard Xilinx synthesis libraries/tools
until the next ISE after (and probably only if) they become official.

Until then, you will most likely have to wait for the next(next(next(...)))
ISE revision and hope for "early" adoption. In the meantime, you can write
your own package and define your own reduction functions, it takes only a
minute or two to code your own xor_reduce function... assuming you do not
already have one in your vendor's libraries that does the same job. No big
deal.

 

[Jim Lewis]

Daniel S. & Weng

Since most of the new syntaxes from this thread come from VHDL 200X
language extension drafts, chances are that none of these new extensions
will be included/supported in/by standard Xilinx synthesis
libraries/tools until the next ISE after (and probably only if) they
become official.

Accellera VHDL 3.0, is an Accellera Standardized that other
vendors are currently implementing to. It was approved in
July 2006.

Hence, it is official so kick your vendor to get it implemented.
The sooner you kick Xilinx, the sooner they will update
their tools.

Best Regards,
Jim

 

[Weng Tianxiang]

On Mar 30, 1:02 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com>
wrote:

Weng Tianxiang wrote:
Or I think I'd prefer:
y_xor(0) <= xor (x and X"B4D1B4D14B2E4B2E");
Because it's much less typing.
I like it. Just if it was more readable.

Jim- Hide quoted text -

- Show quoted text -

Hi Lewis,
Can you tell me which Xilinx ISE version starts to support the new
definition you described in the form of XOR((...))?

Since most of the new syntaxes from this thread come from VHDL 200X
language extension drafts, chances are that none of these new extensions
will be included/supported in/by standard Xilinx synthesis libraries/tools
until the next ISE after (and probably only if) they become official.

Until then, you will most likely have to wait for the next(next(next(...)))
ISE revision and hope for "early" adoption. In the meantime, you can write
your own package and define your own reduction functions, it takes only a
minute or two to code your own xor_reduce function... assuming you do not
already have one in your vendor's libraries that does the same job. No big
deal.

Hi Daniel,
What I mentioned were coded without any trouble.

The trouble is each time one needs it, he must write the code for
himself,

A broad range same function can be written one time as a VHDL standard
and after that everybody doesn't have to write it again and again. Now
in any standard VHDL library, there are too many functions that are
useless, for example, XOR(a, b).

More general functions with variable size of std_logic_vector or
unsigned without troube to introduce another signal definition for the
temparorily set is easier to use and will be widely used.

Weng

 

[Daniel S.]

Weng Tianxiang wrote:

Hi Daniel,
What I mentioned were coded without any trouble.

The trouble is each time one needs it, he must write the code for
himself,

That's why there are third-party packages/libraries out there... so people
who do not want to make up their own stuff can search, download and use
without having to reinvent.

A broad range same function can be written one time as a VHDL standard
and after that everybody doesn't have to write it again and again. Now
in any standard VHDL library, there are too many functions that are
useless, for example, XOR(a, b).

Unary AND/OR/XOR requires updating the language parsers' grammar to accept
unary operations with these traditionally binary keywords and recognize
their unary overloads so they can be defined by packages and libraries.

Anything else that does not require changes to the language's grammar
mostly can and should be handled by packages and libraries: any such
additions can be done by anyone who knows how to write packages, can be
used immediately by anyone interested in those extensions once they get the
package and promoted for inclusion in standard libraries by anyone who sees
merit in the proposed extensions. It is not necessary for everyone to
reinvent the wheel or wait after standard-setting bodies for these things.

BTW, "xor(a,b)" is not useless: it is the functional form for "a xor b" and
very necessary for the more common binary form to work. XOR may be a
reserved language keyword but it is the libraries' responsibility (browse
your tools' version of ieee.std_logic_1164) to define what these actually
do. If you really wanted to, you could edit your libraries to have
and/or/xor/nor/... do whatever obscure twisted thing you can think of
within the language's grammatical boundaries.

More general functions with variable size of std_logic_vector or
unsigned without troube to introduce another signal definition for the
temparorily set is easier to use and will be widely used.

I do not quite get what you meant here... in any case, those specialized
"general functions" will be built upon other library primitives and
functions by most vendors and third-parties anyhow, whether they are
implemented as part of a standard library or some package, standard or
otherwise. Once the language parser/compiler has expanded the constructs,
the results will be the same.