VHDL TIME support in Vivado

[Rob Gaddi]

Y'all. It's 2019. TIME has been in VHDL since what, 1987? And yet Vivado
remains unable to successfully divide an amount of time you want to wait by a
clock period to get a compile-time integer.

https://www.xilinx.com/support/answers/57964.html is from 2014. Five years. In
five years, Xilinx has remained unable to perform simple division. Absolutely
embarrassing.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[Rick C]

On Friday, August 9, 2019 at 1:49:59 PM UTC-4, Rob Gaddi wrote:

Y'all. It's 2019. TIME has been in VHDL since what, 1987? And yet Vivado
remains unable to successfully divide an amount of time you want to wait by a
clock period to get a compile-time integer.

https://www.xilinx.com/support/answers/57964.html is from 2014. Five years. In
five years, Xilinx has remained unable to perform simple division. Absolutely
embarrassing.

Obviously Xilinx customers aren't asking for it. After all, Xilinx is very responsive to their customers, no?

Any other limitations that are issues?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[KJ]

On Friday, August 9, 2019 at 1:49:59 PM UTC-4, Rob Gaddi wrote:

Y'all. It's 2019. TIME has been in VHDL since what, 1987? And yet Vivado
remains unable to successfully divide an amount of time you want to wait by a
clock period to get a compile-time integer.

Well, when the numbers get too big apparently...

https://www.xilinx.com/support/answers/57964.html is from 2014. Five years. In
five years, Xilinx has remained unable to perform simple division. Absolutely
embarrassing.
You're not representing that post accurately. The post showed four examples of time divided by time and it appears that three of the four did synthesize properly. Only in the fourth case, 1000000 ns / 25 ns is a warning generated by the tool and the synthesis fails. That would hardly qualify as "remained unable to perform simple division" in my book.

They do go on to say "Using time for integer calculations should be avoided and is not a recommended coding style supported by Vivado Synthesis.". The stated rationale is "Vivado Synthesis has a limitation to the precision that is supported for time that goes in accordance with the LRM" but it's not clear what part of the LRM they are discussing or which range of time Vivado does accept. At least they do recognize it as a deficiency, they are kicking out a warning message so kudos there. But I agree that the suggested work around is weak. The lack of a defined time range that is supported is also weak (unless it is mentioned in the documentation, I'm only looking at the post).

It's also not clear either whether if it had been written 'smaller' numbers if it would have worked (such as 1 sec / 25 ns) but I'm guessing not.

Kevin Jennings

 

[Allan Herriman]

On Fri, 09 Aug 2019 11:42:10 -0700, Rick C wrote:

On Friday, August 9, 2019 at 1:49:59 PM UTC-4, Rob Gaddi wrote:
Y'all. It's 2019. TIME has been in VHDL since what, 1987? And yet
Vivado remains unable to successfully divide an amount of time you want
to wait by a clock period to get a compile-time integer.

https://www.xilinx.com/support/answers/57964.html is from 2014. Five
years. In five years, Xilinx has remained unable to perform simple
division. Absolutely embarrassing.

Obviously Xilinx customers aren't asking for it. After all, Xilinx is
very responsive to their customers, no?

I can't tell whether you're being sarcastic. Xilinx /should/ be
responsive to their customers. My experience has been that they're
typically the opposite of responsive, when it comes to bugs or (lack of)
HDL support in the tools.

