It's very simple: the compiler uses the BNF to parse text token by token and recognizes what are called
productions . A good example of this is the text
If you were to send just this text through a Verilog compiler, you would get the following error:
** Error: abc.v(1): near "A": syntax error, unexpected IDENTIFIER
That's because at the top level of a Verilog source file, there are only three productions available
Code:
source_text ::= { description }
description ::=
module_declaration
| udp_declaration
| config_declaration
which basically means the first word in a Verilog source descriptions can only be one of
module,
primitive, or
config. The compiler could not match any of the productions with the token "A", so it throws a syntax error.
Now lets send the following code to the compiler:
you would get the following error
** Error: abc.v(4): near "<=": syntax error, unexpected <=, expecting IDENTIFIER
Note the error is now on the "<=" token and not the "A". That's because inside a
module_declaration, you are allowed any number of
module_item productions, one of which could have been a
module_instantiation like
But there no
module_item production that matches an identifier followed by '<='. So you get an error.
This process of parsing all your source text in productions keeps going until there is is no ambiguity left in what a token represents. Skipping ahead to a block of code that looks like
The compiler is parsing a set of procedural statements, or
statement_item productions. One of the production choices is
Code:
nonblocking_assignment ::=
variable_lvalue <= [ delay_or_event_control ] expression
There is no expression production in a
statement_itemso the first '<=' can only be matched as a nonblocking assignment construct. When the compiler parses the B <= C part of the statement, the only thing <= could match in an expression would be a less-than-or-equal operator.
Hope this helps.