AWS_CLK_GEN build errors

[dsw]

I have a system verilog file that builds using your system, but does not meet the 4 ns timing, so I am attempting to use your AWS_CLK_GEN module to get a slower clock. I have studied your documentation and your working example cl_mem_perf carefully however my build is not working.

Here is my Makefile fragment that runs the build:

A_RECIPE := A2                                                                  
                                                                                
.PHONY: build-in-background                                                     
build-in-background:                                                            
        export CL_DIR=`pwd` && \                                                
        cd build/scripts && \                                                   
        nohup time -v nice \                                                    
          ./aws_build_dcp_from_cl.py -c projname \                              
          --aws_clk_gen --clock_recipe_a=${A_RECIPE} &

Doing this failed due to errors that look like this:

ERROR: [Synth 8-439] module 'clk_mmcm_a' not found [/home/ubuntu/aws-fpga/hdk/common/lib/aws_clk_gen.sv:489]                                                   

I suppose you expect people to know Vivado and System Verilog well. As I do not, it took me a long time to figure out that I have to go to the file build/scripts/synth_aws_f2_nrmdd1.tcl, find the section below, and uncomment all of the code in that section. Even ChatGPT could not find this and it can read all the code in a flash. A paragraph in the documentation would help greatly.

############################################################################### 
print "Reading CL IP blocks"                                                    
############################################################################### 
                                                                                
#---- User would uncomment and/or list IPs required in their design ----        

After having done that, I have a new error that I have not yet figured out. Do you know what this is? I tried to imitate the call site to AWS_CLK_GEN in cl_mem_perf as closely as I could. Could this result from a dangling wire I left at the call site, or is this due to another configuration file needing something?

ERROR: [DRC REQP-123] connects_CLKINSEL_VCC_connects_CLKIN1_ACTIVE: WRAPPER/CL/AWS_CLK_GEN/CLK_GRP_A_EN_I.CLK_MMCM_A_I/inst/CLK_CORE_DRP_I/clk_inst/mmcme4_adv_inst: The MMCME4_ADV with CLKINSEL tied high requires the CLKIN1 pin to be active.                                                                            

[mjthimm]

Hi @dsw ,

The DRC error provides a detailed hint as to what's going on. The MMCM has CLKINSEL tied high (meaning "use CLKIN1"), but CLKIN1 is not being driven, as opposed to being tied to either VDD or GND. Inside aws_clk_gen.sv, every clk_mmcm_* IP has its clk_in1 port wired directly to i_clk_hbm_ref, which is the 100 MHz reference clock provided by the shell. Check your instantiation as it needs both clock inputs from the shell:

aws_clk_gen #(
.CLK_GRP_A_EN(1),
// ...
) AWS_CLK_GEN (
.i_clk_main_a0 (clk_main_a0), // 250 MHz -> shell port
.i_clk_hbm_ref (clk_hbm_ref), // 100 MHz -> feeds CLKIN1
.i_rst_main_n (rst_main_n),
// ...
);

From cl_mem_perf.sv, the second input is clk_hbm_ref, which is mapped to .i_clk_hbm_ref. If your instantiation has that port unconnected, or connected to a signal that isn't actually driven, you'll get this DRC error. To confirm this, search your CL for where you instantiate aws_clk_gen and verify .i_clk_hbm_ref(...) is connected to the clk_hbm_ref coming from your shell port list at the top of the file.

With respect to the documentation gap you pointed out, I agree. Neither the AWS_CLK_GEN_spec.md nor the Clock_Recipes_User_Guide.md calls out the step of uncommenting the IP block reads in the synthesis TCL. We will add that in both locations so other customers don't run into this issue.

Thank you for bringing this to our attention!

Best,
Max

[dsw]

Ah, thank you. That got past the error I was getting. In software, (1) named arguments are generally implied to be optional, and further (2) required arguments usually produce a compile-time error at the interface, rather than propagating through the bowels of the implementation and resulting in an error unrelated locally to the interface (except for macro/template-like notions of instantiation).

I have a new problem that Vivado is not halting. I have previously been compiling my code and getting the result from Vivado that my data path delay does not meet the 4 ns deadline. These compiles used to take 8 hours, but as I have simplified my chip, the last time I ran it I had gotten it down to less than 5 hours.

However, every once in a while, Vivado would go into a state where it would just not come back. No error message, it just runs a single core at 100% CPU and a small fraction of the memory and never seems to halt. This has happened a few times, such as just recently when I had my instruction cache at 64K. All I did was reduce the cache to 32K and Vivado went from not halting to halting in less than 5 hours.