I've found two synthesis bugs in Vivado in the past few weeks (one
Verilog regarding incorrect macro expansion, the other VHDL where it will
sometimes think a large 2D array of std_logic is a memory, start trying
to map it to a RAM, realise that's not the right thing to do, then
royally stuff up the generated code). In both cases it gives a warning
(which means I can (automatically) search for it to know whether I'm
triggering that bug.

I'm not even going to bother reporting them. The process is just too
difficult.


To contradict myself, here's an example of a bug report of mine on the
Xilinx forum that was handled well, and the bug was actually fixed (it
took about a year, but they did fix it).
https://forums.xilinx.com/t5/Synthesis/Bug-report-Vivado-VHDL-assertion-
still-broken/m-p/842926
That one had a small, self contained test case though. In my experience,
most tool bugs will only show up on a massive design, and refuse to
manifest themselves on a snall test case.

Allan

 

[Rick C]

On Sunday, August 11, 2019 at 4:46:34 AM UTC-4, Allan Herriman wrote:

On Fri, 09 Aug 2019 11:42:10 -0700, Rick C wrote:

On Friday, August 9, 2019 at 1:49:59 PM UTC-4, Rob Gaddi wrote:
Y'all. It's 2019. TIME has been in VHDL since what, 1987? And yet
Vivado remains unable to successfully divide an amount of time you want
to wait by a clock period to get a compile-time integer.

https://www.xilinx.com/support/answers/57964.html is from 2014. Five
years. In five years, Xilinx has remained unable to perform simple
division. Absolutely embarrassing.

Obviously Xilinx customers aren't asking for it. After all, Xilinx is
very responsive to their customers, no?


I can't tell whether you're being sarcastic. Xilinx /should/ be
responsive to their customers. My experience has been that they're
typically the opposite of responsive, when it comes to bugs or (lack of)
HDL support in the tools.

I've found two synthesis bugs in Vivado in the past few weeks (one
Verilog regarding incorrect macro expansion, the other VHDL where it will
sometimes think a large 2D array of std_logic is a memory, start trying
to map it to a RAM, realise that's not the right thing to do, then
royally stuff up the generated code). In both cases it gives a warning
(which means I can (automatically) search for it to know whether I'm
triggering that bug.

I'm not even going to bother reporting them. The process is just too
difficult.


To contradict myself, here's an example of a bug report of mine on the
Xilinx forum that was handled well, and the bug was actually fixed (it
took about a year, but they did fix it).
https://forums.xilinx.com/t5/Synthesis/Bug-report-Vivado-VHDL-assertion-
still-broken/m-p/842926
That one had a small, self contained test case though. In my experience,
most tool bugs will only show up on a massive design, and refuse to
manifest themselves on a snall test case.

Allan

Yes, I was being sarcastic. But in their defense it is no easier for them to fix difficult to reproduce bugs than it is for us to report them. If there is no failure condition to reproduce the bug, how can we expect them to fix it?

I worked on a project once where the company knew of a problem with the tools that made the timing analysis invalid. We said it was the tool, Altera said it must be our constraints. That's the one total failure of constraints. You can do many things to verify your design, but how do you verify your timing constraints? If they aren't right the timing can fail which will likely be very sporadic and intermittent - hard to detect and diagnose.

Bottom line is FPGA companies target their largest customers. Anyone else gets whatever is left over. The Lattice FAE has been helpful to me more than once. On one occasion he gave me enough info to allow me to program a slightly different part with the same bit stream file so I didn't have to rebuild the sources and requalify the design. That was fantastic saving me tons of work. I couldn't get the Indian support guys to even acknowledge it was possible.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[Rob Gaddi]

On 8/9/19 7:48 PM, KJ wrote:

On Friday, August 9, 2019 at 1:49:59 PM UTC-4, Rob Gaddi wrote:
Y'all. It's 2019. TIME has been in VHDL since what, 1987? And yet Vivado
remains unable to successfully divide an amount of time you want to wait by a
clock period to get a compile-time integer.

Well, when the numbers get too big apparently...

https://www.xilinx.com/support/answers/57964.html is from 2014. Five years. In
five years, Xilinx has remained unable to perform simple division. Absolutely
embarrassing.
You're not representing that post accurately. The post showed four examples of time divided by time and it appears that three of the four did synthesize properly. Only in the fourth case, 1000000 ns / 25 ns is a warning generated by the tool and the synthesis fails. That would hardly qualify as "remained unable to perform simple division" in my book.

They do go on to say "Using time for integer calculations should be avoided and is not a recommended coding style supported by Vivado Synthesis.". The stated rationale is "Vivado Synthesis has a limitation to the precision that is supported for time that goes in accordance with the LRM" but it's not clear what part of the LRM they are discussing or which range of time Vivado does accept. At least they do recognize it as a deficiency, they are kicking out a warning message so kudos there. But I agree that the suggested work around is weak. The lack of a defined time range that is supported is also weak (unless it is mentioned in the documentation, I'm only looking at the post).

It's also not clear either whether if it had been written 'smaller' numbers if it would have worked (such as 1 sec / 25 ns) but I'm guessing not.

Kevin Jennings

