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

[rickman]

rickman








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/vhdl_math_tricks_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

 

[rickman]

rickman








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/vhdl_math_tricks_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

 

[KJ]

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

 

[Mike Treseler]

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

 

[rickman]

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

 

[rickman]

You present a nice list. Thanks.

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.



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

 

[KJ]

You present a nice list. Thanks.


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 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.

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.

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

 

[rickman]

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.

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


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?

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.

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.





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




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

 

[MikeWhy]

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.

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.

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

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?

 

[KJ]

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

 

[KJ]

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?

I second Jonathon's post. The new fixed/floating point library is an
excellent example of why you would want this. While it's great that it can
be used with existing VHDL-93, having to put the size of the thing being
assigned to on the right hand side just so the function can know the size of
the thing being assigned to really clutters up and obscures things. The
declaration of a signal becomes quite interesting in how to format it to
even look intelligible to the reader.

Kevin Jennings

 

[KJ]

KJ,

Don't hold your breath.

I never do, I find work arounds instead...much more effective than breath
holding.

The only way to get what you can live with (not necessarily even
what you want) is to participate in the standards development.

I think you misinterpreted what I meant. By saying "I'll wait for one I
like to see first" I was simply stating that this particular member of the
VHDL community wasn't going to bug the vendors for *this* particular
enhancement to be implemented since I just don't see myself using it for the
reasons that have been pointed out. A new feature that I *am* interested in
using is something I would bug them for if it wasn't already implemented.

Presumably the indiviauals that thought the 'D' 'X' notation is what the
VHDL world needs are the ones that should be voicing their needs if their
tools don't support it.

Yacking out here is like screaming at a mountain.

Not really, it's an open forum to discuss problems that others might know a
solution for. Kind of a pre-screening before submitting a bug/enhancement
request. Sometimes the gripe ends in a legitimate enhancement request,
sometimes it ends in the griper learning something they didn't know.

P.S.
If you are an expert VHDL coder there is no reason you should
not be participating.

No idea whether I would qualify as an expert, but I can peruse Accelera and
see what the needs might be.

Kevin Jennings

 

[KJ]

Jonathan,

For fixed point math, to address the range issue, this seems
reasonable, but it also seems open other issues. For example,
if I use an intermediate object that is too small, overloading
":=" will automatically downsize it.

Another solution might be to allow a function access to attributes of the
thing being copied to. Similar to C++ and 'this', maybe a function that
could get the range of the target with something like that'range. So you
could do

function blah(a, b:ufixed) return ufixed is
variable ReturnVal: ufixed(that'range);
begin
....
return(ReturnVal);

Or (perhaps simpler), 'that' would be the thing that can be assigned to and
returned. It would likely require the user of function blah to explicitly
define the range of the target so composing multiple function like

y <= blah(a, blah(b, c))

might not be possible....or maybe it could if the function would define the
range that *it* thought was correct, and just use that'range to error out if
the range wasn't appropriate. In any case, it would give the function some
knowledge of attributes of the target beyond just the signal/variable type.

Kevin Jennings

 

[Andy]

Is that a point? What was the point? Are you trying to say that
users don't design arithmetic circuits in Verilog??? I am pretty sure
that the limited work I have done in Verilog has included arithmetic.
I must be missing your point.

My point is FIXED or FLOATING point arithmetic, not just arithmetic in
general. Verilog as a language does not pass index ranges along with
vectors into operators or functions, so verilog has no means of either
handling a user-definable data subtype that communicates the location
of binary point, or of defining operators and functions that can
operate on those subtypes automatically. Of course, verilog can do
arithmetic, but for FIXED/FLOATING, you have to manage the binary
point (and/or exponent) manually. Sometimes a little language
complexity makes the big picture a lot less complex and error prone.


Andy

 

[KJ]

KJ,


A couple of comments.
Which of these solutions work for numbers larger than 31 bits?

Trick question...VHDL does not guarantee support for 'numbers' beyond
+/- 2**31 (or thereabouts) so 'A-D' do not, they do work over the
entire range of input parameters, which is what you would expect of a
good function. Once the Accelera folks see fit to either extend
integers (or create a new type) that can even represent 'numbers' with
more than 32 bits of precision these functions would still work.

'E' and 'F' do not work with 'numbers' they work with a pair of
literal text strings.

Beyond strong typing, I think the array sizing rules are important.
Definitely.


For details about signed, unsigned, meaning of D or X, see my presentations.
Since I have been posting links to the presentation, I am surprised you
waited to reflect such negative comments.

Negative only in the sense that it is not a solution for converting an
integer into a (un)signed except in the most constrained case (i.e.
the constant will never have a need to change or be parameterized, and
the target length will never a need to change or be parameterized).
Once you get outside of that boundary that notation won't help. Over
the years, I've found that 'never' happens quite frequently.

The fact that it is useful in those constrained cases may make it
useful to some and I won't begrudge them the opportunity to make the
language easier for them if they think it helps even if I see no
benefit to me. For me, I rarely come across an unsigned that I won't
want to have a parameterized length.

If you want to have an opinion in what is done, I suggest that you
PARTICIPATE in the standards.

I've submitted a couple enhancements that I believe were accepted.

KJ

 

[KJ]

"Jim Lewis" <[email protected]> wrote in message

A bit of a follwup on the previous post. After pondering a bit more
it seems that having an optional keyword on function declarations
might do the trick.

Ex:

function foo(a, b: ufixed) return constrained ufixed;

Such a function could then query attributes of the target type to get
the info that it needs (i.e. target'left, target'right, target'range,
target'length) to do it's job. A function without the 'constrained'
keyword would be today's ordinary function call which of course would
have to determine the range of the thing that it is going to return
based on the input parameters alone.

Ex:
function foo(a, b: ufixed) return ufixed;

These functions would be overloaded, the compiler would choose the
appropriate one based on whether or not the target has a defined range
or not. If it did, it would call the 'constrained' version, if not it
would call the 'classic' version.

Such a method would:
- Allow for functions to be aware of attributes of the target that are
important to the function, not just the base type of the target.
- Not require overloading "<=" or ":="
- Still allow for different functions (i.e. the 'classic' version) to
exist which determine the output range based on the input ranges of
the input parameters.

It would eliminate the possibility of getting something wrong in
things where you need to provide attribute information about the
target through a separate input parameter; the classic example being

x <= to_unsigned(Some_Constant, x'length);

Just a thought.

Kevin Jennings