2016_MeetingDecember1 < P1076

P1076 Web>Vhdl2019MeetingMinutes>2016_MeetingDecember1 (2020-02-17, JimLewis) (raw view)EditAttach
<!--
Set ALLOWTOPICCHANGE = P1076AdminGroup
-->

---+!! P1076 December 1, 2016 Meeting Minutes

---++!! Attendees:

   * Brent Hayhoe, Peter Flake, Rob Gaddi, Jing Pang, Jim Lewis, Patrick Lehmann, Kevin Jennings, Lieven Lemiengre

---++!! Agenda:

%TOC%

---++ Meeting Discussion
   * LCS Review
   * By December, need LCS for proposals that will go into standard.
   * December to March - prepare final document.
   * Format of LCS
      * Common format
         * Red Strike Through for deleted text
         * Black for unchanged LRM Text
      * format 1:
         * Blue underline for new text
      * Format 2:
         * Red for new text
      * Resolution:
         * allow 1 and 2 for existing LCS
      * Going forward:
         * Format 1:
         * Format 2: Kevin, Rob, Peter, Jim
         * Abstain: Brent (happy either)
   * Shared Variables of ordinary types
      * Synthesis & dual port RAM with asynchronous clocks
         * Historic synthesis tool support did this
         * Current tools support signals in a single process with multiple clocks.
      * Ease of initialization - but there are plans to fix this in 2017
      * Not necessary: Patrick, Rob, Brent, Lieven, Jim
   * ISAC must do?
      * Inconsistent and/or incorrect things in LRM
   * AI: Jim contact John Shields and Steven Dovich about P1735 updates
      * Can we get more by reference and less in LRM?
   * Extended Enums
      * There is nothing like this in the current requirements list
      * Patrick: ADA has something like this? Only tagged records and not enumerations.
      * Lieven: Typical enumerations are a closed set, what is being asked for is an open set.
      * Would require someone to work on it.
   * Type Equivalence
      * From the email:
         * A means of stating that two separate type definitions are the same (MAYBE even if they are not exactly the same)<br />a) Simple case: E.g. allow a byte_type to be connected to a byte_type even if these are defined in two separate packages.
      * Analysis:
         * Note: if both types are visible, they can currently be type casted.
         * is byte_type a type or a subtype?
         * if each byte_type were given a unique name (ie: byte_type1 and byte_type2) and they were made subtypes of the same type, such as std_logic_vector, then they will already automatically convert.
      * With type generics, this may happen more often.
      * Implicit conversions between two types that are structurally the same:
         * IE: 2 records
      * Sounds similar to closely related records,
         * however, in that proposal position, name, and type of the elements must be the same
         * could closely related records be extended to also handle closely related arrays.
      * May be able to handle this with a space ship operation if done element by element.
      * May be supported by an already existing proposal, however, if not, there is no bandwidth to consider it at this time.

---++ Review and Approve Meeting Minutes and Decisions by Attendees

Lieven, Rob, Peter, Kevin, All

---++ Review and Approve Meeting Minutes and Decisions by non-attendees

<Add your name below. Indicate if you agree or disagree>

<If you disagree, add a list of items you disagree with and initiate a reflector discussion>

TBD

---++ Next Meeting: Thursday [[2016_MeetingDecember8][December 8, 2016]], 11 am Pacific
---+++ Previous Meeting: Thursday [[2016_MeetingNovember24][November 24, 2016]]
Topic revision: r3 - 2020-02-17 - 15:36:16 - JimLewis
P1076