AMD interview questions & answers

Model answer

Situation — I would use a real example from my experience, such as a disagreement between a product group prioritizing a near-term customer commitment and an engineering group emphasizing reliability work. The key stakes were not simply two teams wanting different things: an aggressive date could create quality risk, while delaying the feature could affect customer trust and a business commitment.

Task — My role was to make the trade-off visible, help stakeholders reach a decision based on shared outcomes, and ensure the teams had a plan they could execute. At AMD, I would bring the same approach while first learning the product, customer, and technical constraints of the specific organization rather than assuming every group has identical priorities.

Action

• I clarified the decision to be made, who owned it, and by when. I asked each stakeholder to state the customer or business outcome they were protecting, not just the solution they preferred.
• I brought evidence into the discussion: delivery confidence, dependencies, reliability or validation data, customer impact, and the cost of delaying either option. For hardware, software, or platform work, I would include integration and validation lead times where relevant.
• I framed viable options—for example, a reduced-scope commitment, a staged delivery, or a date change—and made the risks and reversibility of each explicit. I avoided presenting a false binary when a phased plan could protect both interests.
• I facilitated a decision with the accountable leaders, documented the rationale and guardrails, and translated it into owners, milestones, escalation triggers, and a communication plan for affected teams or customers.
• I followed up on the agreed indicators and revisited the plan if the evidence changed, rather than allowing an old compromise to persist automatically.

Result — In my real example, I would quantify the outcome using the relevant measures—for instance, whether we met the customer commitment, reduced escaped defects, or protected a critical reliability target—and explain what I learned. At AMD, I would listen closely to the people closest to customers and technology, surface trade-offs early, and align local decisions with broader business goals. The management signal is that I can advocate strongly, decide transparently, and then help the organization execute as one team.

Model answer

Situation

At a previous company, our product and platform teams were reorganized after two products merged onto a shared platform. I managed a 12-person engineering group across three workstreams, and the change affected reporting lines, ownership boundaries, and a committed customer launch. People had heard different versions of the plan, so uncertainty and delivery risk were both rising.

Task

I needed to help the team understand the new structure, retain critical expertise, and protect the launch without pretending that every decision was within my control. I also had to make sure the reorganization created clearer ownership rather than simply moving boxes on an org chart.

Action

• I first met with my director and HR partner to separate confirmed decisions from open questions. I wrote down what I could communicate, what remained uncertain, and when I would return with an update rather than speculate.
• I held a team meeting promptly, explained the business rationale and the known changes, and made space for individual concerns. I followed with one-on-ones, especially with people whose roles or reporting lines were changing.
• I mapped current responsibilities, dependencies, and on-call coverage against the proposed team boundaries. That exposed an unowned migration and a single-person operational dependency, which I escalated before the new structure went live.
• I worked with peer managers to agree on a written ownership matrix, decision rights, and escalation path. For example, we assigned one team the platform API and another the product integration, with a shared service-level objective and a named technical contact during the transition.
• I protected capacity by pausing lower-priority roadmap work, assigning transition owners, and reviewing the customer launch plan weekly. I also created a short weekly update so the team did not have to rely on rumor to learn what had changed.

Result

We completed the transition with no missed customer launch milestone, maintained on-call coverage, and closed the previously unowned migration before it became a production issue. The team pulse check improved over the following two months, though not everyone was happy with the outcome, and I learned that clarity and follow-through matter more than overly optimistic reassurance. In future reorganizations, I would bring affected engineers into the ownership design earlier and define success measures for the new structure before announcing it.

Model answer

function romanToInt(s) {
  const values = {
    I: 1,
    V: 5,
    X: 10,
    L: 50,
    C: 100,
    D: 500,
    M: 1000,
  };

  let total = 0;

  for (let i = 0; i < s.length; i++) {
    const current = values[s[i]];
    const next = i + 1 < s.length ? values[s[i + 1]] : 0;

    // A smaller value before a larger one is subtractive.
    total += current < next ? -current : current;
  }

  return total;
}

