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 100The 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.