There is a term in HDL simulation/verification called "backdoor memory access".

I've heard this a lot of times though I'm not sure how is this implemented.

Also, there are a few references for this concept.

  • \$\begingroup\$ Could you link some of said references? \$\endgroup\$
    – pjc50
    Jan 15, 2013 at 10:11
  • \$\begingroup\$ backdoor to me means any unintended access path, it dopes not single out any particular mechanism. \$\endgroup\$ Jan 15, 2013 at 10:37
  • \$\begingroup\$ That link is dead. \$\endgroup\$ Jan 15, 2013 at 10:54
  • \$\begingroup\$ memory backdoor was mentioned in uvm user's guide page 108 here is the link \$\endgroup\$
    – e19293001
    Jan 15, 2013 at 10:57
  • \$\begingroup\$ Has it to do with video RAM that sometimes has two buses? One for regular reads/writes (CPU side) and one for fast access by the DAC's. \$\endgroup\$
    – jippie
    Jan 15, 2013 at 20:33

1 Answer 1


This question really needed a bit more context than simply "How does backdoor memory access work?". A link to a 198 page document for us to read, in order to guess what you are asking, is not really conducive to getting good answers.

Even basic context such as "in the context of HDL simulation" which appears to be what you're asking, would help.

That being said : when simulating a system (maybe testing a CPU you have implemented on an FPGA) you will need to connect the CPU up to external memory in your testbench. The memory model may look like:

entity SRAM is
   port (
      Address : in    unsigned(15 downto 0);
      Data    : inout std_logic_vector(15 downto 0);
      Wr_n    : in    std_logic;
      OE_n    : in    std_logic;
      CS_n    : in    std_logic
end SRAM;

and you might write this memory model yourself or download it from a vendor.

Now, loading a large program through these ports will take a lot of (wasted) simulation time. Ditto saving the program's output for later analysis.

However there is nothing to stop you adding more connections to the memory model, which are entirely separate from actual pins on the physical memory, and connect directly to your testbench.

For example you could add a backdoor interface consisting of the ports

  Filename : in String;
  Load     : in std_logic;
  Save     : in std_logic;

and suitable behaviour (reading a binary file) in the SRAM architecture. Then in the testbench (assuming Progmem_Filename is connected to the correct Filename port) you can write

  Progmem_Filename <= "selftest.elf";
  Load             <= '1';
  wait for 1 ns;
  Load             <= '0';

and your program memory is loaded and ready to run.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.