Verilog-XL Compiler Directives

Verilog-XL Compiler Directives

You can access information on the following Verilog-XL Version 2.7 features: Back to the Quick Reference main page

Comiler Compiler Directive Description
`accelerate
`noaccelerate
The `noaccelerate compiler directive causes Verilog-XL to stop applying the XL algorithm to the modules following the compiler directive.

The `accelerate compiler directive causes Verilog-XL to start re-applying the XL algorithm after a `noaccelerate compiler directive has been issued.

You can only specify these compiler directives outside of module definitions. You can have as many of these compiler directives in the source description as you want.

`autoexpand_vectornets The `autoexpand_vectornets compiler directive lets the compiler expand vectors as needed to form the proper connections between the elements of the source description.
`celldefine
`endcelldefine
The `celldefine and `endcelldefine compiler directives tag module instances as cell instances. More than one pair of `celldefine and `endcelldefine compiler directives can appear in a single source description.

Certain PLI access routines use cells for applications such as delay calculation. Verilog-XL does not mark macro modules (which it expands inline) as cell instances. Refer to the PLI 1.0 Reference and User Guide and the VPI Reference and User Guide for more information about access routines that recognize cells and the use of cells in delay calculation.

Note: You do not need to apply these compiler directives to cells extracted from libraries, because Verilog-XL automatically tags modules as cells unless you invoke it with the command-line plus option +nolibcell.

`default_decay_time The `default_decay_time compiler directive lets you specify the decay time for triregs whose declarations do not include a decay time specification. This directive applies to all of the triregs in all of the modules that follow it in the source description.

The `default_decay_time compiler directive must include an argument that specifies the charge decay time. You can enter this argument as a constant integer, as a real number, or as the character string infinite. The character string infinite specifies no charge decay in the triregs that follow the `default_decay_time directive.

The following example shows a use of the `default_decay_time compiler directive with a numerical argument. All triregs without a decay time specification in the modules that follow this `default_decay_time compiler directive have a charge decay time of 100 time units.

`default_decay_time 100
The following example shows a use of the `default_decay_time compiler directive with the character string infinite as an argument. Charge decay does not occur in triregs without a decay time specification in the modules that follow this `default_decay_time compiler directive.

`default_decay_time infinite
`default_nettype The `default_nettype compiler directive controls the net type created for implicit net declarations. You can use this directive only outside of module definitions. It affects all modules that follow the compiler directive, even across source file boundaries. Multiple `default_nettype compiler directives are allowed. The most recent compiler directive encountered controls the type of nets that are implicitly declared. You can specify any one of the following net types can be specified:

wire tri tri0 wand triand tri1 wor trior trireg
`default_rswitch_strength The `default_rswitch_strength compiler directive specifies the default drive strength of resistive switches in simulations that invoke the Switch-XL algorithm.
`default_switch_strength The `default_switch_strength compiler directive specifies the default drive strength of switches in simulations that invoke the switch-XL algorithm.
`default_trireg_strength The `default_trireg_strength compiler directive specifies the default charge strength of triregs in simulations that invoke the Switch-XL algorithm.
`define The `define compiler directive lets you create macros for text substitution and create macros to trigger the `ifdef compiler directive. You can use text macros both inside and outside module definitions.
`delay_mode_distributed The `delay_mode_distributed compiler directive specifies the distributed delay mode for all the modules that follow the directive in the source description.
`delay_mode_path The `delay_mode_path compiler directive specifies the path delay mode for all the modules that follow the directive in the source description.
`delay_mode_unit The `delay_mode_unit compiler directive specifies the unit delay mode for all the modules that follow the directive in the source description.
`delay_mode_zero The `delay_mode_zero compiler directive specifies the zero delay mode for all the modules that follow the directive in the source description.
`expand_vectornets The `expand_vectornets compiler directive causes Verilog-XL to expand all vector nets into a group of scalar nets, except those with the keyword vectored in their declarations.
`ifdef <macro_name>
`else
`endif
Optionally includes lines of source code during compilation. The `ifdef directive checks that a macro has been defined, and if so, compiles the code that follows. If the macro has not been define, Verilog-XL compiles the code (if any) following the optional `else directive. You can control what code is compiled by choosing whether to define the text macro, either with `define or with +define+. The `endif directive marks the end of the conditional code.
`include The `include compiler directive lets you insert the entire contents of a source file into another file during Verilog-XL compilation. The compilation proceeds as though the contents of the included source file appear in place of the `include command. You can use the `include compiler directive to include global or commonly-used definitions and tasks, without encapsulating repeated code within module boundaries.
`noexpand_vectornets The `noexpand_vectornets compiler directive causes no expansion to take place, except where explicitly specified by the keyword scalared in a vector net declaration.
`pre_16a_paths
`end_pre_16a_paths
The `pre_16a_paths and `end_pre_16a_paths compiler directives turn on and turn off the functionality of conditional paths characteristic of prior versions. Verilog-XL versions prior to 1.6a treat conditional paths as if their conditional expressions are always true. Libraries written for use with Verilog-XL versions prior to 1.6a contain conditional paths, and users of those libraries have become accustomed to performing Verilog-XL simulations in which paths described as conditional always simulate as if their conditions were true.

