You have 40 scenarios and 8 hosts. How do you run ECO efficiently?

Short Answer

Set eco_enable_more_scenarios_than_hosts (PT) to true so DMSA ECO can run with fewer hosts than scenarios. The hosts then swap scenarios in and out, which is slow, so the script has to minimise swaps: fewer merged reports, one batched remote_execute (PT) block, and change lists written from one scenario. Also check whether 40 scenarios are all needed.

Technical Explanation

• PrimeTime needs at least four available hosts for this mode, and recommends at least eight or one-fourth of the number of scenarios, whichever is larger. For 40 scenarios that is 10 hosts, so 8 is below the recommendation and runtime will suffer.
• Runtime grows linearly as available hosts decrease. The actual turnaround depends on design size, violation count, scenario type, network performance and disk space.
• Disk space is a hard requirement. The DMSA working directory must hold the session data of all scenarios, so 40 scenarios at 1 GB each need at least 40 GB there.
• Each remote_execute (PT) command costs one round of scenario swapping. Merge all setup and reporting commands into a single block instead of several small ones.
• Merged reporting commands, such as report_timing (PT) and report_analysis_coverage (PT) run from the manager, also trigger swapping. Keep manager-side reports to the minimum, for example one report_constraint -all_violators (PT).
• Write the change list from one scenario. current_scenario (PT) to one scenario, then write_changes (PT) inside remote_execute (PT), avoids another full swap; the netlist changes are the same in every scenario.
• Reduce scenarios before buying hosts. Scenarios that are dominated in every check add runtime without adding coverage. PrimeTime mode merging (create_merged_modes (PT)) can combine compatible modes, but the merged constraints must be reviewed before they are trusted.

What To Check

• Hosts available against max(8, scenarios/4).
• Free disk in the DMSA working directory against the sum of scenario session sizes.
• Number of separate remote_execute (PT) blocks and manager-side reports in the ECO script.
• Which scenarios never produce a unique worst violation and could be dropped or merged.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Ten hosts for 40 scenarios, 50 GB free for 40 GB of session data, and one merged remote_execute block per phase.
• Suspicious (illustrative): Eight hosts with six separate remote_execute blocks; turnaround is several times the full-host run.
• Hard stop: Fewer than four hosts available, or disk smaller than the total session data. The run cannot proceed.

What The Interviewer Is Testing

• Do you know the host and disk requirements for scenario swapping?
• Understanding what triggers a swap and how to script around it.
• Questioning the scenario count before asking for hardware.

Follow-up Question & Model Response

"Why write changes from only one scenario?"

Candidate Model Response: In DMSA the netlist is shared: a netlist edit must be possible in all scenarios before it is committed to any of them, so every scenario holds the same changes. Writing the change list from one scenario gives the same file as writing from all of them. With fewer hosts than scenarios, asking every scenario to write would force another round of swapping for no new information.