精品国产人成在线_亚洲高清无码在线观看_国产在线视频国产永久2021_国产AV综合第一页一个的一区免费影院黑人_最近中文字幕MV高清在线视频

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

在valid ready協議中對ready進行timing修復打拍的方法

冬至子 ? 來源:數字邏輯電路小站 ? 作者:孟祥志 ? 2023-06-27 16:20 ? 次閱讀

問題提出:ready時序如何優化?

在valid/ready 握手協議中,valid 與 data的時序優化比較容易理解。

但是有時候,關鍵路徑是在ready信號上,如何對ready信號打拍呢?

首先將把目標設計想象成一個黑盒子,如圖1所示,我們的目標是將READY_DOWN通過打拍的方法獲得時序優化。

圖片

(圖1)

嘗試直接對ready打一拍

1.jpg

(僅示例,非verilog代碼。下同)

這樣是行不通的。

一個簡單的例子(case 1)就是你讓READY_DOWN像一個時鐘一個,間隔一個cycle起來一次,那么VALID_UP && READY_UP 與 VALID_DOWN && READY_DOWN無法同步,數據無法傳輸下去。

思路:將其分解成兩個interfaces

將ready打拍的邏輯想象成一個黑盒子,去分析這個黑盒子的設計,分為up interface 和down interface將問題細化:

  • up interface 有VALID_UP, DATA_UP, READY_UP

  • down interface 有VALID_DOWN, DATA_DOWN, READY_DOWN

    可以總結成下面的樣子:

1.jpg

如果去解決剛才例子(case 1),那么這個黑盒子:

當READY_UP為高的時候,可以接受數據;

當READY_DOWN為高的時候, 如果我們有數據可發的話 ,我們可以向downstream發送數據;

是不是很像一個FIFO?

用FIFO去解決

將一個FIFO插在黑盒子這里,那么就會變成這樣子:

圖片

(圖2)

VALID_UP/READ_YUP ==> FIFO ==> VALID_DOWN/READY_DOWN

也就是:

1.jpg

現在問題變成了:如何設計這個FIFO呢?

  • 這個FIFO深度多少?
  • 怎么設計,能夠保證READY_UP是READY_DOWN打過一拍的呢?

FIFO設計多深?

因為本身valid/ready協議是 反壓協議 ( 也就是READY_UP為0的時候,不會寫FIFO,而不會導致FIFO溢出 )而且此處的讀寫時鐘是同一個時鐘,是一個同步FIFO,所以FIFO深度是1或者2就足夠了。

深度是1還是2要看極端情況下需要存儲幾筆數據。

簡單分析可以知道,只有一種情況會去向FIFO中存儲數據:

  • READY_UP是1,可以從upstream接收數據
  • 同時READY_DOWN是0,不可以向downstream發送數據

這種情況在極端情況下最多維持多久呢?

答案是: 一個周期

因為如果cycle a 時:READY_DOWN=0,那么cycle a+1時,READY_UP變為0了,開始反壓,所以只用存一個數就夠了。

所以設計為一個深度為1的FIFO就可以了。

深度為1的FIFO有很多特點,設計起來比較簡單。比如:wr_ptr/rd_ptr始終指向地址0,所以我們可以刪掉wr_ptr和rd_ptr,因為是一個常值0。

簡單的depth-1 FIFO實現

使用depth-1 FIFO傳輸數據,可以這樣設計:

1.jpg

這解決了READY打拍的問題。但是這里有一些可以改進的地方,比如:

  • 是不是可以擠掉多于的氣泡?
  • 在FIFO為空的時候,數據是不是可以直接bypass FIFO?

無氣泡傳輸

具體的說,就是既然你這里有個深度為1的FIFO了,那么我是不是可以利用起來,放點數據啊……

當READY_DOWN持續是0的時候,READY_UP依然可以有一個cycle去接收一筆數據,把FIFO資源利用起來:

1.jpg

同樣的原因,在RESET情況下,READY_UP可以為1,可以將復位值修改。

那么FIFO穿越呢?

