本人目前大三升大四，電子相關科系，目前在IC公司暑期實習。在連被電三周後，整理了一些觀察給同學參考。

學校 (學界)

學校接以 RTL 為主，其餘合成和 backend 都是偏公式化行為，僅有驗證用途。依照使用場合又可以分為以下幾種

1. 課堂

以我修過的IC課為例，學校除了基本硬體架構與觀念外 (加法、乘法、計數器等)，作業方面從 gate level 教起，要求我們用 single bit 的 and, or, nand, xor, FF 等等邏輯閘來寫一些簡單的排序邏輯與除法器，一方面熟悉硬體思維一方面學習 verilog 。整堂課雖名為 IC design ，但連 testbench 都不需要自己寫。

2. 實驗

實驗課指的是上課量少，且多以實作、報告等形式為主的課程。目前筆者修過兩門實驗課，分別以 FPGA 與 ASIC 為載體。
前者在三周教完 RTL 與 Qsys，再經過三次如錄音器等作業後，便放牛吃草讓我們自主設計。最終我們用 fpga 完成用人聲的音高與音量控制的音樂遊戲，強一點的組有做類似立體視差或物件辨識等主題。結論來說確實對於 FPGA 的 DSP 、 RAM 與影像傳輸有一定程度的認識，也對 FFT 等演算法的硬體實踐有較清晰的了解，但對於 synthesis 以後的 design flow 就毫無涉獵了。
後者則是完整從 RTL 一直到 TSMI 晶片下線申請，我們這組以一個新的 GCN 架構做硬體實踐，從 spec 到 scheduler 的設計花了相當多時間，驗證也花了好幾周，而合成與 APR 卻只藉由打幾行講義上的指令就完成，因此僅大概知道指令控制的是甚麼數值，但對這些數值為何如此設定卻完全不了解。

3. 專題

兩次專題我都做與 AI 硬體加速有關，第一次是實踐論文上的低精度的 MAC 與 process element，僅完成 RTL 與輸入給定的指令完成合成。弟二次專題則是研究前一學期各種 ML 架構在低精度下的表現，僅做到軟體模擬。

總結

就學校教育而言，design flow 為軟體模擬 -> RTL -> synthesis -> APR -> DRC/LVS，並在每個步驟後都需要進行驗證。其中學生叫需要注意的便是 RTL 與 testbench，其中 RTL 是功能導向，且 PPA 中大部分只在乎 performance 的部分， testbench 則是一套用到底，其餘都是制式化的操作。
這陣子為了研究一個通訊相關的硬體演算法，翻了十幾篇 IEEE 的論文，在與主管報告時才驚覺學界與業界的落差。學界講求的是創意的發想，發表論文的核心思想是知識共享。學界以無用之學為最高境界，動機是對一個概念的好齊心與熱情，因此往往會設想一個比較理想的情境與探究比較特殊的情況，而業界要應對各種 spec　和製程限制，因此這些論文提到的演算法勢必喪失一些工業性的實用性與泛用度。且學界論文大部分頂多使用 fpga 進行模擬，因此不會分析 power。

公司（業界）

這部分先整理被問到一些我從沒思考過的問題，讓我開始思考學界跟業界的差異。

1. CTS 調錯會出甚麼問題

這是第一個面對的問題，就如前面提到的，學校教育只是把 CTS 當一個一步到位的指令，因此在該周研究 APR 時我僅研究了公司的 script 並大致報告了整體流程，與各指令再做甚麼事。此時主管的這個問題讓我發現我並沒有仔細想過 CTS 的重要性與實際價值，只在乎怎麼使用他，因此最後只說了平衡各個 FF 接收到的 clock。
再加上聽學長聊的DCG，我意識到我對包含合成的所有 design tool 都不太了解。

2. 估計 tape-out power

當時在報告論文整理時，由於該主題大部分論文只在乎 area ，更甚者只在乎乘法器的個數，因此報告時就被質疑一些做法對 power 並沒有好處。雖然 PPA 對 ic design 都很重要，但 area 與 performance 都需要到一個標準就好，且由於 spec 都已經確立，因此往下緊縮也對產品不會有甚麼好處。反觀 power 則是一個很重要的戰場，實際省多少能直接反映在產品上。此外過去在學校僅觀察合成完的 power 結果，但在未經 routing 的 power 相當不准，因此如何評估 tape-out power 也是一個很值得思考的地方。

3. 演算法是否能符合xx奈米製成的constraint

由於該演算法更多講求的是 area 與 throughput，因此對於 latency 反而不那麼在乎，許多演算法比基礎架構還要多了數倍到數十倍。然而台積電對各製程的 timing constraint 都不同，且 performance 也與 power 成高度相關，因此需自行觀察合成的 library 來評估演算法的可行性。

4. 硬體架構看起來會造成過多 glitch

這個是我從沒想過的問題，已涉及 APR 領域，且是造成 power 增加的一大主因，不過可以從 block diagram 來判斷是否各 gate 的 fan-in 的長度差不多。 這也凸顯出 block diagram 的重要，且也對後續 debug 有利。據學長說法當初在寫 RTL 之前會先把 block diagram 和 wavw form 都畫出來，RTL 只是將圖轉成程式碼。好的 RTL 與壞的 RTL 差別就在於是否設想的購遠夠完備，且 PPA 都要同時考慮。

5. 為甚麼 CTS 指令要訂這個值

關於各指令要訂甚麼值，其實都會有一個參考答案，但主管很愛問這個數值的合理性。他們相信這些參考答案也是由經驗法則而定，但依照不同 case 應該也會有不一樣最適合的參數。

結論

以我目前實習的公司而言，挺注重對於從前端到後端都有一定的了解，因為好的 RTL 需要設想到後續 design tool 是否好合成或繞線來思考，而在做 DCG 時也要 SDC ，其中 clock 相關的 CTC 就要對 CTS 有通徹的了解。
筆者認為學界講求的是創意的發想，而業界是在各種限制下盡量做到最好，學界提供業界可行方案，業界提供學界演算法的實踐機會，兩者都有各自偉大的地方，但思維就大相徑庭了。