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

Hi Jim!

Just to clarify, I only referred to memory as
"array of reg" in an effort to directly quote
Francoise's email.   I definitely know that

  reg [7:0] mem [0:1023];

has long been considered a memory.  I'm less sure on

  integer mem [0:1023];
  time mem [0:1023];

in terms of vpiIsMemory results.

And you are correct:  I view that classic Verilog
memories fits most neatly into the superset of
fixed-size unpacked arrays.   (For completeness:
other types of unpacked arrays are dynamic arrays,
associative arrays, and queues.)

I think that iterators and access functions for
fixed-size unpacked arrays should be very natural
for use when dealing with constructs that correspond
to classic Verilog memories.

Thanks!
Doug


> -----Original Message-----
> From: Jim Vellenga [mailto:vellenga@cadence.com]
> Sent: Wednesday, May 09, 2007 1:02 PM
> To: Warmke, Doug; SV-CC
> Cc: sv-bc@eda.org
> Subject: 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.