Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

System Verilog error VLOG-13069 from Questasim with unpacked array

Status
Not open for further replies.

barry

Advanced Member level 7
Joined
Mar 31, 2005
Messages
6,321
Helped
1,194
Reputation
2,400
Reaction score
1,385
Trophy points
1,393
Location
California, USA
Activity points
34,397
I've finally bitten the bullet and crossed over from VHDL to the dark world of System Verilog. I've got a testbench that causes Questasim (Modelsim) to throw the following error:

# ** Error: (vlog-13069) C:/AirMattress/ARIN_Main/tb_top_beam.sv(571): near "[": syntax error, unexpected '[', expecting ';'.

Here's the piece of code that causes the error; it's the line with "slice=" that causes the problem. This looks perfectly ok to me; what am I doing wrong?

Code:
		logic [39:0] bt1[511:0];
		logic [39:0] bt2[511:0];
		logic [39:0] bt3[511:0];
		logic [39:0] bt4[511:0];
		logic [4:0]slice;
		logic [39:0]row;
initial
	begin
		$display (" ");
		$display (" ");
		$readmemh("beam_table1.txt",bt1);
		$readmemh("beam_table2.txt",bt2);
		$readmemh("beam_table3.txt",bt3);
		$readmemh("beam_table4.txt",bt4);
		#10ms;
		slice=bt1[12:8][1];

- - - Updated - - -

Update: if I pull the elements out separately, it works fine:
Code:
		logic [39:0] bt1[0:511];
		logic [39:0] bt2[0:511];
		logic [39:0] bt3[0:511];
		logic [39:0] bt4[0:511];
		logic [4:0]slice;
		logic [39:0]row;
initial
	begin
		$display (" ");
		$display (" ");
		$readmemh("beam_table1.txt",bt1);
		$readmemh("beam_table2.txt",bt2);
		$readmemh("beam_table3.txt",bt3);
		$readmemh("beam_table4.txt",bt4);
		#10ms;
		row=bt1[1];
		slice=row[12:8];
 

You have the select indexes in the wrong order. Packed dimensions come after unpacked dimensions.
slice=bt1[1][12:8];
 

You have the select indexes in the wrong order. Packed dimensions come after unpacked dimensions.
slice=bt1[1][12:8];
First of all, I don’t think that’s right. Second of all, I shouldn’t have gotten that error even if the dimensions were reversed, i.e., the dimensions weren’t out of bounds.
 

Verilog/SystemVerilog only allows contiguous slices of arrays. Your original question seems like you were trying to take a noncontiguous slice, but then your updated example was definitely contiguous. It would help if you put values in your example and told us what kind of results you are expecting.
 

First of all, I don’t think that’s right. Second of all, I shouldn’t have gotten that error even if the dimensions were reversed, i.e., the dimensions weren’t out of bounds.
using the following example arrays:

Code Verilog - [expand]
1
2
3
logic [3:0]       bt1[7:0];
logic [3:0][7:0]  bt2;
logic [7:0][3:0]  bt3;



The bit definitions of the arrays are:

Code:
bt1 (8 unpacked nibbles):
  7777
  6666
  5555
  4444
  3333
  2222
  1111
  0000

bt2 (4 packed bytes):
  33333333222222221111111100000000

bt3 (8 packed nibbles):
  77776666555544443333222211110000
where the number represents the number of the nibble (the bit vector).

As you defined your slice as:

Code:
bt1[12:8][1]

Translating to a range that is valid for the example we could attempt a slice like this:

Code:
bt1[3:2][1]

This results in the following bold red bits being sliced in each case:

Code:
bt1:
  7777
  6666
  5555
  4444
  33[b][COLOR="#FF0000"]3[/COLOR][/b]3
  22[b][COLOR="#FF0000"]2[/COLOR][/b]2
  1111
  0000

bt2:
  333333[b][COLOR="#FF0000"]3[/COLOR][/b]3222222[b][COLOR="#FF0000"]2[/COLOR][/b]21111111100000000

bt3:
  777766665555444433[b][COLOR="#FF0000"]3[/COLOR][/b]322[b][COLOR="#FF0000"]2[/COLOR][/b]211110000

all of these slices are illegal as they are not contiguous bits (packed), hence the syntax error you recieve, even when you use ranges that are valid for either of the array dimensions.

Verilog/Systemverilog requires that the packed bit-vector slice is the right most bracketed range all other dimensions have to be single number indices.
 

using the following example arrays:

Code Verilog - [expand]
1
2
3
logic [3:0]       bt1[7:0];
logic [3:0][7:0]  bt2;
logic [7:0][3:0]  bt3;



The bit definitions of the arrays are:

