• 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. Custom IC Design
  3. How to include an Instantiated Verilog cell in the config...

Stats

  • Locked Locked
  • Replies 1
  • Subscribers 127
  • Views 16509
  • 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

How to include an Instantiated Verilog cell in the config view of AMS simulation

RFStuff
RFStuff over 4 years ago

Dear All,

I have created a VerilogAMSTEXT  module called sync_block.

The module text looks like bleow :-

It has two instances sync_a ad sync_b. These are defined in separate files sync_a.v and sync_b.v.

Though these files are included in the Text, the config is NOT able to detect these cells.

Could anybody please tell how this issue can be overcome.

`include "constants.vams"
`include "disciplines.vams"
`include "/test/sync_a.v"
`include "/test/sync_b.v"

module sync_block #(parameter RESET_TOGGLE_LEVEL = 'b0)

(
input async_toggle_i,
input clk_i,
output pulse_o,
output toggle_delay_o
);

wire toggle_sync;

sync_a #(.RESET_LEVEL(RESET_TOGGLE_LEVEL)) i_sync (
.d_i (async_toggle_i),
.clk_i (clk_i),
.hw_reset_n_i (hw_reset_n_i),
.sw_reset_i (sw_reset_i),
.test_mode_i (test_mode_i),
.z_o (toggle_sync)
);

sync_b #(.RESET_TOGGLE_LEVEL(RESET_TOGGLE_LEVEL)) i_toggle2pulse (
.clk_i (clk_i),
.hw_reset_n_i (hw_reset_n_i),
.sw_reset_i (sw_reset_i),
.toggle_i (toggle_sync),
.pulse_o (pulse_o),
.toggle_delay_o (toggle_delay_o)
);

endmodule

  • Cancel
  • Majdo
    Majdo over 4 years ago

    Hi @RFStuff,

    Config does not use compiler so it don't understand '`include directive or any other directive targeted for compiler or dig simulator its only capable of working with libraries and cellviews visible in LibraryManager.

    I have been dealing with the hierarchical verilog source files a lot lately and can comment that for this specific case you have a few options:

    1.     Create verilog cellviews in your library for all the modules that are present within hierarchy  and copy the content of included files in corresponding cellview (sync_a,sync_b) and don't forget to setup switch and and stop list correctly ( verilog shall not be in the stop list so that the config can proceed exploring the hierarchy)

    2.  In theory you can try another option is to leave the internals of the sync_module verilog file to be handled by a compiler and xcelium/ncsim. In this case you can bind the instance of the sync_block to either "Specify Reference verilog" . However this does not work for the verilog files that contain some hierarchy within .You can specify the verilog or any other file via GUI ( module name must match with the one in config. You will have to configure additional argument for dig simulator and add include directory path using -incdir=pathtotetdir

    3.     Another alternative is similar top previous option but you can bind the instance of the sync_block to  "Mark as External HDL Text" .In this case you will have to setup additional arguments for dig simulator:
          - one to link the verilog file of sync module for dig simuator  using -F path_to_sync_modulefile/verilog_file_name
          - and similar to option #2 setup include path to include directory using -incdir=path_to_test_dir


    4.     I prefer way with "top"  verilog instance bound to  "Mark as External HDL Text"  and  making a my own library via make file and. Example of mylibfile content  :
          -incdir=pathtomyincdir
          -makelib MyTestLib
              path_tofile/filename1
              ..
              path_tofile/filenamex
          -endlib

          Such  file is then included to dig simulator via -f /pathtofile/mylibfile or -F pathtofile/mylibife option.


    Option 3 is ok when you are dealing with simple hierarchies while  personally prefer #4 to any other options since it has a less number of extra steps and its beneficial when working with more complex hierarchy then just 1 level.

    • 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