I am now seeing that behavior again. Since the last compile that took less than 5 hours, all I did was (1) make the caches slightly smaller and (2) plug in the clocking module as directed in your documentation, followed by the changes that you just suggested. My Vivado compile has now been running for over 15 hours with a single CPU at 100%. Again, whenever I have seen this in the past, Vivado has not subsequently halted.

As almost nothing else has changed, I this time the non-halting must have something to do with now using AWS_CLK_GEN. Are there some other undocumented changes that I must make to use AWS_CLK_GEN besides the undocumented requirement to uncomment the "read_ip" statements in build/scripts/synth_aws_f2_nrmdd1.tcl ?

One thing I have been wondering is how Vivado knows that the clock period constraint has changed from 4 ns. Is there some configuration I have to change there? In your cl_mem_perf example, in hdk/cl/examples/cl_mem_perf/build/constraints I find a large number of constraints, some of which seem relevant to clocking. If any of that has to change to build with the 64 ns clock, can you please say exactly what those configuration files must say for this to work?

[AWSdirajesw]

Hi @dsw ,

The clock period constraints are handled automatically by the build flow. The constraint files in hdk/cl/examples/cl_mem_perf/build/constraints/ contain timing exceptions and placement constraints. You do not need to modify these files to specify your clock period.

Clock recipe A2 only configures the frequencies on the clk_extra_a* outputs. The clk_main_a0 remains at 250 MHz for all recipes. The 15.625 MHz clock you are targeting is available on the o_clk_extra_a1 output port of the AWS_CLK_GEN instance. Make sure your design is clocked from o_clk_extra_a1, and not clk_main_a0.

Also when using --aws_clk_gen --clock_recipe_a=A2, make sure the CLK_GRP_A_EN parameter of the AWS_CLK_GEN instance in your CL is set to 1.

This is covered in detail in this comment on #763. Please review this for full explanation and let us know if you have further questions.

Thanks,
Divya

[dsw]

I seem to be doing everything that you recommend.

The constraint files in hdk/cl/examples/cl_mem_perf/build/constraints/ contain timing exceptions and placement constraints. You do not need to modify these files to specify your clock period.

I have not modified these files.

The 15.625 MHz clock you are targeting is available on the o_clk_extra_a1 output port of the AWS_CLK_GEN instance. Make sure your design is clocked from o_clk_extra_a1, and not clk_main_a0.

I seem to be doing that, but feel free to check the code below.

Also when using --aws_clk_gen --clock_recipe_a=A2, make sure the CLK_GRP_A_EN parameter of the AWS_CLK_GEN instance in your CL is set to 1.

Again, I seem to be doing that, but feel free to check the code below.

I got a toy CPU to build and run on the FPGA without the clocking module, as it had a data path delay of about 3.7 ns, so I seem to know how to get all the other aspects of the system to work.

Again, the symptom that I am seeing is that Vivado just does not terminate, although without the clocking module it terminates in less than 5 hours. Not sure if that implies that it could be something else, such as exceeding some total threshold in complexity for Vivado? Ideas?

Here is how I instantiate/call the AWS_CLK_GEN module:

