Connecting Cmod A7 to external SRAM without board file

[idraney]

Hello Digilent Forum!

I have been able to run the Cmod A7 Out of Box Demo and export it to an SDK/Vitis project, then modify memorytest.c to write and read new data to and from the SRAM.  What a great demo for getting started with the Cmod A7!

However, I would like to configure the external memory controller (AXI EMC) block to use its individual ports -- without using the Cmod A7 board file and the "cellular_ram" port from the EMC_INTF pin of the EMC block. 

I created a new project that uses the xc7a35tcpg236-1 FPGA (not the board file), edited the constraints XDC file, and pinned out the EMC block to match the specs of the onboard ISSI IS61WV5128 SRAM; but it fails to generate a bitstream file successfully.  I have also tried to setup tristate buffers (IOBUF) at the top level similar to the demo project's user_35t_wrapper.v file does, but no luck.  Configuring the EMC signals (mem_dq_i, mem_dq_o, mem_dq_t, mem_dq_io) for a tristate buffer to interface with the SRAM's data lines seems to be the most confusing part.

An image of what I "think" the EMC block should look like is attached.  Any help interfacing the EMC block and SRAM correctly (without the board file) would be greatly appreciated.

Thanks!
Ian

 

[JColvin]

Hi @idraney,

We don't have a direct examples, though you could look at the preset for the Cmod A7 board file to see what what is specifically done there: https://github.com/Digilent/vivado-boards/blob/master/new/board_files/cmod_a7-35t/B.0/preset.xml.

Thanks,
JColvin

[idraney]

Hi @JColvin,

Thank you for responding.  The XML data in the board files was definitely helpful to finally finding a solution.  The difficult part was configuring the tristate buffer in the Verilog code properly (and remembering to disable Vivado management of the top level wrapper!).  Here is a little snippet of what I did in the top level Verilog code to interact with the SRAM chip's data pins:

    ///////////////////////////////////////////////////////////
    // SRAM Data IOBUF Instantiation
    
    genvar index;
    generate
    for (index = 0; index < 8; index = index + 1)
        begin: gen_code_label
            IOBUF sram_dq_iobuf_inst
            (
                .I  (sram_dq_o[index]),     // Tristate Buffer data input (EMC Data write)
                .IO (sram_dq_io[index]),    // Tristate Buffer data input/output (External port to SRAM)
                .O  (sram_dq_i[index]),     // Tristate Buffer data output (EMC Data read)
                .T  (sram_dq_t[index])      // Tristate Buffer switch
            );
        end
    endgenerate

While the SRAM o, i, and t ports on the EMC were converted to external pins in the Vivado block design, the Verilog code had to be edited so that they operate as internal signals (wires).  The SRAM io port was created as a port in the top level Verilog code, as it does not exist in the block design.  It just needed some extra work applied to Vivado's Verilog code.

Thanks!
Ian