Re: [Iverilog-devel] Problem with always_comb

[<ni...@ly...>]

Martin Whitaker <ic...@ma...> writes:

> I think the problem is that you are writing to b0 both inside and
> outside the always_comb statement.

I see. If I move out the assignment to b0[7] (and eliminate the
redundant copy via a0[21]) to a separate always @(*) block, tests pass.

> Icarus's sensitivity calculation
> only operates at the word level, not the bit level, so it doesn't
> detect that you are writing to different bits inside and outside.

Bit select expressions must be compile-time constants, right? So it
shouldn't be too hard to detect this case, when Cary or someone else
gets the time to work on it.

> This is of course a bug, but it's not going to be an easy fix. This is
> why I never tackled implementing always_comb.

Detection should be the first step. But to really fix it, could we split
words automatically? Say we have a register [7:0] x, and an always_comb
block which assigns x[7:4]. Then replace x by two registers x_0 [7:4]
and x_1 [3:0] representing subwords. Then each subword should be assigned
in at most one always_comb, and one could also warn for subwords which
are never assigned.

Might make sense to do this splitting also for other types of processes,
for warning purposes. I'm not sure what's actually valid, but I would
expect that one generally should avoid having multiple processes
assigning the same bit (with exceptions for processes that are triggered
by disjoint events, e.g., one proces running on rising clock edge and
another running on falling clock edge).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.