[SV parser] p552.sv the queue types

[Nic30]

p552.sv

function int[$] GenQueue(int low, int high);

The grammar does not support the definition of queue type like this. It seems that the other tools does not underestand this syntax as well. returning-queue-from-function-in-systemverilog

  int[$] q;

Similar problem as previous one. Everywhere except in this example the [$] is always behind variable id. It seems to me that the example is wrong.

[Thomasb81]

For me both construction are legal.

First one means the function GenQueue return an unbound list of int. The second line define q as an array with an undefined or unspecified list of element.

You have to use the method size() to know the number of element in the list. And the number of element can change over the time.

[Nic30]

To solve this once for all it would be best to have predicates for type/non-type hierarchical/non-hierarchical id parsing. Or even better parse any id and then decide it's possible types.

The problem is that predicates are making grammar target dependent. Do you know if there is some way how to just set flags and use them as predicates without using target language within g4?

[Thomasb81]

I should come back on my words. I though now that int[$] q; is illegal. While it must be noted: int q[$] Because here we want to declare an unbound array of int. The previous notation does not make sense: "unbound packed of int".

The construction function int[$] GenQueue(int low, int high);

failed to be properly recognize by the grammar, same for: function int[4][5] GenQueue(int low, int high);

I propose:

function_data_type_or_implicit:
 data_type_or_void ( variable_dimension )*  
      | implicit_data_type 
     ;

instead of

function_data_type_or_implicit:
 data_type_or_void 
      | implicit_data_type 
     ;

In sv2017Parser.g4.

Remaining issues are related to randsequence, that cannot appear at top level construction and is probably malformed.

[Thomasb81]

Find attach a fix of the source code, as I though it could be. p552.sv.txt

[Nic30]

Agree, but I will fix it after removing of ambiguity from expressions, data_type etc. ( I am currently wring the optimizer to do this. But it still needs some polishing because currently it makes grammar unreadable. )

[Nic30]

fixed in new grammar