AXIS-Skid Buffer
Skiiiiiidd
Please Log In for full access to the web site.
Note that this link will take you to an external site (https://shimmer.mit.edu) to authenticate, and then you will be redirected back to this page.
Design and Build a Skid Buffer
In lecture 11, we talked about skid buffers and what they do. It would be a good idea to make one since we can then dump it in front of our almost-but-not-quite AXIS-compliant modules that we've been writing and it will protect us. There's the larger issue about whether the mere propagation combinationally of the tready signal is indeed problematic, especially in small situations between logic that is known to be registered, but we can leave that up for debate. Having a nice skid buffer is a good idea and helpful.
For a skeleton to start here's some Verilog. Other than the interfaces for input and output streams, and a state enmum, there's really nothing else defined. You can write the rest since you the class elected to start this way.
`timescale 1ns / 1ps
`default_nettype none
//based on nice walkthrough and design here:
//https://fpgacpu.ca/fpga/Pipeline_Skid_Buffer.html
module skid_buffer #
(
parameter integer C_S00_AXIS_TDATA_WIDTH = 32,
parameter integer C_M00_AXIS_TDATA_WIDTH = 32
)
(
// Ports of Axi Slave Bus Interface S00_AXIS
input wire s00_axis_aclk, s00_axis_aresetn,
input wire s00_axis_tlast, s00_axis_tvalid,
input wire [C_S00_AXIS_TDATA_WIDTH-1 : 0] s00_axis_tdata,
input wire [(C_S00_AXIS_TDATA_WIDTH/8)-1: 0] s00_axis_tstrb,
output logic s00_axis_tready,
// Ports of Axi Master Bus Interface M00_AXIS
input wire m00_axis_aclk, m00_axis_aresetn,
input wire m00_axis_tready,
output logic m00_axis_tvalid, m00_axis_tlast,
output logic [C_M00_AXIS_TDATA_WIDTH-1 : 0] m00_axis_tdata,
output logic [(C_M00_AXIS_TDATA_WIDTH/8)-1: 0] m00_axis_tstrb
);
enum { EMPTY, BUSY, FULL } state;
endmodule
`default_nettype wire
A good skid buffer should follow the FSM below. Simple, yet also kinda complex.
I'd encourage you to approach this like a Moore FSM and also be verbose in writing your logic, including trying to define wires that are combinationally specified signals conveying the idea of "load", "unload", etc...having all these clearly named internal signals can make it helpful to debug and will also prove useful when we try to see and analyze how much of the state of possibility of this module is being "covered" in our verification journey.
OK that's it. May the Digital gods look upon your efforts favorably or favourably, whichever you prefer.
