Subject: Re: Enumerated Types Proposals - Responding to Kevin and Peter
From: Michael McNamara (mac@verisity.com)
Date: Tue Apr 02 2002 - 21:42:15 PST
Lots of great discussion.
What I see from this is we need the ability to have 'x' bits in named
states for FSMs to fully support existing coding style. (See: casex)
There is an objection to this that stems from the enum initialization,
and subsequent increment syntax: ( { a=3, b, c } := {a=3, b=4, c=5} );
this leads to { a = 4'b1x01, b , c , d } ambiguity. ( presumably b =
4'b1x10, c=4'b1x11, but to what does d get assigned?)
To me, this is a fairly weak argument, as it is extremely easy for any
tool to diagnose the above and give a user an immediate error message.
however, being able to type:
casex(opcode) begin
32'b1xxx_xxxx_xxxx_xxxx: begin: jump
pc = opcode[30] ? pc - opcode[29:0] : pc + opcode[29:0];
end
32'b00xx_xxxx_xxxx_xxxx: begin: loadImmediate
r0 = opcode[29:0];
end
...
by defining jump in an enum:
enum opcode = { jump_op_e = 32'b1_xxxxxxxxxxxxxxx,
loadi_op_e = 32'b00_xxxxxxxxxxxxxx,
add_op_e = 32'b001_000_xxxxx_xxxxx,
sub_op_e = 32'b001_001_xxxxx_xxxxx,
mul_op_e = 32'b001_010_xxxxx_xxxxx,
...
};
Now, as Cliff and Kev hint, one can certainly do the above with
parameters; but won't get the advantage of strong typing.
Enums, with 'x' bits, give us the benefit of both full FSM coding
efficiency; and powerfull use of don't cares. There is a cost in that
enums are now 4 bit values; but guess what: machines are 64 bit these
days... Bugs have more room to hide. We win by using a bit of that
room to build tighter corrals.
-mac
This archive was generated by hypermail 2b28 : Tue Apr 02 2002 - 21:43:26 PST