在上一篇文章中（FPGA 的數字信號處理：Verilog 實現簡單的 FIR 濾波器）演示了在 Verilog 中編寫自定義 FIR 模塊的初始demo。該項目在行為仿真中正常，但在布局和布線時未能滿足時序要求。

所以今天的文章讓我們來看看當設計不能滿足時序要求時如何分析并解決它。

當在目標 FPGA 芯片中布局和布線時，首先在 Vivado 中確定時序要求.

將 FIR 作為RTL 模塊導入到block design中，其中通過AXI DMA 從存儲器傳輸相位增量偏移值的DDS可以輸入可變頻率正弦曲線，這樣就可以演示FIR的行為。

在 Vivado 中綜合布局布線并打開設計后，會彈出嚴重警告，告知設計不符合時序要求。

為了能夠準確查看設計時序失敗的原因，在已完成綜合設計的底部窗口包含一個選項卡，用于 Vivado 在綜合期間對設計執行的時序分析。當存在時序失敗的信號路徑時，用戶可以過濾此時序分析以僅使用下圖中顯示的紅色圓圈感嘆號查看這些違規路徑：

在這個特定的設計中，有幾個信號路徑未能達到其分配的時序，這意味著信號的物理距離太遠而無法穿過芯片和/或在信號出去之前需要通過太多的邏輯級別。保持時間太長的信號意味著當將其計時到下一級寄存器中時，不能依賴它的值是否有效，從而使其余下游邏輯的行為不可靠/不可預測。

s_axis_fir_tdata在這種情況下，進入 FIR 模塊的 AXI Stream 輸入接口的數據信號需要很長時間才能到達m_axis_fir_tdata目標寄存器處的輸出。要查看比屏幕底部的時序分析窗口中的內容更多的詳細信息，右鍵單擊底部時序分析窗口中的違規信號路徑，然后選擇“查看路徑報告（View Path Report）”選項。然后，將能夠看到 Vivado 如何計算出該信號的允許建立時間，并與它實際給出的 HDL 設計編寫方式進行比較。這會給一些提示，說明是什么導致建立時間延長。然而，我發現要真正可視化保持時序違規比在示意圖中查看信號會更直觀。

要在原理圖中打開特定信號路徑，再次右鍵單擊底部時序分析窗口中的違規信號路徑，然后選擇“Schematic”選項。將打開一個新選項卡，顯示信號路徑在設計的物理布局中經過的邏輯。

在為axis_fir_tdata的數據總線中的一個位打開信號路徑時，它揭示了設計在芯片中的布線，從圖中可以看出信號必須通過 11 級邏輯串行后才能到達其目的地。

既然對已實施設計的分析已經揭示了哪些信號路徑是哪個時序違規的問題，現在的問題是我們如何解決它？在這種情況下，很明顯需要重新設計當前邏輯，以更并行的方式處理更小的數據塊，從而縮短數據到其目標寄存器的總路徑。

個人更喜歡在嘗試編寫任何實際的 Verilog 代碼之前繪制出邏輯。當有這種設計執行的操作的可視化表示時，調試設計會容易得多，特別是對于跟蹤此類時序違規等問題。

檢查當前 FIR 模塊的邏輯設計，其中數據總線違反了建立時序，很明顯循環緩沖區串行填充然后將所有 15 個數據發送到累加塊時，立即求和會產生大量的處理延遲。

核心的想法是嘗試填充循環緩沖區，將每個緩沖區乘以適當的系數，最后一次性對 15 個算子的每一個求和，但是這次我們考慮重新設計邏輯，讓循環緩沖區中僅花費乘法和累加（求和）兩個寄存器一個級聯的時間。

新 FIR 模塊的 Verilog 代碼：

