sh_cl_ddr_is_ready not being asserted

Hi,

Can you please try to force load the fpga image (AGFI) using the, -F option for the fpga-load-local-image command.
-F, --force-shell-reload
Reload the FPGA shell on AFI load, even if the next AFI
doesn't require it.

fpga-load-local-image -S <slot_num> -I <image_agfi_id> -F

This should reset the FPGA shell logic, before loading the custom logic (CL).

Thanks for the response, I tried this without any change, still no assertion of sh_cl_ddr_is_ready I'm afraid.

One question, do I need to hook up the stats interface on the sh_ddr() if I'm only using the C DDR instance?

Hello,

We have couple of follow up questions:

1. How do you probe "sh_cl_ddr_is_ready" in your CL? Do you connect it to some register or an ILA?

2. The stats interface must be tied off, if you are not using the DDR Controllers (DDR-A, DDR-B, DDR-D) in the CL.
   https://github.com/aws/aws-fpga/blob/master/hdk/common/shell_v04261818/design/interfaces/cl_ports.vh#L194
   Alternatively, you may include the following file in top level CL which will automatically tie-off unused DDR interfaces:
   https://github.com/aws/aws-fpga/blob/master/hdk/common/shell_v04261818/design/interfaces/unused_ddr_a_b_d_template.inc

3. With sh_cl_ddr_is_ready = 0, the data transfer to/from DDR-C has no issues and works just fine. Can you confirm if my understanding is correct here?

4. Do you see same issues if you try on another instance?

Thanks!
Chakra

Edited by: awschakra on Sep 23, 2020 9:23 AM

1. I'm using an ILA, it also samples a bunch of other things in CL, mostly resets, they seem sane (I include sh_cl_ddr_is_ready in the reset logic to the underlying logic, so nothing else comes out of reset)
2. mostly I had it tied off, I'd had started with the code from ./common/shell_v04261818/new_cl_template/design/cl_template.sv that's used when you run the new design script - in it the nets tie_zero_stat_addr and tie_zero_stat_data are left floating, I just forced them to 0s but that had no effect on what's happening here (note there's other stuff wrong in this file that I've had to fix too - for example the sh_ddr's clock is left floating)

3. I think it fails to work when sh_cl_ddr_is_ready is 0 (the simulation model stalls until it goes to 0) I'll rebuild and make sure what happens in the FPGA

4. seems to fail in every instance (I'm running in Sydney is that helps)

Hi,

Unfortunately we are unable to reproduce this issue on our end. I modified CL_HELLO_WORLD example to probe "sh_cl_ddr_is_ready" signal using an ILA, and see that sh_cl_ddr_is_ready=1.
https://github.com/aws/aws-fpga/blob/master/hdk/cl/examples/cl_hello_world/design/cl_hello_world.sv

Attached is the ILA snapshot from my run on an F1 instance.

Could you try using our example design to ensure its working for you?

Thanks!
Chakra

Thanks for your help - I've solved this - essentially the problem was that I was setting both the pcie vendor and device ids to 0 - the fpga instance would let me load it (with a warning) and would run with some functionality, but some parts (like the dram) didn't get correctly initialised.

I made this (noob) mistake because, as mentioned above, I started with the script that copies from the file ./common/shell_v04261818/new_cl_template/design/cl_template.sv - which contains the lines:

//-------------------------------------------
// Tie-Off Global Signals
//-------------------------------------------
assign cl_sh_id0[31:0] = 32'h0000_0000;
assign cl_sh_id1[31:0] = 32'h0000_0000;

Chakra - might I suggest the following changes for these files for your next software release, to save someone else dealing with this:

1. include a valid version of the cl_id_defines.vh file in with cl_template.sv
2. include cl_id_defines.vh in cl_template.sv and change: assign cl_sh_id0\[31:0] = CL_SH_ID0;
   assign cl_sh_id1[31:0] = `CL_SH_ID1;
3. hook up the clocks to sh_ddr() to something so they're not left hangin
4. connect tie_zero_stat_addr and tie_zero_stat_data to something

again thanks for your help - Paul