luke
/
iverilog
mirror of https://github.com/steveicarus/iverilog.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
iverilog/PScope.h

139 lines
4.2 KiB
C
Raw Normal View History

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-14 04:59:05 +01:00
#ifndef __PScope_H
#define __PScope_H
/*
Rework of lexical scope handling in parser. This patch modifies the parser to use a single stack to track lexical scopes, rather than starting a new stack for each generate construct.
2010-01-08 23:49:48 +01:00
* Copyright (c) 2008,2010 Stephen Williams (steve@icarus.com)
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-14 04:59:05 +01:00
*
* This source code is free software; you can redistribute it
* and/or modify it in source code form under the terms of the GNU
* General Public License as published by the Free Software
* Foundation; either version 2 of the License, or (at your option)
* any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
*/
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-17 22:25:59 +02:00
# include "LineInfo.h"
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-14 04:59:05 +01:00
# include "StringHeap.h"
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-16 06:20:24 +01:00
# include "pform_types.h"
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-17 22:25:59 +02:00
# include "ivl_target.h"
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-14 04:59:05 +01:00
# include <map>
class PEvent;
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-17 22:25:59 +02:00
class PExpr;
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 21:02:09 +02:00
class AProcess;
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-04 05:49:52 +01:00
class PProcess;
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-25 04:40:54 +01:00
class PWire;
class Design;
class NetScope;
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-14 04:59:05 +01:00
/*
* The PScope class is a base representation of an object that
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-16 06:20:24 +01:00
* represents lexical scope. For example, a module, a function/task, a
* named block is derived from a PScope.
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-14 04:59:05 +01:00
*
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-17 22:25:59 +02:00
* NOTE: This is not the same concept as the "scope" of an elaborated
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-14 04:59:05 +01:00
* hierarchy. That is represented by NetScope objects after elaboration.
*/
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-20 06:31:53 +02:00
class LexicalScope {
public:
Rework of lexical scope handling in parser. This patch modifies the parser to use a single stack to track lexical scopes, rather than starting a new stack for each generate construct.
2010-01-08 23:49:48 +01:00
explicit LexicalScope(LexicalScope*parent) : parent_(parent) { }
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-20 06:31:53 +02:00
// A virtual destructor is so that dynamic_cast can work.
virtual ~LexicalScope() { }
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-17 22:25:59 +02:00
struct range_t {
// True if this is an exclude
bool exclude_flag;
// lower bound
// If low_open_flag is false and low_expr=0, then use -inf
bool low_open_flag;
PExpr*low_expr;
// upper bound
// If high_open_flag is false and high_expr=0, then use +inf
bool high_open_flag;
PExpr*high_expr;
// Next range description in list
struct range_t*next;
};
/* The scope has parameters that are evaluated when the scope
is elaborated. During parsing, I put the parameters into
this map. */
struct param_expr_t : public LineInfo {
param_expr_t() : type(IVL_VT_NO_TYPE), msb(0), lsb(0), signed_flag(false), expr(0), range(0) { }
// Type information
ivl_variable_type_t type;
PExpr*msb;
PExpr*lsb;
bool signed_flag;
// Value expression
PExpr*expr;
// If there are range constraints, list them here
range_t*range;
};
map<perm_string,param_expr_t>parameters;
map<perm_string,param_expr_t>localparams;
// Named events in the scope.
map<perm_string,PEvent*>events;
// Nets and variables (wires) in the scope
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-20 06:31:53 +02:00
map<perm_string,PWire*>wires;
PWire* wires_find(perm_string name);
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 21:02:09 +02:00
// Behaviors (processes) in this scope
list<PProcess*> behaviors;
list<AProcess*> analog_behaviors;
Rework of lexical scope handling in parser. This patch modifies the parser to use a single stack to track lexical scopes, rather than starting a new stack for each generate construct.
2010-01-08 23:49:48 +01:00
LexicalScope* parent_scope() const { return parent_; }
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-17 22:25:59 +02:00
protected:
void dump_parameters_(ostream&out, unsigned indent) const;
void dump_localparams_(ostream&out, unsigned indent) const;
void dump_events_(ostream&out, unsigned indent) const;
void dump_wires_(ostream&out, unsigned indent) const;
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-20 06:31:53 +02:00
private:
Rework of lexical scope handling in parser. This patch modifies the parser to use a single stack to track lexical scopes, rather than starting a new stack for each generate construct.
2010-01-08 23:49:48 +01:00
LexicalScope*parent_;
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-20 06:31:53 +02:00
};
class PScope : public LexicalScope {
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-14 04:59:05 +01:00
public:
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-16 06:20:24 +01:00
// When created, a scope has a name and a parent. The name is
// the name of the definition. For example, if this is a
// module declaration, the name is the name after the "module"
// keyword, and if this is a task scope, the name is the task
// name. The parent is the lexical parent of this scope. Since
// modules do not nest in Verilog, the parent must be nil for
// modules. Scopes for tasks and functions point to their
// containing module.
Rework of lexical scope handling in parser. This patch modifies the parser to use a single stack to track lexical scopes, rather than starting a new stack for each generate construct.
2010-01-08 23:49:48 +01:00
PScope(perm_string name, LexicalScope*parent);
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-18 06:45:37 +02:00
PScope(perm_string name);
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-16 06:20:24 +01:00
virtual ~PScope();
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-14 04:59:05 +01:00
perm_string pscope_name() const { return name_; }
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-25 04:40:54 +01:00
protected:
bool elaborate_sig_wires_(Design*des, NetScope*scope) const;
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-04 05:49:52 +01:00
bool elaborate_behaviors_(Design*des, NetScope*scope) const;
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-14 04:59:05 +01:00
private:
perm_string name_;
};
#endif