FIFO穿越

考慮一個特殊情況(case 2):

假設READY_DOWN在復位之后始終為1,

然后某個時刻開始VALID_UP為1了。

是不是每個周期,數據都可以直接傳下來而不用進入FIFO,即使READY_DOWN打過一拍?

換句話說: ***如果READY_UP=1, READY_DOWN=1, FIFO是空的這種情況下,數據可以直通*** 。

  • 上文特殊情況(case 2),READY_DOWN/READY_UP一直是1,顯然可以。
  • READY_UP從0到1的跳變:READY_DOWN也會在前一周期有一個從0到1的跳變。在READY_DOWN為0時,有一筆數據存到FIFO里邊(無氣泡傳輸);當READY_DOWN在時刻a從0變到1時,READY_UP在時刻a+1也會從0變為1。如果此時READY_DOWN也為1,可以直通,不用進入FIFO。也就是:

1.jpg

注意在直通時,我們不希望數據進入FIFO:

1.jpg

將所有這些結合起來:

1.jpg

1.jpg

1.jpg

(注:代碼未經詳細驗證)

換一種思路

經過上面對FIFO的分析,我們可以總結起來,主要是以下幾點:

  • 加入一個深度為1的同步FIFO,這個FIFO在READY_DOWN為0,且READY_UP為1時暫存一個數據;
  • 在READY_DOWN從0->1時,FIFO里邊的數據先輸出到下級;
  • 如果READY_DOWN繼續為1,數據可以繞過FIFO直通;

深度為1的FIFO(不管是同步還是異步FIFO),都是一個特殊的邏輯單元。

對于深度為1的同步FIFO,其實就是一拍寄存器打拍。

所以,我們可以這樣重新設計:

  1. 加一級寄存器作為buffer(實際上就是深度為1的FIFO)

  2. 當以下條件滿足,這一級寄存器會暫存一級數據:

    2.1 READY_DOWN是0,并且

    2.2 READY_UP是1,并且

    2.3 VALID_UP是1;

也就是:

1.jpg

  1. 當READY_UP是1時,數據可以直接暴露在下級接口:READY_UP為1時,BUFFER中一定是空的,因為上一個時鐘周期數據已經排空了。也就是:

1.jpg

這其實就是上面的FIFO直通模式。同樣我們可以擠掉氣泡:

1.jpg

把這所有的總結起來:

1.jpg

1.jpg

(注:代碼未經詳細驗證)

其他

  1. 我在電腦上簡單跑了兩個波形,FIFO方法和Buffer方法結果是一樣的。
  2. 用FIFO去隔離開上下兩個interface思考,比較容易想明白。
  3. 無氣泡傳輸、FIFO直通這兩個小feature拿掉,也可以工作、也是能實現READY_DOWN時序優化的設計目標的。
聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • 寄存器
    +關注

    關注

    31

    文章

    5322

    瀏覽量

    120022
  • AXI總線
    +關注

    關注

    0

    文章

    66

    瀏覽量

    14250
  • FIFO存儲
    +關注

    關注

    0

    文章

    103

    瀏覽量

    5965
