UPF: Add -supply option to create_power_domain

[Waleed99i]

This PR adds support for the -supply option in the create_power_domain command in the UPF flow.

Summary

The create_power_domain command is extended to accept an optional -supply argument, allowing users to associate a supply set with a power domain during creation.Resolving issue #5617

Changes

• Updated Tcl interface to parse -supply argument in create_power_domain
• Added SWIG binding update_power_domain_supply_cmd
• Implemented update_power_domain_supply in C++ to store the mapping
• Maintained existing design pattern: create → update (no changes to core create function)

Implementation Details

• Supply information is currently stored in a UPF-layer mapping (std::unordered_map<std::string, std::string>) since dbPowerDomain does not yet support supply attributes
• This keeps the change non-intrusive and avoids modifying the OpenDB schema

Example Usage

create_power_domain PD1 -supply ss_GNDD_VDDD

Notes

• This PR focuses on parsing and storing supply association
• Integration with OpenDB can be extended in future once native support is available

Impact

• Improves UPF command coverage
• Enables more complete power intent specification in OpenROAD
• Keeps implementation consistent with existing UPF command structure

[gemini-code-assist]

Code Review

This pull request introduces the ability to associate a supply with a power domain by adding the update_power_domain_supply function and updating the create_power_domain TCL command. Review feedback identifies a logic error where the code incorrectly attempts to create a domain instead of finding it to verify existence, a design issue regarding the use of global static maps for state storage which should be replaced with database properties for proper scoping, and the redundant redefinition of the TCL procedure instead of modifying the existing implementation.

[gemini-code-assist]

The function update_power_domain_supply incorrectly uses odb::dbPowerDomain::create to check for the existence of a power domain. In OpenDB, create returns nullptr if an object with the same name already exists. Consequently, this function will always fail when called on an existing domain. It should use block->findPowerDomain(name.c_str()) instead. Additionally, unexpected failures should be logged as errors rather than warnings to ensure critical failure messages are not missed by the user.

Suggested change

	if (odb::dbPowerDomain::create(block, name.c_str()) == nullptr) {
	logger->warn(utl::UPF, 62,
	"Power domain {} not found",
	name);
	return false;
	}
	if (block->findPowerDomain(name.c_str()) == nullptr) {
	logger->error(utl::UPF, 62,
	"Power domain {} not found",
	name);
	return false;
	}

References

1. Unexpected failures should be logged as an error, not a warning, to ensure critical failure messages are not missed by the user.

[gemini-code-assist]

Using a static std::unordered_map for power domain supplies introduces global state that persists across different designs and does not account for multiple blocks. If two different blocks have power domains with the same name, their supply associations will collide. Consider using odb::dbStringProperty to attach the supply information directly to the odb::dbPowerDomain object. This ensures the data is correctly scoped to the block and design, avoiding state leaks between sessions and ensuring correct behavior when multiple designs are active.

References

1. To ensure the correct design context is used, state should be properly scoped to the design or block, especially when multiple designs may be active.

[gemini-code-assist]

The create_power_domain command is being redefined here, creating a duplicate of the definition at lines 27-47. The existing definition should be updated to include the -supply option instead of adding a second one.