• Scan once: subtract a symbol when it is smaller than the following symbol; otherwise add it.
• Assumes the input is a valid Roman numeral, as specified.

Complexity: Time O(n); extra space O(1).

Model answer

function spiralOrder(matrix) {
  if (!matrix.length || !matrix[0].length) return [];

  const result = [];
  let top = 0;
  let bottom = matrix.length - 1;
  let left = 0;
  let right = matrix[0].length - 1;

  while (top <= bottom && left <= right) {
    // Traverse the top edge from left to right.
    for (let col = left; col <= right; col++) {
      result.push(matrix[top][col]);
    }
    top++;

    // Traverse the right edge from top to bottom.
    for (let row = top; row <= bottom; row++) {
      result.push(matrix[row][right]);
    }
    right--;

    // Traverse the bottom edge only if it remains unvisited.
    if (top <= bottom) {
      for (let col = right; col >= left; col--) {
        result.push(matrix[bottom][col]);
      }
      bottom--;
    }

    // Traverse the left edge only if it remains unvisited.
    if (left <= right) {
      for (let row = bottom; row >= top; row--) {
        result.push(matrix[row][left]);
      }
      left++;
    }
  }

  return result;
}

• Maintain inclusive top, bottom, left, and right boundaries; shrink each after traversing that edge.
• The boundary checks prevent duplicate visits for single-row or single-column inner layers.

Complexity: Time O(rows × columns); extra space O(rows × columns) for the returned array.

Model answer

function rotate(matrix) {
  const n = matrix.length;

  // Transpose across the main diagonal.
  for (let row = 0; row < n; row++) {
    for (let col = row + 1; col < n; col++) {
      [matrix[row][col], matrix[col][row]] =
        [matrix[col][row], matrix[row][col]];
    }
  }

  // Reverse each row to complete a clockwise rotation.
  for (let row = 0; row < n; row++) {
    matrix[row].reverse();
  }

  return matrix;
}

• Transposing swaps rows and columns; reversing every row turns that reflection into a 90-degree clockwise rotation.
• Mutates the square matrix in place; an empty matrix is handled naturally.

Complexity: Time O(n²); extra space O(1) beyond the in-place swaps.

Model answer

1. Requirements & scale

Functional requirements

• Acquire a named lock with a bounded lease; renew it; release it; and inspect lock state for debugging.
• Support ownership tokens, timeouts, and safe behavior when clients pause, crash, or lose network connectivity.
• Provide optional fairness and bulk operations only if a concrete workload requires them.

Non-functional requirements

• Prioritize safety: at most one valid owner may act on a protected resource at a time.
• Keep acquisition latency low and availability high, while making consistency semantics explicit.
• A lock is advisory: every protected resource must enforce fencing tokens to reject stale owners.

Assume 100,000 clients, 1 million active locks, and 20,000 lock operations/second. At roughly 1 KB per lock record, raw active state is about 1 GB; with replication and indexes, budget several GB. If the average lease is 30 seconds, renewals can dominate traffic, so clients should renew well before expiry and add jitter.

2. High-level architecture

flowchart TD
  subgraph Client[Client]
    A[Lock client library]
  end
  subgraph Edge[Edge and CDN]
    B[Authenticated endpoint]
  end
  subgraph LB[Load Balancer]
    C[Regional routing]
  end
  subgraph Services[API and Services]
    D[Lock API]
    E[Token allocator]
  end
  subgraph Cache[Cache]
    F[Optional state cache]
  end
  subgraph Stores[Datastores]
    G[Consensus metadata store]
    H[Lock records]
  end
  subgraph Queue[Message Queue]
    I[Expiry events]
  end
  subgraph Workers[Workers]
    J[Expiry and cleanup workers]
  end
  A -->|acquire renew release| B
  B -->|authenticated requests| C
  C -->|route by lock key| D
  D -->|lease transaction| G
  D -->|allocate monotonic token| E
  E -->|transactional sequence| G
  D -->|read hints only| F
  G -->|durable state| H
  G -->|expiry change events| I
  I -->|cleanup work| J
  J -->|compare and delete expired lease| G

