[sv-bc] 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.