RE: [sv-cc] Meeting minutes for 04/25/2007

OK, we have one hint from Doug's comments -- at least
they're thinking of memories as being "fixed-size"
unpacked arrays, rather than dynamically sized ones.

He also referred to it as an "array of reg", using
specifically the name "reg", which suggests that
we exclude bit var and integer types as element
types.

Finally, the VPI object model for a frame does not
allow for a memory to belong to a frame -- although
it can belong to a task func, since a task func can
be a scope.  Thus, it seems that if its statically
declared in a task func, it can be a memory, but not
if the task is declared as "automatic".  However,
it can belong to a named fork, and so can belong
to a dynamic context.

As far as compatibility is concerned, IEEE Std 1364-2001
represents both vpiMemory and vpiMemoryWord has having
single pairs of range bounds.  Thus a memory should
have exactly one unpacked dimension, while its element
type should have at most one packed dimension.  Moreover,
it should not be declared as automatic in a task or
function, but can be declared in a named fork.

So at the very least, vpiIsMemory should indicate a
fixed-size one-dimensional array with an element
type of reg (== logic var), where the element type
has at most one packed dimension, and where it is
not declared as an automatic variable of a task
or function.

This still leaves open the questions of

a) Whether vpiIsMemory applies to such an array
declared in a class defn (class type, class obj), and

b) Whether it applies to such an array declared in
new SystemVerilog contexts such as package, progrem,
or interface.

If we decide to continue to support vpiIsMemory and
the vpiMemory iterations, can we agree on this much?

