hi Stu I don't agree. If we are to develop a fully-defined notion of what a "memory" is in terms that relate it to a hardware understanding, then we should admit that vpiMemory is not deprecated. Further, the correct place to put this fully-defined "memory" definition is either in the language itself, or in the VPI application, but not in the VPI definition. VPI shouldn't create new standalone definitions that relate to usage abstractions over which we have no control; VPI concepts should always relate back to the language and the simulation model abstractions. I think our choices depend on what definition of "memory" remains in the language, but will boil down to these actions: If "memory" is removed from the language we have these choices * deprecate it immediately from its original, leaving it with its unambiguously derivable meaning "one dimensional array of reg" * create a VPI-only new meaning for "memory" with a full analysis of all SV cases as to what a "memory" is I vote option A in this case, because I think that the derivation of "memory" more correctly belongs in the VPI application than the VPI implementation; and the VPI as defined already provides all the information the application needs to make the determination. If the language retains a definition of "memory" then it would be OK to retain the VPI searches for them, based on the language definition. I will admit I seem to be a lone voice here, but I think conceptually this is the way to go. Abi -----Original Message----- From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org <mailto:owner-sv-cc@server.eda.org> ] On Behalf Of Stuart Sutherland Sent: Wednesday, May 09, 2007 10:10 PM To: 'Jim Vellenga'; Warmke, Doug; 'SV-CC' Cc: sv-bc@server.eda.org Subject: RE: [sv-cc] Meeting minutes for 04/25/2007 If I may add my two-cents... First, I am not opposed--and don't think users who write *NEW* VPI applications would be opposed--to deprecating the vpiMemory access model. However, both users and tools need to continue to support legacy code that uses vpiMemory. In my mind, "deprecation" only does three things - The LRM no longer needs to document or maintain a language construct (but can do so) - Tools don't have to support the construct to be IEEE compliant (but most likely will support the construct anyway due to legacy customer code) - Tools *should*, but are not required to, generate warnings when a deprecated construct is compiled informing the user that an alternative, preferred construct should be used. Based on those assumptions of the meaning of deprecation, I think vpiMemory should be deprecated. If not deprecated at this time, then a subclause should be added to annex C stating that it is under consideration of being deprecated in a future version standard. Second, even if deprecated, the P1800-2008 standard should explicitly define the SV types that are supported by vpiMemory access. IMHO, vpiMemory should only access declarations that would most likely be used to model actual hardware memories. These are: a) one-dimensional unpacked arrays of scalar reg, logic, bit and var types b) one-dimensional unpacked arrays of one-dimensional packed arrays of reg, logic, bit and var types. I model memories using either logic or bit. I expect logic to be a synonym for reg in all respects, both in simulation and to PLI access. Using an array as type "logic" is a shortcut for declaring it as "var logic". Likewise, declaring it as "var" is a shortcut for "var logic". I use the bit type to model large memories on the assumption that it probably requires half the virtual memory to simulate large amounts of 2-state storage versus 4-state storage. In hardware, a subfield of a word of a physical RAM or ROM cannot be directly accessed; selecting a RAM/ROM address always access the entire word. Therefore, vpiMemory should not access an array that has multiple packed dimensions. Likewise, an array of structs does not represent a hardware RAM or ROM are addressed. All other fixed size array declarations could be argued as being an abstraction of a hardware RAM or ROM. E.g. an array of packed structures can be implemented in hardware as a RAM or ROM, but the hardware implementation of the memory access would be a full word at a time instead of the behavioral-level access of a struct member at a time. Since the behavioral model access is more abstract than RAM/ROM access, my opinion is that it is not necessary for vpiMemory to access arrays of packed words where the word is anything other than a) or b), above. Stu ~~~~~~~~~~~~~~~~~~~~~~~~~ Stuart Sutherland Sutherland HDL, Inc. stuart@sutherland-hdl.com 503-692-0898 > -----Original Message----- > From: owner-sv-cc@server.eda.org > [mailto:owner-sv-cc@server.eda.org <mailto:owner-sv-cc@server.eda.org> ] On Behalf Of Jim Vellenga > Sent: Wednesday, May 09, 2007 1:02 PM > To: Warmke, Doug; SV-CC > Cc: sv-bc@server.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 <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 <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 <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 <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. > > > > -- 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.Received on Thu May 10 10:34:41 2007
This archive was generated by hypermail 2.1.8 : Thu May 10 2007 - 10:35:00 PDT