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

99 lines
2.9 KiB
C++
Raw Normal View History

Rework the way vectors are represented in NetNet objects.
2012-09-15 19:27:43 +02:00
/*
Handle real value class properties. As a side effect, this also adds support for 64bit integers.
2013-01-11 03:48:15 +01:00
* Copyright (c) 2012-2013 Stephen Williams (steve@icarus.com)
Rework the way vectors are represented in NetNet objects.
2012-09-15 19:27:43 +02: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., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
# include "netvector.h"
Rework parsing of parameter types Use the common data_type_or_implicit rules to support type definitions for parameters. This eliminates a bunch of special rules in parse.y, and opens the door for parameters having more complex types.
2020-12-25 03:12:06 +01:00
# include "compiler.h"
Handle array assignment patters through pform. This gets us to elaboration. In the process also fix up ivl_type_t type comparisons to do deep type comparison.
2013-09-29 23:48:42 +02:00
# include <iostream>
Rework the way vectors are represented in NetNet objects.
2012-09-15 19:27:43 +02:00
Some rework to allow for nested packed types. This also simplifies the NetNet set of contructors and generalizes the types that are supported, especially packed types.
2012-09-30 00:13:45 +02:00
using namespace std;
Handle real value class properties. As a side effect, this also adds support for 64bit integers.
2013-01-11 03:48:15 +01:00
netvector_t netvector_t::atom2s64 (IVL_VT_BOOL, 63, 0, true);
netvector_t netvector_t::atom2u64 (IVL_VT_BOOL, 63, 0, false);
Flesh out class type elaboration Add properties to the classes, and elaborate expressions that have class properties. Describe class object property references all the way down to the stub target.
2012-11-25 19:13:05 +01:00
netvector_t netvector_t::atom2s32 (IVL_VT_BOOL, 31, 0, true);
netvector_t netvector_t::atom2u32 (IVL_VT_BOOL, 31, 0, false);
Handle some different integral types is class properties.
2013-01-07 00:42:23 +01:00
netvector_t netvector_t::atom2s16 (IVL_VT_BOOL, 15, 0, true);
netvector_t netvector_t::atom2u16 (IVL_VT_BOOL, 15, 0, false);
netvector_t netvector_t::atom2s8 (IVL_VT_BOOL, 7, 0, true);
netvector_t netvector_t::atom2u8 (IVL_VT_BOOL, 7, 0, false);
Flesh out class type elaboration Add properties to the classes, and elaborate expressions that have class properties. Describe class object property references all the way down to the stub target.
2012-11-25 19:13:05 +01:00
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
netvector_t netvector_t::time_signed (IVL_VT_LOGIC, 63, 0, true);
netvector_t netvector_t::time_unsigned (IVL_VT_LOGIC, 63, 0, false);
static netvector_t* save_integer_type[2];
const netvector_t* netvector_t::integer_type(bool is_signed)
Rework parsing of parameter types Use the common data_type_or_implicit rules to support type definitions for parameters. This eliminates a bunch of special rules in parse.y, and opens the door for parameters having more complex types.
2020-12-25 03:12:06 +01:00
{
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
if (save_integer_type[is_signed])
return save_integer_type[is_signed];
Rework parsing of parameter types Use the common data_type_or_implicit rules to support type definitions for parameters. This eliminates a bunch of special rules in parse.y, and opens the door for parameters having more complex types.
2020-12-25 03:12:06 +01:00
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
save_integer_type[is_signed] = new netvector_t(IVL_VT_LOGIC, integer_width-1, 0, is_signed);
save_integer_type[is_signed]->set_isint(true);
return save_integer_type[is_signed];
Rework parsing of parameter types Use the common data_type_or_implicit rules to support type definitions for parameters. This eliminates a bunch of special rules in parse.y, and opens the door for parameters having more complex types.
2020-12-25 03:12:06 +01:00
}
Rework synchronous statement synthesis. This changes the flow of the NetProc::synth_sync method, and implements the NetBlock::synth_sync better.
2013-08-24 03:22:32 +02:00
//netvector_t netvector_t::scalar_bool (IVL_VT_BOOL);
netvector_t netvector_t::scalar_logic (IVL_VT_LOGIC);
Flesh out class type elaboration Add properties to the classes, and elaborate expressions that have class properties. Describe class object property references all the way down to the stub target.
2012-11-25 19:13:05 +01:00
netvector_t::netvector_t(ivl_variable_type_t type, long msb, long lsb, bool flag)
Handle scalar typed parameters Parameters without any type or range specification inherit the type from the value that has been assigned to it. Similarly a parameter with just an `signed` or `unsigned` keyword will inherit its range from the value assigned to it. In the current implementation any vector type parameter that does not have a range specification inherits the type form the assigned value. That includes parameters with an explicit scalar vector type. E.g. ``` parameter bit X = 10 ``` Make sure that a parameter only uses the width from the assigned value if the parameter does not have an explicit data type. To support this we need to remember whether a `netvector_t` was declared as an explicit or implicit data type. Currently this information is only available on the unelaborated `vector_type_t`. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-26 10:45:00 +01:00
: type_(type), signed_(flag), isint_(false), implicit_(false)
Rework the way vectors are represented in NetNet objects.
2012-09-15 19:27:43 +02:00
{
packed_dims_.push_back(netrange_t(msb,lsb));
}
netvector_t::netvector_t(ivl_variable_type_t type)
Handle scalar typed parameters Parameters without any type or range specification inherit the type from the value that has been assigned to it. Similarly a parameter with just an `signed` or `unsigned` keyword will inherit its range from the value assigned to it. In the current implementation any vector type parameter that does not have a range specification inherits the type form the assigned value. That includes parameters with an explicit scalar vector type. E.g. ``` parameter bit X = 10 ``` Make sure that a parameter only uses the width from the assigned value if the parameter does not have an explicit data type. To support this we need to remember whether a `netvector_t` was declared as an explicit or implicit data type. Currently this information is only available on the unelaborated `vector_type_t`. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-03-26 10:45:00 +01:00
: type_(type), signed_(false), isint_(false), implicit_(false)
Rework the way vectors are represented in NetNet objects.
2012-09-15 19:27:43 +02:00
{
}
netvector_t::~netvector_t()
{
}
ivl_variable_type_t netvector_t::base_type() const
{
return type_;
}
Generalize struct member type
2013-11-29 21:43:34 +01:00
/*
* vectors are by definition packed.
*/
bool netvector_t::packed(void) const
{
return true;
}
Rework the way vectors are represented in NetNet objects.
2012-09-15 19:27:43 +02:00
long netvector_t::packed_width() const
{
ivl_target access to type information.
2012-09-23 18:28:49 +02:00
return netrange_width(packed_dims_);
Rework the way vectors are represented in NetNet objects.
2012-09-15 19:27:43 +02:00
}
Some rework to allow for nested packed types. This also simplifies the NetNet set of contructors and generalizes the types that are supported, especially packed types.
2012-09-30 00:13:45 +02:00
Add a typedef for `std::vector<netrange_t>` `std::vector<netrange_t>` is used for signal array dimensions. As such it is used in quite a few places. Add a typedef that can be used as a shorthand to refer to it. This helps to keep lines where this is used from growing to overly long. The new type is called `netranges_t`. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-01-06 15:24:20 +01:00
netranges_t netvector_t::slice_dimensions() const
Some rework to allow for nested packed types. This also simplifies the NetNet set of contructors and generalizes the types that are supported, especially packed types.
2012-09-30 00:13:45 +02:00
{
return packed_dims_;
}
Handle array assignment patters through pform. This gets us to elaboration. In the process also fix up ivl_type_t type comparisons to do deep type comparison.
2013-09-29 23:48:42 +02:00
bool netvector_t::test_compatibility(ivl_type_t that) const
{
Improve type compatibility checking for dynamic arrays and queues SystemVerilog defines different levels of type compatibility. * Matching * Equivalent * Assignment compatible * Cast compatible At the moment the `nettype_t` has only one type compatibility test. It is used to check assignment compatibility when assigning to a dynamic array, queue or class. The current implementation rejects a few cases that should allowed and allows a few cases that should be rejected. Dynamic arrays and queues are assignment compatible if their element types are compatible. And two packed types are equivalent if they are both 2-state or 4-state, both signed or unsigned and have the same packed with. In the current implementation the sign is not considered and instead of checking if the packed width is the same it checks that the dimensions are identical. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-09-17 19:37:47 +02:00
return packed_type_compatible(that);
}
Handle array assignment patters through pform. This gets us to elaboration. In the process also fix up ivl_type_t type comparisons to do deep type comparison.
2013-09-29 23:48:42 +02:00
Improve type compatibility checking for dynamic arrays and queues SystemVerilog defines different levels of type compatibility. * Matching * Equivalent * Assignment compatible * Cast compatible At the moment the `nettype_t` has only one type compatibility test. It is used to check assignment compatibility when assigning to a dynamic array, queue or class. The current implementation rejects a few cases that should allowed and allows a few cases that should be rejected. Dynamic arrays and queues are assignment compatible if their element types are compatible. And two packed types are equivalent if they are both 2-state or 4-state, both signed or unsigned and have the same packed with. In the current implementation the sign is not considered and instead of checking if the packed width is the same it checks that the dimensions are identical. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2022-09-17 19:37:47 +02:00
bool netvector_t::test_equivalence(const ivl_type_t that) const
{
return packed_types_equivalent(this, that);
Handle array assignment patters through pform. This gets us to elaboration. In the process also fix up ivl_type_t type comparisons to do deep type comparison.
2013-09-29 23:48:42 +02:00
}