iverilog/PWire.cc

223 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),
Correctly handle unpacked array typedefs for ports If the type of a port is an array type it currently always gets evaluated in the scope where the port is declared. But if the type is a typedef it might be declared in a different scope and must be evaluated in that scope. E.g. the following will declare an array port with 10 entries and an element type of a 5 bit vector, while it should declare one with 4 entries and an element type of a 2 bit vector. ``` localparam A = 2; localparam B = 4; typedef [A-1:0] T[B]; module test ( T x ); localparam A = 5; localparam B = 10; endmodule ``` This is in part due to array types being given special handling. This was necessary before because each base type required slightly different handling and so the base type had to be extracted from the array type. This has now been consolidated and all data types are treated the same. The only exception is the vector type which still needs special handling to support separate definition of port direction and type. As a result it is possible to remove the special handling of the array type. This solves the problem of evaluating the type in the wrong scope. Some special handling needs to be retained though to be able to differentiate between array dimensions that are part of a type and array dimensions that are part of port declaration. This is again necessary to correctly support separate definition of port direction and type. E.g. in the example below port `x` and `y` get treated slightly differently, even though the resulting signals will be identical. ``` typedef logic [7:0] T[1:0]; ... input T x; input [7:0] y[1:0]; ``` Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-04-11 09:48:29 +02:00
error_cnt_(0), set_data_type_(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;
}
}
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;
}
}