RE: [sv-bc] Pre-Proposal to handle X-problems in RTL coding

Cliff,

I have not yet had time to review the proposal and the following
discussions, but I have a question: 

You have proposed unique0 (parallel_case) as obviating the need for
pre-defaults. I don't see the necessary connection. Pre-defaults are
useful regardless of a case being parallel. You yourself wrote:

> In Advanced Verilog training I always recommend making the 
> pre-default assignment, because it synthesizes to very 
> efficient logic and the pre-default can prevent latches that 
> an equivalent case-default will not fix.

I agree. I have long advocated and taught the use of pre-defaults (even
using the same term). I don't see that latch prevention is necessary
related to parallel_case. 

And pre-defaults have additional benefits. First, they can be used even
in the code describing a flip-flop where I want to specify an output
value for every case, even though latch prevention is not relevant
there.

They also have the benefit that I only need to specify output values
when they are different from the pre-default. This can save an enormous
amount of code, make it much more readable, and reduce the number of
bugs.

There are also cases where I might use both a pre-default and a regular
default. For example, in a state machine, I might use the regular
default to specify the next state when the state machine enters an
illegal state. Typically, that next state would be the initial state of
the machine, typically an IDLE state. On the other hand, I would
typically specify the pre-default of the next state as being the same as
the current state. In that case, I would need to specify the next state
in the code only when it is different from the current state. Staying in
the current state is frequent in state machines. 

What have I missed?

Sorry if you already explained this and I just have not read it yet.

Regards,
Shalom
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.