What is DMSA, and why fix ECOs across all scenarios at once?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
Distributed multi-scenario analysis runs one PrimeTime manager and several workers, each worker analyzing one scenario, where a scenario is one combination of operating condition and mode. The manager sets up, hands out tasks and merges results, but does no timing analysis itself. ECOs are fixed across all scenarios together because a change that fixes setup in the slow corner can break hold in the fast corner or timing in test mode, and only a run that sees every scenario can refuse that change.
Technical Explanation
- Scenario count is operating condition sets times modes.
create_scenario(PT) names each one with-common_datascripts shared across scenarios, which go into a baseline image, and-specific_datascripts for that scenario only. - The flow is: start pt_shell with -multi_scenario, create scenarios, configure hosts with
set_host_options(PT), check them withreport_host_usage(PT), bring them online withstart_hosts(PT), pick scenarios withcurrent_session(PT), then run reports and ECOs. set_host_options(PT) takes-num_processes,-max_coresand-protocol, such as ssh, lsf or sge. One manager can control up to 256 workers.- For best runtime, match workers, scenarios in focus and CPUs. With fewer workers than scenarios, workers swap scenario images in and out, which costs time.
current_scenario(PT) narrows the command focus for interactive work, andcurrent_scenario -all(PT) restores every scenario in the session.remote_execute(PT) runs commands in the worker context. Curly braces make variables and expressions evaluate at the worker.- ECO commands at the manager check every scenario in focus. With more scenarios than hosts, set
eco_enable_more_scenarios_than_hosts(PT) to true, which needs at least four hosts.
What To Check
- Every worker ONLINE in
report_host_usage(PT). - Scenarios in the session and in command focus.
- The merged error log for per-scenario setup failures.
- Every signoff scenario present before fixing.
Command Checks & Actions
create_scenario -name func_ss -common_data {common.pt} -specific_data {func_ss.pt}Defines one scenario from shared and scenario-specific scripts.
set_host_options -name farm -num_processes 11 -max_cores 4 -protocol lsfConfigures 11 workers with 4 cores each on the farm.
report_host_usageShows host options, worker status, memory and CPU use.
start_hostsRequests the compute resources and brings workers online.
current_session {func_ss func_ff test_ss}Selects the scenarios for this session.
current_scenario -allRestores command focus to every scenario in the session.
remote_execute {update_timing}Runs the timing update in every worker.
Healthy, Suspicious & Hard-stop Results
- Healthy (illustrative): All 11 workers online, one scenario each, and a full update finishing close to the slowest single scenario.
- Suspicious (illustrative): 8 workers for 24 scenarios, so every
remote_execute(PT) swaps images and runtime triples. - Hard stop: A signoff scenario missing from the session. No ECO from that run can honour it.
Common Mistake
The Trap: Fixing hold in a standalone fast-corner PT session and setup in a separate slow-corner session. Each run is blind to the other, so setup fixes reopen hold paths and hold buffers eat setup margin, and the loop runs four times instead of once.
What The Interviewer Is Testing
- Manager versus worker roles, and session versus command focus.
- Why ECOs need every scenario in one run.
- Can the candidate size hosts sensibly against scenarios?
Follow-up Question & Model Response
"What happens if you have more scenarios than hosts?"
Candidate Model Response: Workers swap scenarios in and out, saving a current image to disk each time, which costs runtime. For ECO fixing you set eco_enable_more_scenarios_than_hosts (PT) to true. The PT UG requires at least four hosts and recommends at least eight or a quarter of the scenario count, whichever is larger, plus enough disk for every scenario's session. Merging remote_execute (PT) blocks and cutting down merged reports reduces the swapping.
Practical Example
Tapeout Scenario: A block has 3 modes and 6 corners, 18 scenarios, of which 11 matter for signoff (illustrative). The team runs 11 workers with 4 cores each, one scenario per worker. A full update takes 50 minutes, close to the slowest scenario at 46. fix_eco_timing -type hold (PT) at the manager fixes 230 fast-corner hold violations while checking setup in all 11 scenarios, and the merged report afterwards shows zero new setup violations.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
Continue practising