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

Thanks to Jim & Gord for the explanations and examples.

I guess there is a need for this naming convention. Do vendors have 
any proposals?
Perhaps $first_module_or_program_compiled_unit.identifier

What if the file only has declarations?
Should it be an error to compile multiple files with 
declarations-only that had the same identifier?
Perhaps declaration-only files should have $root.identifier for a 
name but other units use the $name_unit.identifier notation?

I am finding more and more reasons to avoid multiple compilation 
units and these examples call into question the value of multiple 
compilation units with variables in the "global" space. I'm guessing 
that Jim & Gord are responding to user requests for naming 
conventions for the not-so-global globals in the $unit space (?)

Are users using anything that could not be nicely packaged and used 
with imports? Again, I am guessing that users have requested this "feature."

Does anybody have a nice example where multiple compilation units 
made it easier to execute a design? The more I play with multiple 
compilation units, the less I like them and I have yet to see anybody 
use $unit.identifier in a reasonable way.

Regards - Cliff

At 11:31 AM 6/21/2007, Jim Vellenga wrote:
>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

----------------------------------------------------
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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.