On Monday, August 12, 2019 at 5:12:47 PM UTC-4, Rob Gaddi wrote:> On 8/12/19 1:52 PM, Rick C wrote: > > On Monday, August 12, 2019 at 2:26:36 PM UTC-4, KJ wrote: > >> On Monday, August 12, 2019 at 12:56:10 PM UTC-4, Rob Gaddi wrote: > >>> On 8/9/19 7:48 PM, KJ wrote: > >> > >>> When I run simulations there's an option to explicitly set the time resolution. > >> That would be useful sure, but that is not part of the LRM... > >> > >>> I can't find any such option in Vivado, so I can't design with the foggiest idea > >>> what does or does not fit in what is almost certainly a signed 32-bit time. > >> > >> I would guess that 2^31-1 fs might be the upper end of the range. The LRM says "The only predefined physical type is type TIME. The range of TIME is implementation dependent, but it is guaranteed to include the range –2147483647 to +2147483647." > >> > >>> But at can't imagine any practical resolution of time in which 30 us doesn't fit. > >> > >> 30us = 3E10 fs which is larger than 2^31 fs. But the thing I don't get is that in the AR, they had examples of 10us and 100us (actually 10,000 ns and 100,000 ns) and stated that Vivado worked properly. 2^31 fs is only 2.147 us so if the limit is 2^31 fs, those cases should not have worked either. > >> > >>> I suppose it must be using 1 fs, which feels perhaps excessive. > >> But compliant to the minimum standard of the LRM. That expanding to 64 bits didn't come into play until VHDL-2017, oops 2018, oops 2019, oops?? Whenever the expanded range comes into play, it would not be implemented by tools until a long time afterwards. > > > > I've always thought it was odd that VHDL uses fs for time, but only 32 bit integers. Even today, is there much going on that ps is not good enough for? Certainly it is a bit of a PITA that integers are limited to 32 bits. > > > > Nothing in any VHDL specification through 2008 prevents you from using 64-bit > integers, but nothing demands it either. Most simulators I've seen these days > do in fact use 64, but Xilinx seems to have decided not to.Huh? The issue is what the synthesizer uses. If you can't count on integers being more than 32 bits, you can't write synthesizable code for integers being more than 32 bits. What good does it do for some systems to use 64 bit integers unless you don't want portable code? -- Rick C. -+ Get 1,000 miles of free Supercharging -+ Tesla referral code - https://ts.la/richard11209
VHDL TIME support in Vivado
Started by ●August 9, 2019
Reply by ●August 12, 20192019-08-12
Reply by ●August 12, 20192019-08-12
On 8/12/19 3:06 PM, Rick C wrote:> On Monday, August 12, 2019 at 5:12:47 PM UTC-4, Rob Gaddi wrote: >> On 8/12/19 1:52 PM, Rick C wrote: >>> On Monday, August 12, 2019 at 2:26:36 PM UTC-4, KJ wrote: >>>> On Monday, August 12, 2019 at 12:56:10 PM UTC-4, Rob Gaddi wrote: >>>>> On 8/9/19 7:48 PM, KJ wrote: >>>> >>>>> When I run simulations there's an option to explicitly set the time resolution. >>>> That would be useful sure, but that is not part of the LRM... >>>> >>>>> I can't find any such option in Vivado, so I can't design with the foggiest idea >>>>> what does or does not fit in what is almost certainly a signed 32-bit time. >>>> >>>> I would guess that 2^31-1 fs might be the upper end of the range. The LRM says "The only predefined physical type is type TIME. The range of TIME is implementation dependent, but it is guaranteed to include the range –2147483647 to +2147483647." >>>> >>>>> But at can't imagine any practical resolution of time in which 30 us doesn't fit. >>>> >>>> 30us = 3E10 fs which is larger than 2^31 fs. But the thing I don't get is that in the AR, they had examples of 10us and 100us (actually 10,000 ns and 100,000 ns) and stated that Vivado worked properly. 2^31 fs is only 2.147 us so if the limit is 2^31 fs, those cases should not have worked either. >>>> >>>>> I suppose it must be using 1 fs, which feels perhaps excessive. >>>> But compliant to the minimum standard of the LRM. That expanding to 64 bits didn't come into play until VHDL-2017, oops 2018, oops 2019, oops?? Whenever the expanded range comes into play, it would not be implemented by tools until a long time afterwards. >>> >>> I've always thought it was odd that VHDL uses fs for time, but only 32 bit integers. Even today, is there much going on that ps is not good enough for? Certainly it is a bit of a PITA that integers are limited to 32 bits. >>> >> >> Nothing in any VHDL specification through 2008 prevents you from using 64-bit >> integers, but nothing demands it either. Most simulators I've seen these days >> do in fact use 64, but Xilinx seems to have decided not to. > > Huh? The issue is what the synthesizer uses. If you can't count on integers being more than 32 bits, you can't write synthesizable code for integers being more than 32 bits. > > What good does it do for some systems to use 64 bit integers unless you don't want portable code? >Well, we're talking about the specific case of TIME calculations in synthesizable code here, which means that you're always doing things that cook down at compile time to a constant integer value, and often a fairly small constant integer. So a tool supporting TIME on a 64-bit integer rather than 32 simply allows it to get those calculations correct rather than endaround and say that you need negative numbers of clock ticks. It's not an unreasonable thing, given that any PC sold in the last what, decade?, has a 64-bit processor in. Certainly given that Vivado was just written from scratch to replace ISE, the opportunity was certainly there to support at least TIME and probably all integers as 64-bit. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by ●August 12, 20192019-08-12
On Monday, August 12, 2019 at 6:48:13 PM UTC-4, Rob Gaddi wrote:> On 8/12/19 3:06 PM, Rick C wrote: > > On Monday, August 12, 2019 at 5:12:47 PM UTC-4, Rob Gaddi wrote: > >> On 8/12/19 1:52 PM, Rick C wrote: > >>> On Monday, August 12, 2019 at 2:26:36 PM UTC-4, KJ wrote: > >>>> On Monday, August 12, 2019 at 12:56:10 PM UTC-4, Rob Gaddi wrote: > >>>>> On 8/9/19 7:48 PM, KJ wrote: > >>>> > >>>>> When I run simulations there's an option to explicitly set the time resolution. > >>>> That would be useful sure, but that is not part of the LRM... > >>>> > >>>>> I can't find any such option in Vivado, so I can't design with the foggiest idea > >>>>> what does or does not fit in what is almost certainly a signed 32-bit time. > >>>> > >>>> I would guess that 2^31-1 fs might be the upper end of the range. The LRM says "The only predefined physical type is type TIME. The range of TIME is implementation dependent, but it is guaranteed to include the range –2147483647 to +2147483647." > >>>> > >>>>> But at can't imagine any practical resolution of time in which 30 us doesn't fit. > >>>> > >>>> 30us = 3E10 fs which is larger than 2^31 fs. But the thing I don't get is that in the AR, they had examples of 10us and 100us (actually 10,000 ns and 100,000 ns) and stated that Vivado worked properly. 2^31 fs is only 2.147 us so if the limit is 2^31 fs, those cases should not have worked either. > >>>> > >>>>> I suppose it must be using 1 fs, which feels perhaps excessive. > >>>> But compliant to the minimum standard of the LRM. That expanding to 64 bits didn't come into play until VHDL-2017, oops 2018, oops 2019, oops?? Whenever the expanded range comes into play, it would not be implemented by tools until a long time afterwards. > >>> > >>> I've always thought it was odd that VHDL uses fs for time, but only 32 bit integers. Even today, is there much going on that ps is not good enough for? Certainly it is a bit of a PITA that integers are limited to 32 bits. > >>> > >> > >> Nothing in any VHDL specification through 2008 prevents you from using 64-bit > >> integers, but nothing demands it either. Most simulators I've seen these days > >> do in fact use 64, but Xilinx seems to have decided not to. > > > > Huh? The issue is what the synthesizer uses. If you can't count on integers being more than 32 bits, you can't write synthesizable code for integers being more than 32 bits. > > > > What good does it do for some systems to use 64 bit integers unless you don't want portable code? > > > > Well, we're talking about the specific case of TIME calculations in > synthesizable code here, which means that you're always doing things that cook > down at compile time to a constant integer value, and often a fairly small > constant integer. So a tool supporting TIME on a 64-bit integer rather than 32 > simply allows it to get those calculations correct rather than endaround and say > that you need negative numbers of clock ticks. > > It's not an unreasonable thing, given that any PC sold in the last what, > decade?, has a 64-bit processor in. Certainly given that Vivado was just > written from scratch to replace ISE, the opportunity was certainly there to > support at least TIME and probably all integers as 64-bit. > > -- > Rob Gaddi, Highland Technology -- www.highlandtechnology.com > Email address domain is currently out of order. See above to fix.Doesn't changing integers to 64 bits have potential of breaking code? I would expect they would need a way to specify 64 vs. 32 bits for integers or even a separate type. -- Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209
