1. Identify the Bus and Its Driver Types

Begin with the SDA and SCL connections the design actually uses. Ask the interface owner to identify the controller, connected devices and driver behavior on each side. Keep the voltage-domain labels beside that topology. A board may need bidirectional signaling, but that word alone does not describe how its electrical connections are driven.

TI's PCA9306 documentation describes bidirectional I2C translation and open-drain application context without a direction pin. It is a specific example, rather than a rule that every two-way logic translator behaves the same way. Use the candidate's own functional description to establish the topology that purchasing is being asked to support.

If an existing schematic uses a push-pull connection, record it explicitly for engineering review. PCA9306 documentation describes conditional push-pull use, including direction or three-state constraints. Do not replace those conditions with a blanket promise or prohibition. An unknown driver type is a technical gap, not a detail to infer from the translator's package.

2. Record Translation Rails and Enable State

Record the reference and pullup rails used by the approved circuit, together with how enable is connected or controlled. Preserve their names from the schematic so the reviewer can distinguish the supply domains. This article gives no numeric wiring recommendation or universal rail-offset rule.

The PCA9306 description distinguishes its enabled connection from a disabled high-impedance state. Review the documented requirements for the exact device and the operating states the circuit needs. A desired isolation function should be written as a requirement for assessment, rather than assumed from an unrelated buffer or translator description.

Ask engineering which startup, shutdown or independently powered states require additional checks. Keep those cases attached to the circuit reference and leave their status visible. An enable pin name does not show that every unpowered or disconnected condition has been validated. The manufacturer example identifies behavior to examine; it does not establish a customer's power-domain result.

3. Keep Pullup and Bus Loading in the Comparison

Keep the existing pullups in the interface review. TI's application discussion explains their role in the open-drain configuration and addresses sizing separately. A translator's presence should not cause the purchasing requirement to lose the information about which rails and connections provide the bus's high levels.

Provide the relevant circuit and loading evidence to the responsible engineer. Suggested inputs include the approved pullup arrangement, connected devices and required bus operating mode. If those inputs are incomplete, mark the timing or electrical review pending. This guide does not select resistor values or guarantee a bus speed from a product headline.

When another translator is proposed, identify whether it changes the circuit assumptions that the existing review used. Keep a potential schematic change separate from an offer for the released part. Engineering can then decide what needs assessment instead of comparing catalogue bandwidth labels as if they answered the same system-level question.

4. Define the Candidate's Operating Boundaries

Create a topology-specific comparison with driver types, rail references, enable function and pullup/loading evidence. Link each candidate entry to the applicable document section. Where a condition is unsupported or has not been checked, retain it as an exception. The comparison should describe the bus the part must serve, not simply list alternative product names.

Preserve operating-boundary decisions with the approved code. A conditional push-pull use, an isolation requirement or a missing rail-state check should remain identifiable after procurement data is grouped into one row. Do not promote a typical application connection into a guarantee for another topology.

For an ICULTRA inquiry, identify the permitted translator and any candidate that still needs interface review. Share the relevant public references and an authorised circuit requirement where available. Keep proposed wiring or domain changes outside the confirmed purchase line until engineering accepts them. No bus measurement, resistor calculation, compatibility approval or present stock statement is provided here.

Sources and further reading

TI PCA9306 documents support the device-specific topology and application distinctions. No pullup sizing, bus timing result, numeric wiring rule or approved alternative is supplied.