The `resetall compiler directive, similar to the `end_pre_16a_paths compiler directive , also turns off the functionality of conditional paths characteristic of prior versions. The effect of `pre_16a_paths compiler directive crosses file boundaries until Verilog-XL arrives at `end_pre_16a_paths or a `resetall compiler directive. Choosing to simulate SDPDs as unconditional paths can cause the suppression of some error checking introduced in Verilog-XL 1.6a, and differing results may occur when multiple paths connect an input and an output.

`protect
`endprotect
The `protect and `endprotect compiler directives mark regions in a source description that you want Verilog-XL to source protect when you invoke it with the +protect command-line plus option.
`protected
`unprotected
The `protected and `unprotected compiler directives are inserted inside a module definition by Verilog-XL's source protection methods. You can also use them outside a module definition to prevent that module from being seen.
`remove_gatenames
`noremove_gatenames
The `remove_gatenames compiler directive causes Verilog-XL to eliminate any gate instance names that you have specified in the modules you have defined between the compiler directives `remove_gatenames and `noremove_gatenames. You can only specify these compiler directives outside of module definitions.
`remove_netnames
`noremove_netnames
The `remove_netnames compiler directive causes Verilog-XL to eliminate the names of all nets from the data structure. You cannot use this compiler directive if it is necessary to refer to nets by hierarchical name, either from within the source description or interactively. This compiler directive is incompatible with named port connections.

The `noremove_netnames compiler directive causes Verilog-XL to stop eliminating the names of nets. You must specify compiler directives outside of modules. All of the modules between `remove_netnames and `noremove_netnames are affected.

`resetall The `resetall compiler directive resets all active compiler directives to their default values when it is encountered during compilation. This directive does not remove or redefine text macros as empty.

Use this directive to ensure that only the desired compiler directives in compiling a particular source file are active. The recommended usage is to place `resetall at the beginning of each source text file, followed immediately by the compiler directives desired for the file. This compiler directive is particularly important in library files and library directory files.

`switch default and `switch XL The `switch default compiler directive enables the default algorithm for simulating networks composed of bidirectional switches that follow the directive. The `switch XL compiler directive enables the Switch-XL algorithm for simulating the networks composed of unidirectional and bidirectional switches that follow the directive.

A `switch compiler directive that enables another algorithm for switch-level simulation cuts off the effect of the compiler directive.

`timescale The `timescale compiler directive specifies the time unit and precision of the modules that follow the directive. The time unit is the unit of measurement for time values, such as the simulation time and delay values. The time precision specifies how Verilog-XL rounds time values. The rounded time values that Verilog-XL uses are accurate to within the unit of time that you specify as the time precision. The smallest-specified time precision determines the accuracy at which Verilog-XL must run, and thus the precision affects simlation performance and memory consumption.
`unconnected_drive
`nounconnected_drive
The `unconnected_drive and `nounconnected_drive compiler directives cause unconnected input ports to be automatically pulled up (if pull1 is specified) or down (if pull0 is specified) instead of floating to the high-impedance value z. Inputs are pulled up or down in all modules between the compiler directives `unconnected_drive and `nounconnected_drive. You must specify these compiler directives only outside of modules.
`undef The `undef compiler directive lets you remove definitions of text macros created by the `define compiler directive and the +define+ command-line plus option. You can use the `undef compiler directive undefine a text macro that you use in more than one file.

If you use `undef to undefine a name not previously defined, Verilog-XL displays no error messages or warnings. The `undef compiler directive must be followed by a text macro name; otherwise, compilation results in a syntax error. Once you have undefined a text macro name, that name no longer shows up in the decompilation listing.

`uselib The `uselib compiler directive enables you to specify the paths that the compiler searches to find the definitions of the instantiations whose definitions are not part of the design description. These path specifications can include library files, library directories, and the extensions of the names of files in library directories.

Copyright 1990-98 Cadence Design Systems, Inc. All rights reserved. Printed in the United States of America. Cadence Design Systems, Inc., 555 River Oaks Parkway, San Jose, CA 95134, USA

Confidentiality Notice No part of this publication may be reproduced in whole or in part by any means (including photocopying or storage in an information storage/retrieval system) or transmitted in any form or by any means without prior written permission from Cadence Design Systems, Inc. (Cadence). Information in this document is subject to change without notice and does not represent a commitment on the part of Cadence. The information contained herein is the proprietary and confidential information of Cadence or its licensors, and is supplied subject to, and may be used only by Cadence's customer in accordance with, a written agreement between Cadence and its customer. Except as may be explicitly set forth in such agreement, Cadence does not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or usefulness of the information contained in this document. Cadence does not warrant that use of such information will not infringe any third party rights, nor does Cadence assume any liability for damages or costs of any kind that may result from use of such information.

RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013.