第832章會議決議
第832章會議決議(第1/3頁)
第832章會議決議
“時間不等人。”陳默是真心感覺很緊迫了，畢竟已經是2019了，流氓頭子要搞事了。
他頓了頓，然後又繼續說道：
“eda團隊已經準備好了。
我們將采取‘貼身服務’的模式，我們的架構師將直接嵌入你們的設計團隊，現場支持，現場解決問題。
我們需要在真實的高複雜度設計項目中，暴露出工具的所有問題，同時也用最苛刻的需求，來牽引我們工具的下一步進化。”
姚塵風對此非常滿意：
“好！就要這種力度。
終端這邊也會全力配合，任何基於新工具新流程設計的芯片，流片回來後，測試驗證優先級調到最高，我要第一時間看到真實的數據反饋。”
就在大局似乎已定之時，一位一直沉默的海思資深架構師舉起了手。
他負責的是最關鍵的cpu核心設計：
“馮總，陳總，我有一個擔憂。
全麵切換工具鏈，尤其是在下一代高端芯片項目上，風險是不是太大了？
新工具的穩定性、與現有知識產權核（ip）的兼容性、還有設計師的學習成本......
萬一在關鍵路徑上出現無法預見的錯誤，可能會導致整個項目延期數月。
我們是不是可以考慮更保守的策略？
比如，先在一些非關鍵的模塊或者舊項目上進行驗證？”
這個問題非常現實，也代表了一部分設計人員的擔憂。
會議室剛剛火熱起來的氣氛稍微冷卻了一些。
孟良凡搖了搖頭，率先反駁：
“我理解你的擔憂，但時間不允許我們‘保守’。
傳統的設計-製造迭代周期太長，我們等不起。
新一代的pdk和ai設計工具，恰恰是為了縮短這個周期，降低迭代成本。
越是複雜的設計，越是接近工藝極限，它們的優勢就越明顯。
擔心兼容性，那就去測試、去解決；
擔心穩定性，那就讓eda團隊駐場，出了問題第一時間修複。
我們不能因為怕摔跤就不學走路。”
陳默表示讚同，並提供了更具體的方案：
“李工的擔憂很實際。
我們可以采取‘雙軌並行，逐步切換’的策略。
工作組立即成立，全麵啟動。
但在具體執行上，我們可以先選擇一個最重要的子係統，比如下一代麒麟芯片的npu集群，作為‘尖刀連’，率先全麵應用新pdk和‘伏羲’係統進行從rtl到gdsii的全流程設計。
同時，其他模塊暫時沿用經過驗證的舊流程，但必須與新流程設計的模塊進行頻繁的集成驗證。
一旦npu集群的成功得到驗證，立即全麵鋪開。
這樣既能控製風險，又能保證進度。”
這個務實而高效的方案立刻得到了大
（本章未完，請點擊下一頁繼續閱讀）