integer type output signal is synthesizable?

[sonny]

hi,

i got a small question about a synthesizable code.

i map an output as integer from one component to an input, also
integer type, in another component. would this code be synthesizable?
there is a general discussion on integer type signals and variables,
but no output and input...
any kinda posts will be very helpful.... thx

sonny

 

[KJ]

On Sep 27, 10:51 am, sonny <mazel...@gmail.com> wrote:

hi,

i got a small question about a synthesizable code.

i map an output as integer from one component to an input, also
integer type, in another component. would this code be synthesizable?
Yes, not a problem.

there is a general discussion on integer type signals and variables,
but no output and input...
any kinda posts will be very helpful.... thx

The one place where you might want to avoid anything other than

std_logic/std_logic_vectors as input/output ports is at the very top
level of the design. The reason for avoiding there is not because
it's not synthesizable (it is) but the signal name will get munched up
as it works its way through the tool chain because your design will
have some output called 'My_integer_output' (as an example) but the
output of the synthesizer will generally append on a suffix indicating
the bit position within that output (i.e. '_0', '_1', etc.). Exactly
how the signal gets renamed is tool dependent.

KJ

 

[Thomas Stanka]

On 27 Sep., 16:51, sonny <mazel...@gmail.com> wrote:

i map an output as integer from one component to an input, also
integer type, in another component. would this code be synthesizable?

In general yes, but be aware, that integer has no clear defined width
in VHDL. You should use integer range x to y instead of pure integer,
as your synthesis result may vary between different tools and OS. And
I would use integer range 0 to 2^n to have a good result.

bye Thomas

 

[KJ]

"Thomas Stanka" <usenet_nospam_valid@stanka-web.de> wrote in message
news:1191483047.178014.214180@50g2000hsm.googlegroups.com...

On 27 Sep., 16:51, sonny <mazel...@gmail.com> wrote:
i map an output as integer from one component to an input, also
integer type, in another component. would this code be synthesizable?

In general yes, but be aware, that integer has no clear defined width
in VHDL.
Integer ranges are quite well defined by the VHDL language, they are

synthesized as 32 bit signed quantities.

You should use integer range x to y instead of pure integer,
as your synthesis result may vary between different tools and OS.
No, you should use integer range x to y so that you don't synthesize a full

32 bit integer when only a 4 bit one would do. It does not have to do with
tools (unless the optomizer can somehow fathtom that it can get away with 4
bits and still be LRM compliant) or OS

And
I would use integer range 0 to 2^n to have a good result.

I tend to use the app specifiec proper range, if something is in the range

from 3 to 99 I would tend to use that range. The simulator catches usages
that fall out of that range, synthesis implements the proper size integer,
all is well.

KJ

 

[Andy]

On Oct 4, 6:19 am, "KJ" <kkjenni...@sbcglobal.net> wrote:

"Thomas Stanka" <usenet_nospam_va...@stanka-web.de> wrote in message

news:1191483047.178014.214180@50g2000hsm.googlegroups.com...> On 27 Sep., 16:51, sonny <mazel...@gmail.com> wrote:
i map an output as integer from one component to an input, also
integer type, in another component. would this code be synthesizable?

In general yes, but be aware, that integer has no clear defined width
in VHDL.

Integer ranges are quite well defined by the VHDL language, they are
synthesized as 32 bit signed quantities.

You should use integer range x to y instead of pure integer,
as your synthesis result may vary between different tools and OS.

No, you should use integer range x to y so that you don't synthesize a full
32 bit integer when only a 4 bit one would do. It does not have to do with
tools (unless the optomizer can somehow fathtom that it can get away with 4
bits and still be LRM compliant) or OS

And
I would use integer range 0 to 2^n to have a good result.

I tend to use the app specifiec proper range, if something is in the range
from 3 to 99 I would tend to use that range. The simulator catches usages
that fall out of that range, synthesis implements the proper size integer,
all is well.

KJ

