रजिस्टर इंटरफेस और पार्श्व प्रभाव का समय

“रजिस्टर में लिखना” परिभाषित करें

पूर्वज्ञान: पता डिकोडर^{iडिकोडर द्विआधारी कोड के अनुरूप आउटपुट लाइन सक्रिय करता है। enable होने पर निष्क्रिय अवस्था में सभी आउटपुट 0 रखे जा सकते हैं। और जानें}, ready/valid^{iहैंडशेक उसी किनारे पर प्रेषक का valid और ग्रहणकर्ता का ready दोनों 1 होने पर हस्तांतरण निश्चित करने वाला अनुबंध। प्रतीक्षा के दौरान डेटा बनाए रखने के नियम भी इसका हिस्सा हैं। और जानें}, enable और अवस्था अपडेट की प्राथमिकता।

सेटिंग रजिस्टर^{iरजिस्टर कई बिटों की अवस्था संग्रहित करता है। इस पाठ्यक्रम के तुल्यकालिक रजिस्टर निर्धारित इनपुट को क्लॉक एज पर संग्रहित करते हैं। और जानें} बाहरी नियंत्रक से जोड़ते समय केवल पता मिलने की जाँच पर्याप्त नहीं है। अनुरोध कब स्वीकार हुआ, उत्तर प्रतीक्षा करते समय क्या स्थिर रहना चाहिए और केवल पढ़ने योग्य पते पर लिखने का क्या परिणाम होगा—ये भी तय करें। यहाँ समान क्लॉक वाला सरल एकल अनुरोध-उत्तर इंटरफेस उपयोग करते हैं।

नीचे बाइट पते हैं और वे 32-बिट सीमा पर संरेखित हैं। हर अनुरोध ठीक एक सफल या त्रुटि उत्तर बनाता है।

उत्तर का स्थान खाली हो या इसी एज पर खाली हो, तभी अनुरोध लें

module register_interface (
    input  logic        clk, rst,
    input  logic        req_valid, req_write,
    output logic        req_ready,
    input  logic [3:0]  req_addr,
    input  logic [31:0] req_wdata,
    input  logic [3:0]  req_wstrb,
    output logic        rsp_valid,
    input  logic        rsp_ready,
    output logic [31:0] rsp_rdata,
    output logic        rsp_error,
    input  logic [31:0] status_value,
    output logic [31:0] config_value,
    output logic        start_pulse
);
    assign req_ready = !rsp_valid || rsp_ready;
    always_ff @(posedge clk) begin
        if (rst) begin
            rsp_valid    <= 1'b0;
            config_value <= 32'd0;
            start_pulse  <= 1'b0;
        end else begin
            start_pulse <= 1'b0;
            if (req_ready) begin
                rsp_valid <= req_valid;
                if (req_valid) begin
                    rsp_rdata <= 32'd0;
                    rsp_error <= 1'b0;
                    case (req_addr)
                        4'h0: begin
                            if (req_write) begin
                                for (int i=0; i<4; i++)
                                    if (req_wstrb[i])
                                        config_value[8*i +: 8]
                                            <= req_wdata[8*i +: 8];
                            end else rsp_rdata <= config_value;
                        end
                        4'h4: begin
                            if (req_write) rsp_error <= 1'b1;
                            else rsp_rdata <= status_value;
                        end
                        4'h8: begin
                            if (req_write)
                                start_pulse <= req_wstrb[0] && req_wdata[0];
                        end
                        default: rsp_error <= 1'b1;
                    endcase
                end
            end
        end
    end
endmodule

उत्तर रुके तो req_ready=0 है, इसलिए config लेखन और command पल्स फिर नहीं चलते। स्वीकार अनुरोध का पार्श्व प्रभाव हो चुका हो सकता है जबकि केवल उत्तर प्रतीक्षा कर रहा हो। उत्तर में विलंब देखकर बिना शर्त अनुरोध फिर भेजना आदेश दो बार चला सकता है।

Byte strobe का प्रभाव निकालें

CONFIG=32'h11223344 होने पर req_wdata=32'hAABBCCDD,req_wstrb=4'b0101 लिखें तो केवल byte 0 और byte 2 बदलते हैं। परिणाम 32'h11BB33DD है। पते का संरेखण, बिट स्थान और मेमोरी का बाइट क्रम अलग-अलग जाँचें। wstrb=0000 वाला लेखन सफल उत्तर बनाता है, लेकिन मान नहीं बदलता।

MSB^{iMSB सबसे अधिक स्थानिक भार वाला बिट। उसका इंडेक्स वेक्टर की घोषणा की दिशा पर निर्भर है; उसे हमेशा सबसे बड़ा इंडेक्स न मानें। और जानें} से क्रम byte 3,2,1,0 है। Strobe=0101, byte 2 और byte 0 चुनता है, इसलिए केवल BB और DD नए लिखे जाते हैं। Strobe एक डेटा बिट का नहीं, एक बाइट का write enable है।

अवस्था किस समय की है

STATUS पढ़ने का उत्तर, अनुरोध स्वीकृति के समय का status_value सहेजता है। उसके बाद उत्तर रुका रहने पर वास्तविक status बदले तो भी rsp_rdata बना रहता है। rsp_valid=1,rsp_ready=0 में संयोजी status सीधे उत्तर से जोड़ने पर उत्तर की सामग्री बदल जाएगी, जो प्रोटोकॉल उल्लंघन है।

लगातार एज पर req_valid और req_ready दोनों 1 हों तो वे दो अलग अनुरोध हैं। स्वीकृति के बाद भेजने वाला valid घटाए या अगला अनुरोध प्रस्तुत करे। एक ही अनुरोध बनाए रखकर केवल एक निष्पादन की अपेक्षा नहीं कर सकता।

सत्यापन के तीन पहलू

1. पता और अनुमति: मान्य पता, असंरेखित पता, STATUS लेखन और अपरिभाषित पते पर त्रुटि तथा पार्श्व प्रभाव जाँचें।
2. डेटा चयन: चार strobe बिटों के सभी संयोजन जाँचें और सुनिश्चित करें कि निष्क्रिय बाइट सुरक्षित हैं।
3. प्रवाह नियंत्रण: उत्तर कई चक्र रोकने पर भी उत्तर और अवस्था सुरक्षित रहें; उत्तर लेने और अगला अनुरोध स्वीकार करने के एक साथ होने पर लेनदेन की संख्या मेल खाए।