Re: Signed, Unsigned syntax issues. Please help, I'm stumped

On Sat, 14 Jun 2008 02:30:44 -0500, "MikeWhy" wrote:

>>> ...overrides for "<=" and ":=" would solve the wordiness
>>> problem and still provide for the strong type checking
>
>Yikes. Are there times when the two would be defined differently?

I don't think so.  My proposal to ISAC suggests that only ":=" be
overloaded, and "<=" be redefined as a variable assignment to 
an internal tem****ary of the same subtype as the signal, followed
by all the usual signal assignment rigmarole.  So the overload of
"<=" would follow automatically from any redefined ":=".

>What other use would you have for assignment overload?

I'm clear about why _I_ want it...  

Reason 1:  In any fixed-point package,
I want to be able to do mixed-width arithmetic and have the
result automatically truncated and rounded (using whatever
T&R policy is currently set as the default) as part of
assignment.  Right now this has to be done with an explicit
call to a resize() function; the IEEE fixed-point package
sugar-coats this by allowing you to specify the target 
object as a second argument to resize(), so that resize()
can use that argument to decide what subtype to return.
But overloaded := would be a gazillion times nicer and
more elegant. 

More im****tant still, it would prevent errors that are 
currently unavoidable: if you use := or <= to copy a 
fixed-point value from one place to another, and the 
target object is of the wrong subytpe, you can get its
fixed-point scaling silently and disastrously screwed-up.
Personally I think this leaves VHDL's fixed-point package
holed below the waterline; I would never use it on a 
serious project because of this risk of silent rescaling.


Reason 2:  There are a few places in VHDL where you need a
boolean expression, but other kinds of expression would
make good sense.  For example:

  signal enable: std_logic;
  ...
  if enable then ...   -- currently illegal

It isn't a big stretch to imagine ":="[boolean,std_ulogic]
being automatically invoked in such a situation.  So you
get user control over whether - and how - the test expression
is automatically cast to boolean.

When I submitted the suggestion to ISAC I was completely 
amazed to find that there was nothing similar already
being discussed.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@[EMAIL PROTECTED]
 contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.