I fixed all the Verilator warnings in #9 except for one. For this one I have three functionally equivalent solutions but they all introduce various levels of ugliness so I would like to have your input on which one to choose. Let me know which you prefer and I'll swing you another patch

Option 1

diff --git a/rtl/axis_arb_mux.v b/rtl/axis_arb_mux.v
index 72a3de5..130430b 100644
--- a/rtl/axis_arb_mux.v
+++ b/rtl/axis_arb_mux.v
@@ -66,7 +66,7 @@ module axis_arb_mux #
     input  wire [S_COUNT*DATA_WIDTH-1:0] s_axis_tdata,
     input  wire [S_COUNT*KEEP_WIDTH-1:0] s_axis_tkeep,
     input  wire [S_COUNT-1:0]            s_axis_tvalid,
-    output wire [S_COUNT-1:0]            s_axis_tready,
+    output reg [S_COUNT-1:0]            s_axis_tready,
     input  wire [S_COUNT-1:0]            s_axis_tlast,
     input  wire [S_COUNT*ID_WIDTH-1:0]   s_axis_tid,
     input  wire [S_COUNT*DEST_WIDTH-1:0] s_axis_tdest,
@@ -104,7 +104,10 @@ reg  [DEST_WIDTH-1:0] m_axis_tdest_int;
 reg  [USER_WIDTH-1:0] m_axis_tuser_int;
 wire                  m_axis_tready_int_early;
 
