出一張嘴-avatar-img

出一張嘴

29 位追蹤者

出一張嘴

29 位追蹤者
用嘴做IC,只剩一張嘴
avatar-img
數位IC設計第一品牌
125會員
28內容數
數位IC設計第一品牌 從0到1用嘴做IC 觀念大權
全部內容
由新到舊
付費限定
準備實作Async Fifo時, 我習慣將整個架構切成4塊來實作, 讓coding實的思緒比較有條理一點. Block 0 : 整體的interface Block 1 : mem周邊 Block 2 : Gray code pointer control Block 3 : wri
Thumbnail
回到這張看起來很複雜的AFIFO架構圖 (*藍色訊號為write clk *紅色訊號為read clk) 我們開始來專心探討一下圖中B2G這區塊的功用 相信各位看懂架構後coding就不是甚麼大問題 回顧一下, 我們先思考ptr在傳輸時沒有處理CDC issue時會發生甚麼事? pt
Thumbnail
付費限定
上篇文中最後提到的為甚麼async不用Dmux傳ptr就好, 究竟有甚麼缺點又或是不可行, 這邊來探討一下. 首先我們先來看一下Dmux解CDC issue的原理 dmux架構可以分為兩個部分, Data path和CTRL path, 我們會在CTRL的path的部分在clkA的t
Thumbnail
付費限定
在了解sync fifo後,可以開始來研究一下何謂asyc fifo? 小弟在這邊盡量利用了sync fifo的架構圖來呈現async fifo的運作, 以方便各位更容易的理解其中的奧妙 以Top view來看,基本上和sync fifo沒太大的不同, 最大的差異則是clk和rst長出了兩組
Thumbnail
付費限定
前面介紹完sync fifo的function block用途後, 這篇開始來帶入code要怎麼implement. Full code: module sync_fifo #(parameter N=8, parameter depth=8) (input clk, input rst_
Thumbnail
付費限定
FIFO題目答得好不好可以直接看出面試者的程度為何, FIFO看似簡單卻濃縮了非常多的design細節在裡面, 在這邊來和各位分享一下我個人的心得. 作為designer最常使用到的fifo就只有兩種屬性 1.sync fifo 2.async fifo 那這邊的sync或asy
Thumbnail
付費限定
作為designer一定經常看到spec中描述當edge出現時需要trigger電路運作, 舉個實際的例子 2 phase的handshake protocal, 以下方paper中的圖例來看. Quasi Delay-Insensitive High Speed Two-Phase Prot
Thumbnail
付費限定
到了最後一個階段, 我們做了這麼多CG cell insertion後, 要怎麼知道到底是不是對Design有幫助的呢? 是否有個rule又或是量化的數據來解釋說CG的效果如何 在下面這篇paper中提到了幾種觀測CG cell efficiency的方法 J. Srinivas, M
Thumbnail
DaDa995-avatar-img
2025/04/10
大佬要怎麼私訊您問題? 是不是需要改別的方案才可以? 想問CRPR要怎麼畫圖去分析解釋阿? 感謝
出一張嘴-avatar-img
發文者
2025/04/18
DaDa995 Hi 您好, 因為我都有空時才會看回覆及寫文章,所以沒有開啟私訊, 有想問的可能需要麻煩您留言,我如果剛好知道相關的知識會回覆您. 以下是關於我對CPPR的理解, 先描述一下CPPR在做甚麼, 以往我們在STA check timing的時候都會用最嚴謹的方式做sign off, 因為可以最保險降低出錯的機率, 所以大多時候我們都是over constraint的, 但是以現在的chip design來說, 我們希望可以省下更多的area或是power消耗, 雖然越嚴苛的條件可以讓你的chip容忍越大的variance, 副作用卻是增大了area和power,所以並不是沒有缺點的, 因此cppr就誕生了, cppr目的就是要補償回我們曾經太嚴苛的條件, 實際上根本不會發生的case, 他所觀測的點是clk tree的common path. 在clk tree的建置過程,某種策略下希望common path越長越好然後到reg周遭開始branch開, 但是我們在分析timing時會因為希望預留OCV margin所以會給予一個uncertainty, 就是您於timing report中看到的derate項 在setup check下, derate會對於launch path的timing總和乘上>1的倍率 對於capture path的timing總和乘上<1的倍率 可以想像成arrvial time我假設只要走1ps,但是我為了抓margin給他走1.1ps 對於require time 原本可以走1個cycle 2ps,但是為了抓margin給剩給他1.8ps 讓setup check 的require-arrival變緊達到預防ocv的效果 但是,這樣很純粹的算法會對common path的地方同時作放大跟縮小, 在預期上common path的路徑上不論對於req或arrival都是做出一樣的貢獻, 因此cppr就是在補償回原先這段path所多算的時間 可以參考下面這篇文章 https://vlsi.pro/common-path-clock-reconvergence-pessimism-removal/
前面文章曾經提到說, 除了我們在寫rtl當下直接撰寫加入的cg cell外, 實際上我們有些clk gating cell是靠tool自己幫忙插的, [Verilog] 10分鐘由淺入深看懂 clock gating -2 那麼tool是怎麼判斷說哪邊要插gating cell的呢?
Thumbnail
Jun-Tsung Wu-avatar-img
2025/05/28
大佬您好,由於最近有使用clock gating的設計與合成(第一次碰CG),在Timing上也遇到一些困擾,剛好看到您這幾篇覺得受益良多。不過我這邊的問題似乎還是想不到如何解決,因此想請教您看看! 我在rtl code中應該是寫ICG的寫法,然而利用design compiler合成(應該是有合成出CG cell)。 其中,會出現gclk與clk之間有延遲(D),而原本要被gclk posedge時trigger的訊號(flag) 因為合成加入timing 資訊後,與主要clk也會有些微延遲(d)。 而合成後發現,D>d,會導致gc沒有在正確時間trigger flag,導致simulation有錯。 我在design compiler中是使用compile -gated_clock進行合成 但也沒很確定合出來的結果是否正確。 以上想請教一下大佬,麻煩您了,謝謝!
出一張嘴-avatar-img
發文者
2025/06/21
Jun-Tsung Wu 您好 您可以check一下violation的timing path 如果是clk gating check violation的話 應該會去check enable pin的timing是否能滿足 需要先check這條enable組成的訊號是否為預期的會比較好下手 需要開synthesis後的netlist和timing report作比對一下 抓到path後回去對應rtl 應該跟您coding的行為可以對上 等match後才好想解法,對於cg chk violation的解法確實偏難 最差的狀況就是eco tie住enable放棄這顆cg 所造成的impact是pwr上升但function work
前面文章提到過clk gating check實際上就是在check gating cell的enable訊號 檢查enable的timing是否能滿足STA的check, 不過不知道各位有沒有發現到, 這條path看起來很單純呀而且我還用上了latch大法, 可能讓訊號走完1整個cycle
Thumbnail