History :
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Beginning
Verilog was one of the first modern hardware description languages to be invented. It was created by Prabhu Goel and Phil Moorby during the winter of 1983/1984. The wording for this process was “Automated Integrated Design Systems” (later renamed to Gateway Design Automation in 1985) as a hardware modeling language. Gateway Design Automation was purchased by Cadence Design Systems in 1990. Cadence now has full proprietary rights to Gateway’s Verilog and the Verilog-XL, the HDL-simulator that would become the de facto standard (of Verilog logic simulators) for the next decade. Originally, Verilog was intended to describe and allow simulation; only afterwards was support for synthesis added.
Verilog-95
With the increasing success of VHDL at the time, Cadence decided to make the language available for open standardization. Cadence transferred Verilog into the public domain under the Open Verilog International (OVI) (now known as Accellera) organization. Verilog was later submitted to IEEE and became IEEE Standard 1364-1995, commonly referred to as Verilog-95.
In the same time frame Cadence initiated the creation of Verilog-A to put standards support behind its analog simulator Spectre. Verilog-A was never intended to be a standalone language and is a subset of Verilog-AMS which encompassed Verilog-95.
Verilog 2001
Extensions to Verilog-95 were submitted back to IEEE to cover the deficiencies that users had found in the original Verilog standard. These extensions became IEEE Standard 1364-2001 known as Verilog-2001.
Verilog-2001 is a significant upgrade from Verilog-95. First, it adds explicit support for (2’s
complement) signed nets and variables. Previously, code authors had to perform signed operations
using awkward bit-level manipulations (for example, the carry-out bit of a simple 8-bit addition
required an explicit description of the Boolean algebra to determine its correct value). The same
function under Verilog-2001 can be more succinctly described by one of the built-in operators: +, -, /,
*, >>>. A generate/end generate construct (similar to VHDL’s generate/end generate) allows Verilog2001 to control instance and statement instantiation through normal decision operators (case/if/else).
Using generate/end generate, Verilog-2001 can instantiate an array of instances, with control over the
connectivity of the individual instances. File I/O has been improved by several new system tasks. And
finally, a few syntax additions were introduced to improve code readability (e.g. always @*, named
parameter override, C-style function/task/module header declaration).
Verilog-2001 is the dominant flavor of Verilog supported by the majority of commercial EDA
software packages.
Verilog 2005
Not to be confused with System Verilog, Verilog 2005 (IEEE Standard 1364-2005) consists of minor corrections, spec clarifications, and a few new language features (such as the uwire keyword).
A separate part of the Verilog standard, Verilog-AMS, attempts to integrate analog and mixed signal modeling with traditional Verilog.
System Verilog
System Verilog is a superset of Verilog-2005, with many new features and capabilities to aid design verification and design modeling. As of 2009, the System Verilog and Verilog language standards were merged into System Verilog 2009 (IEEE Standard 1800-2009).
The advent of hardware verification languages such as Open Vera, and Verisity’se language encouraged the development of Super log by Co-Design Automation Inc. Co-Design Automation Inc was later purchased by Synopsys. The foundations of Super log and Vera were donated to Accellera, which later became the IEEE standard P1800-2005: System Verilog.
LEVELS OF DESIGN DESCRIPTION
Circuit Level
At the circuit level, a switch is the basic element with which digital circuits are built. Switches can be combined to for inverters and other gates at the next higher level of abstraction. Verilog has the basic MOS switches built into its constructs, which can be used to build basic circuits like inverters, basic logic gates, simple 1-bit dynamic and static memories. They can be used to build up larger designs to simulate at the circuit level, to design performance critical circuits. Fig.1 shows the circuit of an inverter suitable for description with the switch level constructs of Verilog.
Gate Level
At the next higher level of abstraction, design is carried out in terms of basic gates. All the
basic gates are available as ready modules called “Primitives.” Each such primitive is defined in
terms of its inputs and outputs. Primitives can be incorporated into design descriptions directly. Just
as full physical hardware can be built using gates, the primitives can be used repeatedly and
judiciously to build larger systems. Fig.2 shows an AND gate suitable for description using the gate
primitive of Verilog. One should know the structure of the design to build the model here. One can also build hierarchical circuits at this level. However, beyond 20 to 30 of such gate primitives in a circuit, the design description becomes unwieldy; testing and debugging become laborious.
- Pending – fig1(inverter at circuit level) and fig 2(and gate at gate level)
Data Flow
Data flow is the next higher level of abstraction. All possible operations on signals and variables are represented here in terms of assignments. All logic and algebraic operations are accommodated. The assignments define the continuous functioning of the concerned block. At the data flow level, signals are assigned through the data manipulating equations. All such assignments are concurrent in nature. The design descriptions are more compact than those at the gate level. Fig.3 shows an A-O-I relationship suitable for description with the Verilog constructs at the data flow level.
Behavioral Level
Behavioral level constitutes the highest level of design description; it is essentially at the system level itself. With the assignment possibilities, looping constructs and conditional branching possible, the design description essentially looks like a “C” program. The statements involved are “dense” in function. Compactness and the comprehensive nature of the design description make the development process fast and efficient. Fig. 4 shows an A-O-I gate expressed in pseudo code suitable
for description with the behavioral level constructs of Verilog.
- Pending – fig3(data flow level) and fig4(behavioral level)
The Overall Design Structure in Verilog
The possibilities of design description statements and assignments at different levels necessitate their accommodation in a mixed mode. In fact the design statements coexisting in a seamless manner within a design module is a significant characteristic of Verilog. Thus Verilog facilitates the mixing of the above-mentioned levels of design. A design built at data flow level can be instantiated to form a structural mode design. Data flow assignments can be incorporated in designs which are basically at behavioral level.
CONCURRENCY
In an electronic circuit all the units are to be active and functioning concurrently. The voltages and currents in the different elements in the circuit can change simultaneously. In turn the logic levels too can change. Simulation of such a circuit in an HDL calls for concurrency of operation. A number of activities – may be spread over different modules – are to be run concurrently here. Verilog simulators are built to simulate concurrency. (This is in contrast to programs in the normal languages like C where execution is sequential). Concurrency is achieved by proceeding with simulation in equal time steps. The time step is kept small enough to be negligible compared with the propagation delay values. All the activities scheduled at one time step are completed and then the simulator advances to the next time step and so on. The time step values refer to simulation time and not real time. One can redefine timescales to suit technology as and when necessary and carry out test runs.
In some cases the circuit itself may demand sequential operation as with data transfer and memory-based operations. Only in such cases sequential operation is ensured by the appropriate usage of sequential constructs from Verilog HDL.
SIMULATION AND SYNTHESIS
The design that is specified and entered as described earlier is simulated for functionality and fully debugged. Translation of the debugged design into the corresponding hardware circuit (using an FPGA or an ASIC) is called “synthesis.” The tools available for synthesis relate more easily with the gate level and data flow level modules. The circuits realized from them are essentially direct translations of functions into circuit elements. In contrast many of the behavioral level constructs are not directly synthesizable; even if synthesized they are likely to yield relatively redundant or wrong hardware. The way out is to take the behavioral level modules and redo each of them at lower levels. The process is carried out successively with each of the behavioral level modules until practically the full design is available as a pack of modules at gate and data flow levels (more commonly called
the “RTL level”).
FUNCTIONAL VERIFICATION
Testing is an essential ingredient of the VLSI design process as with any hardware circuit. It has two dimensions to it – functional tests and timing tests. Both can be carried out with Verilog. Often testing or functional verification is carried out by setting up a “test bench” for the design. The test bench will have the design instantiated in it; it will generate necessary test signals and apply them to the instantiated design. The outputs from the design are brought back to the test bench for further analysis. The input signal combinations, waveforms and sequences required for testing are all to be decided in advance and the test bench configured based on the same.
The test benches are mostly done at the behavioral level. The constructs there are flexible enough to allow all types of test signals to be generated.
In the process of testing a module, one may have to access variables buried inside other modules instantiated within the master module. Such variables can be accessed through suitable hierarchical addressing.
SYSTEM TASKS
A number of system tasks are available in Verilog. Though used in a design description, they are not part of it. Some tasks facilitate control and flow of the testing process. The values of signals in a module can be displayed in the course of simulation. The tasks available for the purpose display them in desired formats. Reading data from specified files into a module and writing back into files are also possible through other tasks.Timescale can be changed prior to simulation with the help of specific tasks for the purpose.
A set of system functions add to the flexibility of test benches: They are of three categories:
• Functions that keep track of the progress of simulation time
• Functions to convert data or values of variables from one format to another
• Functions to generate random numbers with specific distributions.
There are other numerous system tasks and functions associated with file operations, PLAs, etc.
PROGRAMMING LANGUAGE INTERFACE (PLI)
PLI provides an active interface to a compiled Verilog module. The interface adds a new dimension to working with Verilog routines from a C platform. The key functions of the interface are as follows:
• One can read data from a file and pass it to a Verilog module as input. Such data can be test vectors or other input data to the module. Similarly, variables in Verilog modules can be accessed and their values written to output devices.
• Delay values, logic values, etc., within a module can be accessed and altered.
• Blocks written in C language can be linked to Verilog modules.
MODULE
Any Verilog program begins with a keyword called a “module.” A module is the name given to any system considering it as a black box with input and output terminals as shown in Fig.5. The terminals of the module are referred to as ‘ports’. The ports attached to a module can be of three types:
• input ports through which one gets entry into the module; they signify the input signal terminals of the module.
• output ports through which one exits the module; these signify the output signal terminals of the module.
• inout ports: These represent ports through which one gets entity into the module or exits the module; these are terminals through which signals are input to the module sometimes; at some other times signals are output from the module through these.
Whether a module has any of the above ports and how many of each type are present depend solely on the functional nature of the module. Thus one module may not have any port at all, another may have only input ports, while a third may have only output ports, and so on.
All the constructs in Verilog are centered on the module. They define ways of building up, accessing, and using modules. The structure of modules and the mode of invoking them in a design are discussed here.
A module comprises a number of “lexical tokens” arranged according to some predefined order. The possible tokens are of seven categories:
- White spaces
- Comments
- Operators
- Numbers
- Strings
- Identifiers
- Keywords
- Pending fig5(Representation of module)
The rules constraining the tokens and their sequencing will be dealt with as we progress. For the present let us consider modules. In Verilog any program which forms a design description is a “module.” Any program written to test a design description is also a “module.” The latter are often called as “stimulus modules” or “test benches.” A module used to do simulation has the form shown in Fig.6. Verilog takes the active statements appearing between the “module” statement and the “endmodule” statement and interprets all of them together as forming the body of the module. Whenever a module is invoked for testing or for incorporation into a bigger design module, the name of the module (“test” here) is used to identify it for the purpose.
- Pending fig6(simulation module)
Consider the IC 7430, an eight input NAND gate. In any design using it, the IC can be looked up on as a black box with eight input leads and one output lead (Fig.7a). Three aspects characterize the IC – its function, its input leads, and its output lead. Other ICs may have more output leads. A NAND gate module is defined in an analogous mariner in terms of its function, input leads and the output
lead. The module used to describe the circuit here also follows the earlier format; that is, the “module” statement signifies the beginning of the module, the “endmodule” statement signifies the end of the module. However, the initial statement “module” has to be more elaborate with the input and the output ports forming part of it(fig.7b).
- Pending – fig7a and 7b (8 input nand gate)
The same type of IC – 7430 – may be repeatedly used in a circuit. Each time it is used, a different name is assigned to it in the design sheet. Part of such a typical design sheet will look as in Fig.8. The associated table (Table 1) allows us to identify each type of IC to be used and put in its proper place. An automated design description can use a module defined above, repeatedly in a number of places as in the circuit of Fig.8.
- Pending – fig 8(circuit diagram), table 1(list of IC number) and fig 9(instantiation of module)
The following observations are in order here:
- The designer has defined a specific function within a module; the module is assigned the name “nand_gate.”
- The nand_gate can be invoked (instantiated) by him in a design as many times as desired.
- Each instantiation has to be assigned a separate identifier name by him (called “IC1”, “IC2”,etc).
- As part of the instantiation declaration, the input and output terminals are to be defined. The convention followed is to stick to the same order as in the module declaration. It is further illustrated in Fig.9.
Some modules may have a large number of ports. Sticking to the order of the ports in an instantiation is likely to cause (human) errors. An alternative (and sometimes more convenient) form of instantiation is also possible – shown in Fig.10. The terminal identifications are explicit (though elaborate) here. Further one need not stick to the order of the ports as they appear in the module definition. With such a form of port assignments, the possibility of errors is considerably reduced.
The following aspects of the modules and their instantiation are noteworthy:
- Each module can be defined only once.
- Module definitions are to be done independently. One module cannot be defined inside
another – they cannot be nested. - Any module can be instantiated inside another any number of times. Each instantiation
has to be done with a separate name assigned to it.
- Pending – Fig.10 a) A typical circuit block b) Its instantiation
LANGUAGE CONSTRUCTS AND CONVENTIONS
INTRODUCTION
The constructs and conventions make up a software language. A clear understanding and familiarity of these is essential for the mastery of the language. Verilog has its own constructs and conventions. In many respects they resemble those of C language.
Any source file in Verilog (as with any file in any other programming language) is made up of a number of ASCII characters. The characters are grouped into sets – referred to as “lexical tokens.” A lexical token in Verilog can be a single character or a group of characters. Verilog has 7 types of lexical tokens – operators, keywords, identifiers, white spaces, comments, numbers, and strings.
Verilog is a case-sensitive language like C. Thus sense, Sense, SENSE, sENse,…etc., are all treated as different entities / quantities in Verilog.
KEYWORDS
The keywords define the language constructs. A keyword signifies an activity to be carried out, initiated, or terminated. As such, a programmer cannot use a keyword for any purpose other than that it is intended for. All keywords in Verilog are in small letters and require to be used as such (since Verilog is a case- sensitive language). All keywords appear in the text in New Courier Bold-type letters.
Examples:
- module<— signifies the beginning of a module definition.
- endmodule<— signifies the end of a module definition.
- begin<— signifies the beginning of a block of statements.
- end<— signifies the end of a block of statements.
- if<— signifies a conditional activity to be checked
- while<— signifies a conditional activity to be carried out.
IDENTIFIERS
Any program requires blocks of statements, signals, etc., to be identified with an attached nametag. Such nametags are identifiers. It is good practice for us to use identifiers, closely related to the significance of variable, signal, block, etc., concerned. This eases understanding and debugging of any program.
e.g., clock, enable, gate_1,…
There are some restrictions in assigning identifier names. All characters of the alphabet or an underscore can be used as the first character. Subsequent characters can be of alphanumeric type, or the underscore (_), or the dollar ($) sign – for example
name, name. Name, namel, namej, . . . <- all these are allowed as identifiers
name aa<— not allowed as an identifier because of the blank ( “name” and “aa” are interpreted as two different identifiers)
$name<— not allowed as an identifier because of the presence of “$” as the first character.
1_name<— not allowed as an identifier, since the numeral “1” is the first character
@name<— not allowed as an identifier because of the presence of the character
A+b<— not allowed as an identifier because of the presence of the character “+”
An alternative format makes it is possible to use any of the printable ASCII characters in an identifier. Such identifiers are called “escaped identifiers”; they have to start with the backslash (\) character. The character set between the first backslash character and the first white space encountered is treated as an identifier. The backslash itself is not treated as a character of the identifier concerned.
Examples
\b=c
\control-signal
\&logic
\abc// Here the combination “abc” forms the identifier.
It is preferable to use the former type of identifiers and avoid the escaped identifiers; they may be reserved for use in files which are available as inputs to the design from other CAD tools.
WHITE SPACE CHARACTERS
Blanks (\b), tabs (\t), newlines (\n), and form feed form the white space characters in Verilog. In any design description the white space characters are included to improve readability. Functionally, they separate legal tokens. They are introduced between keywords, keyword and an identifier, between two identifiers, between identifiers and operator symbols, and so on. White space characters have significance only when they appear inside strings.
COMMENTS
It is a healthy practice to comment a design description liberally – as with any other program. Comments are incorporated in two ways. A single line comment begins with “//” and ends with a new line – for example
module d ff (Q,dp,clk); //This is the design description of a D flip-flop.
//Here Q is the output.
// dp is the input and clk is the clock.
One can incorporate multiline comments also without resorting to “//” at every line. For such
multiline comments “/*” signifies the beginning of a comment and “*/” its end. All lines appearing between these two symbol combinations are together treated as a single block comment – for example
module d ff (Q, dp, elk);
/* This module forms the design description of a d flip-flop wherein Q is the output of the flip-flop, dp is the data input and elk the clock input*/
Multiline comments cannot be nested. For example, the following comment is not valid. /*The following forms the design description of a D flip-flop /*which can be modified to form other types of flip-flops*/ with clock and data inputs.*/
A valid alternative can be as follows: –
/*The following forms the design description of a D flip-flop (which can be modified to form other types of flip-flops) with clock and data inputs.*/
NUMBERS
Frequently numbers need to be specified in a design description. Logic status of signal lines, buses, delay values, and numbers to be loaded in registers are examples. The numbers can be of integer type or real type.
Integer Numbers
Integers can be represented in two ways. In the first case it is a decimal number -signed or unsigned; an unsigned number is automatically taken as a positive number. Some examples of valid number representations of this category are given below:
2
25
253
-253
The following are invalid since non decimal representations are not permissible.
2a
B8
-2a
Normally the number is taken as 32 bits wide. Thus all the following numbers are assigned 32 bits of width
2
25
253
-2
-25
-253
If a design description has a number specified in the form given here, the circuit synthesizer program will assign 32 bits of width to it and to all the related circuits. Hence all such number specifications – despite their simplicity – may be avoided in design descriptions. Number representation in this form may preferably be restricted to test benches.
The alternate form of number representation is more specific — though elaborate. The number can be specified in binary, octal, decimal, or hexadecimal form. The representation has three tokens with an optional sign preceding it. Fig.12 shows typical number representations with the significance of each field explained separately.
Pending : Fig.12 Representation of a number in verilog
Pending : Table 2 Different ways of number representations in verilog
Observations:
• The characters used to specify the base number, the sign or the magnitude can be in either case (Thus A, B, C, D, E, or F can be used in place of a, b, C, d, e, or f, respectively, to specify the concerned hex digit. X or Z can be used in place of x or z value, respectively).
• The single quote character in the base field has to be immediately followed by the character representing the base. Intervening white spaces are not allowed. However, such white spaces can precede the magnitude field.
• Negative numbers are represented in 2’s complement form. The question mark character – “?” – can be used in place of z. The underscore character can be used anywhere after the first character. It adds to the readability. It is normally ignored.
• If the number size is smaller than the size specified, the size is made up by padding O’s to the left. However, if the leftmost bit is a x or z, the same is padded to the left.
• Left truncation and right extension can often be confusing. It is preferable to specify the numbers fully.
Real Numbers
Real numbers can be specified in decimal or scientific notation. The decimal notation has the form
-a.b
where a, b, the negative sign, and the decimal point have the usual significance. The fields a and b must be present in the number. A number can be specified in scientific notation as
4.3e2
where 4.3 is the mantissa and 2 the exponent. The decimal equivalent of this number is 430.
Other examples of numbers represented in scientific notation are —4.3e2, —4.3e—2, and
4.3e—2. The representations are common.
STRINGS
A string is a sequence of characters enclosed within double quotes. A string must be contained on a single line; that is, it cannot be carried over to two lines with a carriage return. Special characters are specified by preceding them with the “\” character. Verilog treats a string as a sequence of ASCII characters – for example,
“This is a string”
“This string is one \t with a gap in between”
“This is called a \”string\””
When a string of ASCII characters as above is an operand in an expression, it is treated as a binary number. This binary number is formed by replacing each ASCII character by 8 bits – a 0 bit followed by the 7-bit ASCII equivalent – and treating the resulting binary sequence as a single binary number. For example, the statement (with P defined as a 32-bit vector beforehand)
P = “numb”
assigns the binary value
0110 11100111 0101 0110 1101 01100010
to P (0110 1110, 0111 0101, 0110 1101 and 0110 0010 are the 8-bit equivalents of the letters n, u, m, and b, respectively).
LOGICAL VALUES
- Signal lines, logic values appearing on signal lines, etc., can normally take two logic levels:
1 <— signifies the 1 or high or true level
0 <— signifies the 0 or low or false level. - Two additional levels are also possible – designated as x and z. Here x represents an unknown or an uninitialized value. This corresponds to the don’t- care case in logic circuits, z represents / signifies a high impedance state. This is possible when a signal line is tri-stated or left floating. The following are noteworthy here:
- When a variable in an expression is in the z state, the effect is the same as it having z value. But when an input to a gate is in the z state, it is equivalent to having the x value.
- The MOS switches form an exception to the above. If the input to a MOS switch is in the z state, its output too remains at the z state.
- With a few exceptions all data types in Verilog can take on all the 4 logic values or levels. The event is an exception to this. It cannot store any value. The tri-reg cannot take on the z value.
- A logic state can have a “strength” associated with it. It is a quantitative representation of the internal impedance value of the corresponding hardware circuit; a change in the internal impedance is reflected as a corresponding change in the strength level. Whenever the logic values from two sources are combined, there can be a conflict and the resulting contention has to be resolved.
STRENGTHS
The logic levels are also associated with strengths. In many digital circuits, multiple
assignments are often combined to reduce silicon area or to reduce pin- outs. To facilitate
this, one can assign strengths to logic levels. Verilog has eight strength levels – four of these
are of the driving type, three are of capacitive type and one of the hi-Z types. Details are
given in Table 3.
When a signal line is driven simultaneously from two sources of different strength
levels, the stronger of the two prevails. A few illustrative examples are considered here.
- If a signal line a is driven by two sources — b at 1 level with strength “strong l” and C at level 0 with strength “pull O”- a will take the value 1.
- If a signal line a is driven by two sources — b at 1 level with strength “pull l” and C at level 0 with strength “strong O,” a will take the value 0.
- If a signal line a is driven by two sources — b at 1 level with strength “strong l” and C at level 0 with strength “strong O,” a will take the value x (indeterminate).
- If a signal line a is driven by two sources — b at 1 level with strength “weak l” and C at level 0 with strength “largeO,” a will take the value 0.
- Pending : Table 3 Details of strengths in verilog
DATA TYPES
The data handled in Verilog fall into two categories:
(i) Net data type
(ii) Variable data type
The two types differ in the way they are used as well as with regard to their respective hardware structures. Data type of each variable or signal has to be declared prior to its use. The same is valid within the concerned block or module.
Nets :A net signifies a connection from one circuit unit to another. Such a net carries the value of the signal it is connected to and transmits to the circuit blocks connected to it. If the driving end of a net is left floating, the net goes to the high impedance state. A net can be specified in different ways.
wire: It represents a simple wire doing an interconnection. Only one output is connected to a wire and is driven by that.
tri: It represents a simple signal line as a wire. Unlike the wire, a tri can be driven by more than one signal outputs. Functionally, wire and tri are identical. Distinct nomenclatures are provided for the
convenience of assigning roles.
Variable Data Type
A variable is an abstraction for a storage device. It can be declared through the keyword reg and stores the value of a logic level: 0, 1, x, or z. A net or wire connected to a reg takes on the value stored in the reg and can be used as input to other circuit elements. But the output of a circuit cannot be connected to a reg. The value stored in a reg is changed through a fresh assignment in the program, time, integer, real, and real time are the other variable types of data.
SCALARS AND VECTORS
Entities representing single bits whether the bit is stored, changed, or transferred are called “scalars.” Often multiple lines carry signals in a cluster – like data bus, address bus, and so on. Similarly, a group of regs stores a value, which may be assigned, changed, and handled together. The collection here is treated as a “vector.” Fig.13 illustrates the difference between a scalar and a vector, wr and rd are two scalar nets connecting two circuit blocks circuit 1 and circuit2.b is a 4-bit-wide vector net connecting the same two blocks.b[0], b[1], b[2], and b[3] are the individual bits of vector b. They are “part vectors.” A vector reg or net is declared at the outset in a Verilog program and hence treated as such. The range of a vector is specified by a set of 2 digits (or expressions evaluating to a
digit) with a colon in between the two. The combination is enclosed within square brackets.
Pending : Fig.13 Illustration of Scalars and Vectors
Examples:
wire[3:0] a; /* a is a four bit vector of net type; the bits are designated as a[3], a[2], a[1]and a[0]. */
reg[2:0] b; /* b is a three bit vector of reg type; the bits are designated as b[2], b[1] and b[0]. */
reg[4:2] C; /* C is a three bit vector of reg type; the bits are designated as c[4], c[3] and c[2]. */
wire[-2:2] d; /* d is a 5 bit vector with individual bits designated as d[-2], d[-1], d[0], d[1] and d[2]. */
Whenever a range is not specified for a net or a reg, the same is treated as a scalar – a single bit quantity. In the range specification of a vector the most significant bit and the least significant bit can be assigned specific integer values. These can also be expressions evaluating to integer constants – positive or negative. Normally vectors – nets orregs – are treated as unsigned quantities. They have to be specifically declared as “signed” if so desired.
Examples
wire signed[4:0] num; // num is a vector in the range -16 to +15. reg signed
[3:0]numl; // numl is a vector in the range -8 to +7.
PARAMETERS
In some designs, certain parameter values are not committed at the outset. Proportionality constants, frequency-scaling levels, number of taps in digital filters, etc., are typical examples. There are also situations where the size of the design is left open and decided at a later stage. Bus width, LIFO depth, and memory size are such quantities which may be committed later. All such constants can be declared as parameters at the outset in a Verilog module, and values can be assigned to them; for example,
parameter WOrd_size =16;
parameter wordsize = 16, memsize = 256;
Such parameter assignments are made at compiler time. The parameter values cannot be changed (normally) at runtime. However, a parameter that has been assigned a value in a module definition can have its value changed at runtime – that is, when the module is used at runtime in some other design (i.e., instantiated) or when it is tested. Such modifications are carried out through a “def parameter” statement. The parameter assignment done as part of parameter declaration can have the appropriate constant on the right-hand side of the assignment statement, as was the case above. The assignment can also have algebraic expressions on the right hand side. Such expressions can involve constants and other parameters declared already; for example
Parameter word size = 16, factor = word_size/2;
OPERATORS
Verilog has a number of operators akin to the C language. These are of three types:
a. Unary: the unary operator is associated with a single operand. The operator precedes the operand – for example, ~a.
b. Binary: the binary operator is associated with two operands. The operator appears between the two operands – for example, a&b.
c. Ternary: the ternary operator is associated with three operands. The two operators together constitute a ternary operation. The two operators separate the three operands – for example
a?b:C // Here the operators “?” and “:” together define an operation.