12-20-2018 10:37 AM - edited 12-22-2018 02:05 PM
I just upgraded to Vivado 2018.3 a few minutes ago. Most of my projects don't work anymore, since the Clocking Wizard IP Core throws some errors. I believe the error is related to using commas instead of decimal points in some TCL code. When upgrading my block designed from 2018.2.2, the Clocking Wizard Block is destroyed.
Anyhow, the following minimal steps are required to reproduce the issue:
I'm using Linux and my system is configured to use the German language, i.e. I have LANG=de_DE.UTF-8.
If I switch to LANG=en_US.UTF-8 and restart Vivado with that setting, then I can actually add a clocking wizard to my design. But I have not tried to generate the bitstream. This issue did not exist with Vivado 2018.2.2.
This is not the first time I have seen locale-related issues in Vivado.
Please advise how to proceed. We want to switch to 2018.3 for our project since we need other import bug fixes.
12-20-2018 12:44 PM - edited 12-22-2018 02:05 PM
So I created a block design with LANG=en_US.UTF-8 and that worked.
However, when I restart Vivado 2018.3 with LANG=de_DE.UTF-8, everything seems alright -- until I try to edit the frequency of the output clocks. Then I get the following Tcl error:
Tcl error in validate procedure while setting value '80' on parameter 'CLKOUT1_REQUESTED_OUT_FREQ'. unexpected "," outside function argument list in expression "1000.000 / 2,155".
So I assume the second number is supposed to be 2.155, however, the Tcl code seems to use the German locale to generate the number string, and that back fires when the string is parsed again.
02-18-2019 04:32 AM
Not only the Clocking Wizard, but also the Clock Configuration of the Zynq itself suffers from this. This used to work on older versions of Vivado irrespective of locale settings. Programming languages SHOULD NOT USE locale settings for calculations!
Btw. On Windows it works correct even though my locale settings use a , for decimals.
02-18-2019 04:47 AM
Oh wait, if I open the Language Settings of my (Ubuntu 16.04) Linux installation it warns me that "the language support is not installed completely". If I then let it install the missing pieces, but change nothing! it starts to work correctly.
I wonder why Ubuntu didn't install the language support completely in the first place.
02-18-2019 07:42 AM
i'm sorry, but when Ubuntu tells you that "the language support is not installed completely", it most likely referrs to the fact that some firefox language support packages were missing. The libc language files were installed properly already.
After I have been hit by the problem above, I have switched Vivado back and forth between German and English language settings (simply by override all language related environment variables in Vivado's start script) and it's **bleep**ing mind-boggling when this problem happens and when it doesn't. I certainly reset the projects, but I can't tell when the issue happens and when it doesn't. So as far as I can tell, the issue might reappear in your next project.
Also, since Xilinx chooses to pass strings around, this problem is what you get when you use locale-aware functions to generate strings in combination with locale-ignorant functions to parse them. And there seems to be no QA at Xilinx to avoid this issue.
The Windows version of their TCL runtime is probably not aware of the Windows language settings. So all Windows users can sleep tight while we Linux users have nightmares about the next language-related issue.
02-18-2019 08:22 AM
No, it installed a lot more than just firefox packages, also some pretty generic looking ones. And it also triggered something to reconfigure the locale settings like dpkg-reconfigure would do.
I'm not saying it won't come back, but so far this fixed it for me instantly.
If it doesn't work for you and if it's any consolation, you have my sympathy.
05-02-2019 07:49 AM
It has to do with the locale settings. When setting all locales environment variables (LC_TYPE, LC_NUMERIC etc) to en_US.UTF-8 I think I was able to solve the problem (Probably LC_NUMERIC is key to the problem) . I believe also running vivado like this should fix the problem:
05-02-2019 09:32 AM
There are many variables on Linux to set the locale. In my case, it would be LANG=en_US.UTF-8
Anyhow, setting the english locale fixed the problem for me as well. The question still is: why is Vivado sensitive to the locale? It shouldn't be! Certainly not in automated scripts.
12-19-2019 02:32 AM
I got this error on Vivado 2019.2. I used XUbuntu 16.4 with full english locale.
But your solution (launch Language Support and complete installed the language packets) was work for me. Thanks!