Keyword Usage in Verilog

Chapter 4 · Page 4.7 · Lexical Conventions

1. What a Keyword Is

A keyword is a word the language has claimed. It always means the same thing, in every Verilog file anyone has ever written, and you cannot use it as a name of your own.

always @(posedge clk) count_q <= count_q + 4'd1;

always and posedge are keywords. clk and count_q are identifiers you chose (Chapter 4.6). The line means what it means because always is fixed and count_q is not.

Try to use one as a name and the file will not compile:

// reg wire;     // 'wire' already means something
// reg time;     // so does 'time'

2. You Do Not Need to Memorise These

This is the most useful thing on the page, so it comes second rather than last.

The reason keyword lists feel intimidating is that they are presented as something to learn. They are not. In practice:

• You will absorb the common ones by writing RTL. module, wire, reg, assign, always, begin, end, if, case — you already know these from Chapter 3 without having studied a list.
• The rare ones you will never type. pulsestyle_ondetect and noshowcancelled are real Verilog keywords. You can have a long career without meeting either.
• Descriptive names never collide. data_valid, count_q, addr_next, rd_en — no keyword has ever looked like these, and no keyword ever will.

Keywords are something to recognise, not something to recite. Name things descriptively and the collision problem mostly disappears.

The sections below are for recognition. Read them once to see the shape of the language; do not try to hold them.

3. The Keywords You Will Meet

Grouped by what they do. This is the working set — the words that turn up in ordinary RTL and testbench code, not an exhaustive roster. The authoritative complete list lives in Annex B of the IEEE 1364 standard, which is where to look if you ever need certainty about an unusual word.

Two observations worth more than the tables themselves. First, notice how many of them you already recognise — the module, port, procedural and control-flow groups are almost entirely Chapter 3 vocabulary. Second, notice that the ones you do not recognise are clustered in areas you have not reached yet: gate and switch primitives are Chapters 11 and 12, specify blocks are timing work. The list grows into you as the course does.

4. One Word, Two Jobs

or appears twice in the tables above, and that is not a mistake:

// 1. In an event control list — "on either of these events"
always @(posedge clk or negedge rst_n) ...

// 2. As a gate primitive — an instance of an OR gate
or u_gate (y, a, b);

Same word, two jobs, and Verilog works out which is meant from where it appears. You do not have to do anything about this — but it is worth seeing once, because it explains why "what does this keyword mean" sometimes has more than one answer.

5. The List Is Fixed by the Standard

Keywords are not something a tool vendor adds. The set is fixed by the IEEE standard, and it changes only when the standard is revised.

This matters in one practical way. Code written against Verilog-1995 predates generate and signed, so a 1995-era file may work around their absence in ways that look odd today. Verilog-2001 is the baseline this course teaches and what tools default to.

6. Keywords Are Not the Only Reserved Words

Three different kinds of token are reserved in a Verilog file, and they are reserved in three different ways. Telling them apart is a genuine reading skill.

