«

On Jun 12, 2:42 pm, Jim Lewis <j...@synthworks.com> wrote:
> rickman
>
>
>
> > BTW, here is one of the reasons I am getting tried of using VHDL. I
> > have coded FPGAs in VHDL off and on for some 10 years. Every time I
> > start a new design (sometimes as long as 18 months since the last one)
> > I have to pick up all of my books again to remember the details and to
> > read my notes on the various shortcuts to efficient use. I typically
> > find that the shortcuts are not very short and look for new ones. The
> > notation is just so verbose for simple things. Here is an example.
>
> > CTPBitCnt is an unsigned.
>
> > What I mean...
> > CTPBitCnt <= 1;
>
> > What I have to write...
> > CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
>
> > Doesn't that seem a bit wordy? I guess this example goes back to the
> > inability to overload the assignment operator which someone has
> > indicated may be changed in the next revision of the language.
>
> Jonathan just submitted a language feature request WRT to overloading
> assignment, however, the standard is already at the balloting point so
> it will not make the 2008 revision.
>
> What has been added is a decimal notation for bit string literals
> and a sizing indication.
>
> signal CTPBitCnt : unsigned (14 downto 0) ; -- 15 bits
> . . .
> -- Representing 1 as a 15 bit object in either hex or decimal
>
> CTPBitCnt <= 15D"1" ; -- Decimal notation
> CTPBitCnt <= 15X"1" ; -- Hex notation
>
> BTW, these are also in Accellera standard VHDL-2006-rev3.0, so
> if your vendors were looking out for your interests, they would
> have already should implemented these.
>
> Make sure to submit these as bug/enhancement requests. This is important
> as this is what lets them know the VHDL community wants the new features.
>
> Best,
> Jim
>
> P.S. Did you grab the paper I referenced:
> http://www.synthworks.com/papers/vhd...mapld_2003.pdf

Yes, I looked at it. I especially like the comment at the bottom of
page 5

"Some think VHDL is difficult because of strong typing
Master the above simple rules and it is easy"

No, it is not "easy". It is cumbersome and crude. Strong typing is
not the problem, verbosity is! Strong typing may keep you from
screwing up certain things that novices might do, but VHDL is a clumsy
language. Just as you point out above, there are any number of ways
to make the language more succinct and readable, not to mention
helping to let my tendinitis heal. It is hard to imagine that it has
taken over 20 years for many of these simple ideas to be
implemented.

Maybe I am being overly critical. Right now I am pretty ticked off
about the Lattice/Aldec tools I paid a kilobuck for. It won't even
let me make a test bench out of the file I wrote for another chip.

I have a mind to abandon VHDL so that I can use the open source
Verilog tools. It may be too late to use them on this design, but I
will look very hard at open source before I start my next design.

Rick

On Jun 12, 2:42 pm, Jim Lewis <j...@synthworks.com> wrote:
> rickman
>
>
>
> > BTW, here is one of the reasons I am getting tried of using VHDL. I
> > have coded FPGAs in VHDL off and on for some 10 years. Every time I
> > start a new design (sometimes as long as 18 months since the last one)
> > I have to pick up all of my books again to remember the details and to
> > read my notes on the various shortcuts to efficient use. I typically
> > find that the shortcuts are not very short and look for new ones. The
> > notation is just so verbose for simple things. Here is an example.
>
> > CTPBitCnt is an unsigned.
>
> > What I mean...
> > CTPBitCnt <= 1;
>
> > What I have to write...
> > CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
>
> > Doesn't that seem a bit wordy? I guess this example goes back to the
> > inability to overload the assignment operator which someone has
> > indicated may be changed in the next revision of the language.
>
> Jonathan just submitted a language feature request WRT to overloading
> assignment, however, the standard is already at the balloting point so
> it will not make the 2008 revision.
>
> What has been added is a decimal notation for bit string literals
> and a sizing indication.
>
> signal CTPBitCnt : unsigned (14 downto 0) ; -- 15 bits
> . . .
> -- Representing 1 as a 15 bit object in either hex or decimal
>
> CTPBitCnt <= 15D"1" ; -- Decimal notation
> CTPBitCnt <= 15X"1" ; -- Hex notation
>
> BTW, these are also in Accellera standard VHDL-2006-rev3.0, so
> if your vendors were looking out for your interests, they would
> have already should implemented these.
>
> Make sure to submit these as bug/enhancement requests. This is important
> as this is what lets them know the VHDL community wants the new features.
>
> Best,
> Jim
>
> P.S. Did you grab the paper I referenced:
> http://www.synthworks.com/papers/vhd...mapld_2003.pdf

