RE: [vhdl-200x] RFC (request for comments): Please review previous items lists

Jim,

I had two proposals that were originally submitted on the Bugzilla database several years ago.  I mentioned these in a post here as well back in August 2011, I'm not seeing those items in the list.  Were those proposals reviewed and discarded or simply overlooked?  Below is the e-mail I sent to 'vhdl-200x@eda.org' back on 8/16/2011.  Unfortunately, it looks like the Bugzilla links in that e-mail are no longer working, do you have a way to retrieve that information?

The brief synopsis of the proposals are:
- When connecting the port map, a signal that happens to be a vector cannot be partially connected with the language as it is defined today.  This does not map with real world usage such as a processor or memory that might have a 16 bit data bus but not all bits need to be used.

- Create a method for functions that return a vector to know the size of the vector to which it is to be assigned.  The classic use case here is "x <= to_unsigned(123, x'length)" (Today's method).  By allowing the function to have knowledge of the size of 'x', then this could be rewritten as "x <= to_unsigned(123)".  Practically any code that is written to use the fixed/floating package gives even more good examples of use cases that could be cleaned up if functions had this knowledge.

Kevin Jennings

-- Start of 8/16/2011 e-mail

Prior to this group's existence there were other sites for proposing suggestions and bug reports.  I don't see any record in this group of those suggestions being carried forward to the 'P1076 Collected Requirement' page of the Twiki (other than to 'submit an enhancement request or a bug' link), so my fear is that the suggestions will get lost yet again.

Are the current Bugzilla reports considered to be part of the collected requirements for the new standard or not?

In case the Bugzilla database suggestions are not in general being carried forward as new requirements for P1076 then, for my particular two cents, I'll re-propose my two suggestions from those earlier days again.

Suggestion #1:  Allow for individual elements of a vector to be left open on a port map.  See this link for more information, this is the last site I posted the suggestion to along with the use case.  https://bugzilla.mentor.com/show_bug.cgi?id=275

Suggestion #2:  Method to allow functions that return arrays to have knowledge of the array bounds.   See this link for more information on the suggestion along with the use case.  https://bugzilla.mentor.com/show_bug.cgi?id=240

Kevin Jennings
-- End of 8/16/2011 e-mail

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jim Lewis
Sent: Thursday, November 29, 2012 12:37 PM
To: vhdl-200x@eda.org
Subject: [vhdl-200x] RFC (request for comments): Please review previous items lists

Hi,
Following the VHDL-2008 standard there were some items
on the VHDL and Accellera working groups lists that did
not get done.

I have added these to the collected requirements page
in tables after the proposals table (the first table).
http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/CollectedRequirements

We need your help to determine the interest level of these
items.  Please review these lists and indicate if the
item is something you would use and its value to you
(a numeric value between 1 and 10 where 10 is most
important).   If an item offends you, we can add another
column for please don't do this.


Also if there is already a proposal on the item, please
add a link to the existing proposal.

Feel free to indicate your support of the current proposals
also.

You will need a TWIKI account to do this.  If you don't
have one, send me an email and I will set it up.

Thanks for the help.

Jim
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.