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

[Jim Lewis]

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/vhdl_math_tricks_mapld_2003.pdf

 

[rickman]

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

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

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

 

[Mike Treseler]

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

 

[rickman]

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

 

[rickman]

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]

On Jun 13, 10:35 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:

"rickman" <gnu...@gmail.com> wrote in message

news:37c87ac4-768f-405f-a262-fe3e4dd0c51b@x35g2000hsb.googlegroups.com...

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

 

[MikeWhy]

"rickman" <gnuarm@gmail.com> wrote in message
news:bdf4e73d-f1d1-460d-a92c-be0518f01f56@d45g2000hsc.googlegroups.com...

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?

 

[Jonathan Bromley]

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 temporary 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 important 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@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jim Lewis]

KJ,

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 couple of comments.
Which of these solutions work for numbers larger than 31 bits?

Beyond strong typing, I think the array sizing rules are important.
Tensilica presented a paper at DVCon some years back where they
imposed lint rules on their Verilog coders to facilitate the translation
to VHDL. These lint rules enforced the array sizing rules in numeric_std.
The number I remember was that when the lint rule fired off, 75% of the
time it was an error. Anyone hear (or from Tensilica know) a different
number?

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

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.

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

Cheers,
Jim Lewis
SynthWorks
IEEE VHDL and Analysis Standards Group, http://www.eda.org/vasg

 

[Jim Lewis]

Jonathan,

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

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.

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.
I think no matter what you do there are issues to watch.

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

There is something for this already ("??"). Although := overloading
could be made to work the same way. There are lots of details.

Cheers,
Jim

 

[Jim Lewis]

KJ,

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'll wait for one I like to see first.

Don't hold your breath.

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

Yacking out here is like screaming at a mountain.

Cheers,
Jim

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

 

[Jonathan Bromley]

On Sun, 15 Jun 2008 10:32:43 -0700, Jim Lewis wrote:

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.

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.

This is true, although errors of precision seem to me
to be less disastrous than errors of scaling. In truth,
there is probably no one-size-fits-all solution to this
kind of problem. For example, fixed-point math surely
needs both saturating and truncating forms of overflow;
how can that be controlled, for individual assignments,
without needing very clunky syntax?

VHDL is a million miles ahead of Verilog, and of just about
any other language, in its ability to support this kind of
control. Assignment overloading allows the programmer to
take *sub*type compatibility into account for assignment,
whereas the base language only considers *type*
compatibility. In an ideal world one could imagine the
ability to add user attributes that behave more like
built-in attributes - i.e. they propagate from actual to
formal parameters of a subprogram - so that a variable
could be tagged as "when assigning to me, do saturating
overflow" or "when assigning to me, error out if my
(target) subtype doesn't match the expression's subtype".

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.

I think no matter what you do there are issues to watch.

Fair enough. I took care to qualify my statement with
"personally" - others will surely see things differently.

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

There is something for this already ("??"). Although := overloading
could be made to work the same way. There are lots of details.

OK. Again there's some personal preference/prejudice at work
here: I'm probably over-sensitive in my distaste for special-
purpose syntax designed to deal with a single issue.

Thanks for the sanity-check!
--
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@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Brian Drummond]

On Thu, 12 Jun 2008 14:02:55 +0100, Brian Drummond
<brian_drummond@btconnect.com> wrote:

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.


Ironically, thanks to overloaded operators,

CTPBitCnt <= (others => '0') + 1;

will work, and I would hope any synthesis tool would realise both inputs
are constant.

It's not pretty though...

Following on from this: (I apologise for not having tried it; I have no
access to a simulator at the moment)

Overload the unary "+" operator. This is commonly done in Ada for
various purposes; I don't see why it won't work in VHDL.

If so, then it ought to be possible to make
CTPBitCnt <= +1;
work.

subtype BitCntType is ...

signal CTPBitCnt : BitCntType;

function "+" (int:integer) return BitCntType is
variable BitCnt:BitCntType := to_unsigned(int, BitCntType'length);
begin
return BitCnt;
end function "+";

Offhand I don't see it working with unconstrained types like unsigned,
which makes it less attractive. Does anyone know better?

- Brian

 

[Jonathan Bromley]

On Mon, 16 Jun 2008 11:43:24 +0100, Brian Drummond wrote:

Overload the unary "+" operator. This is commonly done in Ada for
various purposes; I don't see why it won't work in VHDL.

If so, then it ought to be possible to make
CTPBitCnt <= +1;
work.

subtype BitCntType is ...

signal CTPBitCnt : BitCntType;

function "+" (int:integer) return BitCntType is
variable BitCnt:BitCntType := to_unsigned(int, BitCntType'length);
begin
return BitCnt;
end function "+";

Offhand I don't see it working with unconstrained types like unsigned,
which makes it less attractive. Does anyone know better?

That's exactly the problem; the function signature for an operator
overload (or any other overloaded function) does NOT take subtype
into account, but only type. So your overloaded "+" could only
be made to target exactly one width of UNSIGNED. Bummer.

Going the other way:

function "+"(u: unsigned) return natural is
begin
return to_integer(u);
end;

works nicely, though...
--
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@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Andy]

On Jun 11, 10:52 am, rickman <gnu...@gmail.com> wrote:

On Jun 10, 5:59 pm, Andy <jonesa...@comcast.net> wrote:
One more point: just try to design a fixed or floating point
arithmetic design with verilog!

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]

On Jun 15, 1:06 pm, Jim Lewis <j...@synthworks.com> wrote:

KJ,

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

 

[Jim Lewis]

KJ

I'll wait for one I like to see first.
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.

Oops. I must have overreacted. This is exactly what I would ask all to
do - nag your vendor for the features you need and/or want.

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.
My opinion is that anyone out here who is actively answering questions

would bring value to the standards groups. Design expertise can help
weigh and understand language requests and feature implementations.
The group already has a number of members who are from eda vendors
and are LRM wizards (although there are room for more of these too).

Not sure if Accellera is willing to fund another round of revisions,
so it is likely the work will move back to IEEE and we will need to
put together a new funding model.

Cheers,
Jim

 

[KJ]

On Jun 15, 8:43 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:

"Jim Lewis" <j...@synthworks.com> 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