Language Change Specification History for Partially Connected Vectors on Port Map Proposal
LCS Number: | LCS-2016-001 |
Version: | 5 |
Date: | 21-Oct-2016 (Ver 1), ?? (Ver 2), 17-Jan-2017 (Ver 3), 10-Feb-2017 (Ver 4), 13-Feb-2017 (Ver 5) |
Status: | |
Author: | Kevin Jennings |
Email: | KevinJennings |
Source Doc: | Partiallyconnectedvectorsonportmap |
Summary:
| Allow for vectors to be partially connected in the port map |
Voting Results: Cast your votes here
Comments
Do you really want to remove the last sentence ? This would allow a port without known bounds...
--
Tristan Gingold - 2016-10-21
Looks like in the the copying from Word into Twiki the 'real' last sentence of the paragraph was not copied for some reason.
--
Kevin Jennings - 2016-10-24
Version 2 changes: - Adds changes to section 6.5.6.2 to allow for partially mapped vectors in the generic map - Sprinkles the phrase "or subelement or slice thereof" in several places to be explicit about references to partially mapped vectors. The phrase "or subelement or slice thereof" is currently used in the LRM 14.3.5 d) page 205, top, to refer to port map association elements formal ports.
--
Kevin Jennings - 2016-11-18
The requirement for this feature applies to port maps, not to generic maps. Is the extra work involved in the generic map implementation worthwhile?
--
Peter Flake - 2016-11-24
Yes, I think it's worthwhile since it removes an unnecessary error condition from the language. Removing the error condition for port maps but leaving the error condition for generic maps would be an oversight (one that almost happened).
Besides, do you know for a fact that making generic maps and port maps different from each other in this instance wouldn't make extra work?
--
Kevin Jennings - 2016-11-24
Paragraph 5 on page 83 forbids to use open in combination with individually associated interface objects. This paragraph should be changed too.
It is an error if an actual of open is associated with a formal interface object that is associated individually.
An actual of open counts as the single association allowed for the corresponding formal interface object, but
does not supply a constant, signal, or variable (as is appropriate to the object class of the formal) to the
formal.
Patrick Lehmann - 2017-01-17
Version 3 created. Added change to section 6.5.7.1, page 83.
-- Kevin Jennings - 2017-01-17
Version 3, Edit1: LRM 6.5.6.2 Generic clauses page 78 last paragraph
the text of the main body of the paragraph is repeated twice.
The "error" sentence needs to include the part about subelements:
It is an error if no actual is specified for a given formal generic constant or subelement or slice thereof, and no default expression is present in the corresponding interface element.
Version 3: Edit 2:LRM 6.5.6.3 Port Clauses page 80 last paragraph
It seems you need the terms about: "or subelement or slice thereof" here also.
Version 3: Edit 3: 6.5.7.1 page 83 near the bottom of the page, second paragraph above 'Note 1'
Why did you delete the part about:
An actual of open counts as the single association allowed for the corresponding formal interface object, but does not supply a constant, signal, or variable (as is appropriate to the object class of the formal) to the formal.
-- Jim Lewis - 2017-02-09
Version 4 created to address Jim's comments above.
-- Kevin Jennings - 2017-02-10
Almost there
For generics, last part of the second sentence needs to apply to the generic or subelement or slice thereof. This corresponds to the part you did for ports in 14.3.5.
Just changing the last few words of this sentence:
If no such actual is specified for a given formal generic constant or subelement or slice thereof (either because the formal generic is unassociated or because the actual is open), and if a default expression is specified for that generic, the value of this expression is the value for the formal generic constant or subelement or slice thereof.
-- Jim Lewis - 2017-02-13
My previous comment needs to reference 6.5.6.2 Generics. Also in the same section, first sentence. It would be better to change "generic constant" to "formal generic constant".
-- Jim Lewis - 2017-02-13
Version 5 created to address Jim's latest comments.
-- Kevin Jennings - 2017-02-14
That fixes my concerns. I just wish there was a better way to structure that second sentence in 6.5.6.2 so it does not have to repeat the "generic constant or ..." so many times.
I tried playing with a form like:
For a given formal generic constant or subelement or slice thereof, if no actual is specified (either because the formal is unassociated or the actual is open), the value of the formal is the value of the default expression, if specified.
However, I don't think this quite does. The long form is clear in what it does so I think it is time to it done.
-- Jim Lewis - 2017-02-16
Is there a reason why we don't allow this for constant parameters? Perhaps this is ok as they are a different nature.
-- Jim Lewis - 2017-02-18
Topic revision: r1 - 2017-05-03 - 04:17:42 -
RobGaddi