On Feb 9, 9:02 pm, Jonathan Bromley <
s...@oxfordbromley.plus.com>
wrote:
> Whatever you've done, Quartus's message is silly. If your inner
> subprogram really is "function void" then it isn't a task, and the
> error message is ridiculous.
Indeed, the error message is completely erroneous.
> No, it just says that you can't have a function writing to its
> actual arguments in a situation where you don't know exactly
> when the function is going to get called. That would lead to
> fairly mad nondeterminism.
Yup, I suspected that was the case but wasn't completely convinced
after reading the LRM carefully that it was entirely unambiguous. It
would be a pretty severe limitation otherwise!
> Any chance of a code snippet? Did you try it in any other
> tool than Quartus?
Code below, which VCS is happy compiling. I've raised an SR with
Altera who are yet to confirm that it's a Quartus bug.
Thanks for response,
Chris
<code>
module function_example(
input clk,
input [15:0] data,
output [15:0] result);
typedef enum {
STATE1,
STATE2
} state_enum_e;
typedef struct {
state_enum_e state;
logic [15:0] scratch;
} state_t;
state_t state, next_state;
function void handle_state1(input logic [15:0] somedata, inout state_t
self);
self.scratch = somedata;
self.state = STATE2;
endfunction
function void handle_state2(input logic [15:0] somedata, inout state_t
self);
self.scratch &= somedata;
self.state = STATE1;
endfunction
function void dispatcher(input logic [15:0] somedata, inout state_t
self);
case (self.state)
STATE1: handle_state1(somedata, self);
STATE2: handle_state2(somedata, self);
default: self.state = STATE1;
endcase
endfunction
always_comb begin
next_state = state;
dispatcher(data, next_state);
end
always_ff @(posedge clk)
begin
state <= next_state;
end
assign result = state.scratch;
endmodule
</code>