// NOTE: this is edited from code copied from
// aws-fpga/hdk/cl/examples/cl_mem_perf/design/cl_mem_perf.sv
//
//-----------------------------------------
// Clocking Block : AWS_CLK_GEN
//-----------------------------------------

  logic   gen_clk_hbm_ref;
  logic   gen_clk_main_a0;
  logic   gen_clk_extra_a1;
  logic   gen_clk_extra_a2;
  logic   gen_clk_extra_a3;
  logic   gen_clk_extra_b0;
  logic   gen_clk_extra_b1;
  logic   gen_clk_extra_c0;
  logic   gen_clk_extra_c1;
  logic   gen_clk_hbm_axi;
  logic   gen_rst_hbm_axi_n;
  logic   gen_rst_hbm_ref_n;
  logic   gen_rst_c1_n;
  logic   gen_rst_c0_n;
  logic   gen_rst_b1_n;
  logic   gen_rst_b0_n;
  logic   gen_rst_a3_n;
  logic   gen_rst_a2_n;
  logic   gen_rst_a1_n;
  logic   gen_rst_main_n;

  aws_clk_gen
  #(
    .CLK_GRP_A_EN           (1                        ),
    .CLK_GRP_B_EN           (1                        ),
    .CLK_GRP_C_EN           (1                        ),
    .CLK_HBM_EN             (1                        )
  )
  AWS_CLK_GEN
  (
    .i_clk_main_a0          (clk_main_a0              ),
    .i_rst_main_n           (rst_main_n               ),
    .i_clk_hbm_ref          (clk_hbm_ref              ),

    .s_axil_ctrl_awaddr     (ocl_cl_awaddr            ),
    .s_axil_ctrl_awvalid    (ocl_cl_awvalid           ),
    .s_axil_ctrl_awready    (ocl_cl_awready           ),
    .s_axil_ctrl_wdata      (ocl_cl_wdata             ),
    .s_axil_ctrl_wstrb      (ocl_cl_wstrb             ),
    .s_axil_ctrl_wvalid     (ocl_cl_wvalid            ),
    .s_axil_ctrl_wready     (ocl_cl_wready            ),
    .s_axil_ctrl_bresp      (ocl_cl_bresp             ),
    .s_axil_ctrl_bvalid     (ocl_cl_bvalid            ),
    .s_axil_ctrl_bready     (ocl_cl_bready            ),
    .s_axil_ctrl_araddr     (ocl_cl_araddr            ),
    .s_axil_ctrl_arvalid    (ocl_cl_arvalid           ),
    .s_axil_ctrl_arready    (ocl_cl_arready           ),
    .s_axil_ctrl_rdata      (ocl_cl_rdata             ),
    .s_axil_ctrl_rresp      (ocl_cl_rresp             ),
    .s_axil_ctrl_rvalid     (ocl_cl_rvalid            ),
    .s_axil_ctrl_rready     (ocl_cl_rready            ),

    .o_clk_hbm_ref          (gen_clk_hbm_ref          ),
    .o_clk_main_a0          (gen_clk_main_a0          ),
    .o_clk_extra_a1         (gen_clk_extra_a1         ),
    .o_clk_extra_a2         (gen_clk_extra_a2         ),
    .o_clk_extra_a3         (gen_clk_extra_a3         ),
    .o_clk_extra_b0         (gen_clk_extra_b0         ),
    .o_clk_extra_b1         (gen_clk_extra_b1         ),
    .o_clk_extra_c0         (gen_clk_extra_c0         ),
    .o_clk_extra_c1         (gen_clk_extra_c1         ),
    .o_clk_hbm_axi          (gen_clk_hbm_axi          ),
    .o_cl_rst_hbm_axi_n     (gen_rst_hbm_axi_n        ),
    .o_cl_rst_hbm_ref_n     (gen_rst_hbm_ref_n        ),
    .o_cl_rst_c1_n          (gen_rst_c1_n             ),
    .o_cl_rst_c0_n          (gen_rst_c0_n             ),
    .o_cl_rst_b1_n          (gen_rst_b1_n             ),
    .o_cl_rst_b0_n          (gen_rst_b0_n             ),
    .o_cl_rst_a3_n          (gen_rst_a3_n             ),
    .o_cl_rst_a2_n          (gen_rst_a2_n             ),
    .o_cl_rst_a1_n          (gen_rst_a1_n             ),
    .o_cl_rst_main_n        (gen_rst_main_n           )
  );

//=============================================================================
// application code
//=============================================================================

// NOTE: we implement the AXI-L BAR0 interface part of
// aws-fpga/hdk/common/shell_stable/design/interfaces/cl_ports.vh

axi_lite_follower axi_lite_follower_inst0
  (
   // input         clock,
//   .clock(gen_clk_main_a0),
   .clock(gen_clk_extra_a1),

   // input         reset,
//   .reset(!gen_rst_main_n),
   .reset(!gen_rst_a1_n),

   // input [31:0]  __axi_lite_follower__ocl_cl_awaddr,            
   .__axi_lite_follower__ocl_cl_awaddr(ocl_cl_awaddr),             
   // input [63:0]  __axi_lite_follower__ocl_cl_awuser,            
   .__axi_lite_follower__ocl_cl_awuser(ocl_cl_awuser),             
   // input         __axi_lite_follower__ocl_cl_awvalid,           
   .__axi_lite_follower__ocl_cl_awvalid(ocl_cl_awvalid),           
...
);

[AWSdirajesw]

Hi @dsw ,

Thanks for sharing your code snippet.

I see two issues in the instantiation:

1. The AXI-Lite interface s_axil_ctrl_* of AWS_CLK_GEN are connected to ocl_cl_* signals (PF0-BAR0). The AWS_CLK_GEN spec recommends connecting this to the SDA interface (PF1-BAR4). You can see how cl_mem_perf handles this:

AWS_CLK_GEN
(
  .i_clk_main_a0          (clk_main_a0              ),
  .i_rst_main_n           (sda_xbar_sync_rst_n      ),
  .i_clk_hbm_ref          (clk_hbm_ref              ),

  .s_axil_ctrl_awaddr     (sda_axil_clkgen.awaddr   ),
  .s_axil_ctrl_awvalid    (sda_axil_clkgen.awvalid  ),
  .s_axil_ctrl_awready    (sda_axil_clkgen.awready  ),
  .s_axil_ctrl_wdata      (sda_axil_clkgen.wdata    ),
  .s_axil_ctrl_wstrb      (sda_axil_clkgen.wstrb    ),
  .s_axil_ctrl_wvalid     (sda_axil_clkgen.wvalid   ),
  .s_axil_ctrl_wready     (sda_axil_clkgen.wready   ),
  .s_axil_ctrl_bresp      (sda_axil_clkgen.bresp    ),
  .s_axil_ctrl_bvalid     (sda_axil_clkgen.bvalid   ),
  .s_axil_ctrl_bready     (sda_axil_clkgen.bready   ),
  .s_axil_ctrl_araddr     (sda_axil_clkgen.araddr   ),
  .s_axil_ctrl_arvalid    (sda_axil_clkgen.arvalid  ),
  .s_axil_ctrl_arready    (sda_axil_clkgen.arready  ),
  .s_axil_ctrl_rdata      (sda_axil_clkgen.rdata    ),
  .s_axil_ctrl_rresp      (sda_axil_clkgen.rresp    ),
  .s_axil_ctrl_rvalid     (sda_axil_clkgen.rvalid   ),
  .s_axil_ctrl_rready     (sda_axil_clkgen.rready   ),
  ...

2. The same ocl_cl_* bus connected to AWS_CLK_GEN is also connected to axi_lite_follower in your application code. This means both modules are driving the same output nets (ex: ocl_cl_awready, ocl_cl_rdata etc) simultaneously. Vivado will report a [Synth 8-6859] multi-driven net critical warning during synthesis - can you check your synthesis logs to confirm if this warning was reported?

When AWS_CLK_GEN's AXI-Lite interface is connected to SDA bus as described in point 1, only axi_lite_follower will be driving the ocl_cl_* response nets and this conflict will be resolved.

Please let us know if you have further questions.

Thanks,
Divya

[dsw]

I have attempted to follow your instructions by copying how it is done in the cl_mem_perf example, although that example does so many things that I find difficult to know where the boundary of what I should copy should be. Please find the diff attached.

fix-aws-to-use-sda.diff.txt

Regarding the error message, I did not find it.

fgrep -nH -e 'Synth 8-6859' nohup.out 2026_06_05-073558.vivado.log vivado.jou   
Grep finished with no matches found...

I will try another build while waiting for your reply.

[dsw]

I found that I needed the definition of macro DEF_AXPROT, so I copied it from aws-fpga/hdk/cl/examples/cl_mem_perf/design/cl_mem_perf_defines.vh.

However next it seems that I need a definition of axi_bus_t:
ERROR: [Synth 8-439] module 'axi_bus_t' not found

In one of the other examples there is a typedef struct named that, but that does not seem to be what is needed here. ChaGPT was unable to puzzle this one out either. Can you please suggest how to proceed?

[AWSdirajesw]

Hi @dsw ,

In cl_mem_perf, the SDA interface is shared between two modules - AWS_CLK_GEN (that uses sda_axil_clkgen.*) and a BRAM module (that uses sda_axil_bram.*) - which is why it uses an AXI-Lite crossbar (cl_sda_axil_xbar) to split the SDA bus.

In your case, if you only need the SDA interface for AWS_CLK_GEN and have no other module on SDA, you can skip the crossbar entirely and connect the shell SDA signals directly to AWS_CLK_GEN by copying the below code snippet:

  aws_clk_gen
  #(
    .CLK_GRP_A_EN           (1                        ),
    .CLK_GRP_B_EN           (1                        ),
    .CLK_GRP_C_EN           (1                        ),
    .CLK_HBM_EN             (1                        )
  )
  AWS_CLK_GEN
  (
    .i_clk_main_a0          (clk_main_a0              ),
    .i_rst_main_n           (rst_main_n               ),
    .i_clk_hbm_ref          (clk_hbm_ref              ),

    .s_axil_ctrl_awaddr     (sda_cl_awaddr            ),
    .s_axil_ctrl_awvalid    (sda_cl_awvalid           ),
    .s_axil_ctrl_awready    (cl_sda_awready           ),
    .s_axil_ctrl_wdata      (sda_cl_wdata             ),
    .s_axil_ctrl_wstrb      (sda_cl_wstrb             ),
    .s_axil_ctrl_wvalid     (sda_cl_wvalid            ),
    .s_axil_ctrl_wready     (cl_sda_wready            ),
    .s_axil_ctrl_bresp      (cl_sda_bresp             ),
    .s_axil_ctrl_bvalid     (cl_sda_bvalid            ),
    .s_axil_ctrl_bready     (sda_cl_bready            ),
    .s_axil_ctrl_araddr     (sda_cl_araddr            ),
    .s_axil_ctrl_arvalid    (sda_cl_arvalid           ),
    .s_axil_ctrl_arready    (cl_sda_arready           ),
    .s_axil_ctrl_rdata      (cl_sda_rdata             ),
    .s_axil_ctrl_rresp      (cl_sda_rresp             ),
    .s_axil_ctrl_rvalid     (cl_sda_rvalid            ),
    .s_axil_ctrl_rready     (sda_cl_rready            ),

    .o_clk_hbm_ref          (gen_clk_hbm_ref          ),
    .o_clk_main_a0          (gen_clk_main_a0          ),
    .o_clk_extra_a1         (gen_clk_extra_a1         ),
    .o_clk_extra_a2         (gen_clk_extra_a2         ),
    .o_clk_extra_a3         (gen_clk_extra_a3         ),
    .o_clk_extra_b0         (gen_clk_extra_b0         ),
    .o_clk_extra_b1         (gen_clk_extra_b1         ),
    .o_clk_extra_c0         (gen_clk_extra_c0         ),
    .o_clk_extra_c1         (gen_clk_extra_c1         ),
    .o_clk_hbm_axi          (gen_clk_hbm_axi          ),
    .o_cl_rst_hbm_axi_n     (gen_rst_hbm_axi_n        ),
    .o_cl_rst_hbm_ref_n     (gen_rst_hbm_ref_n        ),
    .o_cl_rst_c1_n          (gen_rst_c1_n             ),
    .o_cl_rst_c0_n          (gen_rst_c0_n             ),
    .o_cl_rst_b1_n          (gen_rst_b1_n             ),
    .o_cl_rst_b0_n          (gen_rst_b0_n             ),
    .o_cl_rst_a3_n          (gen_rst_a3_n             ),
    .o_cl_rst_a2_n          (gen_rst_a2_n             ),
    .o_cl_rst_a1_n          (gen_rst_a1_n             ),
    .o_cl_rst_main_n        (gen_rst_main_n           )
  );

