I have a question about signed property with multiple packed dimensions which is defined in stages with typedef.
Basically,
logic signed [1:0][2:0] foo;
* foo[0] is not signed (signed is meaningless if you expect signed element) because all entire packed array is signed but each element is not signed.
But,
typedef logic signed [1:0] foo_t;
foo_t [2:0] foo;
* foo[0] is signed. What a strange..
Q1> What happens? Why is it signed??
Q2> Is it same declaration with
logic signed [1:0][2:0] foo; // ??
Q3> LRM says that [1:0] index varies most rapidly, which is not my expectation.
logic signed [2:0][1:0] foo; //??
This is an artifact of the allowed syntax(BNF). The signed keyword applies signedness to the identifier as a whole, not to the individual elements (logic) you are packing. There's no syntax that allowes you to control the signedness of each dimension except by the typedef stages you discovered.
When you create a multidimensional array in stages, each dimension you add varies less rapidly than the previous. So dimensionally, your typedef is equivalent to
logic signed [2:0][1:0] foo;
foo_t [2:0] foo; // the [2:0] gets added to the left of [1:0]
If use an unpacked array, we can also keep signed property for each element.
logic signed [1:0] foo [2:0];
But, it seems that array of typedef with unpacked array is not supported by systemverilog.
typedef logic signed data_t [3:0];
data_t [2:0] foo;
When I try this, compiler shows an error
“illegal element type for a vector (vector element type must be an integral type)”. - you may leave any comment for this.
Anyway, thanks for your answer.
Related
Most of the tools I use allow it but one doesn't. I've read the specs, IEEE1800-2017 I couldn't find it.
module mymod (
input logic clk,
input logic reset,
input struct packed {
logic [1:0] var0;
logic [1:0] var1;
logic [8:0] var2;
} addr,
...
I saw some examples here and there, using even typedef structures in ports.
Is it allowed by the specs? Where?
Cf. 7.2 Structures and 7.2.1 Packed structures
A port can be any data type. (section 23.2.2) There are some restrictions on whether that datatype can be represented by a variable or net signal that interact with the port direction.
But I would strongly discourage the use of an anonymous type (struct in your example) and instead declare a user defined type with a typedef in a common package and use that typedef when declaring that port. That eliminates type compatibility issues when trying to connect unpacked struct and enums.
I implemented a specific filter in C/C++, "encapsulated" in a SystemC-Module. I want to use this filter in my actual verification environment (VE), which is based on SystemVerilog. To transfer data from and to the filter, I want to implement a TLM-connection. For TLM, there is something called a "generic payload", basically defining what can be transmitted via TLM, which is a byte-array.
Because of this, I need to convert the data samples in the VE from datatype real to a byte-array. What I tried to do is create a union-type, such that I can store a real-value and read a byte-array.
typedef union packed {
real value;
byte unsigned array[8];
} real_u;
However, I get the following error message.
real value;
|
ncvlog: *E,SVBPSE (Initiator.sv,7|11): The data type of a packed struct/union member must be a SystemVerilog integral type.
byte unsigned array[8];
|
ncvlog: *E,SVBPSE (Initiator.sv,8|20): The data type of a packed struct/union member must be a SystemVerilog integral type.
How could I resolve that issue? Are there other convenient ways to convert floating-point numbers to byte-arrays in SV/C++?
packed unions and structs might only contain packed members. So, in your case, both, real and byte unsigned array[8] are unpacked. Potentially you can use unpacked unions to do so, but not every vendor implements those.
Moreover, byte size of 'real' is not defined in the standard, therefore, your union most likely will not work at all. However, system verilog provides a set of functions to convert real to certain sized variables. In your case, $realtobits which returns 64 bits, will probably work.
So, i suggest you just pass real value after conversion to bits:
bit[63:0] realBits = $realtobits(value);
This question already has answers here:
packed vs unpacked vectors in system verilog
(7 answers)
Closed 5 years ago.
When using typedef to declare a userdefine type, then both these forms are accepted by ModelSim:
typedef logic logic_7_0_t [7:0];
typedef logic [7:0] logic_7_0_t;
However, if doing something similar based on real type, then 2nd format fails:
typedef real real_3_0_t [3:0];
typedef real [3:0] real_3_0_t; // Syntax error by ModelSim
Where to place the array indication, and why the difference between logic and real?
Based on the references to duplicate answers, my conclusion is that:
typedef logic logic_7_0_t [7:0]; // Unpacked array of logic, which is OK
typedef logic [7:0] logic_7_0_t; // Packed array of logic, which is OK
typedef real real_3_0_t [3:0]; // Unpacked array or real, which is OK
typedef real [3:0] real_3_0_t; // Would be packed array of real, which is not illegal
Below is the code I have for my module:
module sext(input in[3:0], output out[7:0]);
always_comb
begin
if(in[3]==1'b0)
assign out = {4'b0000,in};
else
assign out = {4'b1111,in};
end
endmodule
For some reason this is not working. Instead of sign extending it is zero extending. Any ideas to why this might be the case?
I'm going to assume you meant (input [3:0] in, output [7:0] out). If that is true, then all you needed to write is
module sext(input signed [3:0] in, output signed [7:0] out);
assign out = in;
endmodule
You could also write
module sext(input [3:0] in, output [7:0] out);
assign out = 8'(signed'(in));
endmodule
And perhaps you don't even need to write this as a separate module.
Few things you need to take care is,
you haven't declared a data type for in and out, so by default they are wire and wire can't be used at LHS inside procedural block. Refer Section 6.5 Nets and variables (SV LRM 1800-2012). So either use a continuous assignment or declare it as a variable (i.e. reg/logic etc.).
The assignment of unpacked array is illegal in your example, so either use packed array or follow the instructions given in Section 10.10 Unpacked array concatenation (SV LRM 1800-2012)
It is not illegal syntax but assign used inside an always block probably does not do what you think it does. Use assign for wires and do not use it inside initial or always.
You have defined your port ranges after the name, this results in 4 and 8 1-bit arrays rather than a 4 and 8 bit value.
You have used {} for concatination, but they can also be used for replication ie {4{1'b1}}.
module sext(
input [3:0] in,
output reg [7:0] out ); //ranged defined before name
//No assign in always
//concatenation with replication
always_comb begin
out = { {4{in[3]}}, in};
end
endmodule
Or :
module sext(
input [3:0] in,
output [7:0] out ); //out left as wire
assign out = { {4{in[3]}}, in};
endmodule
I have seen your code.
There are some mistake in your code that you have to take care whiling writing the code.
You have use unpacked array so your targeted elements and actual elements are not match.
ERROR : Number of elements in target expression does not match the number of
elements in source expression.
This error can solve by using packed array.So, your targeted elements and actual elements are matched.
Here is link from where you will get better understanding regarding packed and unpacked array.
LINK : [http://www.testbench.in/SV_09_ARRAYS.html][1]
2.Another thing that you have to take care is you are storing some value in out signal(variable) like assign out = {4'b0000,in};
So you have to use reg data type to sore the value.
ERROR : Non reg type is not valid on the left hand side of this assignment
When you use reg data type then you can store value in out data type.
So, your problem is solved.
Here I also provide code which will run fine.
module sext(input [3:0]in, output reg [7:0]out);
always_comb
begin
if(in[3]==1'b0)
assign out = {4'b0000,in};
else
assign out = {4'b1111,in};
end
endmodule
I have an array that I would like to initialize to all 1. To do this, I used the following code snippet:
logic [15:0] memory [8];
always_ff #(posedge clk or posedge reset) begin
if(reset) begin
memory <= '{default:'1};
end
else begin
...
end
end
My simulator does what I think is the correct thing and sets the registers to 16'hFFFF on reset. However, my lint tool gives me a warning that bit 0 has an async set while bits 1 through 15 have async resets. This implies that the linter thinks that this code assigns 16'h0001 to the registers.
Since both tools come from the same vendor I file a bug report since they can't both be right.
The question is: Which behavior is correct according to the spec? There is no example that shows this exact situation. Section 5.7.1 mentions that:
An unsized single-bit value can be specified by preceding the single-bit value with an apostrophe ( ' ), but
without the base specifier. All bits of the unsized value shall be set to the value of the specified bit. In a
self-determined context, an unsized single-bit value shall have a width of 1 bit, and the value shall be treated
as unsigned.
'0, '1, 'X, 'x, 'Z, 'z // sets all bits to specified value
I f this is a "self-determined context" then the answer is 1 bit sign extended to 16'h0001, but if it is not, then I guess the example which says it "sets all bits to the specified value" applies. I am not sure if this is a self -determined context.
The simulator is correct: memory <= '{default:'1}; will assign all each bit in memory to 1. The linting tool does have a bug. See IEEE Std 1800-2012 § 10.9.1 Array assignment patterns:
The **default:***value* applies to elements or subarrays that are not matched by either index or type key. If the type of the element or subarray is a simple bit vector type, matches the self-determined type of the value, or is not an array or structure type, then the value is evaluated in the context of each assignment to an element or subarray by the default and shall be castable to the type of the element or subarray; otherwise, an error is generated. ...
The LRM goes beyond what is synthesizable when it comes to assignment patterns. And most of the tools are sill playing catchup with supporting all the SystemVerilog features. Experiment to make sure your tools (simulator,synthesizer, lint tool, logic-equivalency-checker, etc.) all have the necessary support for the features you want.