qed::run_as_batch (::quartus::qed)
The following table displays information for the qed::run_as_batch Tcl command:
Tcl Package and Version |
Belongs to ::quartus::qed 1.0 |
|||
Syntax | qed::run_as_batch [-h | -help] [-long_help] [-list_of_commands <list_of_commands> ] <object> | |||
Arguments | -h | -help | Short help | ||
-long_help | Long help with examples and possible return values | |||
-list_of_commands <list_of_commands> | List of partial ::qed commands to run as a batch on the object. Omit specifying the object argument from each command, since the object provided to run_as_batch will be used. | |||
<object> | Identifier associated with the object, must be unique | |||
Description |
Some ::qed commands require an interactive connection in order to run (for example, qed::run_command, qed::generate_report). In the event that the compute resources available cannot support enough simultaneous connections for each disconnected project within a group, this command will serialize the work across each project instead. For example, if the max_jobs_per_spec_type property of the workspace (configured via qed::configure_max_jobs_for_compute_spec_type) is currently set to 2 and there is a group of 6 projects to work on, provide qed::run_as_batch with the group and the list of commands to run on the group and it will automatically launch connections, two at a time, issue all the work to each project, track the return values, then disconnect each pair and move on to the next. Once the list of commands has executed properly across all projects in the group, the return value will be assembled as a list of dictionaries corresponding to, and in the same order as, each command in the -list_of_commands argument. Some corner cases to keep in mind are: * If the group currently has some number of disconnected projects but the configured compute resources can support enough interactive connections for each of them, the projects will remain connected after qed::run_as_batch completes (rather than being disconnected). * If qed::run_as_batch is invoked on a project, it will execute as if it was a group of size 1. This is not very different than running the commands on the project in a simple foreach loop and collecting the results, though possibly more convenient. * Each command in the -list_of_commands cannot include either an object to target or the -async flag. The results of qed::run_as_batch will always be fully resolved by the time it returns. |
|||
Example Usage |
# Inside an opened workspace with a local compute specification: # Group "both_projects" has 2 projects "project_A" and "project_B" qed::create_object -type project project_A -qpf_path /file/path/to/A/project.qpf qed::create_object -type project project_B -qpf_path /file/path/to/B/project.qpf qed::create_object -type group both_projects -projects {project_A project_B} # This will run serially across each project and return the results in order. # Each project will be disconnected upon completion. qed::configure_max_jobs_for_compute_spec_type -spec_type local -max_jobs 1 qed::run_as_batch both_projects -list_of_commands { {qed::generate_report -type run_and_extract_report_timing -arguments "-npaths 100 -from_clock sys_clk"} {qed::generate_report -type create_design_closure_summary_panel} } # This will run each project in parallel and return the results in order. # Each project will be connected upon completion. qed::configure_max_jobs_for_compute_spec_type -spec_type local -max_jobs 2 qed::run_as_batch both_projects -list_of_commands { {qed::generate_report -type create_timing_summary_panels -arguments "-setup -hold -recovery -removal"} } |
|||
Return Value | Code Name | Code | String Return | |
TCL_OK | 0 | INFO: Operation successful |