`timescale1ns/1ps

moduleFIR(
inputclk,
inputreset,
inputsigned[15:0]s_axis_fir_tdata,
input[3:0]s_axis_fir_tkeep,
inputs_axis_fir_tlast,
inputs_axis_fir_tvalid,
inputm_axis_fir_tready,
outputregm_axis_fir_tvalid,
outputregs_axis_fir_tready,
outputregm_axis_fir_tlast,
outputreg[3:0]m_axis_fir_tkeep,
outputregsigned[31:0]m_axis_fir_tdata
);

/*ThisloopcontrolstkeepsignalonAXIStreaminterface*/
always@(posedgeclk)
begin
m_axis_fir_tkeep<=?4'hf;
????????end
????????
????/*?This?loop?controls?tlast?signal?on?AXI?Stream?interface?*/
????always?@?(posedge?clk)
????????begin
????????????if?(s_axis_fir_tlast?==?1'b1)
????????????????begin
????????????????????m_axis_fir_tlast?<=?1'b1;
????????????????end
????????????else
????????????????begin
????????????????????m_axis_fir_tlast?<=?1'b0;
????????????????end
????????end
????
????//?15-tap?FIR?
????reg?enable_fir;
????reg?signed?[15:0]?buff0,?buff1,?buff2,?buff3,?buff4,?buff5,?buff6,?buff7,?buff8,?buff9,?buff10,?buff11,?buff12,?buff13,?buff14;
????wire?signed?[15:0]?tap0,?tap1,?tap2,?tap3,?tap4,?tap5,?tap6,?tap7,?tap8,?tap9,?tap10,?tap11,?tap12,?tap13,?tap14;?
????reg?signed?[31:0]?acc0,?acc1,?acc2,?acc3,?acc4,?acc5,?acc6,?acc7,?acc8,?acc9,?acc10,?acc11,?acc12,?acc13,?acc14;?

????
????/*?Taps?for?LPF?running?@?1MSps?*/
????assign?tap0?=?16'hFC9C;??//?twos(-0.0265?*?32768)?=?0xFC9C
????assign?tap1?=?16'h0000;??//?0
????assign?tap2?=?16'h05A5;??//?0.0441?*?32768?=?1445.0688?=?1445?=?0x05A5
????assign?tap3?=?16'h0000;??//?0
????assign?tap4?=?16'hF40C;??//?twos(-0.0934?*?32768)?=?0xF40C
????assign?tap5?=?16'h0000;??//?0
????assign?tap6?=?16'h282D;??//?0.3139?*?32768?=?10285.8752?=?10285?=?0x282D
????assign?tap7?=?16'h4000;??//?0.5000?*?32768?=?16384?=?0x4000
????assign?tap8?=?16'h282D;??//?0.3139?*?32768?=?10285.8752?=?10285?=?0x282D
????assign?tap9?=?16'h0000;??//?0
????assign?tap10?=?16'hF40C;?//?twos(-0.0934?*?32768)?=?0xF40C
????assign?tap11?=?16'h0000;?//?0
????assign?tap12?=?16'h05A5;?//?0.0441?*?32768?=?1445.0688?=?1445?=?0x05A5
????assign?tap13?=?16'h0000;?//?0
????assign?tap14?=?16'hFC9C;?//?twos(-0.0265?*?32768)?=?0xFC9C
????
????/*?This?loop?controls?tready?&?tvalid?signals?on?AXI?Stream?interface?*/
????always?@?(posedge?clk)
????????begin
????????????if(reset?==?1'b0?||?m_axis_fir_tready?==?1'b0?||?s_axis_fir_tvalid?==?1'b0)
????????????????begin
????????????????????enable_fir?<=?1'b0;
????????????????????s_axis_fir_tready?<=?1'b0;
????????????????????m_axis_fir_tvalid?<=?1'b0;
????????????????end
????????????else
????????????????begin
????????????????????enable_fir?<=?1'b1;
????????????????????s_axis_fir_tready?<=?1'b1;
????????????????????m_axis_fir_tvalid?<=?1'b1;
????????????????end
????????end
????
????reg?[3:0]?cnt;
????reg?signed?[31:0]?acc01,?acc012,?acc23,?acc34,?acc45,?acc56,?acc67,?acc78,?acc89,?acc910,?acc1011,?acc1112,?acc1213;
????
????/*?Circular?buffer?w/?Multiply?&?Accumulate?stages?of?FIR?*/
????always?@?(posedge?clk?or?posedge?reset)
????????begin
????????????if?(reset?==?1'b0)
????????????????begin
????????????????????m_axis_fir_tdata?<=?32'd0;
????????????????end
????????????else?if?(enable_fir?==?1'b1)
????????????????begin
????????????????????buff0?<=?s_axis_fir_tdata;
????????????????????acc0?<=?tap0?*?buff0;
????????????????????
????????????????????buff1?<=?buff0;?
????????????????????acc1?<=?tap1?*?buff1;??
????????????????????acc01?<=?acc0?+?acc1;
?????????????????????????
????????????????????buff2?<=?buff1;?
????????????????????acc2?<=?tap2?*?buff2;
????????????????????acc012?<=?acc01?+?acc2;
????????????????????????????
????????????????????buff3?<=?buff2;?
????????????????????acc3?<=?tap3?*?buff3;
????????????????????acc23?<=?acc012?+?acc3;
?????????????????????????
????????????????????buff4?<=?buff3;?
????????????????????acc4?<=?tap4?*?buff4;
????????????????????acc34?<=?acc23?+?acc4;
?????????????????????????
????????????????????buff5?<=?buff4;
????????????????????acc5?<=?tap5?*?buff5;?
????????????????????acc45?<=?acc34?+?acc5;
??????????????????????????
????????????????????buff6?<=?buff5;?
????????????????????acc6?<=?tap6?*?buff6;
????????????????????acc56?<=?acc45?+?acc6;
???????????????????????
????????????????????buff7?<=?buff6;?
????????????????????acc7?<=?tap7?*?buff7;
????????????????????acc67?<=?acc56?+?acc7;
??????????????????????????
????????????????????buff8?<=?buff7;
????????????????????acc8?<=?tap8?*?buff8;
????????????????????acc78?<=?acc67?+?acc8;
???????????????????????????
????????????????????buff9?<=?buff8;?
????????????????????acc9?<=?tap9?*?buff9;
????????????????????acc89?<=?acc78?+?acc9;
??????????????????????????
????????????????????buff10?<=?buff9;?
????????????????????acc10?<=?tap10?*?buff10;
????????????????????acc910?<=?acc89?+?acc10;
???????????????????????????
????????????????????buff11?<=?buff10;?
????????????????????acc11?<=?tap11?*?buff11;
????????????????????acc1011?<=?acc910?+?acc11;
??????????????????????????
????????????????????buff12?<=?buff11;?
????????????????????acc12?<=?tap12?*?buff12;
????????????????????acc1112?<=?acc1011?+?acc12;
??????????????????????????
????????????????????buff13?<=?buff12;?
????????????????????acc13?<=?tap13?*?buff13;
????????????????????acc1213?<=?acc1112?+?acc13;
??????????????????????????
????????????????????buff14?<=?buff13;?
????????????????????acc14?<=?tap14?*?buff14;
????????????????????m_axis_fir_tdata?<=?acc1213?+?acc14;
????????????????????
????????????????end
????????end
????
endmodule

使用新 FIR 模塊的 Verilog 代碼重新運行綜合布局布線后就可以產生滿足所有時序要求的設計。打開之前違反建立時序的相同數據信號路徑的原理圖，可以直觀地證明信號路徑是如何整體縮短的。

新原理圖顯示axis_fir_tdata總線中每個位的信號路徑都被并行處理，有效地縮短了它們到達目標寄存器的時間，這就是減少信號建立時間的原因。

當新設計滿足時序要求時，接下來就是驗證重寫后的邏輯是否仍然與舊邏輯一樣。重新運行行為仿真將很快回答這個問題。

由于希望用新代碼替換之前的邏輯，發現設置斷點并在更新波形圖時單步執行 Verilog 的每一行的功能可以實現我們的目的。

啟動行為仿真后，會注意到 HDL 的每條有效行的行號右側都有一個紅色圓圈。單擊這些紅色圓圈之一將啟用該行上的斷點。

當仿真運行并遇到該斷點時，可以使用頂部工具欄中的“步進”按鈕（如下所示）或 F8 來逐步執行剩余的代碼行。

最后，我們看到 FIR 濾波器的新邏輯設計確實按預期運行！

總結

上面的兩個例子能證明在目標 FPGA 芯片上，最終輸出相同結果的兩種不同的 HDL 編寫方式對時序影響不同的重要性。這就是為什么在編寫代碼腦中“有電路”是很重要的原因。

審核編輯：湯梓紅