收藏 人收藏

    評論

    相關推薦

    時序優化之接收端打拍策略探討

    這篇文章是探討對接收端進行時序優化(即ready打拍,或稱backward打拍)的方式。
    的頭像 發表于 12-04 10:20 ?591次閱讀
    時序優化之接收端<b class='flag-5'>打拍</b>策略探討

    valid-ready握手協議和enable-xoff協議對比

    這一篇主要對比下valid-ready握手協議和enable-xoff協議,當然這個對比僅限于同時鐘域下的信號傳輸。
    的頭像 發表于 12-04 10:32 ?726次閱讀
    <b class='flag-5'>valid-ready</b>握手<b class='flag-5'>協議</b>和enable-xoff<b class='flag-5'>協議</b>對比

    ADS131A04復位后以READY進行響應,第一個幀接收到的響應不正確,為什么?

    ADS131A0x 的數據表指出器件復位后以 READY進行響應:對于 ADS131A02 為 0xFF02,對于 ADS131A04 為 0xFF04。但是,如果我發送多個 NULL 命令
    發表于 11-25 08:11

    add_ready_list_end

    /*add task_ptr to the ready list end*/void add_ready_list_end(RAW_RUN_QUEUE *rq, RAW_TASK_OBJ
    發表于 06-08 17:26

    任務處于Ready狀態如何調試?

    Hi: 各位大俠好,我們調試的時候遇到有幾個任務處于Ready狀態,但是Ready了的任務不執行,而是Idle任務執行的問題,現象如下圖所示:請問遇到這種問題如何調試?
    發表于 01-02 15:07

    Stream的halfPipe方法為什么會導致帶寬減半?

    。pipelinedStream諸多打拍握手方法,或許你記起來比較麻煩,那么可以使用時采用下面的方法:m2s:
    發表于 06-23 15:57

    FATFS格式化FR_NOT_READY錯誤怎么解決?

    對U盤進行格式化,返回了一個錯誤是FR_NOT_READY錯誤掛載的時候f_mount(fs \"1:\" 0);返回FR_OK掛載的時候 f_mount(fs \"1:\" 1);也是返回FR_NOT_READY錯誤,這FR_
    發表于 10-18 07:32

    什么是“HD Ready”標準

    什么是“HD Ready”標準 歐洲EICTA(歐洲通信家電工業聯合會)日前推出了高清顯示器標志“HDTV Ready”以及獲得該標志需要滿足的條件。凡帶有該標志
    發表于 02-05 10:39 ?894次閱讀

    小魚易連多款設備獲得IPv6 Ready Logo認證

    近日,上海賽連信息科技有限公司旗下多款小魚易連智能視頻會議終端在下一代互聯網國家工程中心-全球IPv6測試中心正式通過IPv6 Ready核心協議Phase-2測試。獲由國際組織IPv6 Forum
    發表于 08-23 14:06 ?928次閱讀

    SD-WAN Ready工業互聯網的實踐

    近日,第三屆SD-WAN產業發展論壇上,網銀互聯鄭永為參會企業帶來了《SD-WAN Ready工業互聯網的實踐》的主題演講。
    的頭像 發表于 02-18 15:09 ?1512次閱讀
    SD-WAN <b class='flag-5'>Ready</b><b class='flag-5'>在</b>工業互聯網的實踐

    setup/hold的概念

    協議,需要打拍的信號間存在時序的耦合。 所以問題就簡化成如何在遵循valid -ready協議的master和slave 之間完成“
    的頭像 發表于 07-25 10:09 ?2001次閱讀

    AXI4協議五個不同通道的握手機制

    AXI4 協議定義了五個不同的通道,如 AXI 通道中所述。所有這些通道共享基于 VALIDREADY 信號的相同握手機制
    的頭像 發表于 05-08 11:37 ?1191次閱讀
    AXI4<b class='flag-5'>協議</b>五個不同通道的握手機制

    在握手協議Valid及data打拍技巧

    AXI 協議使用的是valid-ready握手的方式去傳輸數據。
    發表于 06-27 16:12 ?1546次閱讀
    在握手<b class='flag-5'>協議</b><b class='flag-5'>中</b>的<b class='flag-5'>Valid</b>及data<b class='flag-5'>打拍</b>技巧

    validready信號有哪三種情況

    validready信號分三種情況: (1)valid信號先到達 主機valid信號早早就到了,T2時刻并沒有見到接收方的ready信號。
    的頭像 發表于 10-31 15:44 ?1949次閱讀
    <b class='flag-5'>valid</b>與<b class='flag-5'>ready</b>信號有哪三種情況

    Valid-Ready握手協議的介紹與時序說明

    "Valid-Ready" 握手協議是一種常用于數字電路的接口協議,用于控制數據的傳輸和處理。
    的頭像 發表于 12-04 10:37 ?1419次閱讀
    <b class='flag-5'>Valid-Ready</b>握手<b class='flag-5'>協議</b>的介紹與時序說明