iverilog/PWire.cc

224 lines
4.8 KiB
C++
Raw Normal View History

/*
* Copyright (c) 1999-2021 Stephen Williams (steve@icarus.com)
*
* 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
2012-08-29 03:41:23 +02:00
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
# include "config.h"
Prevent invalid port redeclaration (System)Verilog allows to declare the port direction separate from the signal declaration. E.g. ``` output x; integer x; ``` But this is only allowed if the port declaration * does not have an explicit net type * does not have an explicit data type * is a non-ANSI style declaration For all other cases of port declarations the signal is considered fully defined and it is not allowed to have a separate signal declaration. In addition the declared packed dimensions need to match between the port and signal declaration. In the current implementation there are a few cases where this is not handled correctly. 1) It is possible to declare non-ANSI task ports with the same name over and over again, if it was declared as a signal before the port. ``` task t; string x; input logic x; output real x; endtask ``` 2) It is possible to re-declare non-ANSI input ports of a module that have a data type, but no explicit net type. ``` module M; input integer x; wire integer x; endmodule ``` 3) It is possible to re-declare a ANSI port if it has an implicit data type. ``` module M(output [1:0] x); reg [1:0] x; endmodule ``` 4) It is possible to declare a vector signal for a scalar non-ANSI task port. ``` task t; input x; reg [7:0] x; ``` To handle all of these correctly refactor signal declaration and lookup a bit. The PWire class that represents a signal already has two flags `port_set_` and `net_set_`. These flags indicate whether a signal has already been used in a port or signal declaration. A port declaration that includes an explicit data type is considered both a port and signal declaration. Use these flags to decide whether it is possible to extend an existing declaration. E.g. when creating a port without an explicit data type and a PWire by that name already exists and the `port_set_` flag is not set extend the existing PWire. On the other hand if the `port_set_` flag is already set report an error. Similar for signals but with the `net_set_` flag. For port declarations with an explicit data type or ANSI style port declarations it is always an error if a PWire by that name already exists. This is for both module and task/function ports. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-13 09:50:52 +01:00
# include "ivl_assert.h"
# include "PWire.h"
# include "PExpr.h"
# include <cassert>
using namespace std;
PWire::PWire(perm_string n,
2005-07-07 18:22:49 +02:00
NetNet::Type t,
NetNet::PortType pt,
Prevent invalid port redeclaration (System)Verilog allows to declare the port direction separate from the signal declaration. E.g. ``` output x; integer x; ``` But this is only allowed if the port declaration * does not have an explicit net type * does not have an explicit data type * is a non-ANSI style declaration For all other cases of port declarations the signal is considered fully defined and it is not allowed to have a separate signal declaration. In addition the declared packed dimensions need to match between the port and signal declaration. In the current implementation there are a few cases where this is not handled correctly. 1) It is possible to declare non-ANSI task ports with the same name over and over again, if it was declared as a signal before the port. ``` task t; string x; input logic x; output real x; endtask ``` 2) It is possible to re-declare non-ANSI input ports of a module that have a data type, but no explicit net type. ``` module M; input integer x; wire integer x; endmodule ``` 3) It is possible to re-declare a ANSI port if it has an implicit data type. ``` module M(output [1:0] x); reg [1:0] x; endmodule ``` 4) It is possible to declare a vector signal for a scalar non-ANSI task port. ``` task t; input x; reg [7:0] x; ``` To handle all of these correctly refactor signal declaration and lookup a bit. The PWire class that represents a signal already has two flags `port_set_` and `net_set_`. These flags indicate whether a signal has already been used in a port or signal declaration. A port declaration that includes an explicit data type is considered both a port and signal declaration. Use these flags to decide whether it is possible to extend an existing declaration. E.g. when creating a port without an explicit data type and a PWire by that name already exists and the `port_set_` flag is not set extend the existing PWire. On the other hand if the `port_set_` flag is already set report an error. Similar for signals but with the `net_set_` flag. For port declarations with an explicit data type or ANSI style port declarations it is always an error if a PWire by that name already exists. This is for both module and task/function ports. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-13 09:50:52 +01:00
ivl_variable_type_t dt,
PWSRType rt)
: name_(n), type_(t), port_type_(pt), data_type_(dt),
Correctly handle separate port type declaration for `integer` and `time` When using non-ANSI style port declarations it is possible to declare the port direction and the data type for the port in separate statements. E.g. ``` input x; reg x; ``` When using packed array dimensions they must match for both declarations. E.g. ``` input [3:0] x; reg [3:0] x; ``` But this only applies for vector types, i.e. the packed dimension is explicitly declared. It does not apply to the `integer` and `time` types, which have an implicit packed dimension. The current implementation requires that even for `integer` and `time` types the implicit dimension needs to be explicitly declared in the port direction. E.g. the following will result in a elaboration error complaining about a packed dimension mismatch. ``` module test; output x; integer x; endmodule ``` Currently the parser creates a vector_type_t for `time` and `integer`. This means that e.g. `time` and `reg [63:0]` are indistinguishable during elaboration, even though they require different behavior. To fix let the atom2_type_t handle `integer` and `time`. Since it no longer exclusively handles 2-state types, rename it to atom_type_t. This also fixes a problem with the vlog95 target unit tests. The vlog95 target translates ``` module test(output integer x); endmodule ``` to ``` module test(x); output x; integer x; endmodule ``` which then fails when being elaborated again. There were some regression tests that were failing because of this that will now pass. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-12 21:10:19 +01:00
signed_(false),
port_set_(false), net_set_(false), is_scalar_(false),
error_cnt_(0), uarray_type_(0), set_data_type_(0),
2011-12-04 02:16:01 +01:00
discipline_(0)
{
Prevent invalid port redeclaration (System)Verilog allows to declare the port direction separate from the signal declaration. E.g. ``` output x; integer x; ``` But this is only allowed if the port declaration * does not have an explicit net type * does not have an explicit data type * is a non-ANSI style declaration For all other cases of port declarations the signal is considered fully defined and it is not allowed to have a separate signal declaration. In addition the declared packed dimensions need to match between the port and signal declaration. In the current implementation there are a few cases where this is not handled correctly. 1) It is possible to declare non-ANSI task ports with the same name over and over again, if it was declared as a signal before the port. ``` task t; string x; input logic x; output real x; endtask ``` 2) It is possible to re-declare non-ANSI input ports of a module that have a data type, but no explicit net type. ``` module M; input integer x; wire integer x; endmodule ``` 3) It is possible to re-declare a ANSI port if it has an implicit data type. ``` module M(output [1:0] x); reg [1:0] x; endmodule ``` 4) It is possible to declare a vector signal for a scalar non-ANSI task port. ``` task t; input x; reg [7:0] x; ``` To handle all of these correctly refactor signal declaration and lookup a bit. The PWire class that represents a signal already has two flags `port_set_` and `net_set_`. These flags indicate whether a signal has already been used in a port or signal declaration. A port declaration that includes an explicit data type is considered both a port and signal declaration. Use these flags to decide whether it is possible to extend an existing declaration. E.g. when creating a port without an explicit data type and a PWire by that name already exists and the `port_set_` flag is not set extend the existing PWire. On the other hand if the `port_set_` flag is already set report an error. Similar for signals but with the `net_set_` flag. For port declarations with an explicit data type or ANSI style port declarations it is always an error if a PWire by that name already exists. This is for both module and task/function ports. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-13 09:50:52 +01:00
switch (rt) {
case SR_PORT:
port_set_ = true;
break;
case SR_NET:
net_set_ = true;
break;
case SR_BOTH:
port_set_ = true;
net_set_ = true;
break;
}
}
NetNet::Type PWire::get_wire_type() const
{
return type_;
}
perm_string PWire::basename() const
{
return name_;
}
bool PWire::set_wire_type(NetNet::Type t)
{
assert(t != NetNet::IMPLICIT);
switch (type_) {
case NetNet::IMPLICIT:
type_ = t;
return true;
1999-09-10 07:02:09 +02:00
case NetNet::IMPLICIT_REG:
if (t == NetNet::REG) {
type_ = t;
return true;
}
if (t == NetNet::IMPLICIT_REG) return true;
1999-09-10 07:02:09 +02:00
return false;
case NetNet::REG:
if (t == NetNet::REG) return true;
return false;
default:
if (type_ != t)
return false;
else
return true;
}
}
NetNet::PortType PWire::get_port_type() const
{
return port_type_;
}
bool PWire::set_port_type(NetNet::PortType pt)
{
assert(pt != NetNet::NOT_A_PORT);
assert(pt != NetNet::PIMPLICIT);
switch (port_type_) {
case NetNet::PIMPLICIT:
case NetNet::NOT_A_PORT:
port_type_ = pt;
return true;
default:
if (port_type_ != pt)
return false;
else
return true;
}
}
2005-07-07 18:22:49 +02:00
bool PWire::set_data_type(ivl_variable_type_t dt)
{
if (data_type_ != IVL_VT_NO_TYPE) {
2005-07-07 18:22:49 +02:00
if (data_type_ != dt)
return false;
else
return true;
}
2005-07-07 18:22:49 +02:00
assert(data_type_ == IVL_VT_NO_TYPE);
data_type_ = dt;
2005-07-07 18:22:49 +02:00
return true;
}
void PWire::set_signed(bool flag)
{
// For a non-ANSI style port declaration where the data type is
// specified in a corresponding variable declaration, the signed
// attribute may be attached to either the port declaration or to
// the variable declaration (IEEE 1364-2005 section 12.3.3). The
// signal is signed if either the port or the variable is signed.
// Handle that here.
signed_ = signed_ || flag;
}
bool PWire::get_signed() const
{
return signed_;
}
Prevent invalid port redeclaration (System)Verilog allows to declare the port direction separate from the signal declaration. E.g. ``` output x; integer x; ``` But this is only allowed if the port declaration * does not have an explicit net type * does not have an explicit data type * is a non-ANSI style declaration For all other cases of port declarations the signal is considered fully defined and it is not allowed to have a separate signal declaration. In addition the declared packed dimensions need to match between the port and signal declaration. In the current implementation there are a few cases where this is not handled correctly. 1) It is possible to declare non-ANSI task ports with the same name over and over again, if it was declared as a signal before the port. ``` task t; string x; input logic x; output real x; endtask ``` 2) It is possible to re-declare non-ANSI input ports of a module that have a data type, but no explicit net type. ``` module M; input integer x; wire integer x; endmodule ``` 3) It is possible to re-declare a ANSI port if it has an implicit data type. ``` module M(output [1:0] x); reg [1:0] x; endmodule ``` 4) It is possible to declare a vector signal for a scalar non-ANSI task port. ``` task t; input x; reg [7:0] x; ``` To handle all of these correctly refactor signal declaration and lookup a bit. The PWire class that represents a signal already has two flags `port_set_` and `net_set_`. These flags indicate whether a signal has already been used in a port or signal declaration. A port declaration that includes an explicit data type is considered both a port and signal declaration. Use these flags to decide whether it is possible to extend an existing declaration. E.g. when creating a port without an explicit data type and a PWire by that name already exists and the `port_set_` flag is not set extend the existing PWire. On the other hand if the `port_set_` flag is already set report an error. Similar for signals but with the `net_set_` flag. For port declarations with an explicit data type or ANSI style port declarations it is always an error if a PWire by that name already exists. This is for both module and task/function ports. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-13 09:50:52 +01:00
void PWire::set_port(NetNet::PortType pt)
{
Prevent invalid port redeclaration (System)Verilog allows to declare the port direction separate from the signal declaration. E.g. ``` output x; integer x; ``` But this is only allowed if the port declaration * does not have an explicit net type * does not have an explicit data type * is a non-ANSI style declaration For all other cases of port declarations the signal is considered fully defined and it is not allowed to have a separate signal declaration. In addition the declared packed dimensions need to match between the port and signal declaration. In the current implementation there are a few cases where this is not handled correctly. 1) It is possible to declare non-ANSI task ports with the same name over and over again, if it was declared as a signal before the port. ``` task t; string x; input logic x; output real x; endtask ``` 2) It is possible to re-declare non-ANSI input ports of a module that have a data type, but no explicit net type. ``` module M; input integer x; wire integer x; endmodule ``` 3) It is possible to re-declare a ANSI port if it has an implicit data type. ``` module M(output [1:0] x); reg [1:0] x; endmodule ``` 4) It is possible to declare a vector signal for a scalar non-ANSI task port. ``` task t; input x; reg [7:0] x; ``` To handle all of these correctly refactor signal declaration and lookup a bit. The PWire class that represents a signal already has two flags `port_set_` and `net_set_`. These flags indicate whether a signal has already been used in a port or signal declaration. A port declaration that includes an explicit data type is considered both a port and signal declaration. Use these flags to decide whether it is possible to extend an existing declaration. E.g. when creating a port without an explicit data type and a PWire by that name already exists and the `port_set_` flag is not set extend the existing PWire. On the other hand if the `port_set_` flag is already set report an error. Similar for signals but with the `net_set_` flag. For port declarations with an explicit data type or ANSI style port declarations it is always an error if a PWire by that name already exists. This is for both module and task/function ports. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-13 09:50:52 +01:00
ivl_assert(*this, !port_set_);
port_set_ = true;
Prevent invalid port redeclaration (System)Verilog allows to declare the port direction separate from the signal declaration. E.g. ``` output x; integer x; ``` But this is only allowed if the port declaration * does not have an explicit net type * does not have an explicit data type * is a non-ANSI style declaration For all other cases of port declarations the signal is considered fully defined and it is not allowed to have a separate signal declaration. In addition the declared packed dimensions need to match between the port and signal declaration. In the current implementation there are a few cases where this is not handled correctly. 1) It is possible to declare non-ANSI task ports with the same name over and over again, if it was declared as a signal before the port. ``` task t; string x; input logic x; output real x; endtask ``` 2) It is possible to re-declare non-ANSI input ports of a module that have a data type, but no explicit net type. ``` module M; input integer x; wire integer x; endmodule ``` 3) It is possible to re-declare a ANSI port if it has an implicit data type. ``` module M(output [1:0] x); reg [1:0] x; endmodule ``` 4) It is possible to declare a vector signal for a scalar non-ANSI task port. ``` task t; input x; reg [7:0] x; ``` To handle all of these correctly refactor signal declaration and lookup a bit. The PWire class that represents a signal already has two flags `port_set_` and `net_set_`. These flags indicate whether a signal has already been used in a port or signal declaration. A port declaration that includes an explicit data type is considered both a port and signal declaration. Use these flags to decide whether it is possible to extend an existing declaration. E.g. when creating a port without an explicit data type and a PWire by that name already exists and the `port_set_` flag is not set extend the existing PWire. On the other hand if the `port_set_` flag is already set report an error. Similar for signals but with the `net_set_` flag. For port declarations with an explicit data type or ANSI style port declarations it is always an error if a PWire by that name already exists. This is for both module and task/function ports. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-13 09:50:52 +01:00
bool rc = set_port_type(pt);
ivl_assert(*this, rc);
}
Prevent invalid port redeclaration (System)Verilog allows to declare the port direction separate from the signal declaration. E.g. ``` output x; integer x; ``` But this is only allowed if the port declaration * does not have an explicit net type * does not have an explicit data type * is a non-ANSI style declaration For all other cases of port declarations the signal is considered fully defined and it is not allowed to have a separate signal declaration. In addition the declared packed dimensions need to match between the port and signal declaration. In the current implementation there are a few cases where this is not handled correctly. 1) It is possible to declare non-ANSI task ports with the same name over and over again, if it was declared as a signal before the port. ``` task t; string x; input logic x; output real x; endtask ``` 2) It is possible to re-declare non-ANSI input ports of a module that have a data type, but no explicit net type. ``` module M; input integer x; wire integer x; endmodule ``` 3) It is possible to re-declare a ANSI port if it has an implicit data type. ``` module M(output [1:0] x); reg [1:0] x; endmodule ``` 4) It is possible to declare a vector signal for a scalar non-ANSI task port. ``` task t; input x; reg [7:0] x; ``` To handle all of these correctly refactor signal declaration and lookup a bit. The PWire class that represents a signal already has two flags `port_set_` and `net_set_`. These flags indicate whether a signal has already been used in a port or signal declaration. A port declaration that includes an explicit data type is considered both a port and signal declaration. Use these flags to decide whether it is possible to extend an existing declaration. E.g. when creating a port without an explicit data type and a PWire by that name already exists and the `port_set_` flag is not set extend the existing PWire. On the other hand if the `port_set_` flag is already set report an error. Similar for signals but with the `net_set_` flag. For port declarations with an explicit data type or ANSI style port declarations it is always an error if a PWire by that name already exists. This is for both module and task/function ports. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-13 09:50:52 +01:00
void PWire::set_net(NetNet::Type t)
{
ivl_assert(*this, !net_set_);
net_set_ = true;
if (t != NetNet::IMPLICIT) {
bool rc = set_wire_type(t);
ivl_assert(*this, rc);
}
}
void PWire::set_range(const list<pform_range_t>&rlist, PWSRType type)
{
switch (type) {
case SR_PORT:
Prevent invalid port redeclaration (System)Verilog allows to declare the port direction separate from the signal declaration. E.g. ``` output x; integer x; ``` But this is only allowed if the port declaration * does not have an explicit net type * does not have an explicit data type * is a non-ANSI style declaration For all other cases of port declarations the signal is considered fully defined and it is not allowed to have a separate signal declaration. In addition the declared packed dimensions need to match between the port and signal declaration. In the current implementation there are a few cases where this is not handled correctly. 1) It is possible to declare non-ANSI task ports with the same name over and over again, if it was declared as a signal before the port. ``` task t; string x; input logic x; output real x; endtask ``` 2) It is possible to re-declare non-ANSI input ports of a module that have a data type, but no explicit net type. ``` module M; input integer x; wire integer x; endmodule ``` 3) It is possible to re-declare a ANSI port if it has an implicit data type. ``` module M(output [1:0] x); reg [1:0] x; endmodule ``` 4) It is possible to declare a vector signal for a scalar non-ANSI task port. ``` task t; input x; reg [7:0] x; ``` To handle all of these correctly refactor signal declaration and lookup a bit. The PWire class that represents a signal already has two flags `port_set_` and `net_set_`. These flags indicate whether a signal has already been used in a port or signal declaration. A port declaration that includes an explicit data type is considered both a port and signal declaration. Use these flags to decide whether it is possible to extend an existing declaration. E.g. when creating a port without an explicit data type and a PWire by that name already exists and the `port_set_` flag is not set extend the existing PWire. On the other hand if the `port_set_` flag is already set report an error. Similar for signals but with the `net_set_` flag. For port declarations with an explicit data type or ANSI style port declarations it is always an error if a PWire by that name already exists. This is for both module and task/function ports. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-13 09:50:52 +01:00
if (!port_.empty())
return;
port_ = rlist;
break;
case SR_NET:
Prevent invalid port redeclaration (System)Verilog allows to declare the port direction separate from the signal declaration. E.g. ``` output x; integer x; ``` But this is only allowed if the port declaration * does not have an explicit net type * does not have an explicit data type * is a non-ANSI style declaration For all other cases of port declarations the signal is considered fully defined and it is not allowed to have a separate signal declaration. In addition the declared packed dimensions need to match between the port and signal declaration. In the current implementation there are a few cases where this is not handled correctly. 1) It is possible to declare non-ANSI task ports with the same name over and over again, if it was declared as a signal before the port. ``` task t; string x; input logic x; output real x; endtask ``` 2) It is possible to re-declare non-ANSI input ports of a module that have a data type, but no explicit net type. ``` module M; input integer x; wire integer x; endmodule ``` 3) It is possible to re-declare a ANSI port if it has an implicit data type. ``` module M(output [1:0] x); reg [1:0] x; endmodule ``` 4) It is possible to declare a vector signal for a scalar non-ANSI task port. ``` task t; input x; reg [7:0] x; ``` To handle all of these correctly refactor signal declaration and lookup a bit. The PWire class that represents a signal already has two flags `port_set_` and `net_set_`. These flags indicate whether a signal has already been used in a port or signal declaration. A port declaration that includes an explicit data type is considered both a port and signal declaration. Use these flags to decide whether it is possible to extend an existing declaration. E.g. when creating a port without an explicit data type and a PWire by that name already exists and the `port_set_` flag is not set extend the existing PWire. On the other hand if the `port_set_` flag is already set report an error. Similar for signals but with the `net_set_` flag. For port declarations with an explicit data type or ANSI style port declarations it is always an error if a PWire by that name already exists. This is for both module and task/function ports. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-13 09:50:52 +01:00
if (!net_.empty())
return;
net_ = rlist;
break;
case SR_BOTH:
Prevent invalid port redeclaration (System)Verilog allows to declare the port direction separate from the signal declaration. E.g. ``` output x; integer x; ``` But this is only allowed if the port declaration * does not have an explicit net type * does not have an explicit data type * is a non-ANSI style declaration For all other cases of port declarations the signal is considered fully defined and it is not allowed to have a separate signal declaration. In addition the declared packed dimensions need to match between the port and signal declaration. In the current implementation there are a few cases where this is not handled correctly. 1) It is possible to declare non-ANSI task ports with the same name over and over again, if it was declared as a signal before the port. ``` task t; string x; input logic x; output real x; endtask ``` 2) It is possible to re-declare non-ANSI input ports of a module that have a data type, but no explicit net type. ``` module M; input integer x; wire integer x; endmodule ``` 3) It is possible to re-declare a ANSI port if it has an implicit data type. ``` module M(output [1:0] x); reg [1:0] x; endmodule ``` 4) It is possible to declare a vector signal for a scalar non-ANSI task port. ``` task t; input x; reg [7:0] x; ``` To handle all of these correctly refactor signal declaration and lookup a bit. The PWire class that represents a signal already has two flags `port_set_` and `net_set_`. These flags indicate whether a signal has already been used in a port or signal declaration. A port declaration that includes an explicit data type is considered both a port and signal declaration. Use these flags to decide whether it is possible to extend an existing declaration. E.g. when creating a port without an explicit data type and a PWire by that name already exists and the `port_set_` flag is not set extend the existing PWire. On the other hand if the `port_set_` flag is already set report an error. Similar for signals but with the `net_set_` flag. For port declarations with an explicit data type or ANSI style port declarations it is always an error if a PWire by that name already exists. This is for both module and task/function ports. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-13 09:50:52 +01:00
if (!port_.empty() || !net_.empty())
return;
port_ = rlist;
net_ = rlist;
break;
}
}
2012-05-26 00:58:29 +02:00
void PWire::set_unpacked_idx(const list<pform_range_t>&ranges)
{
2012-05-26 00:58:29 +02:00
if (! unpacked_.empty()) {
cerr << get_fileline() << ": error: Array ``" << name_
<< "'' has already been declared." << endl;
error_cnt_ += 1;
} else {
2012-05-26 00:58:29 +02:00
unpacked_ = ranges;
}
}
void PWire::set_data_type(data_type_t*type)
{
assert(set_data_type_ == 0 || set_data_type_ == type);
set_data_type_ = type;
2011-12-04 02:16:01 +01:00
}
void PWire::set_discipline(ivl_discipline_t d)
{
assert(discipline_ == 0);
discipline_ = d;
}
ivl_discipline_t PWire::get_discipline(void) const
{
return discipline_;
}
PNamedItem::SymbolType PWire::symbol_type() const
{
switch (type_) {
case NetNet::IMPLICIT_REG:
case NetNet::REG:
return VAR;
default:
return NET;
}
}