CODEWITHSUNDEEP
simulationvhdlfpga
blueshift
blueshift

Reputation: 6882

VHDL alternative submodule architecture for simulation

I have a VHDL component which implements a DRAM test sequence. It contains a child entity which is the DRAM controller.

I want to simulate (debug) the DRAM test sequence but use a simple fake stub for the DRAM controller rather than the real, complicated thing.

Is there a way I can set this up, perhaps using VHDL configurations to use a simple version of the controller entity for simulation? I'm quite new to simulation, and not hugely experienced with VHDL in general.

This is using Xilinx ISE and ISim targeting Spartan-6, if that makes a difference.

Upvotes: 5

Views: 3435

Answers (2)

Martin Thompson
Martin Thompson

Reputation: 16792

Another configuration-free way is to use generate to achieve this:

sim:if in_simulation generate
   Controller_1 : entity work.DRAM_controller(simple)
                  port map ...
else
   Controller_1 : entity work.DRAM_controller(rtl)
                  port map ...
end generate;

You can use this answer to create an in_simulation constant.

(If you don't have VHDL2008-compliant tools, you can't do an if...else..end generate and you'll have to do an if in_simulation/if not in_simulation pair instead. Raise a bug report :)

Upvotes: 4

user1818839
user1818839

Reputation:

One way that doesn't use configurations:

remember that you can create several architectures for each entity.

Therefore you can instantiate a unit in your testbench as

Controller_1 : entity work.DRAM_controller(simple)
               port map ( ...

or 

Controller_2 : entity work.DRAM_controller(rtl)
               port map ( ...

where "simple" and " rtl" are two architectures. For this purpose, you may have to have the entity and both architectures in different files; Xilinx tools are not very good at handling uncommon cases (at one time they told me that configurations were not design units!)

Then you can instantiate the DRAM controller with either architecture in a testbench.

As vermaete says, you also have to test the simplified architecture. One way is to run unit tests on it by instantiating both controllers in another testbench, one with each architecture, and comparing their outputs for each operation.

Funnily enough Ashenden's example for direct entity instantiation (Designer's Guide to VHDL ch 5.4, p.136 in my 1996 edition) is a DRAM controller!

EDIT: (this was a comment but it's getting too long)

For the unit test, both controllers can be instantiated in the testbench, and all is well.

For the system test, I did not understand that the DRAM controller was inside the UUT (top level design) - you want one instantiation (the real one) for synth and simple DRAM tests, and another (simple) for the full DRAM tests. Yes, a configuration is the correct and cleanest way to do that. Instantiate the controller ENTITY in the top level design (UUT), and select architectures in a configuration.

However there is a less clean alternative, as a fallback plan in case configurations don't work. Create 2 architectures for the top level entity; differing ONLY in the arch they select for the controller. You can select either architecture when you instantiate the top level entity in the testbench. It's a pain though, because you have to keep the two versions in sync.

Upvotes: 5

Related Questions