elektroda.net NewsGroups Forum Index - VHDL Language - Clock Edge notation
Goto page Previous 1, 2, 3 ... 101, 102, 103, 104, 105 Next
rickman
Guest
Guest
Wed Apr 21, 2010 12:10 am
On Apr 20, 5:11 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
Quote:
Andy <jonesa...@comcast.net> writes:
The cost of bugs in code is not a constant, per-bug figure. The cost
is dominated by how hard it is to find the bug as early as possible.
So, in a verbose language, the number of bugs may go up, but the cost
of fixing the bugs goes down.
Case in point: Would you suggest that using positional notation in
port maps and argument lists is more prone to cause errors? And which
is prone to cost more to find and fix any errors? My point is not that
positional notation is an advantage of one language over another, it
is simply to debunk the "fewer lines of code = better code" myth.
Agreed - as with all things, any extreme position is daft...
The problem (as I see it) comes with languages (or past
design-techniques enforced by synthesis tools) which are not
descriptive enough to allow you to express your intent in a
"relatively" small amount of code. Which is why assembly is not as
widely used anymore, and more behavioural descriptions win out over
instantiating LUTs/FFs by hand. It's not about the verboseness of the
language per-se, more about the ability to show (clearly) your intent
relatively concisely.
The cost of bugs in code is not a constant, per-bug figure. The cost
is dominated by how hard it is to find the bug as early as possible.
So, in a verbose language, the number of bugs may go up, but the cost
of fixing the bugs goes down.
Case in point: Would you suggest that using positional notation in
port maps and argument lists is more prone to cause errors? And which
is prone to cost more to find and fix any errors? My point is not that
positional notation is an advantage of one language over another, it
is simply to debunk the "fewer lines of code = better code" myth.
Agreed - as with all things, any extreme position is daft...
The problem (as I see it) comes with languages (or past
design-techniques enforced by synthesis tools) which are not
descriptive enough to allow you to express your intent in a
"relatively" small amount of code. Which is why assembly is not as
widely used anymore, and more behavioural descriptions win out over
instantiating LUTs/FFs by hand. It's not about the verboseness of the
language per-se, more about the ability to show (clearly) your intent
relatively concisely.
Or do you think it has to do with the fact that the tools do a better
job so that the efficiencies of using assembly language and
instantiating components is greatly reduced?
Quote:
And much of the "verboseness" in VHDL can be mitigated with tools like
Emacs or Sigasi's product. And much of the other perceived
verboseness can be overcome by writing "modern" code: single process,
using variables, functions, procedures (the sort of thing some of us
do all the time!)
Emacs or Sigasi's product. And much of the other perceived
verboseness can be overcome by writing "modern" code: single process,
using variables, functions, procedures (the sort of thing some of us
do all the time!)
I am going to give Emacs a try this summer when I have more free
time. I don't see the things you mention as being a solution because
they don't address the problem. The verboseness is inherent in VHDL.
Type casting is something that makes it verbose. That can often be
mitigated by using the right types in the right places. I never use
std_logic_vector anymore.
Rick
rickman
Guest
Guest
Wed Apr 21, 2010 12:59 am
On Apr 20, 1:36 pm, Andy <jonesa...@comcast.net> wrote:
Quote:
On Apr 20, 4:11 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
BTW, what do you mean by "compiler-enforced comments" - is it "simply"
that code should be as self-documenting as possible? Or something else?
Self-documenting and more.
I look at many aspects of a strongly typed language as encouraging or
requiring "verbosity" that would otherwise need comments to explain.
Hence we have different types for vectors of the same base element
type, based on how the contents are to be interpretted, and/or
limitations of the data contained. Integer subtypes allow you to
constrain (and verify) the contents more thoroughly, at least
numerically.
By choosing the appropriate data types, you are telling the tool and
subsequent reviewers/users/maintainers something about your code, and
how it works (and sometimes more importantly, how it doesn't or won't
work.)
BTW, what do you mean by "compiler-enforced comments" - is it "simply"
that code should be as self-documenting as possible? Or something else?
Self-documenting and more.
I look at many aspects of a strongly typed language as encouraging or
requiring "verbosity" that would otherwise need comments to explain.
Hence we have different types for vectors of the same base element
type, based on how the contents are to be interpretted, and/or
limitations of the data contained. Integer subtypes allow you to
constrain (and verify) the contents more thoroughly, at least
numerically.
By choosing the appropriate data types, you are telling the tool and
subsequent reviewers/users/maintainers something about your code, and
how it works (and sometimes more importantly, how it doesn't or won't
work.)
I used to use boolean for most signals that were used as controls for
ifs and such. But in the simulator these are displayed as values
rather than the oscope type trace used for std_logic which I find much
more readable. So I don't use boolean. I seldom use enumerated
types. I find nearly everything I want to do works very well with
std_logic, unsigned, signed and integers with defined ranges. I rely
on comments to explain what is going on, because when it is not clear
from reading the code, I think there is little that using various
types will add to the picture.
Quote:
By using assertion statements, you can not only document assumptions
and limitations of your code, but also ensure that those are met.
and limitations of your code, but also ensure that those are met.
I've never uses assertions in my synthesized code. I hate getting
warnings from the tools so I don't like to provoke them. There are
times I use assignments in declarations of signed or unsigned types to
avoid warnings I get during simulation. But then these produce
warnings in synthesis, so you can't always win.
Can you give an example of an assertion you would use in synthesized
code?
Quote:
Some of these features are enforced by the compiler, some are enforced
by standards compliant implementations. But they are enforced, which
is more than we can say about comments. How many times have you seen
comments that were clearly written for a previous version of the code,
but not completely updated in later revisions to that code?
by standards compliant implementations. But they are enforced, which
is more than we can say about comments. How many times have you seen
comments that were clearly written for a previous version of the code,
but not completely updated in later revisions to that code?
I only worry about my comments...
Rick
Andy
Guest
Guest
Wed Apr 21, 2010 2:31 am
I don't know of any assertions that are used by the synthesis tool,
but I do use assertions in my RTL to help verify the code in
conjunction with the testbench.
The most common occurrence is with counters. I can use integer
subtypes with built-in bouds checking to make sure a counter never
overflows or rolls over on its own (when the surrounding circuitry
should never allow that to happen, but if it did, I would want to know
about it first hand). Or I can use assertion statements with unsigned
when the allowable range for a counter is not 0 to 2**n-1.
If I know that a set of external interface strobe inputs should be
mutually exclusive, and I have optimized the circuit to take advantage
of that, then I use an assertion to verify it. It would be nice if the
synthesis tool recognized the assertion, and optimized the circuit for
me, but I'll take what I can get.
I'm rarely concerned with what waveforms look like, since the vast
majority of my debugging is with the source level debugger, not the
waveform viewer.
I suspect that if your usage is constrained to the data types you
listed (except bounded integer subtypes), you may do well with
verilog. But given that you may not use a lot of what is available in
VHDL, it would be worthwhile to compare the productivity gains from
using more of the capabilities of the language you already know, to
the gains from changing to a whole new language.
Andy
Cesar
Guest
Guest
Wed Apr 21, 2010 9:18 am
On Apr 20, 11:11 am, Martin Thompson <martin.j.thomp...@trw.com>
wrote:
Quote:
And much of the "verboseness" in VHDL can be mitigated with tools like
Emacs or Sigasi's product. And much of the other perceived
verboseness can be overcome by writing "modern" code: single process,
using variables, functions, procedures (the sort of thing some of us
do all the time!)
Emacs or Sigasi's product. And much of the other perceived
verboseness can be overcome by writing "modern" code: single process,
using variables, functions, procedures (the sort of thing some of us
do all the time!)
BTW, it's long time I hear about VHDL "modern" code and the methods
you enumerate. Since typical VHDL books do not deal with coding style,
do you know about any VHDL book explaining this modern coding style?
César
Martin Thompson
Guest
Guest
Wed Apr 21, 2010 10:05 am
Andy <jonesandy_at_comcast.net> writes:
Quote:
On Apr 20, 4:11 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
BTW, what do you mean by "compiler-enforced comments" - is it "simply"
that code should be as self-documenting as possible? Or something else?
Self-documenting and more.
I look at many aspects of a strongly typed language as encouraging or
requiring "verbosity" that would otherwise need comments to explain.
Hence we have different types for vectors of the same base element
type, based on how the contents are to be interpretted, and/or
limitations of the data contained. Integer subtypes allow you to
constrain (and verify) the contents more thoroughly, at least
numerically.
By choosing the appropriate data types, you are telling the tool and
subsequent reviewers/users/maintainers something about your code, and
how it works (and sometimes more importantly, how it doesn't or won't
work.)
BTW, what do you mean by "compiler-enforced comments" - is it "simply"
that code should be as self-documenting as possible? Or something else?
Self-documenting and more.
I look at many aspects of a strongly typed language as encouraging or
requiring "verbosity" that would otherwise need comments to explain.
Hence we have different types for vectors of the same base element
type, based on how the contents are to be interpretted, and/or
limitations of the data contained. Integer subtypes allow you to
constrain (and verify) the contents more thoroughly, at least
numerically.
By choosing the appropriate data types, you are telling the tool and
subsequent reviewers/users/maintainers something about your code, and
how it works (and sometimes more importantly, how it doesn't or won't
work.)
Indeed so - capturing the knowledge that gets lost when you just use a
"bag-of-bits" type for everything.
Quote:
By using assertion statements, you can not only document assumptions
and limitations of your code, but also ensure that those are met.
Yes, I sprinkle assertions through both RTL and testbench code - they
usually trigger when I come back to the code after several weeks ;)
Quote:
Some of these features are enforced by the compiler, some are enforced
by standards compliant implementations. But they are enforced, which
is more than we can say about comments. How many times have you seen
comments that were clearly written for a previous version of the code,
but not completely updated in later revisions to that code?
Well said - I had a feeling that was what you meant by
compiler-enforced comments: it's the whole of the code which should be
used as documentation.
Cheers,
Martin
--
martin.j.thompson_at_trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
Martin Thompson
Guest
Guest
Wed Apr 21, 2010 10:16 am
rickman <gnuarm_at_gmail.com> writes:
Quote:
On Apr 20, 5:11 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
The problem (as I see it) comes with languages (or past
design-techniques enforced by synthesis tools) which are not
descriptive enough to allow you to express your intent in a
"relatively" small amount of code. Which is why assembly is not as
widely used anymore, and more behavioural descriptions win out over
instantiating LUTs/FFs by hand. It's not about the verboseness of the
language per-se, more about the ability to show (clearly) your intent
relatively concisely.
Or do you think it has to do with the fact that the tools do a better
job so that the efficiencies of using assembly language and
instantiating components is greatly reduced?
The problem (as I see it) comes with languages (or past
design-techniques enforced by synthesis tools) which are not
descriptive enough to allow you to express your intent in a
"relatively" small amount of code. Which is why assembly is not as
widely used anymore, and more behavioural descriptions win out over
instantiating LUTs/FFs by hand. It's not about the verboseness of the
language per-se, more about the ability to show (clearly) your intent
relatively concisely.
Or do you think it has to do with the fact that the tools do a better
job so that the efficiencies of using assembly language and
instantiating components is greatly reduced?
Well, that's the reason we *had* to use assembly in the past, the
tools weren't up to the job of *allowing* us to specify the behaviour
in a higher-level way. I know very few people who would choose to
write assembly unless they have a problem they just can't solve in C
for example.
Quote:
And much of the "verboseness" in VHDL can be mitigated with tools like
Emacs or Sigasi's product. And much of the other perceived
verboseness can be overcome by writing "modern" code: single process,
using variables, functions, procedures (the sort of thing some of us
do all the time!)
I am going to give Emacs a try this summer when I have more free
time.
Emacs is a quite a big investment, but it's a tool for life. I wonder
what looks I'll garner when I'm still using it in 20 years time :)
Quote:
I don't see the things you mention as being a solution because
they don't address the problem.
they don't address the problem.
What is the problem - that there's a lot of typing? If that's it then
they *do* solve the problem. VHDL-mode pretty much makes it so you
only have to type in the bits that really matter, all the boilerplate
is done for you (up to and including testbenches if you want).
Quote:
The verboseness is inherent in VHDL.
To some extent it is, but it's there to be used (as Andy pointed out).
VHDL has a lot less overhead when you use a single process inside each
entity. And the instantiation matching ports to wires (which looks
terribly verbose and is a pain to do in a copy/paste style) stops a
lot of silly "positioning" mistakes. (You could always choose to just
do a positional instantiation IIRC).
Quote:
Type casting is something that makes it verbose.
Yes, but it forces you to show you know what you're doing, rather than
the compiler just allowing you to do it, and it works for now, but in
the future some corner-case comes up which breaks the implicit
assumptions that you have put in the code. With strong typing, you
have to be explicit about the assumptions.
Quote:
That can often be mitigated by using the right types in the right
places.
places.
I'd say it's almost always mitigated by using the right types in the
right places. The times it causes me pain is when I have to
instantiate a 3rd party entity (usually an FPGA-vendor RAM) which has
bag-of-bits vectors everywhere, (even on the address lines for example).
Quote:
I never use std_logic_vector anymore.
I wouldn't go that far, but I use them a lot less than some others do
:)
Cheers,
Martin
--
martin.j.thompson_at_trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
Martin Thompson
Guest
Guest
Wed Apr 21, 2010 10:17 am
Cesar <cesteban75_at_gmail.com> writes:
Quote:
On Apr 20, 11:11 am, Martin Thompson <martin.j.thomp...@trw.com
wrote:
And much of the "verboseness" in VHDL can be mitigated with tools like
Emacs or Sigasi's product. And much of the other perceived
verboseness can be overcome by writing "modern" code: single process,
using variables, functions, procedures (the sort of thing some of us
do all the time!)
BTW, it's long time I hear about VHDL "modern" code and the methods
you enumerate. Since typical VHDL books do not deal with coding style,
do you know about any VHDL book explaining this modern coding style?
wrote:
And much of the "verboseness" in VHDL can be mitigated with tools like
Emacs or Sigasi's product. And much of the other perceived
verboseness can be overcome by writing "modern" code: single process,
using variables, functions, procedures (the sort of thing some of us
do all the time!)
BTW, it's long time I hear about VHDL "modern" code and the methods
you enumerate. Since typical VHDL books do not deal with coding style,
do you know about any VHDL book explaining this modern coding style?
Sorry, no.
Maybe some of us should take some of the sample code from the classic
texts and rewrite it "our way" :)
Cheers,
Martin
--
martin.j.thompson_at_trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
Symon
Guest
Guest
Thu Apr 22, 2010 11:27 am
On 4/22/2010 3:26 AM, dlopez wrote:
Quote:
Hi,
I'm trying to calculate the absolute value of a signed number (two's
complement).
Right now, I sign extend the input, and when msb=1, inverse all bits and
add 1. The sign extend is to take care of the most negative number.
I'm trying to calculate the absolute value of a signed number (two's
complement).
Right now, I sign extend the input, and when msb=1, inverse all bits and
add 1. The sign extend is to take care of the most negative number.
So, if I read numeric_std correctly (see below), in VHDL, for (say) four
bit signed numbers, abs("1000"), aka abs(-
, equals zero. What am I
missing?
Thanks, Symon.
p.s. This thought came from a post comp.arch.fpga
--=========================Exported
Functions=================================
-- Id: A.1
function "abs" ( X : SIGNED) return SIGNED is
constant ARG_LEFT:INTEGER:= X'length-1;
alias XX : SIGNED(ARG_LEFT downto 0) is X;
variable RESULT: SIGNED (ARG_LEFT downto 0);
begin
if X'length<1 then return NAS; end if;
RESULT:=TO_01(xx,'X');
if (RESULT(RESULT'left)='X') then return RESULT; end if;
if RESULT(RESULT'left) = '1' then
RESULT:= -RESULT;
end if;
return RESULT;
end; -- "abs"
-- Id: A.2
function "-" ( ARG: SIGNED) return SIGNED is
constant ARG_LEFT:INTEGER:= ARG'length-1;
alias XARG: SIGNED(ARG_LEFT downto 0) is ARG;
variable RESULT,XARG01 : SIGNED(ARG_LEFT downto 0);
variable CBIT : STD_LOGIC:= '1';
begin
if ARG'length<1 then return NAS; end if;
XARG01 := TO_01(ARG,'X');
if (XARG01(XARG01'left)='X') then return XARG01; end if;
for i in 0 to RESULT'left loop
RESULT(i) := not(XARG01(i)) xor CBIT;
CBIT := CBIT and not(XARG01(i));
end loop;
return RESULT;
end; -- "-"
Pieter Hulshoff
Guest
Guest
Thu Apr 22, 2010 1:38 pm
Symon wrote:
Quote:
So, if I read numeric_std correctly (see below), in VHDL, for (say) four
bit signed numbers, abs("1000"), aka abs(-, equals zero. What am I
missing?
bit signed numbers, abs("1000"), aka abs(-
, equals zero. What am I
missing?
Considering that in two's complement, a 4 bit signed is defined from -8 to 7,
what result did you hope for? The lowest negative number in two's complement
is always a special case. It is up to you if you wish to check for it or not.
Kind regards,
Pieter Hulshoff
Symon
Guest
Guest
Thu Apr 22, 2010 3:49 pm
On 4/22/2010 1:38 PM, Pieter Hulshoff wrote:
Quote:
Symon wrote:
So, if I read numeric_std correctly (see below), in VHDL, for (say) four
bit signed numbers, abs("1000"), aka abs(-, equals zero. What am I
missing?
Considering that in two's complement, a 4 bit signed is defined from -8 to 7,
what result did you hope for? The lowest negative number in two's complement
is always a special case. It is up to you if you wish to check for it or not.
Kind regards,
Pieter Hulshoff
So, if I read numeric_std correctly (see below), in VHDL, for (say) four
bit signed numbers, abs("1000"), aka abs(-
, equals zero. What am I
missing?
Considering that in two's complement, a 4 bit signed is defined from -8 to 7,
what result did you hope for? The lowest negative number in two's complement
is always a special case. It is up to you if you wish to check for it or not.
Kind regards,
Pieter Hulshoff
Sure, I just wanted to be sure that's what happens. Before I looked in
numeric_std, I expected abs to take a signed argument and return an
unsigned value. However, it doesn't.
Thanks, Syms.
Rob Gaddi
Guest
Guest
Thu Apr 22, 2010 5:04 pm
On 4/22/2010 7:49 AM, Symon wrote:
Quote:
On 4/22/2010 1:38 PM, Pieter Hulshoff wrote:
Symon wrote:
So, if I read numeric_std correctly (see below), in VHDL, for (say) four
bit signed numbers, abs("1000"), aka abs(-, equals zero. What am I
missing?
Considering that in two's complement, a 4 bit signed is defined from
-8 to 7,
what result did you hope for? The lowest negative number in two's
complement
is always a special case. It is up to you if you wish to check for it
or not.
Kind regards,
Pieter Hulshoff
Sure, I just wanted to be sure that's what happens. Before I looked in
numeric_std, I expected abs to take a signed argument and return an
unsigned value. However, it doesn't.
Thanks, Syms.
Symon wrote:
So, if I read numeric_std correctly (see below), in VHDL, for (say) four
bit signed numbers, abs("1000"), aka abs(-
, equals zero. What am I
missing?
Considering that in two's complement, a 4 bit signed is defined from
-8 to 7,
what result did you hope for? The lowest negative number in two's
complement
is always a special case. It is up to you if you wish to check for it
or not.
Kind regards,
Pieter Hulshoff
Sure, I just wanted to be sure that's what happens. Before I looked in
numeric_std, I expected abs to take a signed argument and return an
unsigned value. However, it doesn't.
Thanks, Syms.
Yeah, numeric_std makes a couple of interesting choices regarding output
formats. I can understand the idea of always wanting your outputs to
remain the same type (signing and range) as your inputs, but it
definitely means that some math expressions require a truly ugly amount
of casting and '0' &.
--
Rob Gaddi, Highland Technology
Email address is currently out of order
Andy
Guest
Guest
Fri Apr 23, 2010 1:21 am
On Apr 22, 11:04 am, Rob Gaddi <rga...@technologyhighland.com> wrote:
Quote:
On 4/22/2010 7:49 AM, Symon wrote:
On 4/22/2010 1:38 PM, Pieter Hulshoff wrote:
Symon wrote:
So, if I read numeric_std correctly (see below), in VHDL, for (say) four
bit signed numbers, abs("1000"), aka abs(-, equals zero. What am I
missing?
Considering that in two's complement, a 4 bit signed is defined from
-8 to 7,
what result did you hope for? The lowest negative number in two's
complement
is always a special case. It is up to you if you wish to check for it
or not.
Kind regards,
Pieter Hulshoff
Sure, I just wanted to be sure that's what happens. Before I looked in
numeric_std, I expected abs to take a signed argument and return an
unsigned value. However, it doesn't.
Thanks, Syms.
Yeah, numeric_std makes a couple of interesting choices regarding output
formats. I can understand the idea of always wanting your outputs to
remain the same type (signing and range) as your inputs, but it
definitely means that some math expressions require a truly ugly amount
of casting and '0' &.
--
Rob Gaddi, Highland Technology
Email address is currently out of order- Hide quoted text -
- Show quoted text -
On 4/22/2010 1:38 PM, Pieter Hulshoff wrote:
Symon wrote:
So, if I read numeric_std correctly (see below), in VHDL, for (say) four
bit signed numbers, abs("1000"), aka abs(-
, equals zero. What am I
missing?
Considering that in two's complement, a 4 bit signed is defined from
-8 to 7,
what result did you hope for? The lowest negative number in two's
complement
is always a special case. It is up to you if you wish to check for it
or not.
Kind regards,
Pieter Hulshoff
Sure, I just wanted to be sure that's what happens. Before I looked in
numeric_std, I expected abs to take a signed argument and return an
unsigned value. However, it doesn't.
Thanks, Syms.
Yeah, numeric_std makes a couple of interesting choices regarding output
formats. I can understand the idea of always wanting your outputs to
remain the same type (signing and range) as your inputs, but it
definitely means that some math expressions require a truly ugly amount
of casting and '0' &.
--
Rob Gaddi, Highland Technology
Email address is currently out of order- Hide quoted text -
- Show quoted text -
You could use fixed point with no fractional bits. It extends the size
to handle the largest possible result. But unfortunately, ufixed -
ufixed is still ufixed, so it does not always handle that correctly.
Andy
Andy Rushton
Guest
Guest
Fri Apr 23, 2010 10:56 am
Symon wrote:
Quote:
So, if I read numeric_std correctly (see below), in VHDL, for (say) four
bit signed numbers, abs("1000"), aka abs(-
, equals zero. What am I
missing?
No, for a 4-bit signed, abs(-
= -8!
In 2's-complement notation, and therefore in numeric_std, the negation
of the most negative value is itself. So, in this case, the negation of
1000 (-
is 1000 (-.
If you consider what would happen if you sign-extended first, you can
see what's happening - 11000 (-
gets negated to 01000 (+.
This is a side-effect of the asymmetry in 2's-complement notation and
not a bug. Deciding what to do with asymmetrical number ranges is an
essential design decision in any design using either 2's-complement
integer or fixed-point numbers.
You can either decide to support the restricted range -7 to 7 and
consider -8 to be out of range, or you can extend the value to 5 bits to
include the whole representable range. If you want to support the full
range of the input type, resize one-bit bigger first (before the abs).
e.g. abs(resize(x,5))
Quote:
Thanks, Symon.
p.s. This thought came from a post comp.arch.fpga
--=========================Exported
Functions=================================
-- Id: A.1
function "abs" ( X : SIGNED) return SIGNED is
constant ARG_LEFT:INTEGER:= X'length-1;
alias XX : SIGNED(ARG_LEFT downto 0) is X;
variable RESULT: SIGNED (ARG_LEFT downto 0);
begin
if X'length<1 then return NAS; end if;
RESULT:=TO_01(xx,'X');
if (RESULT(RESULT'left)='X') then return RESULT; end if;
if RESULT(RESULT'left) = '1' then
RESULT:= -RESULT;
end if;
return RESULT;
end; -- "abs"
-- Id: A.2
function "-" ( ARG: SIGNED) return SIGNED is
constant ARG_LEFT:INTEGER:= ARG'length-1;
alias XARG: SIGNED(ARG_LEFT downto 0) is ARG;
variable RESULT,XARG01 : SIGNED(ARG_LEFT downto 0);
variable CBIT : STD_LOGIC:= '1';
begin
if ARG'length<1 then return NAS; end if;
XARG01 := TO_01(ARG,'X');
if (XARG01(XARG01'left)='X') then return XARG01; end if;
for i in 0 to RESULT'left loop
RESULT(i) := not(XARG01(i)) xor CBIT;
CBIT := CBIT and not(XARG01(i));
end loop;
return RESULT;
end; -- "-"
p.s. This thought came from a post comp.arch.fpga
--=========================Exported
Functions=================================
-- Id: A.1
function "abs" ( X : SIGNED) return SIGNED is
constant ARG_LEFT:INTEGER:= X'length-1;
alias XX : SIGNED(ARG_LEFT downto 0) is X;
variable RESULT: SIGNED (ARG_LEFT downto 0);
begin
if X'length<1 then return NAS; end if;
RESULT:=TO_01(xx,'X');
if (RESULT(RESULT'left)='X') then return RESULT; end if;
if RESULT(RESULT'left) = '1' then
RESULT:= -RESULT;
end if;
return RESULT;
end; -- "abs"
-- Id: A.2
function "-" ( ARG: SIGNED) return SIGNED is
constant ARG_LEFT:INTEGER:= ARG'length-1;
alias XARG: SIGNED(ARG_LEFT downto 0) is ARG;
variable RESULT,XARG01 : SIGNED(ARG_LEFT downto 0);
variable CBIT : STD_LOGIC:= '1';
begin
if ARG'length<1 then return NAS; end if;
XARG01 := TO_01(ARG,'X');
if (XARG01(XARG01'left)='X') then return XARG01; end if;
for i in 0 to RESULT'left loop
RESULT(i) := not(XARG01(i)) xor CBIT;
CBIT := CBIT and not(XARG01(i));
end loop;
return RESULT;
end; -- "-"
Symon
Guest
Guest
Fri Apr 23, 2010 11:34 am
On 4/23/2010 10:56 AM, Andy Rushton wrote:
Quote:
Symon wrote:
So, if I read numeric_std correctly (see below), in VHDL, for (say)
four bit signed numbers, abs("1000"), aka abs(-, equals zero. What
am I missing?
No, for a 4-bit signed, abs(- = -8!
Aha! OK, I see it now, many thanks.
So, if I read numeric_std correctly (see below), in VHDL, for (say)
four bit signed numbers, abs("1000"), aka abs(-
, equals zero. What
am I missing?
No, for a 4-bit signed, abs(-
= -8!
Aha! OK, I see it now, many thanks.
Rob Gaddi
Guest
Guest
Fri Apr 23, 2010 5:19 pm
On 4/23/2010 2:56 AM, Andy Rushton wrote:
Quote:
Symon wrote:
So, if I read numeric_std correctly (see below), in VHDL, for (say)
four bit signed numbers, abs("1000"), aka abs(-, equals zero. What
am I missing?
No, for a 4-bit signed, abs(- = -8!
In 2's-complement notation, and therefore in numeric_std, the negation
of the most negative value is itself. So, in this case, the negation of
1000 (- is 1000 (-.
If you consider what would happen if you sign-extended first, you can
see what's happening - 11000 (- gets negated to 01000 (+.
This is a side-effect of the asymmetry in 2's-complement notation and
not a bug. Deciding what to do with asymmetrical number ranges is an
essential design decision in any design using either 2's-complement
integer or fixed-point numbers.
You can either decide to support the restricted range -7 to 7 and
consider -8 to be out of range, or you can extend the value to 5 bits to
include the whole representable range. If you want to support the full
range of the input type, resize one-bit bigger first (before the abs).
e.g. abs(resize(x,5))
[snip]
So, if I read numeric_std correctly (see below), in VHDL, for (say)
four bit signed numbers, abs("1000"), aka abs(-
, equals zero. What
am I missing?
No, for a 4-bit signed, abs(-
= -8!
In 2's-complement notation, and therefore in numeric_std, the negation
of the most negative value is itself. So, in this case, the negation of
1000 (-
is 1000 (-.
If you consider what would happen if you sign-extended first, you can
see what's happening - 11000 (-
gets negated to 01000 (+.
This is a side-effect of the asymmetry in 2's-complement notation and
not a bug. Deciding what to do with asymmetrical number ranges is an
essential design decision in any design using either 2's-complement
integer or fixed-point numbers.
You can either decide to support the restricted range -7 to 7 and
consider -8 to be out of range, or you can extend the value to 5 bits to
include the whole representable range. If you want to support the full
range of the input type, resize one-bit bigger first (before the abs).
e.g. abs(resize(x,5))
[snip]
Or just copy/paste/tweak the numeric_std code to write your own abs
function that returns an unsigned of the same width as the signed input.
--
Rob Gaddi, Highland Technology
Email address is currently out of order
elektroda.net NewsGroups Forum Index - VHDL Language - Clock Edge notation