Oh, BTW, some of the features you list above are not really a great
solution. If I write...

CTPBitCnt <= 15D"1" ; -- Decimal notation

I am sprinkling my code with numerical constants that have to be
changed, one at a time, if my declaration changes. What exactly is
the problem that is solved by not allowing...

CTPBitCnt <= 1;

Isn't the meaning of this very clear? If I am assigning it to a
signed signal, then it should be treated as signed, right? If I am
assigning it to an unsigned signal, then it should be treated as
unsigned, right? Maybe I do have a problem with strong typing if it
requires me to be so verbose that the size of my files triple without
adding anything to the clarity of the code.

CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);

What am I missing?

Rick

On Jun 12, 2:42*pm, Jim Lewis <j...@synthworks.com> wrote:
> > Here is an example.
>
> > CTPBitCnt is an unsigned.
>
> > What I mean...
> > * CTPBitCnt <= 1;
>

>
> Jonathan just submitted a language feature request WRT to overloading
> assignment, however, the standard is already at the balloting point so
> it will not make the 2008 revision.
>
> What has been added is a decimal notation for bit string literals
> and a sizing indication.
>
> signal CTPBitCnt : unsigned (14 downto 0) ; -- 15 bits
> . . .
> -- Representing 1 as a 15 bit object in either hex or decimal
>
> CTPBitCnt <= 15D"1" ; * -- Decimal notation
> CTPBitCnt <= 15X"1" ; * -- Hex notation
>

The type of syntax only a mother could love...

Let's take a look at some notations

A: CTPBitCnt <= 1;
B: CTPBitCnt <= to_unsigned(1);
C: CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
D: set(CTPBitCnt, "<=", 1);
E: CTPBitCnt <= 15D"1"
F: CTPBitCnt <= CTPBitCnt'length D"1";??

'A' has the advantage of clarity of intent...it has the drawback of
requring loose type checking in the language.

'B' has the advantage of clarity of intent...and it meets the
requirements of strong type checking and is not overly wordy.
Requires the "<=" and the ":=" operators to be overriddent in the
language (in other words just like all the other operators).

'C' is valid VHDL'93 syntax. It is too verbose and subject to error
if one inadverantly does not have the same signal name preceding the
'length attribute that is on the left hand side of the statement.

'D' is kludgy but fairly succint in getting the intent across. Has
the drawback that one would need separately named functions to assign
signals versus variables (why the language does not allow an override
in this case is pointless...but a separate grouse).

'E' is valid VHDL'2008 that has lost the designer's intent...15B??
hmmm....

'F' might be valid VHDL'2008, not sure. But in order to write code
that you don't have to keep re-writing when the width of 'CTPBitCnt'
changes is how you would want to express it. Even if it were legal,
it is just a butt ugly version of what is currently available with
VHDL'93. It's not an improvement, it's worse. Not only do you have
to specify the width (as you do today) but now the intent of the
statement is only clear to those who understand that a 'D' or an 'X'
preceding a constant is specifying the bit width of the
constant....ummmm....OK, I think I'll stick with today's to_unsigned
notation.

Were I to rank them in order of preference it would be
1. 'B', it has everything that a strongly typed language requires and
succintly captures the designer's intent which is to assign an integer
value to an unsigned signal.

2. 'D' has all the same benefits of 'B' but is somewhat klunky and is
only a kludge to get around the unneeded language limitation that
prohibits overriding '<=' and ':='

3. 'C'...all the benefits of 'B' but is overly wordy as has already
been pointed out.