3. API design

• POST /v1/locks/{name}:acquire: owner ID, lease duration, wait deadline, and idempotency key. Return acquired status, lease expiry, and fencing token.
• POST /v1/locks/{name}:renew: owner ID, token, and lease ID. Renew only if all match and the lease has not expired.
• POST /v1/locks/{name}:release: release conditionally using the same identity fields. Releasing twice is safe.
• GET /v1/locks/{name}: administrative inspection; do not expose this as an authorization decision for clients.

4. Data model & storage

Use a consensus-backed, strongly consistent store such as etcd or a transactional SQL database for authoritative state. A lock row contains name, owner_id, lease_id, expires_at, fencing_token, and a revision. Enforce uniqueness on name. Compare-and-swap transactions prevent two successful acquisitions. Partition by lock name, but keep each key's writes ordered by one consensus group. Persist token counters durably; a token must never be reused after failover. An in-memory cache can accelerate diagnostics, never grant ownership.

5. Deep dive

Acquisition is an atomic transaction: if no unexpired lease exists, or the stored lease has expired according to the store's authoritative time, write a fresh lease and increment the token. Otherwise return busy or wait with bounded backoff and jitter. A client receives token 42, for example, and includes it in every write to the protected resource. That resource stores the largest accepted token and rejects any lower token. If the client pauses, its lease expires, and another client receives token 43, the old client cannot resume and overwrite newer work.

sequenceDiagram
  participant C as Client
  participant L as Lock API
  participant S as Consensus store
  participant R as Protected resource
  C->>L: acquire name and lease
  L->>S: compare expiry and increment token
  S-->>L: lease granted with token
  L-->>C: lease id and token
  C->>R: write data with fencing token
  R->>R: reject token below max accepted
  C->>L: renew before expiry
  L->>S: conditional lease extension

Use server/store time for lease comparisons; client clocks are not trustworthy. Renew at roughly one-third of the lease duration with jitter, and stop protected work immediately if renewal fails. A lease expiry event is only a cleanup hint: workers must re-check expiry and revision before deleting, since a newer lease may already exist. Keep retry behavior idempotent. Bound waiting queues so a hot lock cannot exhaust service memory.

6. Scale, bottlenecks & trade-offs

Replicate consensus data across three or five failure domains. For a given lock, serialize acquisition and renewal through its authoritative partition; different lock names scale horizontally. Monitor acquisition p50/p99, contention, renew failures, expired-but-not-cleaned records, consensus quorum health, and stale-token rejections. Rate-limit noisy tenants and isolate hot keys. Strong consistency costs write latency and availability during quorum loss, but is the correct default for mutual exclusion. A cache or eventually consistent database may improve reads, but must not decide ownership. Keep leases short enough to recover from crashes, yet long enough to tolerate normal pauses; choose duration from measured pause and network-tail distributions. The critical operational contract is that callers use fencing tokens—without resource-side enforcement, an expired process can still perform stale work, and the lock service alone cannot guarantee safety.

Model answer

1. Requirements & scale

Functional requirements

• Ingest live video streams, decode and sample frames, run object detection, and return timestamped detections with confidence and object class.
• Support per-stream configuration, health status, replay or backfill where required, and delivery through APIs, events, or webhooks.
• Handle stream disconnects, model upgrades, and tenant isolation.

Non-functional requirements

• Bound end-to-end detection latency, preserve ordering within a stream where useful, and avoid losing data silently.
• Scale GPU capacity independently from ingest, apply backpressure, and meet explicit availability, privacy, and retention targets.

For an example sizing point, 5,000 streams at 2 Mbps each produce 10 Gbps ingress. Sampling each stream at 2 frames/second yields 10,000 frames/second. At 640 × 640 RGB, uncompressed input is about 1.23 MB/frame, or 12.3 GB/second internally; resize and batch near the edge of the GPU pipeline rather than persist raw frames. If each detection event averages 1 KB, output is about 10 MB/second, or 864 GB/day before compression and retention policies. GPU capacity must be benchmarked on the actual model: at 100 frames/second/GPU, 10,000 frames/second needs 100 GPUs before headroom; at 60% target utilization, plan about 167.

2. High-level architecture

flowchart TD
  subgraph Client[Client]
    A[Cameras and stream publishers]
  end
  subgraph Edge[Edge and CDN]
    B[Regional stream ingress]
    C[Decode and frame sampling]
  end
  subgraph LB[Load Balancer]
    D[Regional traffic routing]
  end
  subgraph Services[API and Services]
    E[Stream control API]
    F[Detection scheduler]
    G[GPU inference workers]
    H[Result service]
  end
  subgraph Cache[Cache]
    I[Stream and config cache]
  end
  subgraph Stores[Datastores]
    J[Metadata SQL]
    K[Event store]
    L[Object storage]
  end
  subgraph Queue[Message Queue]
    M[Frame work queue]
    N[Detection event queue]
  end
  subgraph Workers[Workers]
    O[Reconnect and retry workers]
    P[Aggregation and delivery workers]
  end
  A -->|RTSP or WebRTC video| B
  B -->|authenticated stream| C
  C -->|sampled frames| M
  E -->|configuration lookup| J
  E -->|hot configuration| I
  D -->|control requests| E
  M -->|frames and stream ids| F
  F -->|batched jobs| G
  G -->|detections| N
  N -->|durable events| K
  N -->|delivery jobs| P
  P -->|webhooks and subscriptions| H
  C -->|optional clips| L
  O -->|reconnect stream| B

3. API design

• POST /v1/streams: register stream URI, tenant, region, sampling policy, and model profile; return stream ID and status.
• PATCH /v1/streams/{id}: update configuration with versioning.
• GET /v1/streams/{id}: return health, lag, and current model version.
• GET /v1/streams/{id}/detections?from=&to=&cursor=: paginated event query.
• POST /v1/streams/{id}:stop: stop processing idempotently.
• Publish detections to a tenant-scoped event topic or webhook with event IDs and retry semantics.

4. Data model & storage

Keep stream ownership, credentials references, configuration versions, and desired state in SQL. Store short-lived frame jobs in a partitioned queue, keyed by stream ID and sequence number. Persist detections as append-only events partitioned by tenant and event time, with a secondary access path for stream/time queries. Use object storage for explicitly retained clips or audit evidence, with lifecycle expiration. Cache only configuration and routing hints. Never put camera credentials in logs or event payloads; use a secrets manager and scoped access.

5. Deep dive

The crux is capacity-aware inference scheduling. Ingest should decode and sample close to the stream endpoint, attach stream ID, monotonically increasing frame sequence, timestamp, model version, and tenant priority, then enqueue a compact frame reference or payload. The scheduler batches compatible frames by model and input shape to improve GPU throughput, while imposing a maximum batch wait (for example, 20 ms) to protect latency. It tracks queue age and available GPU slots; when demand exceeds capacity, it first lowers sampling frequency for low-priority streams or drops stale frames according to an explicit policy rather than letting latency grow without bound. For real-time detection, the newest frame is often more valuable than every queued frame.

sequenceDiagram
  participant C as Camera
  participant I as Ingest
  participant Q as Frame queue
  participant S as Scheduler
  participant G as GPU worker
  participant E as Event store
  C->>I: video stream
  I->>I: decode and sample frame
  I->>Q: frame with stream and sequence
  Q->>S: deliver frame job
  S->>S: batch by model and deadline
  S->>G: inference batch
  G-->>S: boxes classes and scores
  S->>E: persist idempotent detection events

Use event IDs derived from stream ID, frame sequence, and model version to deduplicate retries. Preserve ordering only where the product needs it; inference itself can be parallel, with results reordered or marked by timestamp downstream. Model rollout should be versioned and canary-based: compare latency, throughput, and detection quality on a small stream cohort before expanding. Keep a rollback path to the prior model artifact.

6. Scale, bottlenecks & trade-offs

Partition ingress and queues by region and stream ID to reduce cross-region traffic and maintain per-stream affinity. Autoscale GPU workers on queue age and utilization, not CPU alone; reserve capacity for high-priority tenants and fail over carefully because moving a live stream can cause reconnect storms. Replicate metadata and event storage across zones; define regional recovery objectives for raw video versus derived detections. Key dashboards include active streams, reconnect rate, sampled frames/sec, queue age, dropped-frame rate, GPU utilization, inference p50/p99, end-to-end detection delay, event delivery lag, and per-model

Model answer

I would first determine whether the violation is static IR drop from sustained current and resistance, or dynamic droop from switching activity and transient response. Then I would use the voltage map and current-density data to identify the specific weak region rather than strengthen the entire grid indiscriminately.

1. Fix the power path: Add or widen power straps, increase mesh density, add vias between power layers, and improve connections to rings, bumps, or package feeds. Address local bottlenecks and via resistance first.
2. Reduce local demand: Spread high-current cells or hotspots, reduce congestion that prevents power routing, and review placement of high-activity blocks. If appropriate, use power gating or activity reduction without violating performance or functional requirements.
3. Improve transient response: Add or reposition decoupling capacitors near the load and review package/board impedance. Validate across realistic switching patterns; decaps do not solve sustained resistive drop.
4. Check design constraints: Confirm power intent, voltage domains, source connections, current assumptions, and the quality of activity inputs. A bad constraint or activity model can produce misleading results.
5. Re-run signoff: Check static and vector-aware dynamic IR, electromigration, timing at the reduced voltage, and all relevant corners. Compare worst drop, affected area, current density, and timing margin before and after.

flowchart TD
    A["Run power integrity analysis"] --> B["Classify static drop or dynamic droop"]
    B --> C["Locate weak grid or current hotspot"]
    C --> D["Strengthen PDN and via paths"]
    C --> E["Reduce or spread local demand"]
    C --> F["Improve decoupling and source impedance"]
    D --> G["Re-run IR, EM, and timing signoff"]
    E --> G
    F --> G
    G --> H["Accept or iterate"]

The trade-off is that stronger grids and more decaps consume routing and area, may increase congestion, and can affect clocking or signal routes. I would prioritize targeted changes and verify that the fix does not create new EM, timing, or congestion problems.

Model answer

At post-route, I would use incremental timing ECOs and preserve the existing placement as much as possible. First, I would identify the failing paths using extracted parasitics and confirm whether the dominant issue is cell delay, net delay, or a setup/hold interaction.

1. Rank the paths: Group violations by endpoint, path topology, and common nets. Fix shared causes before applying many per-path edits.
2. Prefer low-disruption cell changes: Upsize a critical driver, swap to a faster equivalent-footprint cell or lower-Vt option where allowed, or use a spare cell. Keep changes within existing legal sites to avoid broad ECO placement.
3. Optimize the routed net: Reroute critical nets with shorter paths, better layer assignment, fewer vias, or improved buffering. Use route ECO and incremental extraction so the optimization reflects actual parasitics.
4. Use buffers selectively: Insert a buffer only where there is a legal site or spare-cell location and where it improves the path. Check that added load, wire length, and hold impact do not erase the gain.
5. Recheck neighboring constraints: Re-run setup and hold across corners, plus signal integrity, slew, capacitance, and design-rule checks. A setup fix can create hold violations or disturb a shared net.

flowchart TD
    A["Run extracted post-route STA"] --> B["Classify cell delay versus net delay"]
    B --> C["Select minimal ECO"]
    C --> D["Resize or swap equivalent-footprint cell"]
    C --> E["Reroute critical net or promote layer"]
    C --> F["Use spare cell or legal whitespace buffer"]
    D --> G["Incremental route and extraction"]
    E --> G
    F --> G
    G --> H["Check setup, hold, SI, and DRC"]
    H --> I["Sign off or iterate"]

I would avoid broad placement optimization, large logic restructuring, and changes that require moving many cells unless smaller ECOs cannot meet timing. The goal is to improve the failing paths while controlling collateral changes, then validate the result with the same signoff views and constraints used to identify the issue.

Model answer

Core concepts

• Combinational logic computes outputs from current inputs; examples include muxes, decoders, and arithmetic logic. It should describe every output on every path to avoid unintended latches.
• Sequential logic stores state in flip-flops or latches. Clock edges, reset behavior, and setup/hold requirements define when state changes.
• RTL describes hardware behavior at the register-transfer level. Synthesis maps synthesizable RTL into gates and registers; it does not execute like software.
• Timing is constrained by clock period, input/output delays, and exceptions. For a register-to-register setup path, the data must arrive before the capture edge; hold checks require it not to arrive too early.

RTL coding practices

• Use nonblocking assignments (<=) for clocked sequential logic and blocking assignments (=) for combinational logic. This avoids simulation-order surprises and expresses the intended hardware clearly.
• Assign defaults in combinational processes, then override them in branches. Incomplete assignments can infer latches.
• Make reset polarity and synchronous/asynchronous behavior explicit. Keep reset strategy consistent with the design and library.
• Write FSMs with explicit state registers and next-state logic; choose state encoding based on timing, area, and power needs.
• Avoid unsized constants, unintended signed arithmetic, and ambiguous widths. Review synthesized hardware, not just RTL appearance.
• Treat clock-domain crossings (CDC) and reset-domain crossings explicitly. Use synchronizers or recognized protocols; do not assume ordinary RTL simulation proves metastability safety.

Design flow

flowchart LR
  A[Specification] --> B[RTL] --> C[Simulation and formal checks]
  C --> D[Synthesis] --> E[Static timing and physical design]
  E --> F[Signoff]
  F -->|Issue found| B

A strong answer connects RTL choices to the resulting hardware, verifies behavior with simulation or formal methods, and checks timing, CDC, reset, and synthesis results before signoff.

Model answer

I would first identify whether the violation is static IR drop, dynamic droop, or both, then fix the dominant cause rather than applying a generic decap or routing change.

1. Diagnose and prioritize - Run power-integrity analysis with realistic activity, package models, and operating corners. - Map worst voltage drop to cells, current hotspots, power-grid segments, macros, and time windows. - Check both peak drop and duration; correlate failing regions with timing or functional risk.
2. Reduce delivery-path impedance - Widen or add power straps, use higher metal layers where appropriate, and add vias between grid layers. - Improve macro power access and reduce long, resistive local branches. - Strengthen package or bump delivery if the bottleneck is off-chip rather than on-chip.
3. Reduce local transient demand - Add or redistribute decoupling capacitance near high-switching loads, while checking area, leakage, resonance, and routing impact. - Spread high-current cells or shift activity in time where architecture and timing allow. - Use clock gating or power management to avoid unnecessary switching.
4. Re-verify the fix - Re-run static and dynamic IR, electromigration, and timing checks. A grid change can affect routing and capacitance; decaps also consume area and may alter local congestion.

The key trade-off is physical cost versus voltage margin: grid reinforcement consumes routing resources, decaps consume placement area, and activity shaping can affect latency or throughput. I would set an explicit voltage-drop target and confirm it across process, voltage, temperature, activity, and package corners.

Model answer

VDD degrades at a circuit node when the delivered supply is lower than the source or nominal rail. The main mechanism is voltage drop across the impedance between the source and the load:

• Static IR drop: average load current flowing through resistance in the power grid, package, vias, and connections. Approximation: ΔV = I × R.
• Dynamic droop: a rapid current change interacting with grid/package inductance and capacitance. A useful approximation is ΔV ≈ L × di/dt, alongside resistive drop.
• Localized high demand: dense switching, clock-tree activity, simultaneous memory or accelerator bursts, or concentrated placement can create hotspots even when chip-average current is acceptable.
• Weak delivery network: long or narrow rails, insufficient vias, poor macro power access, package limitations, or inadequate decoupling increase effective impedance.
• Operating and design conditions: low supply settings, high temperature, process variation, and aging-related increases in resistance or current demand can reduce voltage margin.

I would distinguish a true supply-network issue from a measurement or analysis artifact: compare source and on-die voltages, inspect static and vector-based dynamic IR maps, correlate droop with switching activity, and check voltage at the affected cells. The impact is reduced noise margin and slower cell delay; severe droop can cause setup failures, functional errors, or reliability problems.

Model answer

VDD at a cell can fall below the nominal supply when the power-delivery path cannot maintain voltage under load. A useful first-order model is Vdie ≈ Vsource − I·R − L·di/dt: resistive loss causes static drop, while inductance and rapid current changes cause transient droop.

• High or concentrated current: Many cells switching together, a localized compute hotspot, or a power-up surge increases current demand.
• High-resistance PDN: Long or narrow power wires, sparse straps, too few vias, weak connections between metal layers, or a distant supply connection increase resistance.
• Poor transient support: Insufficient or poorly placed decoupling capacitance, high package/board inductance, or fast load steps can cause dynamic droop.
• Operating conditions: Higher temperature increases conductor resistance; process variation, supply tolerance, and low input voltage can reduce margin.
• Aging and reliability effects: Electromigration can damage power conductors over time, increasing resistance and potentially causing local voltage degradation.

I would distinguish static IR drop from dynamic droop, then check the worst locations and operating scenarios with power-integrity analysis. Excessive drop can reduce timing margin, cause functional failures, or accelerate reliability problems.

Model answer

Static CMOS commonly implements an OR as a NOR gate followed by an inverter. The first stage has series PMOS transistors in its pull-up network and parallel NMOS transistors in its pull-down network. The inverter restores the polarity.

                 VDD
                  |
              P1 (gate=A)
                  |
              P2 (gate=B)
                  |
                  X  --------> inverter --------> Y = A OR B
                 / \
      N1 (gate=A)   N2 (gate=B)
            |           |
           GND         GND

• If either input is high, its NMOS conducts and pulls X low; the inverter makes Y high.
• Only when both inputs are low do both series PMOS conduct, pulling X high; the inverter makes Y low.
• Therefore X = NOT(A OR B) and Y = A OR B.

The two-stage implementation costs more area and delay than a single NOR gate, but it provides the required OR polarity. In practice, the library may provide an OR cell or synthesis may choose a different equivalent implementation based on timing and area.

Model answer

I would treat this as a constrained post-route ECO: improve the failing path while preserving placement, then prove that the change does not create new setup, hold, SI, or power-integrity problems.

1. Classify the violation. Use signoff STA with extracted parasitics to identify the exact startpoint, endpoint, path group, corner, and whether the issue is setup or hold. Separate cell delay from net delay and check SI/noise effects. Avoid optimizing a path that is not the actual worst-case cause.
2. Prefer changes that preserve the existing placement. For setup paths, consider a same-footprint stronger drive or lower-threshold cell swap, if the library and leakage budget allow it. Reduce excessive fanout using an already placed spare buffer, or optimize the routed net through rerouting, layer promotion, or shorter legal routing. A cell swap may still change pin geometry, so re-extract parasitics.
3. Use spare cells for logic changes. If a buffer or inverter is needed, use a pre-placed, powered spare cell and connect it with an ECO route. This avoids running ECO placement. Check spare-cell availability, legal connectivity, and whether the added stage worsens setup or hold on neighboring paths.
4. Make only evidence-based clock changes. Useful-skew or clock-tree edits can improve one setup path but often move the problem to other endpoints or create hold violations. Consider them only when the clock network is the bottleneck and the wider impact is understood.
5. Close the loop. Re-route the affected nets, extract parasitics, and rerun full signoff STA across corners, including hold, SI, and transition/capacitance checks. Compare the ECO against the baseline and inspect all paths affected by changed cells or nets.

