iverilog/PWire.cc

209 lines
4.5 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
PWSRType rt)
: name_(n), type_(t), port_type_(pt), signed_(false),
port_set_(false), net_set_(false), is_scalar_(false),
Improve handling of type identifier references Currently when referencing a typedef this gets replaced with the `data_type_t` that the typedef points to. This works for most cases, but there are some corner cases where it breaks down. E.g. it is possible to have a scoped type identifier which references a type defined in a package. For such type identifiers, only the data_type_t itself is remembered, but not the package scope. This will cause the type identifier to be elaborated in the wrong scope. Furthermore type identifiers of vector types used for module or task port might not be elaborated in the correct scope. Introduce a new `typeref_t` which has `data_type_t` as a base type and can be used as the data type for a signal. A new instance of a `typeref_t` is created when referencing a type identifier. The `typeref_t` remembers both the data type and the scope of the type identifier. When elaborating the `typeref_t` the elaboration is passed through to the referenced `data_type_t`. But special care is taken to lookup the right scope first. With the new approach also typedefs of typedefs are supported. This previously did not work because chained typedefs all reference the same `data_type_t`, but each typedef sets the `name` field of the `data_type_t`. So the second typedef overwrites the first typedef and a lookup of the scope of the first typedef by name will fail as it will return the scope of the second typedef. This refactoring also allows to define clear ownership of a data_type_t instance. This e.g. means that an array type owns its base type and the base type can be freed when the array type itself is freed. The same is true for signals and class properties, they now own their data type and the data type can be freed when the signal or property is freed. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-24 11:05:33 +01:00
error_cnt_(0), 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;
}
}
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)
{
Improve handling of type identifier references Currently when referencing a typedef this gets replaced with the `data_type_t` that the typedef points to. This works for most cases, but there are some corner cases where it breaks down. E.g. it is possible to have a scoped type identifier which references a type defined in a package. For such type identifiers, only the data_type_t itself is remembered, but not the package scope. This will cause the type identifier to be elaborated in the wrong scope. Furthermore type identifiers of vector types used for module or task port might not be elaborated in the correct scope. Introduce a new `typeref_t` which has `data_type_t` as a base type and can be used as the data type for a signal. A new instance of a `typeref_t` is created when referencing a type identifier. The `typeref_t` remembers both the data type and the scope of the type identifier. When elaborating the `typeref_t` the elaboration is passed through to the referenced `data_type_t`. But special care is taken to lookup the right scope first. With the new approach also typedefs of typedefs are supported. This previously did not work because chained typedefs all reference the same `data_type_t`, but each typedef sets the `name` field of the `data_type_t`. So the second typedef overwrites the first typedef and a lookup of the scope of the first typedef by name will fail as it will return the scope of the second typedef. This refactoring also allows to define clear ownership of a data_type_t instance. This e.g. means that an array type owns its base type and the base type can be freed when the array type itself is freed. The same is true for signals and class properties, they now own their data type and the data type can be freed when the signal or property is freed. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-24 11:05:33 +01:00
if (set_data_type_.get() == type)
return;
assert(!set_data_type_.get());
set_data_type_.reset(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;
}
}