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 |

11/18/2012 12:12:17 AM

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 |

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 |

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 |

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 |

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 |

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 |

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 |

11/19/2012 2:48:46 PM