Add support for parsing the SystemVerilog 'bind' construct

[rswarbrick]

This doesn't do anything useful yet: the patch just adds support for
the syntax to the lexer and parser and adds some tests to check the
syntax parses properly. This generates AST nodes, but doesn't yet
generate RTLIL.

Since our existing hierarchical_identifier parser doesn't allow bit
selects (so you can't do something like foo[1].bar[2].baz), I've also
not added support for a trailing bit select (the constant_bit_select
non-terminal in bind_target_instance in the spec). If we turn out to
need this in future, we'll want to augment hierarchical_identifier and
its other users too.

Note that you can't easily use the BNF from the spec:

bind_directive ::=
    "bind" bind_target_scope [ : bind_target_instance_list]
           bind_instantiation ;
  | "bind" bind_target_instance bind_instantiation ;

even if you fix the lookahead problem, because code like this matches
both branches in the BNF:

bind a b b_i (.*);

The problem is that 'a' could either be a module name or a degenerate
hierarchical reference. This seems to be a genuine syntactic
ambiguity, which the spec resolves (p739) by saying that we have to
wait until resolution time (the hierarchy pass) and take whatever is
defined, treating 'a' as an instance name if it names both an instance
and a module.

To keep the parser simple, it currently accepts this invalid syntax:

bind a.b : c d e (.*);

This is invalid because we're in the first branch of the BNF above, so
the a.b term should match bind_target_scope: a module or interface
identifier, not an arbitrary hierarchical identifier.

This will fail in the hierarchy pass (when it's implemented in a
future patch).

This is part of the commit queue in #2752, but has been split out to make reviewing easier.

[rswarbrick]

Hi all! It's been a month: is there anything I can do to help this get reviewed?

[zachjs]

Sorry for the delay! I'll review this today.

[zachjs]

This all seems very reasonable except for one minor comment. This doesn't introduce anything unprincipled and won't affect any existing designs.

[zachjs]

Is this change to cell_stmt necessary? The split out just_cell_stmt appears to only be used here.

[rswarbrick]

You're completely right! I think this is the fallout from some code when I was first getting this working. Reverted.