Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Unsupported LHS tristate construct: ARRAYSEL #1278

Open
veripoolbot opened this issue Feb 14, 2018 · 4 comments
Open

Unsupported LHS tristate construct: ARRAYSEL #1278

veripoolbot opened this issue Feb 14, 2018 · 4 comments
Labels
effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800

Comments

@veripoolbot
Copy link
Contributor

Author Name: Rob Stoddard
Original Redmine Issue: 1278 from https://www.veripool.org

I am wondering what this actually means, I was under the impression that this is legal SystemVerilog. I am trying to instantiate the IO padring for my GPIOs using a parameter.

The error I get when I do this is:

%Error: : Unsupported LHS tristate construct: ARRAYSEL

module GPIO_iop
#(
         parameter NumGPIOs = 4
)       (
         inout     p_gpio[NumGPIOs],
         input     do_gpio[NumGPIOs],
         output    di_gpio[NumGPIOs],
         input     do_gpio_hiz[NumGPIOs]
);

genvar i;
generate for(i = 0; i < NumGPIOs; i = i+1) begin: Gen_gpio_0

             IOBUF gpio ( .T(do_gpio_hiz[i]), .I(do_gpio[i]), .O(di_gpio[i]), .IO(p_gpio[i]));
         end
     endgenerate
endmodule
</code>

I also tried doing something like this, but got the exact same error:

module GPIONGeneralPurposeIOs_216_iop
#(
         parameter USERPARAM_NumGPIOs = 4
)       (
         inout     p_gpio[USERPARAM_NumGPIOs],
         input     do_gpio[USERPARAM_NumGPIOs],
         output    di_gpio[USERPARAM_NumGPIOs],
         input     do_gpio_hiz[USERPARAM_NumGPIOs]
);

IOBUF gpio[USERPARAM_NumGPIOs] ( .T(do_gpio_hiz), .I(do_gpio), .O(di_gpio), .IO(p_gpio));

endmodule
</code>

Am I doing something wrong, or is this a currently unsupported feature? If it is unsupported, how hard would it be to have it supported?

Thank you for your assistance in this matter.
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-02-15T12:18:15Z

Any message with "Unsupported" generally means the language supports something but Verilator does not.

In this case, it's strange you are using unpacked arrays. Use packed arrays, e.g. "input [USEPARAM_NUMGPIOs] p_gpio".

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Rob Stoddard
Original Date: 2018-02-15T17:58:41Z

What I provided was a trifle example, as you probably know, I am writing software that generates RTL dynamically. Although I don't have an example of one, there is the chance the user will create a parameter-generated set of busses. Supposing the busses are 8 bits each, the user would have something like:

inout [7:0] p_busses [NumBusses];

of course I can do something like this, but it's a little more painful:

inout [8*NumBusses-1:0] p_busses;

I was just hoping to not have to do that.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Udi Finkelstein
Original Date: 2018-02-25T14:31:38Z

You can use packed arrays instead:

inout [NumBusses-1:0][7:0]p_busses ;

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-02-26T09:05:31Z

Due to how the code currently works supporting arrays will be painful, so is unlikely to be improved in the short term, unless you are willing to commit a patch.

Using packed arrays in some form is the recommended workaround in the meantime.

@veripoolbot veripoolbot added effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800 labels Dec 22, 2019
@wsnyder wsnyder mentioned this issue Nov 9, 2020
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@veripoolbot