0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

什么是握手協(xié)議?握手機(jī)制的原理

倩倩 ? 來源:CSDN ? 作者:CSDN ? 2022-08-12 14:51 ? 次閱讀

。

什么是握手協(xié)議

說起握手,首先查了一下百度百科。握手是一種禮儀,起源于中世紀(jì)的歐洲,順序為長幼有序,女士優(yōu)先。(PS:所以握手的時候,男士記得要紳士一點哦)。

芯片中,握手是最古老的跨時鐘域之間傳輸數(shù)據(jù)的方式。握手機(jī)制通過將脈沖信號展寬,待輸出一側(cè)檢測到信號并將其解析為脈沖信號后,再向輸入一側(cè)發(fā)送應(yīng)答信號,表明接收到信號并且傳輸完成。

96f7bf62-19f6-11ed-ba43-dac502259ad0.png

為什么要握手

在人類的進(jìn)化史中,握手作為一種善意的表達(dá)方式,可以增進(jìn)人與人之間的和諧。言歸正傳,那么數(shù)字電路中為什么也需要握手機(jī)制呢?這是因為在數(shù)字電路中,跨時鐘域處理是個較為常見的問題。關(guān)于跨時鐘域,我們公眾號之前有介紹過,想復(fù)習(xí)一下的同學(xué)可以查看一下之前寫的文章。

在從快時鐘向慢時鐘傳遞時,由于輸入信號變化較快,輸出一側(cè)可能跟不上輸入的變化,從而導(dǎo)致“漏采“現(xiàn)象。由于兩個時鐘之間的頻率不同,來自快時鐘域的脈沖信號,還沒來得及被慢時鐘的采到,便轉(zhuǎn)瞬即逝,從而導(dǎo)致信號被漏采。此時,握手機(jī)制便可以大顯神通。

握手機(jī)制的原理

97777d60-19f6-11ed-ba43-dac502259ad0.png

(1)發(fā)送端在t_clk時鐘域下將需要發(fā)送的數(shù)據(jù)準(zhǔn)備好后,將t_rdy信號置為有效,該信號必須在tclk下降沿輸出。接收端在rclk時鐘域下同步r_rdy信號,同步后的信號命名為t_rdy_rclk。

(2)接收端在t_rdy_rclk有效期間,對t_data進(jìn)行采樣,得到t_data_rclk。

(3)接收端將r_ack信號置為1,信號必須在rclk下降沿輸出。發(fā)送端將r_ack同步為r_ack_tclk。

至此,已經(jīng)完成“半握手”,發(fā)送端在輸出下一數(shù)據(jù)前,不會等到r_ack_tclk被置為0。半握手機(jī)制工作速度快,但是使用不當(dāng)有可能會導(dǎo)致操作錯誤。然而,如果要從高頻時鐘向低頻時鐘傳輸數(shù)據(jù),則需要采用全握手機(jī)制。

(4)當(dāng)r_ack_tclk為高電平時,發(fā)送端將t_rdy置為0。

(5)當(dāng)t_rdy_rclk為低電平時,接收端將r_ack置為0。

(6)當(dāng)r_ack_tclk為低電平時,發(fā)送端將t_rdy重新置為1發(fā)送端可以發(fā)送新的數(shù)據(jù)。

至此,全握手完成。顯然,全握手過程耗時較長,數(shù)據(jù)傳輸較慢。但是全握手機(jī)制穩(wěn)定可靠,可以在兩個任意頻率的時鐘域中安全地進(jìn)行數(shù)據(jù)傳輸。需要注意一點的是,數(shù)據(jù)應(yīng)該在發(fā)送時鐘域內(nèi)穩(wěn)定至少兩個時鐘上升沿,請求信號req的寬度應(yīng)該超過兩個時鐘周期,否則從高速時鐘向低速時鐘傳遞可能無法捕捉到該信號,也就是信號“失聯(lián)”了。

握手機(jī)制的代碼實現(xiàn)

發(fā)送端狀態(tài)機(jī):

97c37e22-19f6-11ed-ba43-dac502259ad0.jpg


module transmit(tclk,reset_tclk,t_rdy,data_avail,transmit_data,t_data,r_ack);input tclk;input reset_tclk;input data_avail;input [31:0]transmit_data;input r_ack;output t_rdy;output t_data;
localparam IDLE_T = 2'd0,    ASSERT_T_RDY = 2'd1,    DEASSERT_T_RDY = 2'd2;
reg [1:0] t_hndshk_state,t_hndshk_state_nxt;reg t_rdy,t_rdy_nxt;reg [31:0] t_data,t_data_nxt;reg r_ack_tclk;
always@(*)begin
 t_hndshk_state_nxt = t_hndshk_state; t_rdy_nxt = 1'b0; t_data_nxt = t_data;
 case(t_hndshk_state)  IDLE_T:begin   if(data_avail) begin    t_rdy_nxt = 1'b1;    t_hndshk_state_nxt = ASSERT_T_RDY;    t_data_nxt = transmit_data;   end  end
  ASSERT_T_RDY:begin   if(r_ack_tclk)begin    t_rdy_nxt = 1'b0;    t_hndshk_state_nxt = DEASSERT_T_RDY;    t_data_nxt = 'd0;   end   else begin    t_rdy_nxt = 1'b1;    t_data_nxt = transmit_data;   end  end
  DEASSERT_T_RDY:begin   if(!r_ack_tclk)begin    if(data_avail)begin     t_rdy_nxt = 1'b1;     t_hndshk_state_nxt = ASSERT_T_RDY;     t_data_nxt = transmit_data;    end    else begin     t_hndshk_state_nxt = IDLE_T;    end   end  end
 endcaseendalways@(posedge tclk or negedge reset_tclk)begin if(!reset_tclk)begin  t_rdy <= 1'b0;  t_hndshk_state <= IDLE_T;  t_data <= 32'h00000000;  r_ack_tclk <= 1'b0; end
 else begin  t_rdy <= t_rdy_nxt;  t_hndshk_state <= t_hndshk_state_nxt;  t_data <= t_data_nxt;  r_ack_tclk <= r_ack; end
