cuckoo_cam is a dcp built on xcvu9p-flga2104-2L-e

[luyong6]

What is cuckoo_cam?
It is a checkpoint built on xcvu9p-flga2104-2L-e now. Is it possible to build it to other cards?
If it can also be generated by tcl or source RTLs that makes things more easier.
Thanks.

[mariodruiz]

CuckooCAM is a Content Addressable Memory based on the cuckoo hashing and other few improvements. It is used to convert an incoming three tuples to a unique ID. Maybe Figure 1 here gives a better understanding.
What board are you interested in? I could provide a dcp for that particular FPGA.

[luyong6]

Oh, xcvu37p-fsvh2892-2-e
I just realized that this dcp still passed the synthesis even the fpga_part has been changed to vu37p.

Maybe because it is just a synthesized netlist?
Please hold on and really appreciated.

[mariodruiz]

The current dcp should implement in any VirtexUltrascale+ except on VirtexUltrascale+ HBM.
Yes, it is a synthesized netlist for a family of devices.

The plan is to release the code, but there are some improvements to be done and more experiments.

[luyong6]

Thanks Mario

[luyong6]

Is there any plan to relase the code?
I realized although the bitstream was written, there were some bad timing paths around cuckoo_cam. I don't know whether this is the cause that I still didn't get rx_aligned.

[mariodruiz]

Hi @luyong6,
There is no plan to release the code at the moment.
This should not cause problems with the alignment, but I can be related.

Where are you connecting the FPGA to test link?

[luyong6]

Oh,

According to UG203 (Version 3.1, June24 2020)

I modified the FSM sequence in submodules/cmac/src/cmac_sync/cmac_0_axi4_lite_user_if.v

189                 STATE_INIT_RX_ALIGNED    : begin
190                      rx_busy_led_r           <= 1'b1;
191                      init_rx_aligned         <= 1'b1;
192
193                     case (rd_wr_cntr)
194                         'd0     : begin
195                             $display( "           AXI4 Lite Write Started to Config the Core CTL_* Ports ..." );
196                             axi_wr_data             <= 32'h00000001;           //// ctl_rx_enable
197                             axi_wr_addr             <= ADDR_CONFIG_RX_REG1 + SLAVE_CMAC_BASEADDR;    //// CONFIGURATION_RX_REG1
198                             axi_wr_addr_valid       <= 1'b1;
199                             axi_wr_data_valid       <= 1'b1;
200                             axi_wr_strobe           <= 4'hF;
201                             axi_rd_req              <= 1'b0;
202                             axi_wr_req              <= 1'b1;
203                         end
204                         'd1     : begin
205                             axi_wr_data             <= 32'h00000010;          //// ctl_tx_send_rfi, according to pg203, Version June 24, 2020
206 //                            if (ULTRASCALE_PLUS==0)
207 //                                axi_wr_data             <= 32'h00000010;          //// ctl_tx_send_rfi
208 //                            else
209 //                                axi_wr_data             <= 32'h00000018;          //// ctl_tx_send_lfi, ctl_tx_send_rfi
210                             axi_wr_addr             <= ADDR_CONFIG_TX_REG1 + SLAVE_CMAC_BASEADDR;   //// CONFIGURATION_TX_REG1
211                             axi_wr_addr_valid       <= 1'b1;
212                             axi_wr_data_valid       <= 1'b1;
213                             axi_wr_strobe           <= 4'hF;
214                             axi_rd_req              <= 1'b0;
215                             axi_wr_req              <= 1'b1;
216                         end

However, the rx_aligned seemed not get assigned. So I think this FSM was stuck in waiting for it.
I was using Vivado 2020.1, on a device with vu37p device.

The xdma driver was successfully loaded. Some information:

 sudo ./bin/reg_rw  /dev/xdma0_user 0x24
...
Read 32-bit value at address 0x00000024 (0x7f275c71c024): 0x00000301   CMAC subsystem version is correct: 3.1

sudo ./bin/reg_rw  /dev/xdma0_user 0xC
...
Read 32-bit value at address 0x0000000c (0x7f430b82200c): 0x00000010  (This means ctl_tx_send_rfi)
sudo ./bin/reg_rw  /dev/xdma0_user 0x14
Read 32-bit value at address 0x00000014 (0x7fde06d05014): 0x00000001 (This means ctl_rx_enable)
sudo ./bin/reg_rw  /dev/xdma0_user 0x204
Read 32-bit value at address 0x00000204 (0x7f651d54a204): 0x000000c0 (stat_rx_local_fault, stat_rx_internal_local_fault)

The same card, if I don't use AXI4Lite interface to configure the CMAC but directly assign ctl_tx_enable/ctl_rx_enable,
with a 100G cable connecting to a Mellanox CX4 card, it had rx_aligned, and CX4 card also said "Link UP".

[mariodruiz]

@luyong6 the bring up sequence change slightly. But, I am using the same code with Vivado 2020.1 and it is working. The fact that you can link up writing the registers from the host means that something is not working properly in the interconnection between the cmac_synq and cmac.
How is lbus_tx_rx_restart_in connected?
My block design is exactly this one

Maybe you can generate the example design for the CMAC with AXI4-Lite and check the code.

[edubeZetec]

Hi,
I want to port the design to a kintex device any chance you release de code ? or provide a .dcp for the kintex ?

Thx