UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
6,855 Views
Registered: ‎03-23-2015

Launching multiple runs with different Vivado instances

Hello,

 

long story short, I am integrating Vivado with our own build tools, based on SCons (python).

 

I would like to be able to launch runs on individual bases, so that even if a project has multiple synth/impl run pairs I would like to be able to trigger one of them to run without having to trigger the build for all of them, however, there is also an option to launch all/multiple of them at the same time.

 

Therefore what I have is a single project with all these runs and the user may launch various/all of them at the same time. Since the system has to be able to run runs individually, the mechanisms to run each run are independent, they launch vivado, open the project, launch the run the user demands, and wait for it to run.

 

While this system works well when only one run is launched, when multiple runs are launched, one of the runs does not seem to return from the wait_on_run command. I assume this is because the project is opened twice and I just wanted to know if there is any way around it...

 

This part is probably only for those familiar with scons:

Having a single scons builder which launches all synthesis runs for example would mean having to wait for the last synthesis run to finish before the first implementation run can be even launched, even if they are not dependent. Having a single scons builder that launches both synthesis and implementation would not be "modular", since we also often run synthesis with a their party tool and then run implementation with vivado...

0 Kudos
4 Replies
Explorer
Explorer
6,838 Views
Registered: ‎03-23-2015

Re: Launching multiple runs with different Vivado instances

I have been doing tests and I see that the problem disappears if the run's tcl scripts are sourced directly with no project open instead of using the launch_runs command with the project open, the big problem with this is that I see that once the project is opened after the runs have finish, vivado does not detect the runs have already been ran and completed, the user can not open the synthesized design or anything like that...

 

This is not an option since we need a project we can open and go around looking in case of need... As far as I understand sourcing the run's tcl script is like runing in non-project mode, is there anyway to re-synchronize vivado's project with the completed run afterwards?

0 Kudos
Highlighted
Guide avrumw
Guide
6,834 Views
Registered: ‎01-23-2009

Re: Launching multiple runs with different Vivado instances

if the run's tcl scripts are sourced directly with no project open instead of using the launch_runs.

 

As you noted, doing this "breaks" the project.

 

The "real" native mode of Vivado is non-project batch mode. In this mode, the concept of a project does not exist, only a design - a design is created (via synthesis) or loaded (via read_checkpoint) in memory, and from there, operations can be done on the design.

 

The "project" and the runs manager are wrappers around the native mode of Vivado, managing where inputs come from, where outputs go, what reports are run and where their outputs are saved and the state of the project. However, when a "process" needs to be run, the tools create a runme.tcl based on all the project infrastructure, and launch a second copy of Vivado in the background that runs in non-project batch mode. This background Vivado sources the runme.tcl script. However, the project database management is done before and after the background process is run by the foreground process. By launching Vivado with the runme.tcl (in non-project batch), you are only executing the process, not all the project infrastructure management (and hence your project is now "broken").

 

Also, this flow is definitely not recommended and is not supported. If anything goes wrong with it, you will be completely on your own, and there is nothing that promises that even if you get something workable now, it won't be broken in the next version of the tool; since all this stuff is supposed to be "under the hood" and you are hacking it, there is no promise of consistency from version to version. It's probably not a good idea to invest in a system like this that can be broken by new software versions.

 

is there anyway to re-synchronize vivado's project with the completed run afterwards?

 