4. 'A'...I'd be comfortable with relax strong type checking in this
particular narrow instance before I'd take the final choices

5. 'E' and 'F'. Absolutely nothing about it is better than what we
have with today's to_unsigned() function and it is far worse in that
the designer's intent has been lost.


> BTW, these are also in Accellera standard VHDL-2006-rev3.0, so
> if your vendors were looking out for your interests, they would
> have already should implemented these.
>
> Make sure to submit these as bug/enhancement requests. *This is important
> as this is what lets them know the VHDL community wants the new features.
>

I think I'll sit out requesting this particular enhancement from the
vendors.

Kevin Jennings

rickman wrote:

> No, it is not "easy". It is cumbersome and crude. Strong typing is
> not the problem, verbosity is! Strong typing may keep you from
> screwing up certain things that novices might do, but VHDL is a clumsy
> language. Just as you point out above, there are any number of ways
> to make the language more succinct and readable, not to mention
> helping to let my tendinitis heal.

VHDL-2002 is what it is.
The tendinitis might do better if you pick
one of the working solutions we have offered
and use it, rather than dissertating on vhdl-2010.

-- Mike Treseler

On Jun 13, 1:31 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> rickman wrote:
> > No, it is not "easy". It is cumbersome and crude. Strong typing is
> > not the problem, verbosity is! Strong typing may keep you from
> > screwing up certain things that novices might do, but VHDL is a clumsy
> > language. Just as you point out above, there are any number of ways
> > to make the language more succinct and readable, not to mention
> > helping to let my tendinitis heal.
>
> VHDL-2002 is what it is.
> The tendinitis might do better if you pick
> one of the working solutions we have offered
> and use it, rather than dissertating on vhdl-2010.
>
> -- Mike Treseler

Thanks for your commments Mike. If you are tired of the conversation,
feel free to not participate.

Rick

You present a nice list. Thanks.

On Jun 13, 8:24 am, KJ <kkjenni...@sbcglobal.net> wrote:
> On Jun 12, 2:42 pm, Jim Lewis <j...@synthworks.com> wrote:
>
> > > Here is an example.
>
> > > CTPBitCnt is an unsigned.
>
> > > What I mean...
> > > CTPBitCnt <= 1;
>
> > Jonathan just submitted a language feature request WRT to overloading
> > assignment, however, the standard is already at the balloting point so
> > it will not make the 2008 revision.
>
> > What has been added is a decimal notation for bit string literals
> > and a sizing indication.
>
> > signal CTPBitCnt : unsigned (14 downto 0) ; -- 15 bits
> > . . .
> > -- Representing 1 as a 15 bit object in either hex or decimal
>
> > CTPBitCnt <= 15D"1" ; -- Decimal notation
> > CTPBitCnt <= 15X"1" ; -- Hex notation
>
> The type of syntax only a mother could love...
>
> Let's take a look at some notations
>
> A: CTPBitCnt <= 1;
> B: CTPBitCnt <= to_unsigned(1);
> C: CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
> D: set(CTPBitCnt, "<=", 1);
> E: CTPBitCnt <= 15D"1"
> F: CTPBitCnt <= CTPBitCnt'length D"1";??
>
> 'A' has the advantage of clarity of intent...it has the drawback of
> requring loose type checking in the language.

This is the issue that I am struggling with understanding. Strong
type checking is good in many contexts. But I fail to understand why
it has to prevent me in this case. In fact, I think that someone said
that this is being proposed for the next, next rev of the language.
So obviously it does not present any real issues to make it
incompatible with strong type checking.

I see it as akin to the issue that had previously existed with string
literals. It has been quite a while, so maybe I don't recall
correctly, but I think there was a time when hex constants could not
be used with the slv type. Since then this has been added so I don't
have to convert a bit string literal to an slv literal. I don't know
how they did it and I don't care a lot. I just see that it was pretty
durn obvious that it would have been desirable to support this from
the start and it was not done.

Likewise it seems to me that making version A acceptable is obviously
desirable and it sounds like it is going to happen. But why did it
take 20 years for someone to figure it out?


> 'B' has the advantage of clarity of intent...and it meets the
> requirements of strong type checking and is not overly wordy.
> Requires the "<=" and the ":=" operators to be overriddent in the
> language (in other words just like all the other operators).

I honestly don't understand why the intent is not clear in example A.
I specified that CTPBitCnt was an unsigned signal in the declaration.
Does it make any sense to assume that I mean the literal 1 to be
anything other than an unsigned equivalent? Maybe my software courses
in college were too long ago for me to have learned why strong typing
has to be so cumbersome.


> 'C' is valid VHDL'93 syntax. It is too verbose and subject to error
> if one inadverantly does not have the same signal name preceding the
> 'length attribute that is on the left hand side of the statement.

Yes, and errors are what we are trying to prevent. Of course this
will be caught before it is turned in to a chip, but that whole cycle
of edit-compile-test, even if it is shortened to edit-compile is a
PITA. Maybe I am admitting to being a poor programmer, but today I
actually spend over 15 minutes dealing with compiler complaints about
locally static stuff that is totally obvious to anyone reading the
code. And all that was from a 2 minute code change! I don't memorize
things very well. I expect my tools to be obvious and intuitive...
maybe I should stick to hammers, chisels and sanders? I may get
frustrated, but this stuff does pay a lot better.


> 'D' is kludgy but fairly succint in getting the intent across. Has
> the drawback that one would need separately named functions to assign
> signals versus variables (why the language does not allow an override
> in this case is pointless...but a separate grouse).

I assume this is a special procedure to perform the required function
by reading the middle term? Interesting...


> 'E' is valid VHDL'2008 that has lost the designer's intent...15B??
> hmmm....

To be honest, I don't see how this one can even work. Is this
intended to indicate a signed or an unsigned value? How do you
indicate the other? I don't need to say anything about the 15 part...


> 'F' might be valid VHDL'2008, not sure. But in order to write code
> that you don't have to keep re-writing when the width of 'CTPBitCnt'
> changes is how you would want to express it. Even if it were legal,
> it is just a butt ugly version of what is currently available with
> VHDL'93. It's not an improvement, it's worse. Not only do you have
> to specify the width (as you do today) but now the intent of the
> statement is only clear to those who understand that a 'D' or an 'X'
> preceding a constant is specifying the bit width of the
> constant....ummmm....OK, I think I'll stick with today's to_unsigned
> notation.
>
> Were I to rank them in order of preference it would be
> 1. 'B', it has everything that a strongly typed language requires and
> succintly captures the designer's intent which is to assign an integer
> value to an unsigned signal.
>
> 2. 'D' has all the same benefits of 'B' but is somewhat klunky and is
> only a kludge to get around the unneeded language limitation that
> prohibits overriding '<=' and ':='
>
> 3. 'C'...all the benefits of 'B' but is overly wordy as has already
> been pointed out.
>
> 4. 'A'...I'd be comfortable with relax strong type checking in this
> particular narrow instance before I'd take the final choices
>
> 5. 'E' and 'F'. Absolutely nothing about it is better than what we
> have with today's to_unsigned() function and it is far worse in that
> the designer's intent has been lost.
>
> > BTW, these are also in Accellera standard VHDL-2006-rev3.0, so
> > if your vendors were looking out for your interests, they would
> > have already should implemented these.
>
> > Make sure to submit these as bug/enhancement requests. This is important
> > as this is what lets them know the VHDL community wants the new features.
>
> I think I'll sit out requesting this particular enhancement from the
> vendors.

The more I read about this, the more I like Verilog... at least until
I start using it ;^)

Rick

"rickman" <> wrote in message
news:37c87ac4-768f-405f-a262-...
> You present a nice list. Thanks.
>
>> 'A' has the advantage of clarity of intent...it has the drawback of
>> requring loose type checking in the language.
>
> This is the issue that I am struggling with understanding. Strong
> type checking is good in many contexts. But I fail to understand why
> it has to prevent me in this case. In fact, I think that someone said
> that this is being proposed for the next, next rev of the language.
> So obviously it does not present any real issues to make it
> incompatible with strong type checking.
>