I'm with KJ on this one... I define the range of values expected/
allowed, and let the synthesis tool create the minimum width to
accommodate it. Note that offsets are not used by any tools I'm aware
of, so "integer range 3 to 17" requires 5 bits, not 4. Nevertheless, I
prefer that the simulator automatically enforce functional bounds
checking on the object.

I have had a case where a counter (integer range 0 to 5) decode was
optimized to two bits for certain counts. But I'm not sure whether the
synthesis tool used the range specification or a reachability analysis
to come up with the optimization.

Andy

 

[Thomas Stanka]

On 4 Okt., 13:19, "KJ" <kkjenni...@sbcglobal.net> wrote:

"Thomas Stanka" <usenet_nospam_va...@stanka-web.de> wrote in message

news:1191483047.178014.214180@50g2000hsm.googlegroups.com...> On 27 Sep., 16:51, sonny <mazel...@gmail.com> wrote:
i map an output as integer from one component to an input, also
integer type, in another component. would this code be synthesizable?

In general yes, but be aware, that integer has no clear defined width
in VHDL.

Integer ranges are quite well defined by the VHDL language, they are
synthesized as 32 bit signed quantities.

AFAIK is an VHDL integer defined as at least 32 bit but allowed to
have more than 32 bit (eg 64bit on 64bit OS) (my knowledge may be out-
of-date with the actual versions of VHDL 200x, but it should be valid
for at least VHDL87.)
A counter with full integer width may be 32 bit, but may also be 63
bit or 64 bit depending on the internal integer representation.

And
I would use integer range 0 to 2^n to have a good result.

I tend to use the app specifiec proper range, if something is in the range
from 3 to 99 I would tend to use that range. The simulator catches usages
that fall out of that range, synthesis implements the proper size integer,
all is well.

This is good practice to catch out of range during simulation, but
gives you a lot of work for formal verification for example.

A subtype 0 to 2 results physical in two bit, but your code contains
no information what to do, when the forbidden value "11"
is reached due to any failure. This is especially fatal, when having
IO-ports. The next designer using your code as IP may have no clue,
that you expect some surrounding logic to ensure no forbidden input
occures.

bye Thomas

 

[KJ]

"Thomas Stanka" <usenet_nospam_valid@stanka-web.de> wrote in message
news:1191788196.386248.216180@v3g2000hsg.googlegroups.com...

On 4 Okt., 13:19, "KJ" <kkjenni...@sbcglobal.net> wrote:
"Thomas Stanka" <usenet_nospam_va...@stanka-web.de> wrote in message

news:1191483047.178014.214180@50g2000hsm.googlegroups.com...> On 27 Sep.,
16:51, sonny <mazel...@gmail.com> wrote:
i map an output as integer from one component to an input, also
integer type, in another component. would this code be synthesizable?

In general yes, but be aware, that integer has no clear defined width
in VHDL.

Integer ranges are quite well defined by the VHDL language, they are
synthesized as 32 bit signed quantities.

AFAIK is an VHDL integer defined as at least 32 bit but allowed to
have more than 32 bit (eg 64bit on 64bit OS) (my knowledge may be out-
of-date with the actual versions of VHDL 200x, but it should be valid
for at least VHDL87.)
A counter with full integer width may be 32 bit, but may also be 63
bit or 64 bit depending on the internal integer representation.

No. Integers are defined in the VHDL package standard as...

type integer is range -2147483648 to 2147483647;

And
I would use integer range 0 to 2^n to have a good result.

I tend to use the app specifiec proper range, if something is in the
range
from 3 to 99 I would tend to use that range. The simulator catches
usages
that fall out of that range, synthesis implements the proper size
integer,
all is well.

This is good practice to catch out of range during simulation, but
gives you a lot of work for formal verification for example.
Can you explain why the extra work for formal verification? I would think

that what is being formally verified is conformance to the specification so
if there is extra work it would imply that formal verification is verifying
functionality above and beyond what the functional requirements for the
design actually are. I haven't used such a tool, so if you do then you
could likely enlighten me a bit on this because it's not clear why formal
verification would have this extra work.

A subtype 0 to 2 results physical in two bit, but your code contains
no information what to do, when the forbidden value "11"
is reached due to any failure.
It should do whatever the functional requirements in the specification say

that it should do. If there are no such requirements then the design is
free to do whatever it wants. I might also point out that if the subtype
was one hot coded then it could be implemented as a three bit code so there
would be more than just one forbidden value.

This is especially fatal, when having
IO-ports.
Which is why you can't always impose such a constraint on an input port.

But again, it goes back to what the functional requirements in the spec say
to do. If input pins are in some 'forbidden' combination, how should the
part respond? I've yet to run across a spec from a supplier that says you
can violate some requirement and still expect it to produce the correct
output so why wouldn't the same apply to a programmable part? If such a
condition exists and the part is supposed to flag it in some manner, then
this behaviour would (should) be documented in the spec. In any case, using
integers for top level ports is not a good idea anyway but for totally
different reasons which I mentioned earlier in the thread. Blocks of IP
that are intended for 'internal' blocks do not necessarily have those same
requirements.

The next designer using your code as IP may have no clue,
that you expect some surrounding logic to ensure no forbidden input
occures.
Actually they would be explicitly aware of this because the port would be

specified with the required integer range (i.e. xyz: in natural range 0 to
99). The point is not to somehow burden down the IP user with having to
produce checking logic to insure that they are in the proper range, it is
simply to specify what the operating range actually is.

KJ

 

[Paul Uiterlinden]

KJ wrote:

No. Integers are defined in the VHDL package standard as...
type integer is range -2147483648 to 2147483647;

I think you wanted to say: type integer is range -2147483647 to 2147483647.
The most negative value is missing.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

 

[KJ]

On Oct 8, 12:17 pm, Paul Uiterlinden <puit...@notaimvalley.nl> wrote:

KJ wrote:
No. Integers are defined in the VHDL package standard as...
type integer is range -2147483648 to 2147483647;

I think you wanted to say: type integer is range -2147483647 to 2147483647.
The most negative value is missing.

--
Paul Uiterlindenwww.aimvalley.nl
e-mail addres: remove the not.

Not according to the VHDL references that I use...or according to the
Modelsim 6.2f\vhdl_src\std\standard.vhd file that I copy/pasted the
information from.

KJ

 

[Paul Uiterlinden]

KJ wrote:

On Oct 8, 12:17 pm, Paul Uiterlinden <puit...@notaimvalley.nl> wrote:
KJ wrote:
No. Integers are defined in the VHDL package standard as...
type integer is range -2147483648 to 2147483647;

I think you wanted to say: type integer is range -2147483647 to
2147483647. The most negative value is missing.

Not according to the VHDL references that I use...or according to the
Modelsim 6.2f\vhdl_src\std\standard.vhd file that I copy/pasted the
information from.

Ah, I see. Sorry for truing to put words into your mouth. ;-)

If your VHDL references really say that the minimum required range on type
integer is -2147483648 to 2147483647, then those references are wrong.
According to the 1993 LRM the minimum required range is -2147483647 to
2147483647.

As for ModelSim: a simulator may support a wider range. The trouble with
that however is portability. If your code makes use of the wider range, it
could fail on a different simulator. Therefore I never convert a vector
larger than 31 bits to an integer. If I would do that, this one magical
value would lurk in the dark, waiting to pop up at an inconvenient moment.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

 

[KJ]

On Oct 8, 4:24 pm, Paul Uiterlinden <puit...@notaimvalley.nl> wrote:

KJ wrote:
On Oct 8, 12:17 pm, Paul Uiterlinden <puit...@notaimvalley.nl> wrote:
KJ wrote:
No. Integers are defined in the VHDL package standard as...
type integer is range -2147483648 to 2147483647;

I think you wanted to say: type integer is range -2147483647 to
2147483647. The most negative value is missing.

Not according to the VHDL references that I use...or according to the
Modelsim 6.2f\vhdl_src\std\standard.vhd file that I copy/pasted the
information from.

Ah, I see. Sorry for truing to put words into your mouth. ;-)

If your VHDL references really say that the minimum required range on type
integer is -2147483648 to 2147483647, then those references are wrong.
According to the 1993 LRM the minimum required range is -2147483647 to
2147483647.

Wow! I realize it's kind of a subtle point but the first two

references I grabbed both had ...648 and both knew about and discussed
changes that occurred in VHDL-93 so I guess both missed that also.

"VHDL for Logic Synthesis", Second Edition, Andrew Rushton
"Digital Design and Modeling with VHDL and Synthesis", K.C. Chang

I took a look just now at Synplify 8.9 and they have ...647 so it
looks like they got it right. I guess I should go check some of my
others as well then, see what they have to say for themselves.

As for ModelSim: a simulator may support a wider range.
Ummm....daring to ask, does the LRM actually say that? If so, then

why in the world would that be? I realize that the processors that
run the simulator may have different interpretations of what an
'integer' is but why would the VHDL language definition allow
simulators to have different interpretations of a basic part of the
language that has been defined (and apparently redefined) from the
begining?

The trouble with
that however is portability. If your code makes use of the wider range, it
could fail on a different simulator. Therefore I never convert a vector
larger than 31 bits to an integer. If I would do that, this one magical
value would lurk in the dark, waiting to pop up at an inconvenient moment.

I don't think I've ever really needed -2147483648, -2147483647 is

probably close enough.

Actually, I'm inclined to submit this as a trouble report to the good
folks at Modelsim. To be fair though, the file that has this also has
the following comment at the top...

This is Package STANDARD as defined in the VHDL 1992 Language
Reference Manual

Unless I run across some other file for the 93 language, this would
imply that they do not quite fully support -93 as they say (unless the
LRM does give them the out that you alluded to earlier).

Ah well, maybe not worth the trouble....but thanks for the
clarification, learn something new every day.

KJ

 

[Thomas Stanka]

On 7 Okt., 23:49, "KJ" <kkjenni...@sbcglobal.net> wrote:

In general yes, but be aware, that integer has no clear defined width
in VHDL.

Integer ranges are quite well defined by the VHDL language, they are
synthesized as 32 bit signed quantities.

AFAIK is an VHDL integer defined as at least 32 bit but allowed to
have more than 32 bit (eg 64bit on 64bit OS) (my knowledge may be out-
of-date with the actual versions of VHDL 200x, but it should be valid
for at least VHDL87.)
A counter with full integer width may be 32 bit, but may also be 63
bit or 64 bit depending on the internal integer representation.

No. Integers are defined in the VHDL package standard as...
type integer is range -2147483648 to 2147483647;

The package standard in modelsim is not the golden reference.
Integer is defined to have _at_least_ this width in the VHDL-LRM.
Each synthesis tool is allowed to use any other representation of
integer, as far as integer covers at least 32 bit. It would be no bug,
if your synthesis tool uses a port width of 64 or 128 bit when you
defined the IO as integer without range.

bye Thomas

 

[Marcus Harnisch]

KJ <Kevin.Jennings@Unisys.com> writes:

As for ModelSim: a simulator may support a wider range.
Ummm....daring to ask, does the LRM actually say that?

Yes.

"The range of INTEGER is implementation dependent, but it is
guaranteed to include the range ~2147483647 to +2147483647"

Actually, I'm inclined to submit this as a trouble report to the good
folks at Modelsim.

Why? It's a legal range and so much easier to be used internally as
`int32_t'.

Regards
Marcus

--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]

(seen on http://www.veripool.com/verilog-mode_news.html)

 

[KJ]

On Oct 9, 7:38 am, Marcus Harnisch <marcus.harni...@gmx.net> wrote:

KJ <Kevin.Jenni...@Unisys.com> writes:
As for ModelSim: a simulator may support a wider range.
Ummm....daring to ask, does the LRM actually say that?

Yes.

"The range of INTEGER is implementation dependent, but it is
guaranteed to include the range ~2147483647 to +2147483647"

Actually, I'm inclined to submit this as a trouble report to the good
folks at Modelsim.

Why? It's a legal range and so much easier to be used internally as
`int32_t'.

Which is why I also said...

(unless the LRM does give them the out that you alluded to earlier).

KJ

 

[Paul Uiterlinden]

KJ wrote:

If your VHDL references really say that the minimum required range on
type integer is -2147483648 to 2147483647, then those references are
wrong. According to the 1993 LRM the minimum required range is
-2147483647 to 2147483647.

Wow! I realize it's kind of a subtle point but the first two
references I grabbed both had ...648 and both knew about and discussed
changes that occurred in VHDL-93 so I guess both missed that also.

This has not changed from 87 to 93.

"VHDL for Logic Synthesis", Second Edition, Andrew Rushton
"Digital Design and Modeling with VHDL and Synthesis", K.C. Chang

I took a look just now at Synplify 8.9 and they have ...647 so it
looks like they got it right. I guess I should go check some of my
others as well then, see what they have to say for themselves.

As for ModelSim: a simulator may support a wider range.
Ummm....daring to ask, does the LRM actually say that?

Yes, section 3.1.2.1 of the both the 87 an 93 LRM (and I suppose 2002):

"The only predefined integer type is type INTEGER. The range of INTEGER is
implementation dependent, but is guaranteed to include the
range -2147483647 to 2147483648. It is defined with an ascending range.
Note: The range of INTEGER in a particular implementation may be determined
from the 'LOW and 'HIGH attributes".

If so, then why in the world would that be?

I suppose to leave a free path for future extension. But I'd rather see a
new type and/or subtype for that.

What intrigues me is why this one magical number is left out. Is it because
it is the only number besides zero that shows the same bits when taking its
two's complement? I'm not sure.

I realize that the processors that
run the simulator may have different interpretations of what an
'integer' is but why would the VHDL language definition allow
simulators to have different interpretations of a basic part of the
language that has been defined (and apparently redefined) from the
begining?

Nothing has been redefined. It has always been like that.

The trouble with
that however is portability. If your code makes use of the wider range,
it could fail on a different simulator. Therefore I never convert a
vector larger than 31 bits to an integer. If I would do that, this one
magical value would lurk in the dark, waiting to pop up at an
inconvenient moment.

I don't think I've ever really needed -2147483648, -2147483647 is
probably close enough.

Close enough is not good enough. Converting vector X"8000_0000" to an
integer and back can give more than a difference of one, depending on the
simulator. The best case is a fatal error. If you're really unlucky it can
be anything without any error or warning.

Actually, I'm inclined to submit this as a trouble report to the good
folks at Modelsim.

No, even if they had chosen to use signed 42 bits it would still comply with
the standard.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

 

[KJ]

"Paul Uiterlinden" <puiterl@notaimvalley.nl> wrote in message
news:470beedd$0$235

Earlier in the thread in a post from you....

. According to the 1993 LRM the minimum required range is
-2147483647 to 2147483647.

Latest posting...

Yes, section 3.1.2.1 of the both the 87 an 93 LRM (and I suppose 2002):

"The only predefined integer type is type INTEGER. The range of INTEGER is
implementation dependent, but is guaranteed to include the
range -2147483647 to 2147483648. It is defined with an ascending range.

So I guess even among those who quote the LRM, those boundary values are a
pain

KJ

 

[Paul Uiterlinden]

KJ wrote:

"Paul Uiterlinden" <puiterl@notaimvalley.nl> wrote in message
news:470beedd$0$235

Earlier in the thread in a post from you....
. According to the 1993 LRM the minimum required range is
-2147483647 to 2147483647.

Latest posting...

Yes, section 3.1.2.1 of the both the 87 an 93 LRM (and I suppose 2002):

"The only predefined integer type is type INTEGER. The range of INTEGER
is implementation dependent, but is guaranteed to include the
range -2147483647 to 2147483648. It is defined with an ascending range.

So I guess even among those who quote the LRM, those boundary values are a
pain

Apparently my brain fell apart into bits there for a moment. Thirty two bits
to be exact.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.