Algorithm for testing correct operation of the UNPKBU4 instruction on TMS320C66x

Question

algorithm on testing the correct operation of the UNPKBU4 instruction in the TMS320C66x microprocessor.

I hope someone here point me to the right direction cause I am kinda stuck and I need some guidance if possible if it a course or steps to be taken anything I have about one month to do so, thanks in advance

I searched online and I found out that assembly is the language needed I believe other than that I can't say for sure

Answer 1

I have constructed test frameworks for various instruction sets in the past, such as x87, MMX, 3dNow!, and SSE.

The way to do this is to construct a golden reference in the form of emulation code written in C or C++, then generate test vectors to compare the responses from the golden reference to the hardware for these inputs.

According to the TMS320C66x DSP CPU and Instruction Set Reference Guide the UNPKBU4 instruction performs the straightforward expansion of four packed bytes into four packed 16-bit half-words using zero extension, and it shows in section 3.415 how that works in detail. You can create a function uint64_t unpckbu4_ref (uint32_t x); as the reference based on that specification. Note the use of fixed-width integer types.

You should be able to access the hardware instruction via the _unpkbu4() intrinsic listed in table 8-4 of the TMS320C6000 Optimizing Compiler v8.2.x User's Guide. Inspect the generated machine code to make sure this actually invokes the UNPKBU4 instruction. Alternatively, there may be ways of accessing the instruction via inline assembly, or by linking to a separately compiled wrapper function written in assembly code that utilizes the instruction. I wrote "may" because I have not used this particular platform, but these alternatives are generally available on most computing platforms.

What remains is to generate test vectors for eliciting responses from both the hardware instruction and the golden reference model. A generic technique is to use random numbers generated with a good quality PRNG (pseudo-random number generator). This by itself is suitable for a quick "smoke" test that establishes that the functionality is not completely broken. For single-input operations with a 32-bit input, such as UNPKBU4, correct operation can be demonstrated by an exhaustive test, i.e. applying all possible 2³² inputs, and I highly recommend this. It will take only a few minutes.

For operations with more input bits, for which exhaustive test is not feasible, it is important to check corner / edge cases. For example, for the UNPKBU4 instruction each byte should take the minimum and maximum values of 0x00 and 0xff and to make sure the extension is by zero-extend rather than sign-extend, each byte should also take the values of 0x7f and 0x80.

For an initial test run, you would follow-up on any mismatches to resolve them based on the instruction specifications. You would either correct the golden reference and / or the test framework, or correct the hardware in cases where that is still under development, e.g. when creating a new CPU implementation, or clarify the specification itself if necessary. Thereafter you should be able to carry forward the golden reference code for new generations of processors.