It breaks the rules of strong type checking because 'CTPBitCnt' is of type
'unsigned' and '1' is of type integer and assigning something of one type to
something that is of another type directly without some form of conversion
function breaks what is considered to be strong type checking.

Relaxation of the rules in certain instances (like this one) can be a
productivity enhancer and a 'good' thing for the language but you should
also accept that this relaxing of the rules IS a violation of strong type
checking.

<snip>
>
>> 'B' has the advantage of clarity of intent...and it meets the
>> requirements of strong type checking and is not overly wordy.
>
> I honestly don't understand why the intent is not clear in example A.

Flip back and you'll see that I said that both 'A' and 'B' are clear about
the designer's intent.

> I specified that CTPBitCnt was an unsigned signal in the declaration.
> Does it make any sense to assume that I mean the literal 1 to be
> anything other than an unsigned equivalent?

I hate having to flip back to the declaration to see what the type of a
particular signal is.

> Maybe my software courses
> in college were too long ago for me to have learned why strong typing
> has to be so cumbersome.
>

It needn't be...overrides for "<=" and ":=" would solve the wordiness
problem and still provide for the strong type checking....as someone else
stated, other languages have it. The needed conversion function can be the
function that provides an operator overload....just like how one can
overload "and", "or", etc. to work with custom types today.

<snip>
>
>> 'D' is kludgy but fairly succint in getting the intent across.
>
> I assume this is a special procedure to perform the required function
> by reading the middle term? Interesting...
>

Yes, it would be a homegrown procedure that one would put into a package of
commonly used functions. Just as you get into the habit of including the
std_logic stuff at the begining of every VHDL file you would start to
include your package of homegrown stuff and then always have these shortcuts
handy.

By the way, the middle term "<=" wouldn't even be used by the procedure it
would simply be there to aid the reader since something like this

set (this, that)

would always cause someone to say, well does that mean
this <= that
or
that <= this?

whereas
set (this "<=" that);
would be more clear...at the expense of more typing....for a parameter that
doesn't functionally contribute anything...I can hear the moans and groans
already, but you can make your homegrowns your way, I'll make 'em mine.

The procedure should have an assert to make sure that the middle term is
"<=" though so that some smarty pants that said

set (this, "=>" that)

would get hammered in simulation by firing an assertion.

>
>> 'E' is valid VHDL'2008 that has lost the designer's intent...15D??
>> hmmm....
>
> To be honest, I don't see how this one can even work. Is this
> intended to indicate a signed or an unsigned value? How do you
> indicate the other? I don't need to say anything about the 15 part...
>

VHDL has a lot of nice things....this one isn't one of them...well, assuming
that it actually gets approved.

>
> The more I read about this, the more I like Verilog... at least until
> I start using it ;^)
>
comp.lang.verilog is always looking for members....and from what I read
Verilog is finally catching up to VHDL.

KJ

On Jun 13, 10:35 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "rickman" <gnu...@gmail.com> wrote in message
>
> news:37c87ac4-768f-405f-a262-...
>
> > You present a nice list. Thanks.
>
> >> 'A' has the advantage of clarity of intent...it has the drawback of
> >> requring loose type checking in the language.
>
> > This is the issue that I am struggling with understanding. Strong
> > type checking is good in many contexts. But I fail to understand why
> > it has to prevent me in this case. In fact, I think that someone said
> > that this is being proposed for the next, next rev of the language.
> > So obviously it does not present any real issues to make it
> > incompatible with strong type checking.
>
> It breaks the rules of strong type checking because 'CTPBitCnt' is of type
> 'unsigned' and '1' is of type integer and assigning something of one type to
> something that is of another type directly without some form of conversion
> function breaks what is considered to be strong type checking.
>
> Relaxation of the rules in certain instances (like this one) can be a
> productivity enhancer and a 'good' thing for the language but you should
> also accept that this relaxing of the rules IS a violation of strong type
> checking.