Code:
bt1 (8 unpacked nibbles):
  7777
  6666
  5555
  4444
  3333
  2222
  1111
  0000

bt2 (4 packed bytes):
  33333333222222221111111100000000

bt3 (8 packed nibbles):
  77776666555544443333222211110000
where the number represents the number of the nibble (the bit vector).

As you defined your slice as:

Code:
bt1[12:8][1]

Translating to a range that is valid for the example we could attempt a slice like this:

Code:
bt1[3:2][1]

This results in the following bold red bits being sliced in each case:

Code:
bt1:
  7777
  6666
  5555
  4444
  33[b][COLOR="#FF0000"]3[/COLOR][/b]3
  22[b][COLOR="#FF0000"]2[/COLOR][/b]2
  1111
  0000

bt2:
  333333[b][COLOR="#FF0000"]3[/COLOR][/b]3222222[b][COLOR="#FF0000"]2[/COLOR][/b]21111111100000000

bt3:
  777766665555444433[b][COLOR="#FF0000"]3[/COLOR][/b]322[b][COLOR="#FF0000"]2[/COLOR][/b]211110000

all of these slices are illegal as they are not contiguous bits (packed), hence the syntax error you recieve, even when you use ranges that are valid for either of the array dimensions.

Verilog/Systemverilog requires that the packed bit-vector slice is the right most bracketed range all other dimensions have to be single number indices.
Now youve REALLY confused me. Youve defined Bt1 as 8 elements of 4 bits each; youve shown it as an array of 8 elements of 32 bits.

But still, doesnt bt1[3:2][1] select bits 3,2 of the second row? If that's backwards, then would bt1[1][3:2] select that slice?
 

No the numbers just represent the bits for a specific array entry they aren't hex digits. I though the widths of the bits and the descriptions would be enough to be clear what I was showing, I guess it wasn't enough. That 7777 (isn't a 16-bit or 32-bit value) it is the 4-bits of the row 7 bits. The use of the numbers was to make the rows distinguishable when in the packed format, i.e. bt3 is the packed format of the all 8 4-bit values in memory (the simulation's database)

the declaration of an array is represented by the unpacked array:
logic [#bits-1:0] bt1 [#rows-1:0];

or by a packed array:
logic [#rows-1:0][#bits-1:0] bt1;

and both of these representations can be referenced using the following nomenclature:
bt1[a_row][bit_slice]

similarly a 2D array of bits would be declared as:
logic [#cols-1:0][#rows-1:0][#bits-1:0] bt1;

A nice feature of using packed arrays instead of unpacked arrays is you can treat the array variable in assignments as a rows*bits wide bit vector and assign all the array values with a single assignment without for loops.

Code:
logic [31:0] entire_bt;
logic [7:0][3:0] bt1;

bt1 = 32'b 0111_0110_0101_0100_0011_0010_0001_0000;  // assigns all array nibbles at once
entire_bt = bt1; // assigns the entire array to a bit-vector

// which is equivalent to
entire_bt[31:28] = bt1[7][3:0];
entire_bt[27:24] = bt1[6][3:0];
...
entire_bt[3:0] = bt1[0][3:0];

- - - Updated - - -

But still, doesnt bt1[3:2][1] select bits 3,2 of the second row? If that's backwards, then would bt1[1][3:2] select that slice?
bt1[3:2][1] is illegal because the row selected is not a single row but two different rows and you are trying to extract bit one from those two rows. These bits are not part of the same bit-vector and can't be sliced.

The bit vector specified is done with the last bracketed value in this case it's [1], i.e. a single bit. When swapped bt1[1][3:2] now it is specifying the data in row 1 bit vector [3:2] which are contiguous bits in a bit vector.

This is no different from VHDL, which also has ordering rules for which dimension is represented.
 

The bit vector specified is done with the last bracketed value in this case it's [1], i.e. a single bit. When swapped bt1[1][3:2] now it is specifying the data in row 1 bit vector [3:2] which are contiguous bits in a bit vector.

That’s the answer I was looking for; I simply had the indexes swapped. Someone who I thought knew more about such things misinformed me. I will try that when I get back from vacation.
 

That’s the answer I was looking for; I simply had the indexes swapped. Someone who I thought knew more about such things misinformed me. I will try that when I get back from vacation.

dave_59 in post #2 mentioned the indices were swapped, you must have misread the line.
 

Well, that was it; indices were reversed. My SV guru was adamant about doing it the (wrong) way that I was. Minus guru points for him.

Thanks all.
 

Well, that was it; indices were reversed. My SV guru was adamant about doing it the (wrong) way that I was. Minus guru points for him.

Thanks all.
Insisting something is right when it doesn't compile should give them a less than 0 guru score IMO.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top