Subject: Re: [vhdl-200x] Implicit conversion, Overloading, & Strong Typing
From: Jim Lewis (Jim@synthworks.com)
Date: Thu Dec 18 2003 - 16:18:51 PST
Hamish Moffatt wrote:
> The problem is that it's implicit, not that it's a conversion function
> with overloading etc. The latter is fine.
Actually, I believe you are comfortable with this
behavior, you are just stuck on "implicit".
Let me give an example:
signal A, Y : unsigned (8 downto 0) ;
Y <= A + "000001111" ;
vs.
Y <= A + 15 ;
This is overloading. The compiler picks the right "+" operator
to call based on the equation and we are happy. It only knows
which one to call based on type of the operands.
Likewise:
if Cs = '1' and Cs2 = '1' then -- if1
vs.
if Cs1 and Cs2 then -- if2
Here the compiler also picks the right "COND" operator for the
expression. For the first one (if1), it sees the top
expression is boolean so it realizes it does not need to call "COND".
For the second one (if2), it sees the top expression results in
std_ulogic, so it applies the "COND" operator to
convert from std_ulogic to boolean. Again, this is all based
on the value of the expression that the top level *conditional*
evaluates to.
The big difference between the "implicit" call and
the handling of overloading is that with overloading,
something is always called. Here when the *conditional*
evaluates to boolean, nothing is called; when the *conditional*
evaluates to bit, the "COND" for bit is called; when the
*conditional* evaluates to std_ulogic, the "COND for std_ulogic
is called.
-------------------------
Evan Lavelle wrote:
> Hang on. You can't overload an expression; that doesn't make sense. You
> want to change the type of an expression according to its context.
Technically, you are correct.
It is an implicit operator that is being proposed to be added.
I am trying to make an analogy that states that shows the
similarity between implicit conversion and operator overloading.
See the example above.
-------------------------
Hamish Moffatt wrote:
> Overloading of the binary logic operators will be crucial too; otherwise
> it's useless. Without it you can't write ...
Agreed. It is in my write-up already. I will be publishing
the write-up shortly. Sorry for the delay (I have been
replying to emails).
This is a really important feature as it also allows expressions
like:
if Cs1 and Cs2 and (Addr = X"A5") then
-- sul sul boolean <<<---- Types
Something else good this does is for the following decode logic.
Currently the Reg1Sel must be coded as follows:
Reg1Sel <= '1' when Cs1='1' and Cs2='1' and (Addr = X"A5") else '0' ;
With just the overloading of the binary logic operators, I can
write:
Reg1Sel <= Cs1 and Cs2 and (Addr=X"A5") ;
For me, the second one is a more natural way to think.
I think it is more natural to think in terms of
std_ulogic equations than it is to think in terms of
boolean equations (and use ='1').
-------------------------
Evan Lavelle wrote:
> It's time to get
> some perspective here. An 'average' chip, if it exists, might take from
> 5 to 100 man years to specify, design, code, document, verify, and
> implement. How much of this 5 - 100 man years is taking up with typing
> on a keyboard? Forget it; it's *zero*.
I agree design capture time is zero, but this is not a reason
not to improve the expressiveness of the language.
I could use this argument to say nothing needs to be done
to either VHDL or Verilog WRT to RTL design. I think we
all agree there are things that each of us want.
-------------------------
I think this one is going to remain a religious topic.
Perhaps the idea to put the "COND" operators and
logic operator overloading into a separate package
should be adopted so we all get something.
Note, package proliferation does not excite me.
I think once people start using it, that it will
become the defacto way to code.
Cheers,
Jim
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Thu Dec 18 2003 - 16:20:37 PST