Regards,
Jim

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Architect                              (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information." 
----------------------------------------------------------  

]-----Original Message-----
]From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On 
]Behalf Of Warmke, Doug
]Sent: Wednesday, May 09, 2007 2:15 PM
]To: SV-CC
]Cc: sv-bc@eda.org
]Subject: RE: [sv-cc] Meeting minutes for 04/25/2007
]
]Hi Francoise,
]
]Thanks for your response.
]The BC has had no discussion on removing $readmem.
]I think that would be a poor idea, personally.
]Rather, $readmem has been extended to handle more
]of the unpacked array types in SystemVerilog.
]
]The main point is that "array of reg" is a simple
]subset of fixed-size unpacked arrays.  It is frequently
]used to model physical hardware memories, though nowadays
]there are plenty of other options for that in SV.
]
]The notion under discussion is that any specialized
]access for that "array of reg" subset is redundant with
]general access to fixed-size unpacked arrays, and thus
]overcomplicates the language.
]
]Also, note that nobody is talking about "removing" anything
]from the language.  "Deprecating" would be a better term.
]
]And while I'm not too familiar with Chuck's compatibility
]proposal, it occurs to me that some form of compatibility
]would be needed for older VPI accesses to "array of reg"
]memories.
]
]Thanks again - please keep us informed with your findings
]after talking to some users.
]
]Regards,
]Doug
]
]> -----Original Message-----
]> From: Francoise Martinolle [mailto:fm@cadence.com]
]> Sent: Wednesday, May 09, 2007 10:19 AM
]> To: Warmke, Doug; Charlie Dawson; SV-CC
]> Subject: RE: [sv-cc] Meeting minutes for 04/25/2007
]> 
]> 
]> Doug,
]> 
]> We discussed this today at the CC meeting and we want to get more
]> information on what the
]> BC is planning to do with memories.
]> Is the BC going to remove the system tasks $readmem? or enhance them
]for
]> generic arrays?
]> 
]> I think in VPI the term memory very specifically represents an array
]of
]> regs which
]> was supposed to model a physical hardware memory. That was the usage
]of
]> the vpiMemories
]> iteration to return such declarations. We do not know if users
]> would want to retain this specific access or if they would 
]want to get
]> all
]> fixed size arrays. We would like to have some user input on this
]matter
]> before doing anything.
]> 
]> Francoise
]>     '
]> 
]> 
]> -----Original Message-----
]> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
]> Warmke, Doug
]> Sent: Monday, April 30, 2007 12:23 PM
]> To: Charlie Dawson; SV-CC
]> Subject: RE: [sv-cc] Meeting minutes for 04/25/2007
]> 
]> Hello SV-CC,
]> 
]> I was hoping to make this request before your face-to-face, but
]somehow
]> I forgot.
]> On the SV-BC reflector, we have recently been discussing the V2K
]> "memory" construct in the merged LRM.  Basically, SV 
]"unpacked arrays"
]> are a pure superset of V2K memories.
]> Retaining the term "Memory" in the merged LRM is therefore redundant.
]> The SV side of the
]> language would be simplified and have better integrity if we could
]drop
]> the special handling of the term "memory".
]> 
]> However, we know that the term has a lot of significance in the world
]of
]> VPI.
]> Could you guys please discuss this issue, and see if you could also
]come
]> to some sort of arrangement in which special handling of "memory" is
]> subsumed into the general handling of "fixed size unpacked array"?
]> 
]> Thank you,
]> Doug Warmke
]> 
]> > -----Original Message-----
]> > From: owner-sv-cc@server.eda.org 
][mailto:owner-sv-cc@server.eda.org]
]> On Behalf Of Charlie Dawson
]> > Sent: Monday, April 30, 2007 7:55 AM
]> > To: SV-CC
]> > Subject: [sv-cc] Meeting minutes for 04/25/2007
]> >
]> > Minutes of 04/25/2007 SV-CC Meeting.
]> >
]> > ATTENDEES
]> > 000000000000000000
]> > 777777777666666666
]> > 000000000111110000
]> > 443322111221009988
]> > 212121310200212131
]> > 518484173068517306
]> > xxxxxx-xxxxxxxxxxx Charles Dawson
]> > xxx-xxxxxxx-x-xxxx Ralph Duncan
]> > xxxxxxxxxxxxxxxxxx Jim Vellenga
]> > xxxxxxxx-xxx-x-xxx Andrzej Litwiniuk
]> > xxxx-xxxxx-xxxxxxx Abigail Moorhouse
]> > xxx-xxxx--xxxxxx-x Michael Rohleder
]> > xxxx-xxxxxxxxxxxxx Chuck Berking
]> > xxxxxxxxxxxx-xxxxx Bassam Tabbara
]> > xx-xx-xx-x-xxxxxxx Francoise Martinolle
]> > xxxxxx-xxxxxxxxxx- Ghassan Khoory
]> > -----xx----------- Steve Dovich
]> > --x--xxxx----xx-xx Amit Kohli
]> > --x--------------- Stu Sutherland
]> > x----------------- Gord Vreugdenhil
]> >
]> > 1.  Reviewed Patent information.
]> >
]> >    - Chas reviewed the patent information.
]> >
]> >
]> > 2.  Reviewed minutes of the 04/11/2007 Meeting.
]> >      - Ralph/Chuck.  ACCEPTED
]> >
]> >
]> > 3.  Liaisons
]> >    - Chas commented on the P1800 meeting. 890  Going ahead with
]merged
]> doc.
]> >    - Francoise has no other meetings to report.
]> >    - No other meetings to report on.
]> >
]> >
]> > 4.  New business
]> >
]> >    - Gord's tf_nodeinfo() question
]> >      Michael thinks we should force people to go to VPI.  There is
]no
]> >      reason for it.  Too many other issues are coming up.  Abi
]agrees.
]> >      Chas commented that the main concern is for accessing memories
]> >      efficiently.  Michael suggested accessing memories as a packed
]> array
]> >      of words.  Jim pointed out that there were cases where
]customers
]> >      did not want to propagate the values.  Abi asked when we would
]be
]> >      encroaching on DPI.  Michael thought that the use 
]model for the
]> >      two interfaces are different.  Gord commented that if we went
]too
]> >      far in VPI, the implementations would be fully constrained.
]> >      Gord thinks that it might be a reasonable option to 
]consciously
]> >      decide that vendors would provide a proprietary solution for
]the
]> >      performance issues.  Francoise suggested a function tray idea
]for
]> >      dealing with the memory performance.  Michael liked the idea.
]> >      Michael proposed that we should do some brainstorming 
]on how to
]> >      improve VPI performance for accessing memories and arrays.
]> >
]> >    - Agenda for the 4/30-5/1 face to face meeting
]> >      Add accessing memories and arrays.  Switch order of
]compatibility
]> >      and packed structs.
]> >
]> >    - Chuck sent out a new compatibility doc
]> >      Chuck would like to discuss the include file layout.  
]Abi asked
]> that
]> >      there be a 2008 compatibility mode.
]> >
]> > 5.  Reviewed items with proposals.
]> >
]> >    - Item 1726 Clarify meaning of vpiConstantSelect
]> >      Francoise and Jim had a long discussion on this again.
]> >      Tied into the discussion needed on validity.
]> >
]> > Motion to Adjourn.  JimV/Michael.  Meeting ended at 1:06pm.
]> >
]> > 6.  Reviewed SV-CC items with proposals (Straw poll only).
]> >
]> > 7.  Old Business
]> >
]> > 8.  Action items
]> >
]> >    - Ongoing review of Michael and Abi's compatibility proposal.
]> >    - Francoise and Bassam to continue work on assignment patterns.
]> >    - Francoise to champion adding support for typed parameters to
]the
]> >      typespec diagrams.
]> >    - Abi to champion adding support for parameterized classes.
]> >    - Abi/JimV to champion improving the ability to compare objects.
]> >    - Steve Dovich to determine best way to deal with issues between
]> >      versions of the IEEE specs.
]> >    - SV-CC to review proposal for Item 0890.
]> >    - Michael to compose response to the Clean Scheduling Proposal.
]> >    - All to verify their Acknowledged Mantis Items.
]> >    - Steve to send out exact text on referring to a prior version.
]> >    - Chas to gather a list of all SV-CC approved mantis items which
]> have
]> >      not been incorporated into draft 2.
]> >    - Chas to formulate an agenda for the next SV-CC face to face
]> meeting.
]> >
]> >
]> > 9.  Items for consideration at the next meeting (they already have
]> proposals):
]> >
]> >    - Item 1726 Clarify meaning of vpiConstantSelect
]> >    - Item 1741 1800-2005 Section 27.50 Issues with foreach diagram
]> >
]> >
]> > 10. Next meeting
]> >     The next SV-CC meeting will be the face to face starting on
]> 04/30/2007.
]> >     The next P1800 meeting will be on 05/24/2007.
]> >
]> >
]> >
]> > --
]> > 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.
]> 
]
]
]-- 
]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.