Time Divided by Time is What?

[rickman]

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

 

[KJ]

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

 

[rickman]

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

 

[Alan Fitch]

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

 

[Paul Uiterlinden]

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.

 

[valtih1978]

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

 

[Paul Uiterlinden]

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

 

[rickman]

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