RISC-V 讓開源硬體變成採購表

我把一篇 RISC-V 市場簡報拆成團隊可直接套用的評估模板，重點放在控制權、供應鏈、工具鏈與導入風險。

我最近一直在看 RISC-V 的資料，看到快有點煩。每次一進會議，大家都把「open standard」掛嘴邊，好像只要沾到開放兩個字，剩下的問題就會自己消失。可我實際看過幾輪評估後，只覺得更不對勁：誰來維護 roadmap、要不要做 custom instruction、軟體工具鏈誰扛、換供應商會不會整包炸掉，這些才是你真的要付錢的地方。

最麻煩的是，很多團隊以為自己在選架構，其實是在選一個更好聽的故事。故事很順，採購也比較好講，但等到要進 silicon、要跑 OS、要 debug、要撐三五年維護，才發現「開放」不是答案，只是把責任拆得更細。我看這種戲碼看太多了，真的會有點火。

所以我才會去拆這份市場簡報。不是因為它寫得多漂亮，而是它剛好把 RISC-V 的真問題露出來：開放硬體如果不能變成可重複的工程決策，那就只是另一種包裝精美的風險。這篇我就把它翻成台灣團隊可以直接拿去用的版本。

觸發我寫這篇的是 OpenPR 上的 Market Research Corridor 的 RISC-V Market Research Report 2026-2032。文中點到 SiFive、Andes Technology、Codasip、Synopsys、Imagination Technologies。它沒有給我可以直接引用的硬數字，所以我把它當成市場訊號，不硬掰成數據報導。

別把 RISC-V 當口號，先把它當採購決策

The global semiconductor architecture landscape is witnessing a seismic shift toward open-standard hardware.

這句話翻成白話就是：RISC-V 已經不是單純的架構討論，它其實是在談你要把多少控制權留在自己手上。你選它，不只是選 instruction set，你是在選 licensing、客製化程度、以及未來被單一 vendor 綁住的機率。

我之前看過一個硬體團隊，聽到「open ISA」眼睛就亮了，然後直接跳過最無聊但最重要的問題：工具鏈成熟嗎？目標 OS 撐得起來嗎？debug flow 有沒有坑？他們一直問能不能更快，卻沒問之後會不會更痛。這就是典型的買標題、吞帳單。

實操寫法很簡單：每次 RISC-V 被提起來，你就逼大家先回答三件事。

• 我們到底擁有什麼？
• 我們還依賴誰？
• 18 個月後換 vendor，哪裡會先爆？

如果這三題都只能用「應該」「大概」「可以找 partner」來回，你其實不是在評估架構，你是在買一個還沒長好的故事。

真正的對手不是 ARM，而是控制權跟便利性在打架

那篇簡報愛點名「star players」，這很像市場報告的標配，但我覺得更有用的讀法是：RISC-V 生態正在分成兩派，一派賣控制權，一派賣便利性。SiFive 主打 RISC-V IP 和實作選項，Andes Technology 在可客製 CPU IP 這條路走很久，Codasip 也是偏可配置處理器。名字不同，但底層賣的都是同一件事：少一點 lock-in，多一點可調整空間。

問題來了，這種自由不是免費的。你還是要有 compiler、verification、debug、firmware、板級支援，還要有人半夜兩點能把問題抓出來。這也是我對很多市場文案最不爽的地方，它把自由講得像不用付代價一樣。拜託，哪有這種事。

我自己看團隊選型時，通常不會問「RISC-V 好不好」，我會問「你要多少控制，這些控制你真的扛得住嗎？」如果你的產品差異化真的在 silicon 行為、指令擴充、供應鏈可控性，那 RISC-V 很合理；如果你只是想要一顆 CPU 安安靜靜跑起來，成熟的現成方案常常更便宜。

實操寫法：拉一張四欄表，直接打分數，不要靠感覺。

• 客製化能力
• 生態成熟度
• vendor 依賴程度
• 到量產時間

高客製、低成熟度，通常是研究案。高成熟、低客製，通常是 commodity。你要找的不是最帥的那個，是最符合你產品節奏的那個。

看 vendor 名單，不是看排名，是看拼裝進度

我會在意那份簡報把 Synopsys 跟 Imagination Technologies 也放進來，不是因為它們比較「RISC-V 純」，而是因為這代表市場已經不是只有幾家新創在講漂亮話了。它開始碰到真正大 chip 團隊需要的東西：工具、IP block、verification、整合層。

白話講，一顆 CPU core 不是產品策略，它只是鏈條中的一段。鏈條其他地方一弱，core 再漂亮都沒用。我看過太多團隊愛上一顆處理器，結果真正燒錢的是 firmware bring-up、SDK 維護、以及 build pipeline 穩不穩。

所以你在看 vendor 時，別只問規格，直接問這三件事：

• 驗證流程成熟嗎？
• 出事時 support 怎麼接？
• 軟體堆疊有多少是 upstream 維護？

如果對方只會說「我們有夥伴」「我們可協助整合」，我會先扣分。因為夥伴很美，直到時程開始滑，大家就會開始找別人的 interface 當藉口。

實操寫法：把 CPU、RTL、verification、toolchain、debug、firmware、board support 全部攤開。誰能把整條路線講清楚，誰才像平台；只給你一顆 core 的，多半只是零件商。

市場簡報有用的地方，不是成長敘事，是摩擦點

