# 2025 年[「資訊科技產業專案設計」](https://hackmd.io/@sysprog/info2025-homework3)作業 3
## 相關領域
數位IC設計 數位IC驗證 實體設計

## [履歷 (Resume)](https://drive.google.com/file/d/1DXPddHXwvcHQM972ncsP7P6aOijWsG2G/view?usp=sharing)

## 工作描述 (JD)
:::info
#### 高通 Qualcomm: High-Speed Interface Micro-Architect & RTL Engineer
\*博通、輝達、聯發科也有較多類似職缺

|要求|自我評估|
|-|-|
|**SerDes** / DDR / Die-to-die / ADC / DAC 等 Mixed-Signal IP 的數位邏輯 |$\times$:沒有課可以修，可能要靠實習或 certificate|
|Microarchitecture (not only RTL)|$$\checkmark$$|
|ASIC Flow 工具|$\checkmark$: 數位設計部分</br>$\times$: 實體及類比部分|

:::
:::info
#### 瑞昱：高效能運算(HPC)前端設計資深工程師
|要求|自我評估|
|-|-|
|DFT經驗|$$\times$$: 可能要在未來的課程 projects 中強調可測試的部分|
|Low-power design|$\times$: 可以修課|
:::
:::info
#### 輝達 NVIDIA: Senior ASIC Design Engineer, Clocks
|要求|自我評估|
|-|-|
|英語能力|$\checkmark$: 聽讀</br>$\times$: 說寫，需要有證書|
|Script Languages|$\checkmark$ tcl|
|製程的課題 (sub-micron silicon issues like noise, cross-talk, and OCV effects)|$\times$: 需要「xx半導體xx製程」等相關課程|
:::
## 列出面試題目

### 問答
|Interviewer|Interviewee|
|-|-|
|請說明你對 IC 設計流程的理解？|IC 設計流程可以分成前端與後端兩部分。前端是從 RTL、模擬驗證、Lint/CDC，到合成為止，主要確保功能正確、架構清楚、邏輯能被實現；後端則負責 floorplan、placement、routing、CTS、STA 與實體檢查，要確保同一份邏輯在實體晶片上能跑得動、符合 timing、也符合design rules。我過去在做 CPU/SoC 相關設計時，常會把前後端的 timing 結果對照，理解為什麼 RTL 的某些結構特別容易成為 critical path，這也是我覺得前後端必須互相理解的原因。|
|D flip-flop 的 hold time 和 setup time 是什麼？|Setup time 是資料在 clock edge 前需要穩定的時間，而 hold time 是 clock edge 之後資料不能太快變化的時間。實際上 setup 通常在較長的 datapath 看到，而 hold 常出現在較短的datapath 或 clock skew 特別明顯的位置。我過去遇過某些 CDC 的 handshake，在跑 RTL 正常，但在高頻率 post-sim 時會報 error，最後發現就是由於 hold violation 與 skew 共同造成 jitter。|
|請解釋 Cache 的運作原理，以及 Write Through 與 Write Back 的差異？|Cache 本質上就是 CPU 與 DRAM 之間的高速緩衝，透過 locality 來降低記憶體存取延遲。Write Through 每次寫都會觸發後端存取，穩定但效能明顯不如 Write Back；Write Back 則只在 eviction 時寫回 main memory，因此吞吐量比較高，但需要管理 dirty bit，也比較容易遇到 coherency 行為。|
|你如何處理跨部門衝突？|我處理跨部門衝突的方式是客觀看待問題。以前在整合高頻接口時，常會看到設計、驗證、後端都站在自己的角度講 timing 或 latency，我通常會準備相關資料：實際波形、STA path、PPA 數據、simulation log 等，先客觀看問題。|
|遇到不熟領域（像封裝）你如何補強？|我補強新領域的方式是先有一張心智圖。像是研究封裝時，我會先掌握最核心的框架，例如 routing 限制、差分阻抗、crosstalk 等，再針對自己會實際遇到的情境做深入，例如了解 SerDes channel 的 loss、package trace 的 RC、lane 間 coupling 的來源與 mitigation 方法。我也會快速看 application note 和 vendor guide，必要時請教有經驗的同事。|
|你 debug 過最困難的問題是什麼？|我遇過最困難的問題，是一個 CDC 的資料傳輸在高速下報了錯誤，但 RTL 模擬完全看不到，post-layout 模擬也不明顯。我把問題拆成 timing、CDC、protocol 三個角度，逐一排除：先用 STA 找出 hold 風險路徑，再用 formal 驗證 handshake 是否可能產生 race condition，最後才發現是由於某一 corner 的 skew 偏移，使 valid/ready 在 clock boundary 上產生 race condition。後來重新插入 synchronizer 並調整 retiming 自動化後才完全解決。我才知道複雜問題通常是很多細小偏差所導致。|
|你有沒有提升流程自動化的經驗？|有。在整合與驗證流程中，我常看到一些手動操作非常容易出錯，例如整理 regression log、合併 waveform、跑 lint 或產生 testlist，所以我會先觀察整個流程的 pattern，再把流程拆成可以自動化的部分，最後用 Python 或 TCL 自動化。後來把 regression 結果統一輸出成結構化表格，讓設計與 DV 都能快速定位問題。|