`timescale 1ns/1ps          // directive — backtick

module tb;                  // keyword

    initial $display("go"); // keyword, then system task

endmodule                   // keyword

$display is not a keyword. It is reserved by its $ prefix instead — which is exactly why Chapter 4.6 §7 says an identifier may not begin with $. Directives work the same way with the backtick.

The practical consequence: these are three separate namespaces, so a name cannot accidentally collide with a system task or a directive. The only collision you can have is with a keyword. What system tasks do is Chapter 8; what directives do is Chapter 7.

7. When a Keyword Is the Word You Wanted

Occasionally the natural name for a signal is a keyword. Several of them are ordinary engineering vocabulary: time, output, input, signed, force, event, and, or, not.

The fix is always to say what you actually mean, which usually produces a better name anyway:

reg [31:0] time_q;         // not 'time'      — and now it reads as registered
reg [7:0]  input_data;     // not 'input'     — and now it says what kind of input
reg        and_result;     // not 'and'       — and now it says it is a result
reg        force_reload;   // not 'force'

There is a second option you should know about and not use. The escaped form from Chapter 4.6 §8 will let you write \time and get a signal literally named time. It parses. It also guarantees that every future reader stops to work out why a keyword was forced into service as a name.

8. A Note on SystemVerilog

SystemVerilog is a different standard (IEEE 1800) with a considerably larger keyword set — it adds the words for classes, interfaces, assertions, coverage, two-state types and much else.

One consequence is worth carrying, because it is the classic problem when old code meets new tools:

Words that were perfectly good identifiers in Verilog are keywords in SystemVerilog. bit, logic, int, string, class and interface are all legal signal names in a .v file and all reserved in a .sv one.

So a file that compiled happily for years can stop compiling the moment it is treated as SystemVerilog. The remedy is the same as §7: rename. bit becomes bit_sel, int becomes idx, string becomes name_str.

That is as much as Chapter 4 needs. This course teaches Verilog-2001, and nothing else on this page changes because SystemVerilog exists.

9. Common Mistakes

Trying to learn the list. Keywords are recognised, not recited. Time spent memorising pulsestyle_ondetect is time not spent writing RTL.

Using a keyword as a signal name. reg time; will not compile. Rename to time_q or whatever the value actually is.

Forcing a keyword through the escaped form. \time works and should not be used.

Assuming $display is a keyword. It is a system task, reserved by its $ prefix — a different mechanism, a different namespace.

Carrying Verilog identifiers into SystemVerilog unchecked. A signal called bit or logic is fine in .v and reserved in .sv.

10. Exercises

Work each one out before reading the answers.

Exercise 1 — Keyword or identifier?

wire        data_q;
always @(posedge clk) count <= count + 1;

For each word — wire, data_q, always, posedge, clk, count — say whether it is a keyword or an identifier.

Exercise 2 — The same word twice

always @(posedge clk or negedge rst_n) ...

or u_gate (y, a, b);

or appears in both lines. What is it doing in each?

Exercise 3 — Name it anyway

You want a register that holds a timestamp, and the obvious name is time. What do you do, and what do you not do?

Exercise 4 — Which namespace?

Classify each: `define, $finish, endmodule, data_valid.

Exercise 5 — Why naming style matters

Why does naming signals count_q, addr_next and rd_en make the whole keyword-collision problem nearly disappear?

Answers

Exercise 1.

The keywords are the structural words — they would mean the same thing in any file. The identifiers are this design's own vocabulary.

Exercise 2. In the first line or separates two events in an event-control list: on a rising edge of clk, or a falling edge of rst_n. In the second it is a gate primitive, instantiating an OR gate named u_gate. One word, two jobs, distinguished by where it appears — §4.

Exercise 3. Do: rename. time_q if it is registered, timestamp if that is clearer, last_update_time if the extra words earn their place. The rename almost always produces a more informative name than time would have been.

Do not: write \time to force the keyword through as an escaped identifier. It parses and it is a signal to every later reader that something odd is going on.

Exercise 4.

Exercise 5. Because keywords are single, generic words — wire, time, force, and — and those names are compound and specific. A name that says what the signal is (count_q, addr_next, rd_en) is structurally the kind of name no keyword has. Good naming makes collisions an accident that stops happening.

11. Summary

• A keyword is a word the language owns. It always means the same thing and cannot be used as a name.
• You do not need to memorise the list. Recognise them, and let descriptive naming keep you clear of collisions.
• You already know most of the ones that matter — they are Chapter 3's vocabulary. The rest arrive with the chapters that need them.
• or has two jobs — event-control separator and OR-gate primitive — and context decides which.
• Three kinds of reserved token, three mechanisms: keywords reserved as words, system tasks by a leading $, directives by a leading backtick.
• When a keyword is the word you wanted, rename. time_q, not \time .
• SystemVerilog reserves more words than Verilog does, which is why a .v file with a signal called bit can stop compiling as .sv.

That completes Chapter 4. You can now read Verilog source text with nothing in it that is a mystery — whitespace, comments, identifiers, numbers, strings, operators and keywords. Next, Variables & Data Types moves from how the text is read to what the things you declare actually are.

Related Tutorials

• Lexical Conventions — Chapter 4 overview; the parent layer.
• Identifier Declaration — Chapter 4.6; the names that are yours rather than the language's.
• Compiler Directives — Chapter 7; the backtick-prefixed namespace.
• System Tasks & Functions — Chapter 8; the $-prefixed namespace.
• Variables & Data Types — Chapter 5; what comes next.
• RTL Designing — Chapter 3; where most of these keywords were first met.