我對市場研究的標題一向很有戒心，因為它們很愛講大趨勢，卻不太講代價。但就算是一篇不夠漂亮的簡報，只要你會讀，它還是能幫你抓到摩擦點。這份報告拉到 2026-2032，我解讀成：它想把 RISC-V 從「新東西」拉成「可以放進長期規劃」的選項。這方向沒問題，我更想看的是它背後的摩擦是什麼。

對 RISC-V 來說，摩擦其實很明顯：software maturity、ecosystem fragmentation、以及「我們能客製」和「我們能長期支援」之間的落差。這些不是小瑕疵，這些就是整件事的核心。如果是 embedded 專案，你有時候還能吞；但如果你做的是要活很多年的平台，任何薄弱環節最後都會變成維護稅。

我以前看過一些團隊太早上新基礎設施，前面都很爽，因為 licensing 省了、供應鏈故事也好講。可是一旦進入維運期，內部 expertise、debug 時間、vendor coordination、support burden 全部回來收債。這就是 open hardware 最討厭也最迷人的地方。

實操寫法：讀市場報告時，不要抄它的形容詞，直接把問題抽出來。

• 哪些產業可以忍受工具鏈還不夠成熟？
• 哪些場景的 custom silicon 值得那個工程成本？
• 哪一段 stack 還綁著少數 vendor？

如果報告不能幫你回答這些，那它就只是包裝得比較好的趨勢圖。

RISC-V 最適合那種「我就是有理由難搞」的團隊

這句我講得直接一點：RISC-V 最適合那些真的有理由要難搞的團隊。也許你需要 custom extension，也許你在意 licensing predictability，也許你的產品 moat 就在 architecture control。這些都很合理。但「因為開放」本身，不夠。

我不太買那種無條件的熱情。開放標準不是天然比較好，它只有在符合你的問題形狀時才比較好。如果你的團隊沒有硬體、firmware、toolchain 的深度去承擔後果，那開放只會讓錯誤面積變大。

所以我現在看 RISC-V adoption，會把它當成一般嚴肅的平台 bet：先看 use case，再看生態成熟度，最後才決定要不要上。符合就做，不符合就等。等不是失敗，半吊子上線才是。

實操寫法：先過這個門檻，不要被簡報帶著跑。

• 我們真的需要現有架構給不了的 custom compute 行為嗎？
• 我們有足夠內部能力扛整合嗎？
• 這個選擇能不能撐完整產品生命週期？

如果這三題你只能穩穩答對一題，我會建議先踩煞車。

把簡報當 checklist，不要當結論

我覺得這類報告最好的用法，不是照單全收它的結論，而是把它改寫成你自己的評估清單。它給你 vendor 名單和方向性敘事，這就夠了。比起再看一篇講轉型講到天花亂墜的文，我更想要一份能拿去開會的 checklist。

所以我最後的結論很簡單：RISC-V 有用，是因為它能給你真正可操作的控制權；它很煩，是因為很多人把控制權講得像不用付管理成本。控制如果沒有 execution，只是更多東西要你自己扛。

我現在對這類選型的建議就一句：把 RISC-V 當成 ownership 的決策，不要當成 ideology。架構只是開始，真正難的是架構外面那一圈。

實操寫法：你們內部 review 就圍繞 ownership、support、lifecycle 三件事來問。答得越清楚，架構越不會變成口號。

可抄的模板

RISC-V 評估模板｜給產品團隊直接填空用

# Decision summary
- 為什麼要看 RISC-V： [customization / licensing / supply-chain / roadmap control]
- 影響範圍： [embedded / edge / automotive / industrial / server / other]
- 預計量產時間： [date]

## 1) 先講清楚你在解什麼問題
- 我們現在卡在哪裡？
- 為什麼 RISC-V 比現有方案更適合？
- 什麼情況下這個案子不值得做？

## 2) Control map
### 我們自己要掌握的
- ISA choice:
- Core customization:
- Firmware:
- Toolchain integration:

### 我們仍然依賴外部的
- Vendor IP:
- Verification:
- Board support:
- OS patches:

## 3) Ecosystem check
- Compiler/toolchain maturity: [pass / risk / fail]
- Debug and profiling support: [pass / risk / fail]
- OS and RTOS support: [pass / risk / fail]
- Upstream/community activity: [pass / risk / fail]
- Vendor support model: [pass / risk / fail]

## 4) Vendor comparison
| Vendor | Customization | Ecosystem maturity | Support quality | Time to production | Risk |
|--------|---------------|-------------------|------------------|-------------------|------|
| [name] | [score]       | [score]           | [score]          | [score]           | [notes] |
| [name] | [score]       | [score]           | [score]          | [score]           | [notes] |

## 5) Lifecycle questions
- Can we support this for 3-5 years?
- What happens if we change vendors?
- What breaks if our first silicon spin misses?
- Who owns debugging when things go wrong?

## 6) Go / no-go rule
- Go if: [write the exact conditions]
- No-go if: [write the exact conditions]
- Revisit date: [date]

## 7) Final decision
- Selected option:
- Reason:
- Main risk:
- Owner:
- Review date:

你可以直接把這段丟進 Notion、Google Docs、Jira wiki，甚至當成採購會議的預設頁面。重點不是格式漂亮，是逼大家在開口說「open」之前，先把責任寫出來。

來源致謝：原始材料來自 OpenPR 的 RISC-V Market Research Report to 2032 - Star Players are SiFive, Inc. (US), Andes Technology Corporation. (Taiwan), Codasip (Germany), Synopsys, Inc. (US), Imagination Technologies (UK)。我在這篇裡做的是拆解、翻譯與模板化；市場敘事和 vendor 名單來自原文，分析框架與可抄模板是我自己整理的。