Hidden Gems of SystemVerilog – 2. Name spaces

Keisuke Shimizu

Yesterday was Halloween and candies are around every corner, even in my code. But do you think it compiles?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

`define candy
 
function void candy;
endfunction
 
module candy( input candy );
  initial begin
    (* candy *) bit candy;
  end
endmodule
 
package candy;
  function void candy;
  endfunction
endpackage

It will! This is because each candy is in different name spaces. SystemVerilog has eight name spaces for identifiers (names).

  • Global
    • Definitions name space — module, primitive, program, and interface names defined outside all other declarations.
    • Package name space — package names.
  • Global to the compilation unit
    • Compilation-unit name space — function, task, and other names defined outside the module, interface, package, etc.
    • Text macro name space — text macro names.
  • Local
    • Module name space — names defined within the module, interface, package, etc.
    • Block name space — names defined in blocks, function, task, etc.
    • Port name space — port names of module, interface, etc.
    • Attribute name space — attribute names.

These are the name spaces each candy belongs to. Since they are in different name spaces, they do not conflict each other.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

`define candy // This candy is in the text macro name space.
 
function void candy; // This candy is in the compilation-unit scope name space.
endfunction
 
module candy(    // This candy is in the definitions name space.
  input candy ); // This candy is in the port        name space.
  initial begin
    (* candy *)  // This candy is in the attribute name space.
    bit candy;   // This candy is in the block     name space.
  end
endmodule
 
package candy;         // This candy is in the package name space.
  function void candy; // This candy is in the module  name space.
  endfunction
endpackage

EDA Playground

You can view and run the code on EDA Playground.

11 thoughts on “Hidden Gems of SystemVerilog – 2. Name spaces”

  1. Pingback: IP Systems Blog Review – Monday December 24, 2014 • JB Systems Tech

  2. VCS 2014.12 gives the below compilation error.

    ———————————————————————————————–
    Parsing design file ‘design.sv’

    Error-[SV-PPD] Package previously declared
    design.sv, 18
    candy
    Identifier ‘candy’ is already declared in file “design.sv”, line 10.
    ———————————————————————————————–

    Reply

    1. It is an attribute that specifies a property about bit candy. Tools such as simulators and logic synthesizers can use the attribute to control their operation or behavior. Probably no tools understand the candy attribute, though.

      Reply

  4. Hi Keisuke,

    Since you mentioned name space, I have some questions about name space and parameter type. Would you please tell any good material or paper written by you or other about it?

    1. Are A1, A2, A4 the same? What is the different between A2 and A3.

    class A;
     virtual task A1;
endclass

class B extends  A;
     task A1;
     virtual task A2;
     virtual protected task A3;
endclass

class C extends A;
endclass

task C::A1;

    2. Will the parameter data have any conflict for method_1? Is there a better way to handle it?

    class A
    int Data;
    
    task A 
        Data = Data+1;
    endtask

    task B
         Data = Data+2;
     endtask

endclass

    3. Is this a legal way to program parameter. Will the parameter Data have different copy? How could we access each parameter Data

    class A
    
    task A 
        int Data;
        Data = Data+1;
    endtask

    task B
         int Data;
         Data = Data+2;
     endtask

endclass

    4. What is the difference between local, private and protected parameters.

    Thanks you very much. Sorry for so many questions

    Best,

    Reply
      1. I’m afraid I don’t fully understand your question, but regarding the A2 and A3, A2 is available to anyone who has access to it because it is a public class method. On the other hand, A3 is visible to class B and its subclasses only, because it is a protected class method.
      2. Since Data is a class property, task A and task B can access it. It is caller’s responsibility when to update it.
      3. It is legal and yes, you have two separate Data. However, since the Data exists only in the task, you cannot access the updated Data from outside of the task.
      4. A local (private) class property is available only inside the class. A protected class property is visible to subclasses, too.
      Reply

      1. Hi Keisuke,

        Thanks for your explanation, Please correct me if I am wrong.

        For my understanding, property in the class is accessible to task. by if the parameter is defined inside the task, it is only accessible inside the task.

        Best,

        Kevin

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *