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

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