This removes the need for cl_sda_axil_xbar module, axi_bus_t interface and all the crossbar-related signals. And you will no longer see: ERROR: [Synth 8-439] module 'axi_bus_t' not found.

For reference, axi_bus_t is a SystemVerilog interface defined in hdk/common/lib/interfaces.sv. This file is read automatically by synth_cl_header.tcl, which is the common synthesis header that all CL synthesis scripts are expected to source at the top. The fact that you are seeing this error suggests your synthesis script may not be sourcing synth_cl_header.tcl.

Could you share your synthesis script so we can confirm whether synth_cl_header.tcl is being sourced?
Also, could you share your full build output log so we can see the full synthesis output?

Thanks,
Divya

[dsw]

I removed the reference to cl_sda_axil_xbar and instead used the instantiation of AWS_CLK_GEN that you gave me, verbatim. Vivado now builds in slightly over 3 hours with no ERROR messages and the build process returns an error code of 0. Thank you for your assistance with that.

Regarding your request for my synthesis script, it is exactly as generated by your wizard. All I did in addition to running your wizard to generate the project was (1) drop in my .sv file containing my code and (2) pass through the AXI4-Lite interface to my module and plug in the AWS_CLK_GEN, per your instructions. In particular, I did nothing to alter the build process other than (1) to comment-out the TCL code in build/scripts/encrypt.tcl that encrypts the source and (2) to uncomment certain lines in build/scripts/synth_aws_f2_nrmdd1.tcl, in section 'Reading CL IP blocks', where I un-commented read_ip statements delimited by comment saying 'User would uncomment and/or list IPs required in their design'.

Regarding your request for my full build output log, I would not mind showing it to you, but anything I send you is on the public internet forever and I hesitate to put that much information about my chip out in the public. Perhaps certain sections would suffice or there is a way I could send it to you privately? Further, now that your instructions seemed to work to build using AWS_CLK_GEN, perhaps they are no longer relevant? Now I seem to have a timing problem, as detailed below.

Note that I am using this as the input clock to my code:

axi_lite_follower axi_lite_follower_inst0                                       
  (                                                                             
   // input         clock,                                                      
//   .clock(gen_clk_main_a0),                                                   
   .clock(gen_clk_extra_a1),                                                    
                                                                                
   // input         reset,                                                      
//   .reset(!gen_rst_main_n),                                                   
   .reset(!gen_rst_a1_n),                                                       

What I see now is the following at the top of my build/reports/aws_f2_projname.2026_06_08-211647.post_route_timing.rpt

Timing Report

Slack (VIOLATED) :        -8.703ns  (required time - arrival time)
  Source:                 <hidden>
                            (rising edge-triggered cell FDRE clocked by clk_main_a0  {rise@0.000ns fall@2.000ns period=4.000ns})
  Destination:            WRAPPER/CL/axi_lite_follower_inst0/__axi_lite_follower_____inst0__V__cl_ocl_rdata_____entry_out_param_reg_reg[4]/R
                            (rising edge-triggered cell FDRE clocked by clk_out1_clk_mmcm_a  {rise@0.000ns fall@32.000ns period=64.000ns})
  Path Group:             clk_out1_clk_mmcm_a
  Path Type:              Setup (Max at Slow Process Corner)
  Requirement:            4.000ns  (clk_out1_clk_mmcm_a rise@64.000ns - clk_main_a0 rise@60.000ns)
  Data Path Delay:        15.220ns  (logic 0.859ns (5.644%)  route 14.361ns (94.356%))
  Logic Levels:           8  (LUT2=1 LUT3=2 LUT4=1 LUT5=1 LUT6=3)
  Clock Path Skew:        3.959ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    9.511ns = ( 73.511 - 64.000 ) 
    Source Clock Delay      (SCD):    5.826ns = ( 65.826 - 60.000 ) 
    Clock Pessimism Removal (CPR):    0.273ns
  Clock Uncertainty:      0.251ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Discrete Jitter          (DJ):    0.250ns
    Phase Error              (PE):    0.121ns
  Inter-SLR Compensation: 1.117ns  ((DCD - CCD) * PF)
    Destination Clock Delay (DCD):    9.511ns
    Common Clock Delay      (CCD):    2.061ns
    Prorating Factor         (PF):    0.150
  Clock Net Delay (Source):      2.408ns (routing 0.460ns, distribution 1.948ns)
  Clock Net Delay (Destination): 2.348ns (routing 1.282ns, distribution 1.066ns)

And in my build/scripts/2026_06_08-211647.vivado.log I find this:

CRITICAL WARNING: [Route 35-39] The design did not meet timing requirements. Please run report_timing_summary for detailed reports.                            

I recently built a very similar version of the project using your 10 ns clock and not using AWS_CLK_GEN, as follows:

axi_lite_follower axi_lite_follower_inst0                                       
  (                                                                             
   // input         clock,                                                      
   // .clock(clk_main_a0),                                                      
   .clock(clk_hbm_ref),  // NOTE: use the 100MHz clock                          
   // input         reset,                                                      
   .reset(!rst_main_n),                                                         

I got the following timing report:

  Requirement:            10.000ns  (clk_hbm_ref rise@10.000ns - clk_hbm_ref rise@0.000ns)                                                                     
  Data Path Delay:        37.526ns  (logic 10.322ns (27.506%)  route 27.204ns (72.494%))                                                                       

So I understand the clock that I requested in this build with AWS_CLK_GEN using clock gen_clk_extra_a1 to be a 64 ns clock; see https://awsdocs-fpga-f2.readthedocs-hosted.com/latest/hdk/docs/Clock-Recipes-User-Guide.html#f2-clock-recipe-tables , "Clock Group A", row A2, column clk_extra_a1, where the clock rate specified is 15.625 MHz. This clock rate corresponds to 64 ns data path delay, unless I misunderstand something.

Again, my build command is as follows, so I think I am requesting that 64 ns delay clock:

./aws_build_dcp_from_cl.py -c aws_f2_projname --aws_clk_gen --clock_recipe_a=A2"

It seems to me that my design should meet timing, as 37.526 ns < 64 ns, and yet I get a message that I missed timing. What am I missing here?

[dsw]

I just thought I would repeat my whole current interface instantiation just to make it easy for you to check the whole thing in one place.

// NOTE: this is edited from code copied from
// aws-fpga/hdk/cl/examples/cl_mem_perf/design/cl_mem_perf.sv
//
//-----------------------------------------
// Clocking Block : AWS_CLK_GEN
//-----------------------------------------

  logic   gen_clk_hbm_ref;
  logic   gen_clk_main_a0;
  logic   gen_clk_extra_a1;
  logic   gen_clk_extra_a2;
  logic   gen_clk_extra_a3;
  logic   gen_clk_extra_b0;
  logic   gen_clk_extra_b1;
  logic   gen_clk_extra_c0;
  logic   gen_clk_extra_c1;
  logic   gen_clk_hbm_axi;
  logic   gen_rst_hbm_axi_n;
  logic   gen_rst_hbm_ref_n;
  logic   gen_rst_c1_n;
  logic   gen_rst_c0_n;
  logic   gen_rst_b1_n;
  logic   gen_rst_b0_n;
  logic   gen_rst_a3_n;
  logic   gen_rst_a2_n;
  logic   gen_rst_a1_n;
  logic   gen_rst_main_n;

  aws_clk_gen
  #(
    .CLK_GRP_A_EN           (1                        ),
    .CLK_GRP_B_EN           (1                        ),
    .CLK_GRP_C_EN           (1                        ),
    .CLK_HBM_EN             (1                        )
  )
  AWS_CLK_GEN
  (
    .i_clk_main_a0          (clk_main_a0              ),
    .i_rst_main_n           (rst_main_n               ),
    .i_clk_hbm_ref          (clk_hbm_ref              ),

    .s_axil_ctrl_awaddr     (sda_cl_awaddr            ),
    .s_axil_ctrl_awvalid    (sda_cl_awvalid           ),
    .s_axil_ctrl_awready    (cl_sda_awready           ),
    .s_axil_ctrl_wdata      (sda_cl_wdata             ),
    .s_axil_ctrl_wstrb      (sda_cl_wstrb             ),
    .s_axil_ctrl_wvalid     (sda_cl_wvalid            ),
    .s_axil_ctrl_wready     (cl_sda_wready            ),
    .s_axil_ctrl_bresp      (cl_sda_bresp             ),
    .s_axil_ctrl_bvalid     (cl_sda_bvalid            ),
    .s_axil_ctrl_bready     (sda_cl_bready            ),
    .s_axil_ctrl_araddr     (sda_cl_araddr            ),
    .s_axil_ctrl_arvalid    (sda_cl_arvalid           ),
    .s_axil_ctrl_arready    (cl_sda_arready           ),
    .s_axil_ctrl_rdata      (cl_sda_rdata             ),
    .s_axil_ctrl_rresp      (cl_sda_rresp             ),
    .s_axil_ctrl_rvalid     (cl_sda_rvalid            ),
    .s_axil_ctrl_rready     (sda_cl_rready            ),

    .o_clk_hbm_ref          (gen_clk_hbm_ref          ),
    .o_clk_main_a0          (gen_clk_main_a0          ),
    .o_clk_extra_a1         (gen_clk_extra_a1         ),
    .o_clk_extra_a2         (gen_clk_extra_a2         ),
    .o_clk_extra_a3         (gen_clk_extra_a3         ),
    .o_clk_extra_b0         (gen_clk_extra_b0         ),
    .o_clk_extra_b1         (gen_clk_extra_b1         ),
    .o_clk_extra_c0         (gen_clk_extra_c0         ),
    .o_clk_extra_c1         (gen_clk_extra_c1         ),
    .o_clk_hbm_axi          (gen_clk_hbm_axi          ),
    .o_cl_rst_hbm_axi_n     (gen_rst_hbm_axi_n        ),
    .o_cl_rst_hbm_ref_n     (gen_rst_hbm_ref_n        ),
    .o_cl_rst_c1_n          (gen_rst_c1_n             ),
    .o_cl_rst_c0_n          (gen_rst_c0_n             ),
    .o_cl_rst_b1_n          (gen_rst_b1_n             ),
    .o_cl_rst_b0_n          (gen_rst_b0_n             ),
    .o_cl_rst_a3_n          (gen_rst_a3_n             ),
    .o_cl_rst_a2_n          (gen_rst_a2_n             ),
    .o_cl_rst_a1_n          (gen_rst_a1_n             ),
    .o_cl_rst_main_n        (gen_rst_main_n           )
  );

//=============================================================================
// application code
//=============================================================================

// NOTE: we implement the AXI-L BAR0 interface part of
// aws-fpga/hdk/common/shell_stable/design/interfaces/cl_ports.vh

axi_lite_follower axi_lite_follower_inst0
  (
   // input         clock,
//   .clock(gen_clk_main_a0),
   .clock(gen_clk_extra_a1),

   // input         reset,
//   .reset(!gen_rst_main_n),
   .reset(!gen_rst_a1_n),

   // input [31:0]  __axi_lite_follower_____inst0__V__ocl_cl_awaddr,
   .__axi_lite_follower_____inst0__V__ocl_cl_awaddr(ocl_cl_awaddr),
   // input [63:0]  __axi_lite_follower_____inst0__V__ocl_cl_awuser,
   .__axi_lite_follower_____inst0__V__ocl_cl_awuser(ocl_cl_awuser),
   // input         __axi_lite_follower_____inst0__V__ocl_cl_awvalid,
   .__axi_lite_follower_____inst0__V__ocl_cl_awvalid(ocl_cl_awvalid),
   // output        __axi_lite_follower_____inst0__V__cl_ocl_awready,
   .__axi_lite_follower_____inst0__V__cl_ocl_awready(cl_ocl_awready),
   // input [31:0]  __axi_lite_follower_____inst0__V__ocl_cl_wdata,
   .__axi_lite_follower_____inst0__V__ocl_cl_wdata(ocl_cl_wdata),
   // input [7:0]   __axi_lite_follower_____inst0__V__ocl_cl_wstrb,
   .__axi_lite_follower_____inst0__V__ocl_cl_wstrb(ocl_cl_wstrb),
   // input         __axi_lite_follower_____inst0__V__ocl_cl_wvalid,
   .__axi_lite_follower_____inst0__V__ocl_cl_wvalid(ocl_cl_wvalid),
   // output        __axi_lite_follower_____inst0__V__cl_ocl_wready,
   .__axi_lite_follower_____inst0__V__cl_ocl_wready(cl_ocl_wready),
   // output [7:0]  __axi_lite_follower_____inst0__V__cl_ocl_bresp,
   .__axi_lite_follower_____inst0__V__cl_ocl_bresp(cl_ocl_bresp),
   // output        __axi_lite_follower_____inst0__V__cl_ocl_bvalid,
   .__axi_lite_follower_____inst0__V__cl_ocl_bvalid(cl_ocl_bvalid),
   // input         __axi_lite_follower_____inst0__V__ocl_cl_bready,
   .__axi_lite_follower_____inst0__V__ocl_cl_bready(ocl_cl_bready),
   // input [31:0]  __axi_lite_follower_____inst0__V__ocl_cl_araddr,
   .__axi_lite_follower_____inst0__V__ocl_cl_araddr(ocl_cl_araddr),
   // input [63:0]  __axi_lite_follower_____inst0__V__ocl_cl_aruser,
   .__axi_lite_follower_____inst0__V__ocl_cl_aruser(ocl_cl_aruser),
   // input         __axi_lite_follower_____inst0__V__ocl_cl_arvalid,
   .__axi_lite_follower_____inst0__V__ocl_cl_arvalid(ocl_cl_arvalid),
   // output        __axi_lite_follower_____inst0__V__cl_ocl_arready,
   .__axi_lite_follower_____inst0__V__cl_ocl_arready(cl_ocl_arready),
   // output [31:0] __axi_lite_follower_____inst0__V__cl_ocl_rdata,
   .__axi_lite_follower_____inst0__V__cl_ocl_rdata(cl_ocl_rdata),
   // output [7:0]  __axi_lite_follower_____inst0__V__cl_ocl_rresp,
   .__axi_lite_follower_____inst0__V__cl_ocl_rresp(cl_ocl_rresp),
   // output        __axi_lite_follower_____inst0__V__cl_ocl_rvalid,
   .__axi_lite_follower_____inst0__V__cl_ocl_rvalid(cl_ocl_rvalid),
   // input         __axi_lite_follower_____inst0__V__ocl_cl_rready,
   .__axi_lite_follower_____inst0__V__ocl_cl_rready(ocl_cl_rready)
   );

[AWSdirajesw]

Hi @dsw ,

I'm glad to hear the build is completing now!

Regarding the timing violation, it is a classic clock domain crossing (CDC) issue.

• The OCL AXI-Lite interface (ocl_cl_* / cl_ocl_*) from the shell is synchronous to clk_main_a0 at 250 MHz (4 ns period). This is mentioned in the AWS Shell Interface Specification:

  All the interfaces between the CL and SH, as listed in cl_ports.vh are synchronous to clk_main_a0. The CL design must perform the required clock domain crossing when interfacing logic in another clock domain with Shell-CL interface ports.

• Your module axi_lite_follower is clocked by gen_clk_extra_a1 at 15.625 MHz (64 ns period).

Since the source registers (ocl_cl_*) are on clk_main_a0 and the destination registers are on gen_clk_extra_a1, Vivado performs a cross-clock setup check. According to your timing report, Vivado found a scenario where clk_main_a0 edge launches at 60 ns and the next gen_clk_extra_a1 capture edge is at 64 ns, leaving a requirement of 4 ns for the data path.

Breaking down your timing report:

Slack = requirement + clock skew - data_path delay - clock uncertainty - inter-SLR compensation = 4.000 + 3.959 - 15.220 - 0.251 - 1.117 = -8.629 ns 

You can fix CDC by introducing a synchronizer circuit with handshaking protocols.

I want to bring up that the HDK provides cl_axi_clock_converter_light IP which implements all of the CDC handshaking internally for AXI-Lite bus.

After sourcing hdk_setup.sh, the IP is available under $HDK_IP_SRC_DIR/cl_axi_clock_converter_light/

To use the IP:

1. You can refer to the port list in $HDK_IP_SRC_DIR/cl_axi_clock_converter_light/sim/cl_axi_clock_converter_light.v to write the instantiation in your design - connect its slv side (s_axi_* and s_axi_aclk) to the Shell's ocl_cl_* / cl_ocl_* signals at clk_main_a0, and its mstr side (m_axi_* and m_axi_aclk) to axi_lite_follower's ports at gen_clk_extra_a1.

2. You need to add a read_ip entry for cl_axi_clock_converter_light.xci in your synthesis TCL (similar to how the clocking IPs are listed in synth_cl_mem_perf.tcl)

Thanks,
Divya