Commit Graph

8 Commits

Author SHA1 Message Date
Martin Whitaker a4973c217d Support parameter, localparam, and event declarations in any scope.
Currently, parameters and localparams declared in tasks, functions,
generate blocks, and named blocks are placed in the parent module
scope. Event declarations in these scopes are not permitted (a
syntax error is reported). This patch corrects this behaviour, so
that all the above declarations are accepted and are placed in the
scope in which they are declared.

Note that the IEEE standard does not permit parameter declarations
in generate blocks. This patch causes the parser to reject such
declarations.
2008-09-19 20:23:14 -07:00
Stephen Williams 03e306c805 Infrastructure for parsing analog process statements.
Organize the parsing infrastructure for parsing analog processes,
including holding them in scopes, and collecting analog statements.
2008-07-27 15:02:09 -04:00
Stephen Williams c87e629150 Better handle nesting of scopes inside generate blocks.
Within generate schemes it is possible to have nested scopes, even
more liberally then outside generate blocks. So see to it that the
scopes properly stack with the generate blocks, and that wires and
behaviors are put in the right scopes.
2008-06-19 21:31:53 -07:00
Stephen Williams 15481a9520 Elaborate block scopes burried in generate schemes.
Named begin/end blocks burried within generate schemes need to be
elaborated. Handle this by remembering to elaborate_scope on the
statements within the generate scheme.

In the process, clean up/regularize some of the member names and
methods.
2008-06-17 21:45:37 -07:00
Stephen Williams 8d3febff2b Keep processes in proper lexical scope
Normally processes are found in the lexical scope of a module, but
there are special cases where processes (other then task/function
definitions) are in other lexical scopes. The most likely case is
initilizations that are in the lexical scope where the assigned
variable is declared.

In the process, the behaviors list is kept in the base PScope class
instead of the Module or any other derived lexical scope class.
2008-03-03 20:49:52 -08:00
Stephen Williams 8e704cbf93 Rework handling of lexical scope
Move the storage of wires (signals) out of the Module class into
the PScope base class, and instead of putting the PWires all into
the Module object, distribute them into the various lexical scopes
(derived from PScope) so that the wire names do not need to carry
scope information.

This required some rewiring of elaboration of signals, and rewriting
of lexical scope handling.
2008-02-24 19:40:54 -08:00
Stephen Williams b0e4a6884a Objects of lexical scope use PScope base class.
All the pform objects that represent lexical scope now are derived
from the PScope class, and are kept in a lexical_scope table so that
the scope can be managed.
2008-02-15 21:20:24 -08:00
Stephen Williams 3f2fa29482 Factor compile-time scopes into PScope class
Modules, functions and tasks are named scopes so derive them all
from the PScope base class. These items all take scoped items, so
the eventual plan is to move these items into PScope.
2008-02-13 19:59:05 -08:00