-assign s_axis_tready = (m_axis_tready_int_reg && grant_valid) << grant_encoded;
+always @* begin
+   s_axis_tready = {S_COUNT{1'b0}};
+   s_axis_tready[grant_encoded] = (m_axis_tready_int_reg && grant_valid);
+end

Option 2

diff --git a/rtl/axis_arb_mux.v b/rtl/axis_arb_mux.v
index 72a3de5..ea00ea9 100644
--- a/rtl/axis_arb_mux.v
+++ b/rtl/axis_arb_mux.v
@@ -104,7 +104,9 @@ reg  [DEST_WIDTH-1:0] m_axis_tdest_int;
 reg  [USER_WIDTH-1:0] m_axis_tuser_int;
 wire                  m_axis_tready_int_early;
 
+/* verilator lint_off WIDTH */
 assign s_axis_tready = (m_axis_tready_int_reg && grant_valid) << grant_encoded;
+/* verilator lint_on WIDTH */
 
 // mux for incoming packet
 wire [DATA_WIDTH-1:0] current_s_tdata  = s_axis_tdata[grant_encoded*DATA_WIDTH +: DATA_WIDTH];

Option 3

index 72a3de5..cbbe1ad 100644
--- a/rtl/axis_arb_mux.v
+++ b/rtl/axis_arb_mux.v
@@ -104,7 +104,7 @@ reg  [DEST_WIDTH-1:0] m_axis_tdest_int;
 reg  [USER_WIDTH-1:0] m_axis_tuser_int;
 wire                  m_axis_tready_int_early;
 
-assign s_axis_tready = (m_axis_tready_int_reg && grant_valid) << grant_encoded;
+assign s_axis_tready = {{S_COUNT-1{1'b0}},(m_axis_tready_int_reg && grant_valid)} << grant_encoded;
 
 // mux for incoming packet
 wire [DATA_WIDTH-1:0] current_s_tdata  = s_axis_tdata[grant_encoded*DATA_WIDTH +: DATA_WIDTH];

Steps to reproduce:

1. Push data into a dual clock FIFO with back pressure applied by holding output_axis_tready low.
2. Reset the FIFO.
3. Release the FIFO reset and the data will then come out.

Expected behaviour: resetting will empty the FIFO.

Dear alexforencich,
when using axis_async_fifo.v in this repository, I met some questions and I'm not sure whether it's just designed for this, so I want to seek for help for these quesions:
1.if I just write data in this fifo, and don't read→ that means m_axis_tready keep deasserted, in this situation, store_output will assert , and fifo is not empty, so it will perform read, and rd_ptr_reg will continually plus 1 until empty is asserted , but in fact I am not ready to read, these data will be ignored.
2. In this fifo's read logic, it seems that tvalid's asserting depends on whether tready is asserted or not, but axi4s protocol said that 'it's not permitted to wait until TREADY is asserted before asserting TVALID'.
Hoping for you advice for these questions,thanks!

Hi Alex,
Thanks for the great IP.
Can you explain concept of the frame WRT AXI-S, and how you use it?
Thanks
Mike

1. use TKEEP and TLAST signal;
2. Slave width is 250 bytes;
3. Master width is 4 bytes;

250 = 62 * 4 + 2, then the last 2 bytes lost

Hi I am looking at this specific commit 40acee1bc59c8091c65cedfa470cc16cbce8e6bb.

The module "axis_async_fifo" has a write clock domain (driven by s_clk) and a read clock domain (driven by m_clk). To my understanding, the CDC strategy used in the write domain -> read domain direction is a mux-controlled CDC, i.e., the read domain will only accept the gray pointer from write domain if the update signal generated from write domain is propagated from write to read domain. Also, any updates to the write pointer will be delayed until the ACK for the update signal is propagated back to the write domain.

Above is the case for write -> read direction. However, in read -> write direction, it seems to me we only use 2-flop synchronizer (without any ACK signal) to sync the read pointer from read to write domain.

Q1: Is there a reason why the ACK signal is needed in the write -> read direction? Can't we just simply use 2-flop synchronizer like we do in the read -> write direction?

Q2: Why the pipeline registers in "axis_async_fifo" are needed to sync the read output from the memory? Isn't the read result already synced to the read clock? (based on my assumption that the memory is 1r1w synchronous with separate read/write clocks)

Thanks!

@alexforencich I ran stimulus (two AXI Stream interfaces) through the axis_mux.v module and it seems to be missing the tvalid on the first beat on the m_axis output. So, if i transmit send it a transaction of 16 beats, I only get 15 tvalid's out. tdata is correct though. Can you confirm this?

Hi. I'm trying to use axis_frame_length_adjust_fifo in such a way that length_max * HEADER_FIFO_DEPTH << FRAME_FIFO_DEPTH. In this situation, the fifo with headers is filled first. The input AXI interface of the axis_frame_length_adjust module looks fine. But the AXI output interface continues to keep a high level of the m_axis_valid signal at the end of the transaction. Thus, the data FIFO is filled with invalid data and when reading a data packet, its length does not correspond to the length that got into the fifo of the headers.

tuser is supposed to line up with tvalid and tready but it is not hence the reason why in the axis_async_fifo_adapter no tuser is not propagated through the asynchronous FIFO.
This case might not have been tested because tuser in network interfaces is not used but it is the start of frame for axis video while tlast is the end of line .

Will look at the code and come up with a solution.

Thank you,

Wim

Quartus gives HOLD slack using the quartus and quartus_pro constraint files.

• rd_ptr_gray_reg[1] rd_ptr_gray_sync1_reg[1]
• rd_ptr_gray_reg[0] rd_ptr_gray_sync1_reg[0]
• rd_ptr_gray_reg[2] rd_ptr_gray_sync1_reg[2]
• wr_ptr_update_sync3_reg wr_ptr_update_ack_sync1_reg

The problem is the Data Required Path, clock path:

So firstly, thank you for these modules, they've been super useful to me as somebody still new to RTL design.

I just want to confirm my findings on the axis_adapter. I hooked it up to your great axis_uart module and found that when I send [b'\xbf', b'\x80'] in that order over UART, the Xilinx ILA shows the output of the axis_adapter as b'\x80\xbf'. It seems to me that the axis_adapter is expecting things in little-endian byte/word order, but the bytes/words themselves are big-endian. Is this part of the AXI4 standard or can I submit a PR to make a flag parameter that changes the word order?

Additionally, is this accomplished by simply replace indexing instances of seg_reg with (SEG_COUNT - seg_reg - 1)?

python some module file giving module error how to solve it??? alleast give some file related info in each file

I used the axis_fifo module in a design and it wasn't working due to some issues with the depth of the memory. After some digging I found that the KEEP_ENABLE parameter causes the FIFO depth to shrink based on how many tkeep bits there are.

parameter ADDR_WIDTH = (KEEP_ENABLE && KEEP_WIDTH > 1) ? $clog2(DEPTH/KEEP_WIDTH) : $clog2(DEPTH);

Is there a reason the tkeep is impacting the depth of the FIFO? If I force the code to always use $clogs(DEPTH) then it works great. If there's a reason it was done this way I'd like to understand it in order to use the IP as-is instead of modifying it in my project.

The version I'm using isn't the latest, but I see the same line in the current version.

If there is a barrage of back to back single transfer packets (with last set on every transfer) the internal frame length counter doesn't clear. So instead the output frame length for each packet continues to grow in size, accumulating larger with each single transfer packet.

Hi,
In the axis_adapter module, if the S_KEEP_ENABLE parameter is disabled, the tkeep input signal should be taken as 1'b1. This was the case in the previous version of the module. In the current version, if the s_axis_tkeep port is set to 1'b0, then this value participates in the logic of the module.

In order to see it in tests, you need to change the test. For example

diff --git a/tb/axis_adapter/Makefile b/tb/axis_adapter/Makefile
index 3e06415..730b77b 100644
--- a/tb/axis_adapter/Makefile
+++ b/tb/axis_adapter/Makefile
@@ -35,7 +35,7 @@ VERILOG_SOURCES += ../../rtl/$(DUT).v
 export PARAM_S_DATA_WIDTH := 8
 export PARAM_S_KEEP_ENABLE := $(shell expr $(PARAM_S_DATA_WIDTH) \> 8 )
 export PARAM_S_KEEP_WIDTH := $(shell expr \( $(PARAM_S_DATA_WIDTH) + 7 \) / 8 )
-export PARAM_M_DATA_WIDTH := 8
+export PARAM_M_DATA_WIDTH := 64
 export PARAM_M_KEEP_ENABLE := $(shell expr $(PARAM_M_DATA_WIDTH) \> 8 )
 export PARAM_M_KEEP_WIDTH := $(shell expr \( $(PARAM_M_DATA_WIDTH) + 7 \) / 8 )
 export PARAM_ID_ENABLE := 1
diff --git a/tb/axis_adapter/test_axis_adapter.py b/tb/axis_adapter/test_axis_adapter.py
index 5997d61..e49f7d1 100644
--- a/tb/axis_adapter/test_axis_adapter.py
+++ b/tb/axis_adapter/test_axis_adapter.py
@@ -88,6 +88,7 @@ async def run_test(dut, payload_lengths=None, payload_data=None, idle_inserter=N
 
     for test_data in [payload_data(x) for x in payload_lengths()]:
         test_frame = AxiStreamFrame(test_data)
+        if tb.source.byte_lanes == 1: test_frame.tkeep = [0]*len(test_data)
         test_frame.tid = cur_id
         test_frame.tdest = cur_id

Besides, the test script tb/test_axis_adapter_8_64.py with the current version of the module hangs in an infinite loop.

BR,
Pavel

I'm using the axis_fifo_adapter with an input data width of 32 and output data width of 8. I was surprised to see that the output data stream seems to come out in little endian. For example if the input data word is "DEAD_BEEF", it's coming out of the FIFO as "EF", "BE", "AD", "DE".

Is this by design? I would have expected the fifo to use Netowrk byte order or have an option to do that. Am I doing something wrong?

Defined here and assigned here but never used.

I'm not sure where these should be documented but it would be nice for the user to have a template to get the constraints right for Vivado. After, poking around in the FIFO from Xilinx and Xilinx forums, this works for me:

#grey coded counter synchronizers in  get a max_delay -datapath only
set wrclk [get_clocks -of_objects [get_ports input_clk]]
set rdclk [get_clocks -of_objects [get_ports output_clk]]
set_max_delay -from [get_cells fifo_inst/wr_ptr_gray_reg_reg[*]] -to [get_cells fifo_inst/wr_ptr_gray_sync1_reg_reg[*]] -datapath_only [get_property -min PERIOD $wrclk]
set_max_delay -from [get_cells fifo_inst/rd_ptr_gray_reg_reg[*]] -to [get_cells fifo_inst/rd_ptr_gray_sync1_reg_reg[*]] -datapath_only [get_property -min PERIOD $rdclk]

#set ASYNC_REG property for all registers in the grey code synchronizer chain
set_property ASYNC_REG TRUE [get_cells -regexp {fifo_inst/(wr|rd)_ptr_gray_sync[12]_reg_reg\[\d+\]}]

#ASYNC_REG property and false path to the reset synchronizer
set_property ASYNC_REG TRUE [get_cells -regexp {fifo_inst/(input|output)_rst_sync[123]_reg_reg}]
set_false_path -to [get_cells -regexp {fifo_inst/(input|output)_rst_sync[123]_reg_reg}]
set_false_path -from [get_cells fifo_inst/output_rst_sync1_reg_reg] -to [get_cells fifo_inst/input_rst_sync2_reg_reg]

While going after the items reported by the CDC related DRCs of intel quartus 21.3, most of the items seem to be OK from an RTL perspective. But one item catched my eye, which is

I don't get the reason why it is OK in FRAME_FIFO mode to read the first stage of the synchronisation chain of the write pointer.

Another item is that in CDCs it is usually not a good idea to add logic in between the last flop of the source clock and the first flop of the destination clock, see

Hi,

I'm using your core in a larger code base which has another module called arbiter which is a bit tricky to handle nicely. Would you consider renaming the one here to something like verilog_axis_arbiter?