• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Functional Verification
  3. Class definition outside module and package

Stats

  • Locked Locked
  • Replies 3
  • Subscribers 65
  • Views 17241
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Class definition outside module and package

Rama Kishore
Rama Kishore over 10 years ago

Hi,

I'm new to SV verfication and hence appreciate your help on this.

Usually I've seen SV class definitions inside a module / package . I remember having read before that class definitions cannot exist outside these, and as such cannot be compiled standalone.

But strangely, I've seen IUS14.1 successfully compiling a  .sv file which contains only class definition. Do not see module/package constructs inside the file.

Am I missing something in my understanding? Thanks for your suggestions and help in advance.

Regards

Kishore

  • Cancel
  • StephenH
    StephenH over 10 years ago

    Hello Kishore.

    SV allows you to declare classes (and many other things) outside the scope of modules and packages; it's what's referred to as the compilation unit scope (CU). It's legal but generally not advisable, because it is harder to control where the declared types are visible. The LRM rules are that the type is visible in all files that are compiled at the same time, so depending on how you invoke the compilation flow that may be all your files in one step or it may be a small subset if you break the compile into multiple stages.

    Another problem is that if you import code from multiple sources (e.g. some 3rd party VIP) and it has used the same names that you did, you have a clash because of the "global" namespace. The only solution is to split the compile into separate stages (which may then break your own use of the CU scope, or you have to rename your types (which can be a pain in the bum if you have lots of legacy code that depends on those names).

    If you stick to declaring everything inside of modules or preferably packages, you have much better controlled namespaces, and overall it's much cleaner.

    Good luck!

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Rama Kishore
    Rama Kishore over 10 years ago

    Thanks Stephen, for the very good explanation. That really helped my understanding.

     

    So, can I assume CU scope as analogous to Global scope in C/C++ ? Also, can you please elaborate a bit on "type is visible in all files that are compiled at the same time". What do you mean by the phrase "same time" in this context  - same .sv file that includes other .sv/.svh files  or  one compilation-tool invocation?

     

    Regards

    Kishore

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Shalom B
    Shalom B over 10 years ago
    For most tools, the default of "same time" is "one compilation-tool invocation". I think all Cadence tools work that way.
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information