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)

Reply to
Weng Tianxiang
Loading thread data ...

Good Evening Mr. Tianxiang,

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

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)

Reply to
Jim Lewis

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

x(32), x(36),

x(54), x(55),

Reply to
Andy

Andy

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:

formatting link

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):

formatting link

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)

Reply to
Jim Lewis

x(32), x(36),

x(54), x(55),

Hi Jim, Thank you for your response.

Yes.

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

Reply to
Weng Tianxiang

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:

x(32), x(36),

x(54), x(55),

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:

Reply to
Jim Lewis

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.

formatting link

Reply to
Symon

Reply to
Ben Jones

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

x(32), x(36),

x(54), x(55),

x(36),

x(55),

Reply to
Andy

x(30), x(32), x(36),

x(52), x(54), x(55),

x(36),

x(55),

Hi Jim, Andy, Thank you for your inputs.

Weng

Reply to
Weng Tianxiang

Ben

I like it. Just if it was more readable.

Jim

Reply to
Jim Lewis

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

Reply to
Weng Tianxiang

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.

Reply to
Daniel S.

Daniel S. & Weng

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

Reply to
Jim Lewis

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

Reply to
Weng Tianxiang

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.

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.

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.

Reply to
Daniel S.

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.