• 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. Modularization of SystemVerilog

Stats

  • Locked Locked
  • Replies 12
  • Subscribers 64
  • Views 20942
  • 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

Modularization of SystemVerilog

archive
archive over 17 years ago

Hi guys,

I have an question concerning modularization, but I have not found it in one of the following books: "Writing Testbenches using SystemVerilog" and "SystemVerilog for Verification". So, I hope you can help me.

I have written much classes, which are all in ONE file so far, but this is not the target state I wish for this project. The problem is, that for example, one class instantiates another class and I don't know, how to separate the classes.

Is a mechanism available, as C-Header-Files?

I hope you can help me, because several smaller files are much better than one singe huge file.

Thanks for your help!
If the answer should be in one of the itemized books, please sorry, I haven't found it!

Sebastian


Originally posted in cdnusers.org by sebastian
  • Cancel
Parents
  • archive
    archive over 17 years ago

    And yet another question, I'm sorry for this, but I'm unexperienced in Verilog, SystemVerilog AND verification in general, so this is very hard. I've read books about verification in general, without any specific language and books concerning only Verilog and SystemVerilog, but the questions are appearing during programming.

    So here's my question:

    I've separated the classes in single files and packed them together in one class (with help of the keywords typedef, `include and of course with the help of you all here.

    My next task is to connect to "top level classes" (as described in Spear: page 212 - 213 with interfaces, because at the moment, no DUV is available.

    Now, I'm very unsure and don't know how to realise this task.

    Shall I implement two program blocks inside a module which both gets the same interface? For example:

    module top;

    interface if_inst;

    program1 (interface if_inst.if_master);

    Environment env1;
    ......

    endprogram

    program2 (interface if_inst.if_slave);

    Environment env2;

    endprogram

    endmodule


    Thanks for your great help, without this I wouldn't be able to get ahead.
    Have a nice weekend!
    Sebastian


    Originally posted in cdnusers.org by sebastian
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • archive
    archive over 17 years ago

    And yet another question, I'm sorry for this, but I'm unexperienced in Verilog, SystemVerilog AND verification in general, so this is very hard. I've read books about verification in general, without any specific language and books concerning only Verilog and SystemVerilog, but the questions are appearing during programming.

    So here's my question:

    I've separated the classes in single files and packed them together in one class (with help of the keywords typedef, `include and of course with the help of you all here.

    My next task is to connect to "top level classes" (as described in Spear: page 212 - 213 with interfaces, because at the moment, no DUV is available.

    Now, I'm very unsure and don't know how to realise this task.

    Shall I implement two program blocks inside a module which both gets the same interface? For example:

    module top;

    interface if_inst;

    program1 (interface if_inst.if_master);

    Environment env1;
    ......

    endprogram

    program2 (interface if_inst.if_slave);

    Environment env2;

    endprogram

    endmodule


    Thanks for your great help, without this I wouldn't be able to get ahead.
    Have a nice weekend!
    Sebastian


    Originally posted in cdnusers.org by sebastian
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

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