The practical trade-off is that the least disruptive fix may not be the largest timing improvement. I would try same-site cell swaps and route optimization first, use spare-cell ECOs when necessary, and escalate to broader placement or logic changes only if the fixed-placement options cannot meet timing safely.

Model answer

1. Frame the decision and workload. I would not treat fine-grained P-states as universally better. I would define the decision per power domain and workload: CPU cores or clusters, GPU, display, video encode/decode, and shared memory or interconnect. First establish whether a state is a performance operating point, a voltage/frequency operating point, or a subsystem-level configuration that also changes clocks, voltage rails, or power gating. Then collect representative traces: interactive bursts, sustained compute, media playback, concurrent CPU/GPU work, idle-to-active transitions, and thermal or battery-limited operation.
2. Measure the right outcomes. Compare a few coarse states against a finer set under identical workloads and thermal conditions. Measure energy per completed task, average and peak power, throughput, frame-time or audio/video deadlines, p50/p95/p99 response latency, transition latency, and time spent in each state. Include energy overhead from transitions and the impact on neighboring domains. For a workload, a useful first-order metric is energy = integral(power over time); compare energy per frame, inference, or encoded minute, not just instantaneous power. Also measure stability: oscillation between states, missed deadlines, and time to recover after a thermal limit.
3. Analyze granularity and coupling. Fine-grained states can match demand more closely and reduce energy at intermediate loads, but they add firmware/driver policy complexity, more transitions, validation combinations, and potentially more voltage-rail or clock-domain coordination. Coarse states simplify characterization and can improve predictability, but may overprovision power or force a large performance jump. I would build a Pareto curve of energy versus latency/throughput and identify whether additional states produce meaningful gains beyond measurement noise. Check whether domains share voltage rails, memory bandwidth, thermal limits, or synchronization requirements: nominally independent state changes can create system-level regressions.
4. Recommend by subsystem, not by ideology. A CPU cluster often benefits from several operating points because load changes quickly and DVFS support is mature; per-core control is worthwhile only if the hardware and scheduler can exploit it without excessive coordination. A GPU may need a smaller set of well-characterized states if work arrives in bursts or memory-bound workloads make clock increases ineffective. Multimedia engines with predictable real-time modes may be better served by a few validated states tied to codec, resolution, and frame rate, plus a low-power idle state. I would use fine granularity only where measured marginal energy or performance benefit justifies the transition and validation cost.
5. Validate and decide incrementally. I would run controlled A/B experiments across silicon and temperature variation, with fixed workloads, repeatable traces, and sufficient samples for confidence intervals. Test concurrent workloads, suspend/resume, thermal throttling, and worst-case transitions—not only isolated benchmarks. Roll out behind a firmware or driver policy flag, canary on device cohorts, and preserve a known-good fallback. Define guardrails such as no increase in missed frame deadlines, bounded p99 transition latency, and no regression in battery energy per task. Monitor performance, power, thermal events, and state-transition churn in the field.

flowchart TD
  A[Define workloads and constraints] --> B[Measure coarse baseline]
  B --> C[Prototype candidate state tables]
  C --> D[Evaluate energy and performance Pareto]
  D --> E{Benefit exceeds complexity and risk?}
  E -->|Yes| F[Validate interactions and silicon variation]
  E -->|No| G[Keep coarse states]
  F --> H[Canary policy rollout]
  H --> I[Monitor guardrails and regressions]
  I -->|Stable| J[Expand rollout]
  I -->|Regression| K[Fallback and retune]

At Staff level, I would make this a cross-functional decision with silicon, firmware, OS, workload, and product teams. I would publish the evidence and assumptions, name an owner for the state table and policy, and ensure the power/performance win is visible to users rather than only in a microbenchmark. The recommendation should include the operating points to ship, the workloads where they matter, the guardrails, and the criteria for revisiting the decision.