endendmodule

接收端狀態(tài)機(jī):

97e481b2-19f6-11ed-ba43-dac502259ad0.jpg


module receiver(rclk,reset_rclk,t_rdy,t_data,r_ack);input rclk,reset_rclk;input t_rdy;input[31:0] t_data;output r_ack;
reg r_hndshk_state,r_hndshk_state_nxt;reg t_rdy_rclk;reg[31:0] t_data_rclk,t_data_rclk_nxt;reg r_ack,r_ack_nxt;
localparam IDLE_R = 1'b0,    ASSERT_ACK = 1'b1;
always@(*)begin r_hndshk_state_nxt = r_hndshk_state; r_ack_nxt = 1'b0; t_data_rclk_nxt = t_data_rclk; case(r_hndshk_state)  IDLE_R:begin   if(t_rdy_rclk)begin    r_hndshk_state_nxt = ASSERT_ACK;    t_data_rclk_nxt = t_data;    r_ack_nxt = 1'b1;   end  end
  ASSERT_ACK:begin   if(!t_rdy_rclk)begin    r_hndshk_state_nxt = IDLE_R;    r_ack_nxt = 1'b0;   end   else begin    r_ack_nxt = 1'b1;   end  end
 endcaseend
always@(posedge rclk or negedge reset_rclk)begin if(!reset_rclk)begin  r_hndshk_state <= IDLE_R;  t_data_rclk <= 1'b0;  t_rdy_rclk <= 1'b0;  r_ack <= 1'b0; end
 else begin  r_hndshk_state <= r_hndshk_state_nxt;  t_data_rclk <= t_data_rclk_nxt;  t_rdy_rclk <= t_rdy;  r_ack <= r_ack_nxt; endend
endmodule

握手機(jī)制的缺點

一個字:慢。

好了,希望本文對大家有所幫助。

審核編輯 :李倩

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 數(shù)字電路
    +關(guān)注

    關(guān)注

    193

    文章

    1608

    瀏覽量

    80680
  • 代碼
    +關(guān)注

    關(guān)注

    30

    文章

    4798

    瀏覽量

    68726
  • 脈沖信號
    +關(guān)注

    關(guān)注

    6

    文章

    399

    瀏覽量

    37009

原文標(biāo)題:談?wù)剶?shù)字芯片中的握手協(xié)議

