VHDL TIME support in Vivado

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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.

Re: VHDL TIME support in Vivado
On Friday, August 9, 2019 at 1:49:59 PM UTC-4, Rob Gaddi wrote:
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: VHDL TIME support in Vivado
On Fri, 09 Aug 2019 11:42:10 -0700, Rick C wrote:

Quoted text here. Click to load it


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

Re: VHDL TIME support in Vivado
On Sunday, August 11, 2019 at 4:46:34 AM UTC-4, Allan Herriman wrote:
Quoted text here. Click to load it
t
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: VHDL TIME support in Vivado
On 8/11/19 8:51 AM, Rick C wrote:
Quoted text here. Click to load it

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.

Re: VHDL TIME support in Vivado
On Friday, August 9, 2019 at 1:49:59 PM UTC-4, Rob Gaddi wrote:
Quoted text here. Click to load it
do  
Quoted text here. Click to load it
by a  
Quoted text here. Click to load it
Well, when the numbers get too big apparently...

Quoted text here. Click to load it
rs.  In  
Quoted text here. Click to load it
utely  
Quoted text here. Click to load it
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

Re: VHDL TIME support in Vivado
On 8/9/19 7:48 PM, KJ wrote:
Quoted text here. Click to load it

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.

Re: VHDL TIME support in Vivado
On Monday, August 12, 2019 at 12:56:10 PM UTC-4, Rob Gaddi wrote:
Quoted text here. Click to load it

ution.  
That would be useful sure, but that is not part of the LRM...

Quoted text here. Click to load it
st idea  
Quoted text here. Click to load it
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."

Quoted text here. Click to load it
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
.

Quoted text here. Click to load it
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

Re: VHDL TIME support in Vivado
On Monday, August 12, 2019 at 2:26:36 PM UTC-4, KJ wrote:
Quoted text here. Click to load it
olution.  
Quoted text here. Click to load it
iest idea  
Quoted text here. Click to load it
ime.  
Quoted text here. Click to load it
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."
Quoted text here. Click to load it
oesn't fit.  
Quoted text here. Click to load it
 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.
Quoted text here. Click to load it
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
We've slightly trimmed the long signature. Click to see the full one.
Re: VHDL TIME support in Vivado
On 8/12/19 1:52 PM, Rick C wrote:
Quoted text here. Click to load it

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.

Re: VHDL TIME support in Vivado
On Monday, August 12, 2019 at 5:12:47 PM UTC-4, Rob Gaddi wrote:
Quoted text here. Click to load it
esolution.
ggiest idea
 time.
Quoted text here. Click to load it
 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."
Quoted text here. Click to load it
 doesn't fit.
Quoted text here. Click to load it
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.
Quoted text here. Click to load it
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.
Quoted text here. Click to load it
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.
Quoted text here. Click to load it
-bit  
Quoted text here. Click to load it
 days  
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: VHDL TIME support in Vivado
On 8/12/19 3:06 PM, Rick C wrote:
Quoted text here. Click to load it

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.

Re: VHDL TIME support in Vivado
On Monday, August 12, 2019 at 6:48:13 PM UTC-4, Rob Gaddi wrote:
Quoted text here. Click to load it
 resolution.
Quoted text here. Click to load it
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."
Quoted text here. Click to load it
us doesn't fit.
Quoted text here. Click to load it
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.
Quoted text here. Click to load it
 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.
Quoted text here. Click to load it
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.
Quoted text here. Click to load it
 64-bit
Quoted text here. Click to load it
ese days
tegers being more than 32 bits, you can't write synthesizable code for inte
gers being more than 32 bits.
Quoted text here. Click to load it
 don't want portable code?
Quoted text here. Click to load it
 cook  
Quoted text here. Click to load it
l  
Quoted text here. Click to load it
han 32  
Quoted text here. Click to load it
and say  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
to  
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline