testing - Multiple behaviours for single entity -

i wrote vhdl testbench contains following :

• lots of signal declarations
• uut instantiations / port maps
• a huge amount of one-line concurrent assignments
• various small processes
• one main (big) process stimulates uut.

everything fine except fact want have 2 distinct types of stimulation (let's simple stimulus , more complex one) did created 2 testbenches have in common except main big process. don't find convenient since need update both when, example, make change uut port map. not cool.

i don't want merge 2 main process because hell , can't have 2 process declared concurrently in same architecture (i might end long file , don't can theoretically access same signals).

so keep "distinct files" approach specific process. there way out of or doomed?

this seems example using multiple architectures of same entity help. have file along lines of:

entity testbench end testbench;  architecture simpletest of testbench     -- might have component declaration uut here begin     -- test bench code here end simpletest; 

you can add architecture. can have architectures in separate files. can use direct entity instantiation avoid component declaration uut (halving work required if uut changes):

architecture anothertest of testbench begin     -- test bench code here     uut : entity work.mydesign (behavioral)     port map (         -- port map usual     );  end anothertest ; 

this doesn't save having duplicate code, @ least removes 1 of port map lists.

another point if have lot of signals in uut port map, can easier if try make more of signals vectors. example, might have lots of serial outputs of same type going different chips on board. have seen lots of people name these spi_cs_sensors, spi_cs_cpu, spi_cs_front_panel, etc. find makes vhdl lot more manageable if these combined spi_cs (2 downto 0), mapping of signal goes device specified circuit diagram. suppose preference, maybe sort of approach if have huge port lists.

using testcontrol entity

a more sophisitcated approach involve using test control entity implement stimulus. @ simplest level, have ports of signals uut interested in. more sophisticated test bench have test control entity interfaces can control bus functional models contain actual pin wiggling required exercise design. can have 1 file declaring entity, testcontrol_entity.vhd:

entity testcontrol port (     clk : out std_logic;     uutinput : out std_logic;     uutoutput : in std_logic ); 

then have 1 or more architecture files, example testcontrol_simpletest.vhd:

architecture simpletest of testcontrol begin     -- stimulus simple test end simpletest; 

your top level test bench like:

entity testbench end testbench;  architecture behavioral of testbench     signal clk : std_logic;     signal : std_logic;     signal b : std_logic; begin      -- common processes clock generation go here      uut : entity work.mydesign (behavioral)     port map (         clk : in std_logic;         : in std_logic;         b : out std_logic     );       testcontrol_inst : entity work.testcontrol (simpletest)     port map (         clk => clk,         uutinput => a,         uutoutput => b     );  end simpletest; 

you can change test changing architecture selected testcontrol.

using configurations

if have lot of different tests, can use configurations make easier select them. this, first need make test control entity instantiation use component declaration opposed direct instantiation. then, @ end of each test control architecture file, create configuration:

use work.all;  configuration config_simpletest of testbench     behavioral         testcontrol_inst : testcontrol             use entity work.testcontrol (testcontrol_simpletest);         end for;     end for; end config_simpletest; 

now when want simulate, simulate configuration, instead of command sim testbench, run sim work.config_simpletest. makes easier manage test benches large number of different tests, because don't have edit files in order run them.