StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Separating test bench code in manageable procedures is possible, but maybe the compiler complained because a procedure tries to access signals that were not in scope ? If a procedure is to controls a signal that is not in scope, then the signal can be given as argument to the procedure, as shown for the <code>procReset</code> example below.</p> <p>A test bench structure, with multiple levels for easier maintenance, is shown below:</p> <pre><code>--========================================================== -- Reusable procedures -- Reset generation procedure procReset(signal rst : out std_logic; ...) is ... --========================================================== -- Main test control procedure in test bench process is ------------------------------------------------------------ -- General control and status -- Reset device under test and related test bench modules procedure genReset is begin procReset(rst, 100 ns); -- procReset declared elsewhere -- Other code as required for complete reset end procedure; ------------------------------------------------------------ -- Test cases procedure testClockSignals is begin genReset; -- Apply reset to avoid test case interdependency -- Test code here, and call genErr if mismatch detected end procedure; procedure testDigitialIO is begin genReset; -- Apply reset to avoid test case interdependency -- Test code here, and call genErr if mismatch detected end procedure; procedure testDACSignals is begin genReset; -- Apply reset to avoid test case interdependency -- Test code here, and call genErr if mismatch detected end procedure; begin ------------------------------------------------------------ -- Run test cases testClockSignals; testDigitialIO; testDACSignals; -- End of simulation std.env.stop(0); wait; end process; </code></pre> <p>There are several levels in the structure:</p> <ol> <li><p>Run test cases: Where the procedures for each test case is called. It is thereby possible to comment out one or more of the test cases during development and debugging.</p></li> <li><p>Test cases: Test test case code itself, which is written as separate and independent procedures. Interdependence between run of the different test cases is avoided by reset (using <code>genReset</code> procedure) of the device under test and related test bench support modules.</p></li> <li><p>General control and status: Reusable test bench specific procedure, for example reset of device under test and test bench support modules.</p></li> <li><p>Reusable procedures: Does not control or use test bench signals directly, but only through procedure arguments. These procedures may be located in packages (other files) for reuse in other test benches.</p></li> </ol> <p>The test bench file may still be quite a number of lines, since all the test case code still have to be in the same file with the above approach, if this test bench code need direct access to test bench signals in order to control or check the signals values. If signal values can be passed to test case procedures through arguments, as done for the <code>procReset</code> call, then it is possible to move the test case code to another package.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload