f

#### Time Divided by Time is What?

```I thought a time quantity divided by a time quantity would be a real,
but it seems to be an integer.  Can anyone confirm that?  I can't find a
reference that discusses this.

Rick
```
 0
rickman
11/18/2012 12:12:17 AM
comp.lang.vhdl 6430 articles. 2 followers.

7 Replies
1187 Views

Similar Articles

[PageSpeed] 31

```On Saturday, November 17, 2012 7:12:31 PM UTC-5, rickman wrote:
> I thought a time quantity divided by a time quantity would be a real, but it seems to be an integer. Can anyone confirm that? I can't find a reference that discusses this. Rick

Yes, time/time is an integer.  If you need more precision than integer than you can do something like this as an example...

real(time/1ps)/1E12

Kevin Jennings
```
 0
KJ
11/18/2012 2:17:40 AM
```On 11/17/2012 9:17 PM, KJ wrote:
> On Saturday, November 17, 2012 7:12:31 PM UTC-5, rickman wrote:
>> I thought a time quantity divided by a time quantity would be a real, but it seems to be an integer. Can anyone confirm that? I can't find a reference that discusses this. Rick
>
> Yes, time/time is an integer.  If you need more precision than integer than you can do something like this as an example...
>
> real(time/1ps)/1E12
>
> Kevin Jennings

That's essentially what I did.  Thanks for the confirmation.

My concern is that time has the potential of being much larger than an
integer can hold, but then it would have a lot more precision than a
real can hold either.  I guess it is best to do time math in the time
domain until you need to convert it to something else, like a trig
function, e.g. sin(pi*1e-9*real((2*freq*now)/1ns)).  But the trouble is
the intermediate integer can overflow if you aren't careful.  Maybe
better is...

sin(2.0*pi*1e-9*real(freq)*real(now/1ns))

Rick
```
 0
rickman
11/18/2012 3:52:52 AM
```On 18/11/12 03:52, rickman wrote:
> On 11/17/2012 9:17 PM, KJ wrote:
>> On Saturday, November 17, 2012 7:12:31 PM UTC-5, rickman wrote:
>>> I thought a time quantity divided by a time quantity would be a real, but it seems to be an integer. Can anyone confirm that? I can't find a reference that discusses this. Rick
>>
>> Yes, time/time is an integer.  If you need more precision than integer than you can do something like this as an example...
>>
>> real(time/1ps)/1E12
>>
>> Kevin Jennings
>
> That's essentially what I did.  Thanks for the confirmation.
>
> My concern is that time has the potential of being much larger than an
> integer can hold, but then it would have a lot more precision than a
> real can hold either.  I guess it is best to do time math in the time
> domain until you need to convert it to something else, like a trig
> function, e.g. sin(pi*1e-9*real((2*freq*now)/1ns)).  But the trouble is
> the intermediate integer can overflow if you aren't careful.  Maybe
> better is...
>
> sin(2.0*pi*1e-9*real(freq)*real(now/1ns))
>
> Rick
>

There's a function for retrieving the time resolution in VHDL 2008, of
which I've forgotten the name.

I always describe time as an integer. The time resolution then tells you
the maximum time you can represent, and what 1 integer step represents.
Normally time is a 64 bit unsigned integer, so 1 fs resolution gives you
steps of 1 fs and a maximum value of (2**64 -1 ) * 1 fs.

regards
Alan

--
Alan Fitch
```
 0
Alan
11/18/2012 11:20:58 AM
```Alan Fitch wrote:

> On 18/11/12 03:52, rickman wrote:
>> On 11/17/2012 9:17 PM, KJ wrote:
>>> On Saturday, November 17, 2012 7:12:31 PM UTC-5, rickman wrote:
>>>> I thought a time quantity divided by a time quantity would be a real,
>>>> but it seems to be an integer. Can anyone confirm that? I can't find a
>>>> reference that discusses this. Rick
>>>
>>> Yes, time/time is an integer.  If you need more precision than integer
>>> than you can do something like this as an example...
>>>
>>> real(time/1ps)/1E12
>>>
>>> Kevin Jennings
>>
>> That's essentially what I did.  Thanks for the confirmation.
>>
>> My concern is that time has the potential of being much larger than an
>> integer can hold, but then it would have a lot more precision than a
>> real can hold either.  I guess it is best to do time math in the time
>> domain until you need to convert it to something else, like a trig
>> function, e.g. sin(pi*1e-9*real((2*freq*now)/1ns)).  But the trouble is
>> the intermediate integer can overflow if you aren't careful.  Maybe
>> better is...
>>
>> sin(2.0*pi*1e-9*real(freq)*real(now/1ns))
>>
>> Rick
>>
>
> There's a function for retrieving the time resolution in VHDL 2008, of
> which I've forgotten the name.

env.resolution_limit

> I always describe time as an integer. The time resolution then tells you
> the maximum time you can represent, and what 1 integer step represents.
> Normally time is a 64 bit unsigned integer, so 1 fs resolution gives you
> steps of 1 fs and a maximum value of (2**64 -1 ) * 1 fs.

To the previous two posters: between the number and the unit the space is
not optional.

vcom Message # 1207:
[13.2 Lexical elements, separators, and delimiters], line 130:
At least one separator is required between an identifier or an
abstract literal and an adjacent identifier or abstract literal.

Paul.

```
 0
Paul
11/19/2012 11:08:16 AM
```I think that physical value is internally an integer plus unit. So, you
do not loose anything when convert the time into integer. You might
afraid that integer is limited to 4 giga values. I think that the time
relies on `Universal integer` rather than STD.INTEGER and LRM is precise
at page 128: "Any physical type / The same type = Universal integer".
So, you do not loose anything again.

On 18.11.2012 5:52, rickman wrote:
> On 11/17/2012 9:17 PM, KJ wrote:
>> On Saturday, November 17, 2012 7:12:31 PM UTC-5, rickman wrote:
>>> I thought a time quantity divided by a time quantity would be a real,
>>> but it seems to be an integer. Can anyone confirm that? I can't find
>>> a reference that discusses this. Rick
>>
>> Yes, time/time is an integer.  If you need more precision than integer
>> than you can do something like this as an example...
>>
>> real(time/1ps)/1E12
>>
>> Kevin Jennings
>
> That's essentially what I did.  Thanks for the confirmation.
>
> My concern is that time has the potential of being much larger than an
> integer can hold, but then it would have a lot more precision than a
> real can hold either.  I guess it is best to do time math in the time
> domain until you need to convert it to something else, like a trig
> function, e.g. sin(pi*1e-9*real((2*freq*now)/1ns)).  But the trouble is
> the intermediate integer can overflow if you aren't careful.  Maybe
> better is...
>
> sin(2.0*pi*1e-9*real(freq)*real(now/1ns))
>
> Rick

```
 0
valtih1978
11/19/2012 11:14:52 AM
```valtih1978 wrote:

> I think that physical value is internally an integer plus unit. So, you
> do not loose anything when convert the time into integer. You might
> afraid that integer is limited to 4 giga values. I think that the time
> relies on `Universal integer` rather than STD.INTEGER and LRM is precise
> at page 128: "Any physical type / The same type = Universal integer".
> So, you do not loose anything again.

Considering for example 5 ns / 3 ns, resulting in 1, I would say you lose
quite some precision.

--
Paul

```
 0
Paul
11/19/2012 11:29:36 AM
```On 11/19/2012 6:08 AM, Paul Uiterlinden wrote:
>
> To the previous two posters: between the number and the unit the space is
> not optional.
>
> vcom Message # 1207:
> [13.2 Lexical elements, separators, and delimiters], line 130:
>    At least one separator is required between an identifier or an
>    abstract literal and an adjacent identifier or abstract literal.

Thanks for the info.  I'm often not online and so can't check the web.
I noticed that in the example code for my application they left out the
space, so that's how I typed it and it works ok.  Doing a Google search
I found this discussion...

http://www.eda.org/isac/IRs-VHDL-87/IR0003.txt

"VHDL Issue Number:      0003
Classification:         Examples, Notes, and Appendices
Language Version:       VHDL-87
Summary:                Examples in the LRM do not have a space
between the abstract literal and the
unit name of physical literals
"
....

"Description of Problem
----------------------

The fourth paragraph of section 13.2 of the LRM states that:

"... At least one separator is required between  an  identifier
or  an  abstract literal and an adjacent identifier or abstract
literal."

Thus a space is always required between the abstract literal and the
unit name in a physical literal.  Nevertheless, many of the examples
in the LRM incorrectly include physical literals  which  contain  no
space between the abstract literal and the unit name.
"

So it seems that at one time at least the LRM didn't practice what it
preached and so I expect all vendors will accept code that does not
include a space between the literal and the unit.  Still, it's not a
good practice to follow.  There is always the potential for a new tool
to be more strict and all your code would then break!

Rick
```
 0
rickman
11/19/2012 2:48:46 PM