VHDL Test Bench Packge: Version 2 Beta Release

 The version 2 VHDL Test Bench Package Beta is now available.

This version of the package introduces very few changes. The main addition to the package is the ability to have an undefined number of parameters for a command. The other addition is the predefined record types for the stimulus access bus. A minor change is the clean up of the package for commented out lines and unused functions. They were removed.

There is one bug fix in this issue. It seems the file_name variable had no return value from the access_inst_sequ procedure.

In order to create an instruction that has an undefined number of parameters, the “args” value, in the define_instruction call, must contain a value larger than six. This will cause the parser to skip the checking for the correct number of parameters for that command.

The reason for introducing the ability to have an undefined number of parameters passed in an instruction is to enable more dynamic commands to be created. For instance, the CPU style commands presented in the code_snips download, have some commands defined as three parameters. Optionally those commands could be created so two or three parameters could be passed. If only two parameters are valid, then the target of the operation must be the second parameter. As another example, an INC command could be created that enables the one to six parameters to be passed and have all of them incremented in value in one line of a stimulus script. I am sure users will find a use for this feature.

There is one caution about commands with an undefined number of parameters. The test bench package parsing was created such that user scripting errors were found ASAP. One of the items tested for is a correct number of parameters being passed for every command. By creating an instruction to have an undefined number of parameters, you are telling the parser to skip testing for the correct number of parameters. It then becomes the responsibility of the creator to deal with user input, or ignore errors like too many parameters passed. The code for this change was done in the check_valid_inst procedure.

The predefined stimulus bus record types are intended to be used on BFMs. They are presented as an example of a flexible, standardized interface method. Not that this interface is a standard in industry, but it could be for you applications. This definition of the stimulus bus interface enables the flexibility of ease of change. Say you adopt these record types and create many BFMs using them. If later you find that there is another signal needed in your system, it can be added easily just by changing the record definitions. As a facility to easily set a stimulus bus into a neutral state, a stm_neut function is also provided. This function returns a value that can be directly assigned to the record type, making interfacing simpler. This also provides an example of record assignment and function overloading.

As an example of the stimulus bus record types a packet generator BFM example is provided with the beta release. This BFM implementation demonstrates the following features:

• self generating data, incrementing and random
• data loading from a file and file opening
• data loading from the stimulus file
• dynamic file name in stimulus files
• direct setting of text data from the stimulus file.
• use of the new stimulus port definition.

NOTE: It is required to download the random package from here http://www.synthworks.com/downloads/ package link in order for the example BFM to compile.

The packet generator itself is a generic data generator example. It could be combined with a signaling BFM to implement an complete interface. This is a way of disconnecting the data generation from the actual interface signaling. A data generator can service many different kinds of signaling interfaces. This concept is restated in the BFMs #1 blog post. The request input to the packet generator would originate from a signaling BFM to get new data. In this case the request is implemented in a stimulus command called REQUEST.

The other interesting item presented in the example, something I have never done before, is the assignment of text from the stimulus file. In the example stimulus_file.stm file, the SET_FN command takes the dynamic string and assigns it to the stm_text type input of the BFM. This feature is handy for setting file names dynamically from the test case. The parsing system ensures that strings are nul terminated. This makes it easy to do assignment in a loop. The text string input on the example packet generator BFM is part of the stimulus system, but I did not see it needed for all cases, so left it out of the record definitions.

The Beta version of the test bench package is available here: tb_2011beta2.zip direct download in .zip form. Once I am confident the package has no obvious errors the OpenCores release will be updated.

Included in this release is an updated test bench package header and body files. Some additions and fixes to the ttb_gen utility. Updated documentation, yet to be fully completed. And an example of the new package features and test bench techniques in the form of a packet generator BFM.

If you are a user of the VHDL Test Bench Package and discover a bug or want an enhancement, now is your opportunity provide input. Feel free to post any responses in the comments section of this post.

If you are already using the VHDL Test Bench Package, you can upgrade to the new release, there should be no changes needed to your bhv file.

Enjoy

Sckoarn