RE: [sv-cc] Re: [sv-bc] Request from the SV-CC

Just to second what Gordon says here:

For VPI applications, it's helpful to be able to have a predictable
set of "full names" for objects, including those in compilation-unit
scopes.  In particular, this is handy if a client wants to rerun
the same application multiple times; it would be great if they
don't have to adapt the "full names" differently for each run.

The same would be true for command-language based applications,
although these are, of course, outside the scope of the standard.
Consider, for example, an independent coverage analysis tool,
or an HDL debugger and display tool.  Customers may want to write
scripts in the tool's command language that they can use for
multiple regressions -- with multiple simulator vendors(!) -- and
would therefore prefer not to have to adapt the scripts each
time they switch vendors.

And often these independent tools are based underneath on VPI,
so it would be helpful if the VPI tools can recognize the
common names as well.  And a vendor-specific mapping file
would make this possible.

Is that helpful?

Regards,
Jim Vellenga

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Software 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 Gordon Vreugdenhil
]Sent: Thursday, June 21, 2007 1:58 PM
]To: Clifford E. Cummings
]Cc: Charlie Dawson; SV-BC; sv-cc@eda-stds.org
]Subject: [sv-cc] Re: [sv-bc] Request from the SV-CC
]
]
]Cliff -- I'll plead mea culpa here.  I actually made the original
]suggestion to CC in the face-to-face a while ago.  The context
]of the issue is that there is no authoritative name for $unit
]based names.
]
]So, for example,
]    f1.sv
]    -----
]       int C;
]       // other stuff
]    f2.sv
]    -----
]       int C;
]       // other stuff
]
]If f1.sv and f2.sv define different compilation units, you have
]no ability to uniquely name the distinct declarations of "C".
]
]So, either we all need to agree on one globally authoritative naming
]scheme, or we have to provide a mechanism for mapping between
]vendor approaches for the cases in which you really do care that
]various tools in your tool chain have the same global name for such
]declarations.
]
]Since vendors (or at least "vendor") have already made determinations
]about naming such compilation units, it seemed easier to just require
]a mapping mechanism than to get into a long distracting argument
]about how to name such compilation units.
]
]
]Gord.
]
]
]
]Clifford E. Cummings wrote:
]> Hi, Charles -
]> 
]> I'm sure the SV-CC has a good reason for this request but the SV-BC 
]> needs to understand why this is important.
]> 
]> Could the SV-CC explain in lay terms that even we SV-BC-types can 
]> understand and include an example showing why the requested feature 
]> makes life better for all SV users? Even if the SV-CC could 
]explain at a 
]> high level why this is important to VPI applications, it would help.
]> 
]> Although the SV-CC gets professional SV-courtesy and attention, the 
]> SV-BC needs to understand why the feature should be considered.
]> 
]> Regards - Cliff
]> 
]> At 08:00 AM 6/21/2007, Charlie Dawson wrote:
]>> Hi SV-BC,
]>>
]>> The SV-CC has directed me, as chair of SV-CC, to request 
]that the SV-BC
]>> consider adding language to the LRM requiring 
]implementations to have a
]>> mapping file which will bind names to $units objects.
]>>
]>> Please let me know if this request needs further explanation.
]>>
]>> Thank you for your consideration of this matter.
]>>
]>>   -Chas
]>>
]>> -- 
]>> Charles Dawson
]>> Senior Engineering Manager
]>> NC-Verilog Team
]>> Cadence Design Systems, Inc.
]>> 270 Billerica Road
]>> Chelmsford, MA  01824
]>> (978) 262 - 6273
]>> chas@cadence.com
]>>
]>>
]>> -- 
]>> This message has been scanned for viruses and
]>> dangerous content by MailScanner, and is
]>> believed to be clean.
]> 
]> ----------------------------------------------------
]> Cliff Cummings - Sunburst Design, Inc.
]> 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
]> Phone: 503-641-8446 / FAX: 503-641-8486
]> cliffc@sunburst-design.com / www.sunburst-design.com
]> Expert Verilog, SystemVerilog, Synthesis and Verification Training
]> 
]> 
]
]-- 
]--------------------------------------------------------------------
]Gordon Vreugdenhil                                503-685-0808
]Model Technology (Mentor Graphics)                gordonv@model.com
]
]
]-- 
]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.