|
From: <ni...@ly...> - 2016-05-12 12:30:11
|
Martin Whitaker <mai...@ma...> writes:
>> The expression is
>>
>> rf[write_idx] <= write_data;
>>
>> inside an always @(posedge clk) block. I imagine this is non-trivial to
>> fix, but I'd be very happy to be wrong.
>
> Handling this relatively simple case might not be too hard, but making the tool robust (handling all
> the possible ways a user might use array words on the LHS of an assignment) would be a lot of work.
For the case of -t sizer, I'd be happy if the memory was reported as an
atomic unit with no synthesis of internals. So count the circuit size
for generation of the LHS index, the RHS value, and any mux and enable
logic needed to get the right value assigned at the right time.
> For example, someone might quite reasonably write multiple assignments targeting different words or
> ranges of words in an array.
You're talking of ranges of addresses of words, not ranges of bits
within a word, I hope? Writing multiple words at the same time requires
multiple write ports to the memory (which I guess one would generally
want to avoid). For -t sizer, output like
MEM 64-bit words, size 16, 3 read-ports, 1 write-port
would be nice.
> There are a couple of other ways you could eliminate this warning:
>
> 1) Move the register file read outside the always @* block, e.g.
>
> assign stored_a_data = rf[a_idx];
>
> always @* begin
> if (a_idx == 15)
> a_data = 64'b0;
> else if (write_enable && a_idx == write_idx)
> a_data = write_data;
> else
> a_data = stored_a_data;
> end
[...]
> I would always go for option 1, as it protects against accidentally
> missing a sensitivity.
Thanks a lot for the advice!
I admit I also don't quite understand the fine distinction between
assign stored_a_data = rf[a_idx];
and
always @*
stored_a_data = rf[a_idx];
But I take it the former is a more primitive thing, as far as the
simulator is concerned?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
|