文章出處:【微信號:IP與SoC設(shè)計,微信公眾號:IP與SoC設(shè)計】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    如何監(jiān)測TCP三次握手過程

    在計算機(jī)網(wǎng)絡(luò)中,傳輸控制協(xié)議(TCP)是確保數(shù)據(jù)可靠傳輸?shù)年P(guān)鍵協(xié)議之一。TCP通過三次握手過程來建立兩個端點之間的連接,這個過程對于網(wǎng)絡(luò)通信的穩(wěn)定性和安全性至關(guān)重要。 TCP三次握手
    的頭像 發(fā)表于 01-06 09:20 ?152次閱讀

    TCP三次握手與負(fù)載均衡的配置

    在計算機(jī)網(wǎng)絡(luò)中,TCP(傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。它通過三次握手(Three-way Handshake)建立連接,確保數(shù)據(jù)的可靠傳輸。而負(fù)載均衡(Load
    的頭像 發(fā)表于 01-06 09:15 ?159次閱讀

    TCP三次握手如何影響網(wǎng)絡(luò)性能

    在計算機(jī)網(wǎng)絡(luò)中,TCP是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。它通過三次握手過程來建立兩個網(wǎng)絡(luò)實體之間的連接,確保數(shù)據(jù)傳輸?shù)目煽啃院晚樞蛐浴?TCP三次握手的過程 SYN(同步
    的頭像 發(fā)表于 01-06 09:13 ?155次閱讀

    TCP三次握手的常見問題及解決方案

    TCP三次握手(Three-way Handshake)是TCP(傳輸控制協(xié)議)建立連接時的一個過程,它確保了兩個端點在開始通信之前都準(zhǔn)備好了。這個過程包括三次通信:SYN(同步),SYN-ACK
    的頭像 發(fā)表于 01-06 09:11 ?170次閱讀

    TCP三次握手與連接建立的關(guān)系

    在計算機(jī)網(wǎng)絡(luò)中,TCP(傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。它負(fù)責(zé)在兩個主機(jī)之間建立、維護(hù)和終止連接,確保數(shù)據(jù)的可靠傳輸。TCP連接的建立過程是通過三次握手
    的頭像 發(fā)表于 01-06 09:09 ?150次閱讀

    TCP三次握手的步驟詳解

    1.TCP是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。在兩個主機(jī)之間建立通信之前,必須通過三次握手過程來建立一個穩(wěn)定的連接。這個過程確保了兩個端點都準(zhǔn)備好發(fā)送和接收數(shù)據(jù)。 2. 第一次握手
    的頭像 發(fā)表于 01-06 09:07 ?155次閱讀

    TCP三次握手的網(wǎng)絡(luò)抓包分析

    在計算機(jī)網(wǎng)絡(luò)中,TCP(傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。TCP通過三次握手過程建立兩個通信實體之間的連接,確保數(shù)據(jù)傳輸?shù)目煽啃院晚樞蛐浴?TCP三次握手
    的頭像 發(fā)表于 01-06 09:05 ?149次閱讀

    TCP三次握手安全性分析

    TCP(傳輸控制協(xié)議)的三次握手是建立可靠連接的重要機(jī)制,它確保了通信雙方在數(shù)據(jù)傳輸前的連接狀態(tài)是可靠和準(zhǔn)確的。然而,從安全性的角度來分析,TCP三次握手并非無懈可擊,以下是對其安全性
    的頭像 發(fā)表于 01-03 18:10 ?442次閱讀

    TCP三次握手與UDP的區(qū)別

    在計算機(jī)網(wǎng)絡(luò)中,數(shù)據(jù)傳輸?shù)目煽啃院托适莾蓚€關(guān)鍵因素。為了滿足不同的應(yīng)用需求,設(shè)計者們開發(fā)了多種傳輸層協(xié)議。其中,TCP(傳輸控制協(xié)議)和UDP(用戶數(shù)據(jù)報協(xié)議)是最常用的兩種。它們在數(shù)據(jù)傳輸
    的頭像 發(fā)表于 01-03 17:35 ?330次閱讀

    TCP三次握手的基本原理

    在計算機(jī)網(wǎng)絡(luò)中,TCP(傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。它確保了數(shù)據(jù)在網(wǎng)絡(luò)中傳輸?shù)目煽啃院晚樞蛐?。為了建立兩個網(wǎng)絡(luò)實體之間的通信,TCP使用一種稱為“三次握手
    的頭像 發(fā)表于 01-03 17:25 ?428次閱讀

    TCP三次握手協(xié)議的作用

    在計算機(jī)網(wǎng)絡(luò)中,數(shù)據(jù)的傳輸需要在發(fā)送方和接收方之間建立一個穩(wěn)定的連接,以確保數(shù)據(jù)的完整性和順序。TCP(傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議,它通過三次握手協(xié)議
    的頭像 發(fā)表于 01-03 17:15 ?307次閱讀

    TCP三次握手的詳細(xì)過程

    TCP(傳輸控制協(xié)議)三次握手是一種在互聯(lián)網(wǎng)上建立一個可靠的、有序的和錯誤檢測能力的連接的方法。這個過程確保了兩個設(shè)備(通常是客戶端和服務(wù)器)在數(shù)據(jù)傳輸開始之前能夠相互確認(rèn)對方的存在和狀態(tài)。以下
    的頭像 發(fā)表于 01-03 17:11 ?325次閱讀

    簡述TCP協(xié)議的三次握手機(jī)制

    TCP(Transmission Control Protocol,傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。它主要用于在IP網(wǎng)絡(luò)中進(jìn)行數(shù)據(jù)傳輸。TCP協(xié)議的三次握手
    的頭像 發(fā)表于 08-16 10:57 ?1095次閱讀

    說說TCP三次握手的過程?為什么是三次而不是兩次、四次?

    三次而不是兩次或四次。 首先,我們需要了解TCP是一種面向連接的協(xié)議。在進(jìn)行數(shù)據(jù)傳輸之前,發(fā)送端和接收端需要建立一個可靠的連接。TCP三次握手就是用來建立這個連接的過程。 三次握手的過程如下: 第一步:發(fā)送端向接收端發(fā)送一個SY
    的頭像 發(fā)表于 02-04 11:03 ?703次閱讀

    TCP協(xié)議連接的三次握手

    通過三次握手,客戶端與服務(wù)端能夠確保彼此的網(wǎng)絡(luò)連接是可用的??蛻舳税l(fā)起的SYN報文和服務(wù)端返回的SYN+ACK報文都包含了對方的初始序列號和通信能力信息,通過互相確認(rèn)這些信息,雙方確認(rèn)彼此的能力和正確性。
    的頭像 發(fā)表于 02-03 16:44 ?1385次閱讀
    TCP<b class='flag-5'>協(xié)議</b>連接的三次<b class='flag-5'>握手</b>