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
A suggestion for a new input interface for functions in VHDL: XOR(a0, a1, ...)
Started by ●March 26, 2007
Reply by ●March 28, 20072007-03-28
Reply by ●March 30, 20072007-03-30
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
Reply by ●March 30, 20072007-03-30
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.
Reply by ●March 30, 20072007-03-30
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
Reply by ●March 30, 20072007-03-30
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
Reply by ●April 1, 20072007-04-01
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.