I think my point is that calling 1 an integer is arbitrary. It has
been defined as an integer, just like X"5A69" was originally defined
as a bit vector. But we can also see it as a std_logic_vector and
understand its meaning. I feel that calling 1 an integer is
arbitrary. I can consider it to be a unconstrained slv literal just
as easily as an integer. I understand that this is not part of the
language, but I don't see any reason that it can't be. I don't see
any ambiguity in considering integer numbers to represent slv of
indeterminate length.


> >> 'B' has the advantage of clarity of intent...and it meets the
> >> requirements of strong type checking and is not overly wordy.
>
> > I honestly don't understand why the intent is not clear in example A.
>
> Flip back and you'll see that I said that both 'A' and 'B' are clear about
> the designer's intent.
>
> > I specified that CTPBitCnt was an unsigned signal in the declaration.
> > Does it make any sense to assume that I mean the literal 1 to be
> > anything other than an unsigned equivalent?
>
> I hate having to flip back to the declaration to see what the type of a
> particular signal is.

Then how would you know to write unsigned(... rather than
signed(... ? Once the code is written, the meaning is obvious, assign
the numerical value 1 to the signal in whatever format is
appropriate. Do you need to know that the signal is signed or
unsigned to understand this assignment?

> > Maybe my software courses
> > in college were too long ago for me to have learned why strong typing
> > has to be so cumbersome.
>
> It needn't be...overrides for "<=" and ":=" would solve the wordiness
> problem and still provide for the strong type checking....as someone else
> stated, other languages have it. The needed conversion function can be the
> function that provides an operator overload....just like how one can
> overload "and", "or", etc. to work with custom types today.

Yes, I think we all agree that would be a good idea. I just don't
understand why it has taken the experts over 20 years to figure this
out. I have only worked with this stuff part of the time and even
then I was just trying to get something done with it, not invent the
language... and I can clearly see the need.


> >> 'D' is kludgy but fairly succint in getting the intent across.
>
> > I assume this is a special procedure to perform the required function
> > by reading the middle term? Interesting...
>
> Yes, it would be a homegrown procedure that one would put into a package of
> commonly used functions. Just as you get into the habit of including the
> std_logic stuff at the begining of every VHDL file you would start to
> include your package of homegrown stuff and then always have these shortcuts
> handy.
>
> By the way, the middle term "<=" wouldn't even be used by the procedure it
> would simply be there to aid the reader since something like this
>
> set (this, that)
>
> would always cause someone to say, well does that mean
> this <= that
> or
> that <= this?
>
> whereas
> set (this "<=" that);
> would be more clear...at the expense of more typing....for a parameter that
> doesn't functionally contribute anything...I can hear the moans and groans
> already, but you can make your homegrowns your way, I'll make 'em mine.

Personally, I think set (this, that) is just fine. It is a strange
construct to begin with. But once someone learns about it, it is very
easy to remember that the order is the same as in an assignment. No
confusion there. Or you could name it set_to(this, that) as in "set
this to that". This is starting to sound a bit like Forth...!


> The procedure should have an assert to make sure that the middle term is
> "<=" though so that some smarty pants that said
>
> set (this, "=>" that)
>
> would get hammered in simulation by firing an assertion.
>
>
>
> >> 'E' is valid VHDL'2008 that has lost the designer's intent...15D??
> >> hmmm....
>
> > To be honest, I don't see how this one can even work. Is this
> > intended to indicate a signed or an unsigned value? How do you
> > indicate the other? I don't need to say anything about the 15 part...
>
> VHDL has a lot of nice things....this one isn't one of them...well, assuming
> that it actually gets approved.
>
>
>
> > The more I read about this, the more I like Verilog... at least until
> > I start using it ;^)
>
> comp.lang.verilog is always looking for members....and from what I read
> Verilog is finally catching up to VHDL.
>
> KJ

Well, I still need to get this one done. I'll wait and see if I am
still inclined to jump ship when I start the next project.

Rick

"rickman" <> wrote in message
news:bdf4e73d-f1d1-460d-a92c-...
>> > I specified that CTPBitCnt was an unsigned signal in the declaration.
>> > Does it make any sense to assume that I mean the literal 1 to be
>> > anything other than an unsigned equivalent?
>>
>> I hate having to flip back to the declaration to see what the type of a
>> particular signal is.
>
> Then how would you know to write unsigned(... rather than
> signed(... ? Once the code is written, the meaning is obvious, assign
> the numerical value 1 to the signal in whatever format is
> appropriate. Do you need to know that the signal is signed or
> unsigned to understand this assignment?

In C/C++, "promotion" of signed integer values is sign-bit extension;
unsigned promotion is zero-extension. It seems a resaonable enough approach
to the problem you define. You only need to clearly establish whether your
literal constant is signed or unsigned.

>> > Maybe my software courses
>> > in college were too long ago for me to have learned why strong typing
>> > has to be so cumbersome.

C++ clearly defines type coercions, but we needn't go there on this, I
think. I can tell you that allowing C-style typecasts, similar to VHDL
typecasts, defeats its type system. VHDL, by not allowing more reasonable
constructs, encourages the same abuse and misuse.

>> It needn't be...overrides for "<=" and ":=" would solve the wordiness
>> problem and still provide for the strong type checking....as someone else
>> stated, other languages have it.

Yikes. Are there times when the two would be defined differently?

>> The needed conversion function can be the
>> function that provides an operator overload....just like how one can
>> overload "and", "or", etc. to work with custom types today.
>
> Yes, I think we all agree that would be a good idea. I just don't
> understand why it has taken the experts over 20 years to figure this
> out. I have only worked with this stuff part of the time and even
> then I was just trying to get something done with it, not invent the
> language... and I can clearly see the need.

I can see some issues. But so far, it sounds like you only want to better
define assignment of signed/unsigned integer values and literal constants.
Size promotion rules will cover it without fighting that battle.

What other use would you have for assignment overload?

"rickman" <> wrote in message
news:bdf4e73d-f1d1-460d-a92c-...
> On Jun 13, 10:35 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
>> "rickman" <gnu...@gmail.com> wrote in message
>>
>> news:37c87ac4-768f-405f-a262-...
>>
>
>> would always cause someone to say, well does that mean
>> this <= that
>> or
>> that <= this?
>>
>> whereas
>> set (this "<=" that);
>> would be more clear...at the expense of more typing....for a parameter
>> that
>> doesn't functionally contribute anything...I can hear the moans and
>> groans
>> already, but you can make your homegrowns your way, I'll make 'em mine.
>
> Personally, I think set (this, that) is just fine. It is a strange
> construct to begin with. But once someone learns about it, it is very
> easy to remember that the order is the same as in an assignment. No
> confusion there.

But you would also have to admit that the learning curve upon first seeing
set(this, "<=", that) is lower (hopefully non-existent) than it is for
set(this,that) since the "<=" parameter makes it plainly obvious which is
the target of the assignment (although one can certainly quibble about the
name, maybe 'copy' would be better than 'set').

So now you get into the tradeoff between productivity gained while banging
in the code (if you don't have to type in the "<=" every time you use it)
versus productivity lost (from having to go back to refresh your noggin on
which is the target if you don't use this on a daily basis) in later
supporting the code. While you're focusing right now on the code entry
hassles, remember that effort only gets done once, but you (or someone else)
will have to look at it more than once and not always while it's still fresh
in your mind, maybe years later...or perhaps by someone else who has to
support your design after you move on....then again, maybe the obscure
approach is better from a future support contracting perspective....after
all, that's partly why suppliers generate obtuse code for 'wizard' generated
widgets to make it at least a bit of a pain to go back and
rework/modify/extend it.

Anyway, I just tossed this procedure one out as an idea and admitted it is
klunky, but certainly less so than the 15D/15X prefix thing.

We're certainly off on a tangent from your original query. You can always
submit an enhancement request in to the VHDL gods. I don't have the link
handy but if you Google for Accelera and VHDL enhancements you can probably
find the link, Jim Lewis' posts sometimes have it since he is part of that
group. I submitted a couple that got accepted...although I'm not sure
when/if they ever will/did make it into the new standard.

Kevin Jennings