Re: [問題] 數位電路問題
數位設計的某些target的確以DSP的應用為主
但是我想應用的層面有分General與special兩種?
而special則以ASIC為大宗 反之General則以CPU或DSP為主
尤其您做multimedia 在此領域的standard層出不窮
假使做AISC大概都死光了吧? 應該都是以CPU應用居多
而電路設計分同步與非同步 同步設計所以為主流
應該還是應用簡單 掌握度高為主 所以幾乎看到的design都已同步設計為主
反之 非同步設計有很多問題
timing control與非同步會遇上很多不可預期的問題
也因此在EDA上的發展非常的緩慢 但是真的沒有非同步設計的產品?
還是有的 過去以簡單的device為主
可是看看這一兩年 ARM跟其他CPU業者 開始推出高階的非同步CPU
講求的是什麼? 就是低耗電...
想想同步設計都圍繞在clock上 要多少DFF clock tree要多少buffer跟delay?
這些EDA都會幫你做好 但是也會變成同步設計的包袱
我看的是這點 所以我才說未來的非同步設計 應該會慢慢浮出檯面:)
其次 Maddulin網友所提的三種design 04/07的兩篇論文我應該可以想像
大概都是以一些技巧 如用MUX取代DFF架構性的改變來省transition
通常都是area與power consumption的拔河
但是閣下的design假使跟前兩篇論文用同樣的cell library與EDA卻如此傑出
那鄙人真是由衷的佩服 實是優秀
倘若您不嫌棄 這三篇能在IEEE上查的到嗎? 能否讓在下見識一番?
#的應用 如某網友推文一般 我也聽過在跨clock domain時有其好處
畢竟有的design可能clock domain就至少兩個以上
我自己做過的就有三個clock domain 內建兩套PLL與一個recovery clock
不過我也為此吃過非常多苦頭
在此跟大家宣傳一下 Cadance有CDC(clock domain check):p
我長官為了省DFF 一堆test bench/FPGA沒檢查的未爆彈 我自己是de到要死
另一位網友提到的gate level design 不巧不才也有一點點了解
有時候把CPU或是一些ASIC decap來看
不難發現有部份數位電路都不是cell base
在EDA公司不斷的吹噓他們合成/最佳化能力之時 這事實上反而是他們的弱點
數位電路某些相似性高級重複性高時
用full custom design可以gain到不少好處 不管是area或power consumption
而EDA tool有時候為了廣泛性 往往在這點作得soso...
因為你寫的code他檢查不出feature或是他的library沒有 就是土法煉鋼了
舉個最簡單的例子 有人做memory是用EDA去合成的嗎?
現在大公司自己都有養專門的人在做full custum design
也有網友提到數位電路就直接analog了
在某些design講求低成本時 製程不斷shrink下 類比電路往往會變成一種包袱
早期某些數位電路可能會用類比實現(rtk的早期網卡)
數位電路會隨製程shrink而有效縮小
但是類比電路卻不然 不但無法像數位電路有效縮小 連架構可能都要改變
我現在在業界比較少聽到數位電路改用類比電路取代 @_@
未來的趨勢反而是類比電路PLL/DAC/ADC有趨勢往transfer level走
RTL有時後是一種捷徑 但有時後卻是束縛了自己
gate level或是full custom多少懂一點 還是總有用到的一天
※ 引述《Maddulin (what else do u focus?)》之銘言：
[恕刪]
: 談這些問題我一定從理論,背景精神切入,這樣視野才廣
: digital circuit 必然以實現處理 DSP 為發展, 這點無庸至疑
: DSP 的運算精神就是 clock-based 亦即 sampling
: 當然電路的完全同步,當設計的複雜度提升,
: 過度的同步要求便對電路的實現造成瓶頸
: 雖然我們可見到非同步設計的確非常有他的必要性
: 不過非同步設計必需建立在同步設計之上
: 因為clock 是 DSP 理論的基礎
: 因此小弟認為若設計牽扯非同步, 設計的精神還是在於同步設計
: 進一步談到 area, power 的問題, 我提出一個我自身研究的實例做為印證
: 同樣的spec. (multimedia 應用), 同樣的 processing capability
: JSSC'04 250kgate/10mW (.18 1.2v)
: TCSVT'07 300kgate/4mW (.18 1.3v)
: 我們的設計 100k/0.7mw (.13 1.2v) (dyn. power 0.3mW)
: 同時我們的設計有更好的system performance,特別在於某些環境,greatly
: 這些數據都是極客觀比較, 沒有背後隱藏的事實
: 我們也沒有使用太特別的演算法,但就是比目前學術界最頂尖的設計好上數個order
: 看來不可思議? 何故? 如同我曾說過, 電路設計者必需有一定程度的理論基礎
: 硬體設計是門藝術,非常強調天分,同樣的理論,在某些人手上就是像變魔術
: 在那些成熟的工業 例如建築,航空 ... 都是如此
: 我想談的事,許多的設計是要看設計者的功力, 功力不是做做黑手
: 隨便寫寫 code 就會出來
: 欠缺嚴僅的分析 設計者的功力絕對是天差地遠,
: 所以同步設計是否真的 more area/power cost?
: 我想未必, 還是要看設計者的能力而定,
: 某此設計者就是用一些簡單的設計技巧就能端出滿漢全席
: 另外一個問題我想進一步討論的就是為何我關於放 # 的問題
: 為何我如此排斥? 我那時的說法只是把我的想法簡略的表達出來
: 以下我只從 cell-based 的角度切入
: 數位電路的設計的演進及間題的切割有其背景及必要性
: cell-based flow 目前的理論將巨大的設計問題做有效的垂直切割
: 每個層級所考慮的問題或是層級間的 interfact, 或是跨 domain
: 都有其背景及必要性, 理論與應用就在這樣的環境底下孕育發展
: 以RTL為例, 它是 cell-based flow 設計垂直切割中可說是最重要的一個層次
: 系統的設計目前仍主要由 RTL 所述描, 在某方面, 專注於 RTL 層級的設計
: 能給系統設計者帶來非常主要的正面價值
: 特別是讓我們能站在巨人肩膀的那些動輒數億 CADs 便是基於這樣的切割而發展
: 即然我們已有效的 切割這些問題 (基於發展背景或精神), 代表某程度而言,
: 我們必需學習更高 abstraction 的體會, 在此層級下學習信任的遵從那些設計限制
: 限制就字義看來, 或許沒有必要, 例如為何 RTL 不處理 cycle 內的 timing?
: (暫且先將 RTL 視為一種邏輯描述的方法, 如果你喜歡 就叫它 ABC)
: 但這些發展都是包含處理這些限制最佳與期望最佳解,
: 或是正確的說是"限制"由此而生
: 若能跨 domian 而有效率,或是更佳解, 那問題的切割就並非如此
: 理論不斷進步,看問題的角度也可能改變,
: 例如 RTL 邏輯描述某程度而言並不是那麼有效, 我們可以將問題的abstraction
: 提升至 algorithm/system level, 抽離 時鐘-based description
: (按:
: 我個人持保留的態度, 一定行為的描述抽離了時鐘的scheduling
: 在此 abstraction 下, 不同時脈而同樣的邏輯結果是完全 equivalency
: 而此過程某些適度包含時序的邏輯就因此被剝離, 但這些邏輯合成的演算法
: 絕不可能超越人的思考與分析能力, 因此我個人認為要以 system/algorighm
: level 的行為描述取代 RTL 是完全不可能的事, 除非我們只在乎東西會不會動)
: 回到 RTL, 這一層級的邏輯描述只專注在 register transfer
: 換言之, 所有系統的運算/邏輯的行為描述是看不見 cycle 這數字
: 在一個 clock edge 下, 同時轉換, 這就是 DSP 的主要基礎
: 既然沒有 timing 的 information, 加 # 有何意義? 希望有這習慣的人思考這問題
: 如同a網友說 有些人這樣做是為幫助閱讀,分辦 comb. logic/ seq. logic
: 這樣應該在 naming 去解決, 而不是破壞 RTL 的架構
: 會有這樣想去的人, 我認為他不能融入 RTL 存在的精神與目的
: 這樣真的很難設計出有水準的電路
: 另外,有人回說 fpga 內部有 cell 可呼叫
: 只要是 cell-based flow 都有 cell 可做為 instance
: 可是這就不屬於 RTL 層級下的設計, 你的 RTL synthesis對於這樣的設計
: 不會有更好的合成能力,
: 除非非有不得已的原因否則沒有這樣設計的餘地
: 我已經證明,我們"專注"在 RTL 設計, 將有非常大的 benefits
: 超越事必恭親的 design vision,
: 我們應該朝向設計的藝術前進, 如何設計出一流的電路
: 對這問題我的建義是多多培養
: 對設計正確的認知,包含用心的體會這些設計理論的精神與發展的背景
: 我想我能表達的都差不多了, 希望能給一些初學者不同的 vision
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.133.134.198
討論串 (同標題文章)