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.
-- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
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
do
by a
Well, when the numbers get too big apparently...
rs. In
utely
You're not representing that post accurately. The post showed four example s of time divided by time and it appears that three of the four did synthes ize properly. Only in the fourth case, 1000000 ns / 25 ns is a warning gen erated 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.". Th e stated rationale is "Vivado Synthesis has a limitation to the precision t hat is supported for time that goes in accordance with the LRM" but it's no t clear what part of the LRM they are discussing or which range of time Viv ado does accept. At least they do recognize it as a deficiency, they are k icking out a warning message so kudos there. But I agree that the suggeste d 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
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).
Allan
t
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 th ere 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 too ls 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 constrain ts. You can do many things to verify your design, but how do you verify yo ur 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 th an once. On one occasion he gave me enough info to allow me to program a s lightly different part with the same bit stream file so I didn't have to re build the sources and requalify the design. That was fantastic saving me t ons 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
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.
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.
ution. That would be useful sure, but that is not part of the LRM...
st idea
e.
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."
sn't fit.
30us = 3E10 fs which is larger than 2^31 fs. But the thing I don't get i s that in the AR, they had examples of 10us and 100us (actually 10,000 ns a nd 100,000 ns) and stated that Vivado worked properly. 2^31 fs is only 2.1 47 us so if the limit is 2^31 fs, those cases should not have worked either .But compliant to the minimum standard of the LRM. That expanding to 64 bit s didn't come into play until VHDL-2017, oops 2018, oops 2019, oops?? When ever the expanded range comes into play, it would not be implemented by too ls until a long time afterwards.
Kevin
olution.
iest idea
ime.
M says "The only predefined physical type is type TIME. The range of TIME i s implementation dependent, but it is guaranteed to include the range ? ??2147483647 to +2147483647."
oesn't fit.
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 eith er.
its didn't come into play until VHDL-2017, oops 2018, oops 2019, oops?? Wh enever the expanded range comes into play, it would not be implemented by t ools 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 fo r? 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
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.
esolution.
ggiest idea
time.
LRM says "The only predefined physical type is type TIME. The range of TIM E is implementation dependent, but it is guaranteed to include the range ?2147483647 to +2147483647."
doesn't fit.
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 onl y 2.147 us so if the limit is 2^31 fs, those cases should not have worked e ither.
4 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 b y tools until a long time afterwards.bit integers. Even today, is there much going on that ps is not good enoug h for? Certainly it is a bit of a PITA that integers are limited to 32 bit s.
-bit
days
Huh? The issue is what the synthesizer uses. If you can't count on intege rs 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
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.
resolution.
foggiest idea
it time.
he LRM says "The only predefined physical type is type TIME. The range of T IME is implementation dependent, but it is guaranteed to include the range ?2147483647 to +2147483647."
us doesn't fit.
t get is that in the AR, they had examples of 10us and 100us (actually 10,0
00 ns and 100,000 ns) and stated that Vivado worked properly. 2^31 fs is o nly 2.147 us so if the limit is 2^31 fs, those cases should not have worked either. 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. 2 bit integers. Even today, is there much going on that ps is not good eno ugh for? Certainly it is a bit of a PITA that integers are limited to 32 b its. 64-bitese days
tegers being more than 32 bits, you can't write synthesizable code for inte gers being more than 32 bits.
don't want portable code?
cook
lhan 32
and say
to
Doesn't changing integers to 64 bits have potential of breaking code? I wo uld 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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.