OCL Poke commands in init_ddr() simulation function

[rick-heig]

There seem to be artefacts from the DRAM DMA example in the init_ddr() function in the file
/hdk/common/verif/include/sh_dpi_tasks.svh

Lines 211 to 216

      //de-select the ATG hardware

      poke_ocl(.addr(64'h130), .data(0));
      poke_ocl(.addr(64'h230), .data(0));
      poke_ocl(.addr(64'h330), .data(0));
      poke_ocl(.addr(64'h430), .data(0));

This seems unrelated to initializing the DDR, I came accross this while trying to simulate a project that made use of the DDR but did not use the OCL bus.

I could run my project by removing those lines.

If they are only related to the DRAM DMA example it could be better to remove them and add call them from the DRAM DMA code instead of the init_ddr() function. Or I could be mistaken and every project/design should have the ATG for the DDR modules ?

In my previous designs with the DDR I manually called the following lines during simulation

      power_up(.clk_recipe_a(ClockRecipe::A1),
                  .clk_recipe_b(ClockRecipe::B0),
                  .clk_recipe_c(ClockRecipe::C0));

      nsec_delay(1000);
      poke_stat(.addr(8'h0c), .ddr_idx(0), .data(32'h0000_0000));
      poke_stat(.addr(8'h0c), .ddr_idx(1), .data(32'h0000_0000));
      poke_stat(.addr(8'h0c), .ddr_idx(2), .data(32'h0000_0000));

But since there is a init_ddr() function in a common file for verification, it would be nice if it was be generic and initialize the DDR without doing OCL bus accesses. This way people could simply call init_ddr(). Also if people use the OCL bus in their design for other purposes these accesses could do unintended things.

Regards

[deeppat]

Hello! Thanks for providing feedback and we'll incorporate this change in our next major release.

[deeppat]

Hi @rick-heig We've added a deselect_atg_hw task to make this step easier for you.

Thank you for providing feedback here! I'm closing this issue for now, but feel free to reach out to us for any other issues/suggestions you may have!

-Deep