No. And the important note is that this is not a "completed run" - the runme.tcl exists outside the "runs manager". So by executing the runme.tcl, you are not executing the "run" but creating a .dcp file in a particular location, which is only one step in executing a "run". The rest of the stuff of the run is managed through the "runs" objects, and it may be possible to change some of the properties there to convince it that the "run" is in a different state than what the runs manager thinks it is (or maybe it isn't), but, again, anything you accomplish will not be supported by Xilinx and could very easily change in a future version of the tool.

 

As I said in your other post - if you really want to do this kind of stuff, you will have to abandon project mode and write your own mechanism in non-project batch. Anything else you come up with is going to be a hack...

 

Avrum

0 Kudos
Explorer
Explorer
6,810 Views
Registered: ‎03-23-2015

Re: Launching multiple runs with different Vivado instances

Thanks Avrum,

 

while I understand what you say, and I also know that this might break on a future release, I got it working for the time being. I noticed that running multiple runs simultaneously launching theirs runme.sh would keep the project up-to-date with the completed runs. If you see the runme.sh and ISEWrap.sh generated files you'll see vivado writes to some hidden files in the backgroud to do this, so I guess that is what was missing when sourcing the tcl without a project open.

 

I tested this and I can open the project, open the completed runs, view netlists, etc, so everything seems fine, for now I will use this flow.

 

If anybody is interested, I wroty this python function (since I have an allergy to bash) copying what the original vivado scripts do (I also realise this might also break more easily if those generated scripts change, but I will give it a try):

 

Some of this code relyies on objects created by me (run and project), but I think what it does is pretty self explanatory

 

def vivado_launch_run_tcl(project, run):
    #This is needed in order to launch multiple runs simultaneously and keep the project in sync

    log_name    = "runme.log"
    begin_name  = ".vivado.begin.rst"
    end_name    = ".vivado.end.rst"
    error_name  = ".vivado.error.rst"
    launcher    = "vivado -log {}.vds -m64 -mode batch -messageDb vivado.pb -notrace -source {}".format(project.top_hdl_module, os.path.basename(run.get_tcl_script())).split()

    log_path    = os.path.join(run.get_build_directory(), log_name)
    begin_path  = os.path.join(run.get_build_directory(), begin_name)
    end_path    = os.path.join(run.get_build_directory(), end_name)
    error_path  = os.path.join(run.get_build_directory(), error_name)

    with open(log_path, 'w+') as logfile, open(begin_path, 'w+') as beginfile, open(end_path, 'w+') as endfile, open(error_path, 'w+') as errorfile:
        os.utime(log_path, None)
        if os.path.isfile(os.path.join(run.get_build_directory(), '.stop.rst')):
            logfile.write("\n")
            logfile.write("*** Halting run - EA reset detected ***\n")
            logfile.write("\n")
            return 1

        logfile.write("\n")
        logfile.write("*** Running vivado\n")
        logfile.write("    with arg {}\n".format(launcher[1:]))
        logfile.write("\n")

        print "cd {}".format(run.get_build_directory())
        print " ".join(launcher)

        process = subprocess.Popen(launcher, cwd = run.get_build_directory(), stdout = logfile, stderr = logfile, shell = False)

        beginfile.write("<?xml version=\"1.0\"?>\n")
        beginfile.write("<ProcessHandle Version=\"1\" Minor=\"0\">\n")
        beginfile.write("    <Process Command=\"vivado\" Owner=\"{}\" Host=\"{}\" Pid=\"{}\">\n".format(getpass.getuser(), socket.gethostname(), process.pid))
        beginfile.write("    </Process>\n")
        beginfile.write("</ProcessHandle>\n")

        process.wait()

        if process.returncode:
            os.utime(error_path, None)
        else:
            os.utime(end_path, None)

        return process.returncode
0 Kudos
Guide avrumw
Guide
6,797 Views
Registered: ‎01-23-2009

Re: Launching multiple runs with different Vivado instances

I am glad you got something to work for you.

 

However, I want to reiterate (to others that may come across this thread in the future) that this is not a supported mechanism, and is not recommended.

 

The choice of project mode vs. non-project batch mode can be a complex one to make. You need to take into account what you need to do and how you are planning to interact with the tool, and then make a choice. Once the choice is made you should follow the recommended flow for that choice.

 

For project mode, you should work only and entirely within the framework provided by the project - which means launching runs only through the runs manager. This can be done either through the GUI, or through scripts or through a combination of the two.

 

For non-project batch mode, you have more flexibility, but none of the automation provided by project mode - you remain in control of the process at all times. You still have access to all the reporting capabilities of Vivado as well as all the visualization capabilities of the GUI -  but only if you choose to do so; no reports are generated automatically - reports are either generated as a result of the script invoked to perform the processes or manually after the processes are complete. Similarly, all the visualization is available, but only if you write out checkpoint files at key points and then read them in using the GUI (or launch the GUI directly from your script, which is supported but unusual).

 

Trying to mix and match parts of the two modes is not supported, and "hacking" the project mechanism is not recommended.

 

Avrum

0 Kudos