04-14-2016 10:41 AM
It seems that Vivado will not generate output products for IP or block designs on remote hosts, even when remote hosts is selected in the Generate Output Products dialog. This is true for any synthesis option.
To reproduce: select Generate Output Products... from the context menu of an IP or block diagram. Select Global, Out of context per IP, or Out of context per Block Diagram for the Synthesis Options. Select On remote hosts for the Run Settings. Select Generate.
The job(s) run locally and not on the remote host. Looking through the tcl, the -host option is not used. Running on a remote host does work when synthesising or implementing the project, so I know the remote host is configured correctly.
Can anyone confirm this behavior? Is this a bug or am I missing something?
I am running Vivado 2015.4.2 on ubuntu 14.04.4.
12-11-2017 07:50 AM
We are experiencing the same behavior in Vivado 2017.3. It looks like the issue hasn't been addressed yet. Could someone from Xilinx answer is this is a bug or a deliberate design feature?
05-31-2019 03:18 PM
Also doesn't work for me in 2018.2.
I know this is an old post now, but were any of you guys successful in getting it to do remote synthesis for OOC ip by any means?
If I click just "Run Synthesis" on the left bar in Vivado, it skips immediately to synthesizing the top level module,
which will fail out if the OOC ip hasnt already been synthesized.
Generating output products has the same bug as described in this post (synthesis is done locally).
Implementation appears to work correctly.
Why is Xilinx silent on this?
Its important for us that we be able to dish off the work of synthesizing OOC ip for performance reasons.
06-03-2019 12:30 AM
This is an old post.
Please create a fresh new thread with your query. And community will help you out on your issue.
And also have a look into this thread. https://forums.xilinx.com/t5/Installation-and-Licensing/Vivado-2013-2-Launching-jobs-on-a-remote-host/td-p/396861
06-07-2019 07:19 AM
This may be an old post, but that is because Xilinx has not addressed the original question and has apparently still not fixed the problem. The other post you referenced does not address the issue at hand. Instead of reproaching firstname.lastname@example.org for posting to an older (but still open) thread, why doesn't Xilinx actually address the issue? I started this thread over three years ago, and the only response from Xilinx is yours from a few days ago telling us to start a new thread. Can you please either help us or bring this to the attention of someone who will?
06-07-2019 09:25 AM
Completely agree with Brian.
But perhaps Xilinx would prefer customers *using Xilinx products* ask our questions about product failings on Twitter?