In my particular case, the numbers in question were 30 us / 8.333 ns, which
should come out about 3600. Instead I got -17. Fortunately I declared my
constants as natural rather than integer so it at least failed early rather than
get all the way through to a broken bitstream.

They mention that "Vivado Synthesis has a limitation to the precision that is
supported for time that goes in accordance with the LRM" but provide no
information what that limit IS, instead just opting for the statement you quote
above of "Time is hard, so we just have no expectation of getting it right."

When I run simulations there's an option to explicitly set the time resolution.
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. But
at can't imagine any practical resolution of time in which 30 us doesn't fit.
I suppose it must be using 1 fs, which feels perhaps excessive. But they don't
talk about it, they just mention in an AR that it's "not a recommended coding
style".

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[Rob Gaddi]

On 8/11/19 8:51 AM, Rick C wrote:

On Sunday, August 11, 2019 at 4:46:34 AM UTC-4, Allan Herriman wrote:
On Fri, 09 Aug 2019 11:42:10 -0700, Rick C wrote:

On Friday, August 9, 2019 at 1:49:59 PM UTC-4, Rob Gaddi wrote:
Y'all. It's 2019. TIME has been in VHDL since what, 1987? And yet
Vivado remains unable to successfully divide an amount of time you want
to wait by a clock period to get a compile-time integer.

https://www.xilinx.com/support/answers/57964.html is from 2014. Five
years. In five years, Xilinx has remained unable to perform simple
division. Absolutely embarrassing.

Obviously Xilinx customers aren't asking for it. After all, Xilinx is
very responsive to their customers, no?


I can't tell whether you're being sarcastic. Xilinx /should/ be
responsive to their customers. My experience has been that they're
typically the opposite of responsive, when it comes to bugs or (lack of)
HDL support in the tools.

I've found two synthesis bugs in Vivado in the past few weeks (one
Verilog regarding incorrect macro expansion, the other VHDL where it will
sometimes think a large 2D array of std_logic is a memory, start trying
to map it to a RAM, realise that's not the right thing to do, then
royally stuff up the generated code). In both cases it gives a warning
(which means I can (automatically) search for it to know whether I'm
triggering that bug.

I'm not even going to bother reporting them. The process is just too
difficult.


To contradict myself, here's an example of a bug report of mine on the
Xilinx forum that was handled well, and the bug was actually fixed (it
took about a year, but they did fix it).
https://forums.xilinx.com/t5/Synthesis/Bug-report-Vivado-VHDL-assertion-
still-broken/m-p/842926
That one had a small, self contained test case though. In my experience,
most tool bugs will only show up on a massive design, and refuse to
manifest themselves on a snall test case.

Allan

Yes, I was being sarcastic. But in their defense it is no easier for them to fix difficult to reproduce bugs than it is for us to report them. If there is no failure condition to reproduce the bug, how can we expect them to fix it?

I worked on a project once where the company knew of a problem with the tools that made the timing analysis invalid. We said it was the tool, Altera said it must be our constraints. That's the one total failure of constraints. You can do many things to verify your design, but how do you verify your timing constraints? If they aren't right the timing can fail which will likely be very sporadic and intermittent - hard to detect and diagnose.

Bottom line is FPGA companies target their largest customers. Anyone else gets whatever is left over. The Lattice FAE has been helpful to me more than once. On one occasion he gave me enough info to allow me to program a slightly different part with the same bit stream file so I didn't have to rebuild the sources and requalify the design. That was fantastic saving me tons of work. I couldn't get the Indian support guys to even acknowledge it was possible.

And yet, in those "difficult to reproduce bugs" situations? I've often been in
a scenario where I can say "You know what, there's nothing NDAed in this design,
I really can send you the whole thing. I don't know what's wrong in it, but
this crashes your code, and you can trace it through." What I get back is
"Yeah, but can you work up a smaller test case?" No, I can't. That's not what
I get paid to do. I have isolated a specific failure condition by dumb luck,
and am happy to share it, but spending a day trying to turn it into a general
problem statement? That's for someone on the vendor's payroll.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[KJ]

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.

Kevin

 

[Rick C]

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.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

 

[Rob Gaddi]

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.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[Rick C]

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

 

[Rob Gaddi]

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.

 

[Rick C]

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