Subject: Preliminary results of votes on change proposals
From: Peter Ashenden (peter@ashenden.com.au)
Date: Sun Feb 16 2003 - 22:08:45 PST
Dear colleagues,
Here are the preliminary results of the votes on the changes proposals
being considered by the P1164 working group. Final results are
subject to confirmation of DASC membership status for some voters.
Member votes received: 13
Eligible members: 14
Return rate: 93%
Non-member votes received: 2
In summary, all analyses except that for CP-003 were accepted. For
CP-003, there was no clear consensus to accept or reject the analysis;
the issue needs further consideration within the working group.
In the following, accept and reject percentages are of the total
accept/reject vote, and abstain percentages are of the total
accept/reject/abstain vote.
CP-001 Uncomment xnor operators
Analysis accepted
Member votes: Accept 13 (100%) Reject 0 (0%) Abstain 0 (0%)
All votes: Accept 15 (100%) Reject 0 (0%) Abstain 0 (0%)
No comments
CP-002 Add shift operators for vector types
Analysis accepted
Member votes: Accept 13 (100%) Reject 0 (0%) Abstain 0 (0%)
All votes: Accept 15 (100%) Reject 0 (0%) Abstain 0 (0%)
From Jose Torres
I would suggest to add a comment in each function to indicate how
the shift is done and what happens to the n bit.
CP-003 Add array/scalar logical operators
Analysis not accepted
Member votes: Accept 7 (58%) Reject 5 (42%) Abstain 1 (8%)
All votes: Accept 9 (64%) Reject 5 (36%) Abstain 1 (7%)
From Lance Thompson
I prefer the idea of waiting for 1076 to alter the specification of
logical operator behavior. The potential confusion of bit_vector
operators behaving differently than std_(u)logic_vector operators is
not worth the minor keystroke savings. As has been pointed out,
(a'range=>b) is a reasonable subexpression for the time being.
Or perhaps these can be treated like xnor was. That is, standardize
the behavior, but defer it until 1076 approves the underlying
behavior.
From Steve Bailey
In general, the analysis/recommendation is fine. However, I prefer
that the range of the result be consistent with 1076. My reason
being that if the design/designer typically uses N downto 0 ranges,
then the result would be consistent with what is typical of the
design/designer (assuming that the vector operand is typical).
Also, I believe some tools already do it this way (even though it
isn't standard).
But, I think this is a relatively minor detail since the result is
usually assigned to something else and then has the range of the
target. (Which means that failing to persuade the WG to change, I
wouldn't vote No on the ballot because of this.)
From J. Basker
I find this proposal non-intuitive. The more common interpretation
is to treat '1' as "000...001", rather than "111....111". For
example, "A and '1'" would mean "A and "000001"" which is same as "A
+ '1'" which means "A + "000001"". I therefore reject this proposal.
From Paul Menchini
Bhasker wrote:
> I vote to accept all except CP-003. I find this proposal
> non-intuitive. The more common interpretation is to treat '1' as
> "000...001", rather than "111....111". For example, "A and '1'"
would
> mean "A and "000001"" which is same as "A + '1'" which means "A +
> "000001"". I therefore reject this proposal.
I did not realize that CP-003 attached this interpretation to '1'.
I therefore also switch my vote on CP-003 only to "no."
From George Economakos
Even though the proposed operations by Jim are very powerful and
capture hardware related issues I feel we need more discussion on
how to include them without complicating things and misleading
designers with their usage.
CP-004 Add capacitive drive strength
Analysis accepted
Member votes: Accept 13 (100%) Reject 0 (0%) Abstain 0 (0%)
All votes: Accept 14 (100%) Reject 0 (0%) Abstain 1 (7%)
No comments
CP-005 Make vector result subtypes same as 1076 operators
Analysis accepted
Member votes: Accept 12 (92%) Reject 1 (8%) Abstain 0 (0%)
All votes: Accept 12 (86%) Reject 2 (14%) Abstain 1 (7%)
From Steve Bailey
(see comments for CP-003 above)
From David Bishop
I find that l'range make much more sense here.
CP-006 Add logical reduction operations/operators
Analysis accepted
Member votes: Accept 11 (85%) Reject 2 (15%) Abstain 0 (0%)
All votes: Accept 13 (87%) Reject 2 (13%) Abstain 0 (0%)
From Lance Thompson
I prefer the idea of waiting for 1076 to alter the specification of
logical operator behavior. However, if 1076 analysis rejects the
notion of unary logical operators, I would be in favor of the
analysis. Reduction functions ARE very useful, I only worry about
having redundant methods...
From Steve Bailey
I think we need the unary reduction operands. I think they should
be added to 1076 first and then overloaded here. I see no benefit
in typing "xor_reduce" instead of xor. Nor do I see a benefit in
later having overloadable unary reduction operators in the language
and then not overload them in 1164.
My recommendation is that this group request the 200x group to
quickly agree to adding the unary reduction operators so 1164 and
1076.3 can exploit them immediately. This would be a good test as
to how quickly we can move things on the 200x side of things. (I
think having a short list of relatively straight-forward fast lane
items is worth considering in 1076 200x.)
CP-009 Provide 'image attribute
Analysis accepted
Member votes: Accept 13 (100%) Reject 0 (0%) Abstain 0 (0%)
All votes: Accept 15 (100%) Reject 0 (0%) Abstain 0 (0%)
From Steve Bailey
I agree with the analysis and recommendation. If this issue is as
"hot" as unary reduction, then let's also add this to the 200x "fast
lane" issues.
From Jim Lewis
With respect to CP-009, when CP-007 and CP-008 get implemented,
there will need to be a corresponding to_string of some type in
std_logic_textio. I would like this function made visible the
package declaration. Hence we would have something that is
effectively the same as 'image. I have a similar request for 200X.
This suits me better from a usability standpoint anyway: with
to_string:
write(OUTPUT, to_str(My_slv) & CR) ;
with 'image it is more verbose:
write(OUTPUT, std_logic_vector'image(My_slv) & CR) ;
CP-010 Add match functions like numeric_std.std_match
Analysis accepted
Member votes: Accept 13 (100%) Reject 0 (0%) Abstain 0 (0%)
All votes: Accept 15 (100%) Reject 0 (0%) Abstain 0 (0%)
From Egbert Molenkamp
match /= std_match if both are null arrays. Maybe we should pass it
also to the WG1076.3 for inclusion of match for signed/unsigned in
the numeric packages.
Cheers,
PA
-- Dr. Peter J. Ashenden peter@ashenden.com.au Ashenden Designs Pty. Ltd. www.ashenden.com.au PO Box 640 Ph: +61 8 8339 7532 Stirling, SA 5152 Fax: +61 8 8339 2616 Australia Mobile: +61 414 70 9106
This archive was generated by hypermail 2b28 : Sun Feb 16 2003 - 22:10:19 PST