What can RedHawk Fusion in ICC2 not do that standalone RedHawk signoff can?

Short Answer

RedHawk Fusion is built for fast in-design rail analysis, not for every signoff feature. The ICC2 guide states it does not support hierarchical analysis or dynamic analysis with lumped or SPICE packages, analyses only the current scenario of an MCMM design by default, and does not support signal EM or inrush current analysis. Some signoff features can be enabled in ICC2 with RedHawk signoff licenses; anything outside that list needs standalone RedHawk.

Technical Explanation

• Hierarchical analysis is not supported in Fusion. Full-chip signoff with block models, the usual way to handle very large designs, runs in standalone RedHawk.
• Dynamic analysis with lumped or SPICE package models is not supported by default. Fusion taps are ideal voltage sources, so without a package model the result leaves out package resistance and inductance.
• With RedHawk signoff licenses you can set rail.allow_redhawk_license_checkout (ICC2) to true (default off) and pass the settings through a GSR or script file. The guide lists features such as dynamic analysis with custom macro models, dynamic analysis with package models, and analysis with RTL-level VCD files. Features not on the list run only in standalone RedHawk.
• Signal EM and inrush current analysis are not supported by either Fusion flavour. Power-gating wake-up analysis with perform analysis -lowpower (RH) therefore needs standalone RedHawk and an Ansys license.
• Only the current design scenario is analysed by default. rail.scenario_name (ICC2) picks a different one, and rail scenarios created with create_rail_scenario (ICC2) run several.
• RedHawk-SC Fusion has its own limits: -min_path_resistance, -effective_resistance and -check_missing_via work only together with -voltage_drop (ICC2), and -extra_gsr_option_file, -multiple_script_files and -submit_to_other_machines (ICC2) are not supported.
• analyze_rail -script_only (ICC2) writes the GSR, generated LEF, DEF, SPEF and STA files and the run script without running, a practical bridge to a standalone signoff run.

What To Check

• Which signoff features the project requires: hierarchy, package model, inrush, signal EM.
• Whether the Fusion runs covered every required scenario, not just the current one.
• Which Fusion flavour is in use and whether the options used are supported in it.
• That standalone and Fusion runs share the same tech file, libraries and taps.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Fusion used for daily in-design checks; one standalone RedHawk signoff run per tapeout with package model, all scenarios and ramp-up analysis.
• Suspicious (illustrative): Signoff claimed from Fusion runs with ideal taps and only the current scenario analysed.
• Hard stop: A power-gated design signed off with no inrush analysis, or an option used that the active Fusion flavour does not support.

What The Interviewer Is Testing

• Knowledge of the documented Fusion limits, not a guess.
• Awareness of the license switch and that it defaults off.
• Separating RedHawk Fusion and RedHawk-SC Fusion option support.

Follow-up Question & Model Response

"If Fusion cannot do signoff on its own, why use it at all?"

Candidate Model Response: Because it runs inside the implementation database, early and often. After placement you can find missing vias, weak grid regions and IR hotspots before detail routing, and after routing you can drive IR-aware placement and optimization with the same data. Finding a grid problem at placement costs an afternoon, while finding it in standalone signoff after chip finishing costs a routing iteration. Fusion narrows the problem so the standalone run confirms rather than discovers.