Post Go back to editing

ZCU102 + ADRV9009 HDL implementation fail

Category: Choose a category
Product Number: ADRV9009 with ZCU102
Software Version: 2021_r1

I have downloaded the latest HDL for ZCU102 attached with ADRV9008-1W. HDL version is for ADRV9009. I have only modified the design to have hierarchy blocks in it. After arranging the individual IP blocks into hierarchy, the design is giving critical error saying 

ERROR: [Constraints 18-851] Could not find an automatically derived clock matching the supplied criteria for renaming.

I have modified the system_contr.xdc file to have proper hierarchy block name so that the respective pins can be taken correctly.

My report_clocks 

Critical Warning list

Thank you and regards

Added critical warning after the implementation
[edited by: FPGA@noob at 12:25 PM (GMT -4) on 30 Sep 2022]
  • I think the AXI_DMAC can read data from an AXI address and stream it to a custom core.

    AXI_DACFIFO is used to get data from a DMA, store it in an PL DDR and from there forward it to a stream. As you already have the data in the memory, you don't need that. Now that i'm thinking about it, instead of getting the data from the DMA you could get it from stream directly. You could try that, but I don't think we had this use case tested.

    UTIL_adc/dacFIFOs are used with BRAM and AXI_adc/dacFIFOs are used with DDR as intermediary storage.



  • I want to get the data from ddr4 RAM which is saved there by axi_adcfifio and not from DMAC. Now, I want to extract the data from ddr4 RAM but dont know which IP core can do that.


  • The DMAC is an IP which can take data from a memory and send it to the stream, It will be an additional DMAC, on top of the one you are already using to move data from the ADC_FIFO to the PS DDR. Is there a reason you don't want to use it ?



  • Hi   and  , sorry for late reply.
    I am posting here a screenshot of DMA where I have added DDR4 MIG and adcfifo IP cores. To that I have added additionally AXI interconnect having 2 subordinate and 1 main.
    Main is DDR4 MIG and one of the subordinate is adcfifo which writes the data in the DDR4 and another subordinate is in the question which will retrieve the data from the DDR4 and will send it to a custom IP core.

    Now, the question: If there is IP core from ADI which can be used as second subordinate to the interconnect IP core which can retrieve the data from the DDR4 through MIG.


  • Hello  ,

    Sorry for the late reply, there are two possible options:

    1) You can keep the original connections of the axi_adrv9009_rx_dma(basically the source of your DMA will be a FIFO interface connected with the util_cpack) and then connect axi_adcfifo_0/dma_wdata stream to your custom IP where all the captured data will be continuously streamed and your IP should determine when the frame ends.

    2) The other option is to drop the axi_adcfifo_0 from the design and replace it with a DMA that can capture data to DDR4 memory(this DMA will be configured as the existent axi_adrv9009_rx_dma, the source interface is a FIFO interface connected to the util_cpack and destination interface is a Memory-Mapped AXI connected to S00_AXI from axi_interconnect_0) and in order to extract the data from the DDR4 to a stream you can use another DMA which will be configured as TX DMA(source interface is a Memory-Mapped AXI connected to S01_AXI from axi_interconnect_0 and destination interface can be a FIFO interface or Streaming AXI connected to your IP logic). 

    The second option is more flexible from the software perspective cause you can establish when the data is written to DDR4 and when is extracted from the DDR4.

    Best regards,


  • Hello  ,

    Do you have any updates on this topic?



  • Hello  

    Sorry for late reply. This was pushed under due to other ongoing projects.
    Thank you for your suggestions. According to our requirements, I have taken axi_dacfifo from library/xilinx folder and there I have modified the IP core in such a way that dacfifo_rd.v is applied. Here, the core will be initiated by one of my IP core which will again collect the data from dac_data port of the modified axi_dacfifio IP core. I am struggling with the control of the IP core and was hoping if you could help me with the signals which are coming from dacfifo_wr.v but are not used as I am only reading. With what value should I iniialize them? The increment of address is done by adding arincr value but let's assume that the arincr value is 80 (in decimal format) so how much data is delivered by in each incrememnt. is it axi_size multiplied by axi_length?



  • Hello  , 

    Can you please send me the changes you did on those modules? It will help me a lot!

    Best regards


  • Hi   

    Here is the modified code 

    `timescale 1ns/100ps
    module axi_dataextractor #(
      parameter   DAC_DATA_WIDTH = 64,
      parameter   AXI_DATA_WIDTH = 128,
      parameter   AXI_SIZE = 4,
      parameter   AXI_LENGTH = 4,
      parameter   AXI_ADDRESS = 32'h80000000,
      parameter   AXI_ADDRESS_LIMIT = 32'h9fffffff,
      parameter   AXI_LAST_ADDR = 32'h80012C50 
    ) (
    // dac interface
      input                   dac_clk,
      input                   dac_rst,
      input                   dac_valid,
      input                   axi_xfer_req_s,
      output  reg [(DAC_DATA_WIDTH-1):0]  dac_data,
      output  reg             dac_dunf,
      output  reg             dac_xfer_out,
      // axi interface
      input                   axi_clk,
      input                   axi_resetn,
      output                  axi_awvalid,
      output      [ 3:0]      axi_awid,
      output      [ 1:0]      axi_awburst,
      output                  axi_awlock,
      output      [ 3:0]      axi_awcache,
      output      [ 2:0]      axi_awprot,
      output      [ 3:0]      axi_awqos,
      output      [ 7:0]      axi_awlen,
      output      [ 2:0]      axi_awsize,
      output      [ 31:0]     axi_awaddr,
      input                   axi_awready,
      output                  axi_wvalid,
      output      [(AXI_DATA_WIDTH-1):0]  axi_wdata,
      output      [(AXI_DATA_WIDTH/8-1):0]  axi_wstrb,
      output                  axi_wlast,
      input                   axi_wready,
      input                   axi_bvalid,
      input       [ 3:0]      axi_bid,
      input       [ 1:0]      axi_bresp,
      output                  axi_bready,
      output                  axi_arvalid,
      output      [ 3:0]      axi_arid,
      output      [ 1:0]      axi_arburst,
      output                  axi_arlock,
      output      [ 3:0]      axi_arcache,
      output      [ 2:0]      axi_arprot,
      output      [ 3:0]      axi_arqos,
      output      [ 7:0]      axi_arlen,
      output      [ 2:0]      axi_arsize,
      output      [ 31:0]     axi_araddr,
      input                   axi_arready,
      input                   axi_rvalid,
      input       [ 3:0]      axi_rid,
      input       [ 1:0]      axi_rresp,
      input                   axi_rlast,
      input       [(AXI_DATA_WIDTH-1):0]  axi_rdata,
      output                  axi_rready,
      output                  axi_rerror,
      // Debug output
      output      [4:0]       fsm_dacfifio_deb,  
      output      [31:0]      last_raddr_deb,
      output      [31:0]      axi_araddr_deb,
      output      [8:0]       axi_arincr_deb,
      output                  axi_rready_deb,
      output                  axi_rrvalid_deb,
      output                  axi_rrlast_deb,
      output reg              axi_xfer_req_deb,
      output                  axi_fifo_rst_deb                           
      reg                                axi_xfer_req_m_s1;
      reg                                axi_xfer_req_m;
      (* dont_touch = "true" *) wire    [31:0]                      axi_last_addr_s ;
      (* dont_touch = "true" *) wire    [ 7:0]                      axi_last_beats_s;
      reg    [ 3:0]                       dma_last_beats_s  = 4'b0000;
      wire    [(DAC_DATA_WIDTH-1):0]      dac_data_fifo_s;
      wire    [(DAC_DATA_WIDTH-1):0]      dac_data_bypass_s;
      wire                                dac_xfer_fifo_out_s;
      wire                                dac_dunf_fifo_s;
      wire                                dac_dunf_bypass_s;
      localparam  AXI_BYTE_WIDTH = AXI_DATA_WIDTH/8;
      localparam  AXI_ARINCR = (AXI_LENGTH + 1) * AXI_BYTE_WIDTH;
      assign axi_last_addr_s = AXI_LAST_ADDR & (~AXI_ARINCR + 1);
      assign axi_last_beats_s = AXI_LENGTH;
      // setting deafult values for Write channel. In our case,
      // the write channel should be disabled.
      assign axi_awvalid = 1'b0;
      assign axi_awid    = 4'b0000;
      assign axi_awburst = 2'b01;             // INCR (Incrementing address burst)
      assign axi_awlock  = 1'b0;              // Normal access
      assign axi_awcache = 4'b0010;           // Cacheable, but not allocate
      assign axi_awprot  = 3'b000;            // Normal, secure, data access
      assign axi_awqos   = 4'b0000;           // Not used
      assign axi_awlen   = AXI_LENGTH;
      assign axi_awsize  = AXI_SIZE;
      assign axi_awaddr  = AXI_ADDRESS;
      assign axi_wvalid  = 1'b0;
      assign axi_wdata   = {128{1'b0}};
      assign axi_wstrb   = {AXI_BYTE_WIDTH{1'b1}};
      assign axi_wlast   = 1'b0;
      assign axi_bready  = 1'b0;
      axi_dataextractor_rd #(
        .AXI_SIZE (AXI_SIZE),
      ) i_rd (
        .axi_xfer_req (axi_xfer_req_m_s1),
        .axi_last_raddr (axi_last_addr_s),
        .axi_last_beats (axi_last_beats_s),
        .axi_clk (axi_clk),
        .axi_resetn (axi_resetn),
        .axi_arvalid (axi_arvalid),
        .axi_arid (axi_arid),
        .axi_arburst (axi_arburst),
        .axi_arlock (axi_arlock),
        .axi_arcache (axi_arcache),
        .axi_arprot (axi_arprot),
        .axi_arqos (axi_arqos),
        .axi_arlen (axi_arlen),
        .axi_arsize (axi_arsize),
        .axi_araddr (axi_araddr),
        .axi_arready (axi_arready),
        .axi_rvalid (axi_rvalid),
        .axi_rid (axi_rid),
        .axi_rresp (axi_rresp),
        .axi_rlast (axi_rlast),
        .axi_rdata (axi_rdata),
        .axi_rready (axi_rready),
        .axi_rerror (axi_rerror),
        .dma_last_beats (dma_last_beats_s),
        .dac_clk (dac_clk),
        .dac_rst (dac_rst),
        .dac_valid (dac_valid),
        .dac_data (dac_data_fifo_s),
        .dac_xfer_out (dac_xfer_fifo_out_s),
        .dac_dunf (dac_dunf_fifo_s),
       /* if (~FIFO_BYPASS) */
        always @(posedge dac_clk) begin
          if (dac_valid) begin
            dac_data <= dac_data_fifo_s;
          dac_xfer_out <= dac_xfer_fifo_out_s;
          dac_dunf     <= dac_dunf_fifo_s;
        always @(posedge axi_clk) begin
            axi_xfer_req_m    <= axi_xfer_req_s;
            axi_xfer_req_m_s1 <= axi_xfer_req_m;
            axi_xfer_req_deb  <= axi_xfer_req_m_s1;

    In this I have removed DMA and dacfifo_wr.v logic as I am only interested in reading from MM part and then sending the readed Data through a different lower clock. The axi_xfer_req_s signal comes from my custom IP core @122.88 MHz  and as a result CDC so that it can register to AXI clock which is connected to MIG UI clk port. Other than that dacfifo_rd.v is untouched and no modification is done there. I am having trouble with three signals namely : axi_last_addr_s, axi_last_beats_s and dma_last_beats_s. With which deafult value should I initialize them? In my custom IP core I control axi_xfer_req_s in such a way that when counter reaches a demanded IQ samples value then the signal is put to LOW for a single clock and then again to HIGH so that I can again read the same value from starting address of the RAM. Here is the snip from my BD (For simplicity the modified IP core is named as AXI_Dataextractor) 

    I hope this will help you in providing a feedback.

    Thank you for your time.