The DSPCAD Integrative Line Environment: Introduction to DICE Version 1.1

Shuvra S. Bhattacharyya, William Plishker, Chung-Ching Shen, Nimish Sane, and George Zaki Department of Electrical and Computer Engineering, and Institute for Advanced Computer Studies University of Maryland College Park, USA {ssb, plishker, ccshen, nsane, gzaki}@umd.edu

Abstract—DICE (the DSPCAD Integrative Command heterogeneous programming languages or models of Line Environment) is a package of utilities that facilitates computation. DICE is being developed by the Mary- efficient management of software projects. Key areas of land DSPCAD Research Group, focuses on emphasis in DICE are cross-platform operation, support computer-aided design (CAD) techniques for digital for projects that integrate heterogeneous programming signal processing (DSP) systems. However, the features languages, and support for applying and integrating different kinds of design and testing methodologies. The provided in DICE are generally not specific to DSP or package is being developed at the University of Maryland CAD-for-DSP applications, and can be applied in other to facilitate the research and teaching of methods for domains. implementation, testing, evolution, and revision of engi- For clarity, we should note what DICE is not. DICE neering software. The package is also being developed as is not meant to replace existing software development a foundation for developing experimental research soft- tools. DICE is not a shell nor is it a compiler or synthe- ware for techniques and tools in the area of computer- sizer. It is not a debugger nor does it provide simulation aided design (CAD) of digital signal processing (DSP) capabilities. It does not provide automatic transcoding systems. The package is intended for cross-platform for porting between platforms and languages. DICE is operation, and is currently being developed and used actively on the , Mac OS, Solaris, and Windows instead a command line solution to utilize all of these (equipped with Cygwin) platforms. existing kinds of tools effectively, especially for This report provides an introduction to DICE, and cross-platform design. provides background on some of the key features in DICE Version 1.1. This report also gives a brief introduc- II. SETTING UP DICE tion to dicelang, which is a plug-in package for DICE DICE is implemented as a collection of utilities that that provides additional utilities, libraries, and tools are in the form of Bash scripts, C programs, and Python for managing software projects in specific programming scripts. Therefore, facilities for interpreting/compiling languages. these languages must be available to use all of the capabilities in DICE. DICE is developed with signif- I. INTRODUCTION icant attention to cross-platform operation. Platforms This report provides an introduction to DICE, which on which DICE is used actively include Linux, Mac stands for the DSPCAD Integrative Command Line OS, Solaris, and Windows (equipped with Cygwin). Environment, and accompanies the latest release of DICE can be downloaded from the DICE Project DICE, which is Version 1.1. The objective of DICE Website [1]. Details on setting up, using, and trou- is to provide a flexible, lightweight environment for bleshooting DICE can also be found through this the research, development, testing, and integration website. of software projects, particularly those that employ III. INTRODUCTION TO DICE UTILITIES

Technical Report UMIACS--2011-10, Institute for Advanced DICE includes a variety of utilities to improve Computer Studies, University of Maryland at College Park, 2011. productivity while working in a command-line or shell- based project development environment. This section dlk p1 provides a brief introduction to some of the basic ˜/documents/doc1 utilities available in DICE. These utilities help improve g p1 the convenience with which one can do some common After the above sequence of commands, the user will and fundamental tasks. end up in ˜/projects/proj1. A. NAVIGATION If the dlk command is called with a label that is For users of command line based development en- already associated with a different directory, then the vironments, directory navigation can be cumbersome previous association is silently overwritten, and the and consuming when done many times a day. To association is changed so that the label is linked to alleviate this, DICE provides a number of utilities for the current working directory. efficient navigation through directories. This group of The associations used by DICE between directory utilities allows one to label directories with arbitrary, labels and absolute paths are maintained in a subdi- user-defined identifiers, and to move to (i.e., cd to) rectory called g in the dice_user directory. The directories by simply referencing these identifiers. This dice_user directory is a directory in which user- is a much more convenient way of “jumping” from specific files related to DICE are maintained. Infor- one directory to another compared to typing the com- mation about setting up the dice_user directory is plete directory path or explicitly changing directories provided as part of the instructions for installing and through the relative path of the desired destination setting up DICE. directory. After using the DICE navigation utilities for several The primary DICE utility related to directory navi- weeks, it is natural to build up a large collection gation is dlk, which stands for the “directory linking of directory labels, and such a collection can eas- utility”. The following is the general usage format for ily be backed up, along with other relevant, user- the dlk command. specific DICE settings and files, by backing up one’s dice_user dlk

2 as their standard UNIX counterparts, except that they different directories. We refer to these utilities infor- do not produce any text to standard output. Instead, mally as the DICE utilities for MTA (“moving things their standard output is redirected to the DICE user around”). These utilities can be especially convenient files dice_user/tmp/dxpushd_discard.txt when used in conjunction with the directory navigation and dice_user/tmp/dxpopd_discard.txt, utilities described in Section III-A, but they can also respectively. By redirecting the output in this way, the be used independently of any other utilities. output is available for diagnostic reference as needed Users are upgrading from the previous version without cluttering standard output. This is useful, for of DICE should take note that the names of several example, when “pushing” and “popping” directories MTA utilities have changed in the latest version. This in scripts as it helps to keep the output from the section provides the updated names of the utilities. scripts more relevant to the direct functionality of the The DICE MTA utilities reference a standard user scripts (rather than their internal use of pushd and subdirectory in DICE that we called the DICE user popd operations). clipboard. The DICE user clipboard resides within The usage formats for dxpushd and dxpopd are another standard user directory called the DICE tempo- the same as their standard UNIX counterparts: any - rary directory or simply, the temporary directory when guments provided to these wrapper versions are passed the DICE qualification is understood from context. on directly to pushd and popd, respectively. The paths of the DICE user clipboard and temporary The naming of the dxpushd and dxpopd com- directory are stored in the DICE environment vari- mands illustrates a naming convention that is used ables UXCLIPBOARD and UXTMP, respectively. The often (but not everywhere) in DICE: that of prefixing value of the UXTMP variable (i.e., the location of the the name of a DICE utility with “dx.” DICE plug-in temporary directory) is set by default upon startup of packages, such as the dicelang package, which is DICE to be the path to a subdirectory called tmp discussed in Section V, will in general have similar in the DICE user directory. So, for example, if the utility-name prefix conventions (e.g., the core part of DICE user directory is located at ˜/dice_user, dicelang uses the prefix dlx, while sub-packages then the DICE temporary directory is located at within dicelang in general have their own specific ˜/dice_user/tmp, and the DICE user clipboard is prefixes, with each sub-package-specific prefix starting located at ˜/dice_user/tmp/clipboard. with the two letters “dl” to indicate that they are sub- The DICE temporary directory and DICE user clip- packages of dicelang. board can be labeled for fast navigation by running the The DICE command plk (“push directory to link”) following command sequence. works like the g command, except that the new cd $UXTMP directory is pushed onto the directory stack (using dlk tmp dxpushd) so that one can return to the original cd $UXCLIPBOARD directory with a dxpopd or popd command. dlk clip The usage format for plk is as follows. Of course, it is not necessary to label the dlk plk

3 • dxparl: paste (copy) and remove the last file or that proj1 and proj2 are project directories that directory transferred (LFDT) from the DICE user have previously been labeled as pr1 and pr2, re- clipboard. spectively, using dlk. Suppose also that there is a • dxpal: paste the LFDT from the DICE user file called utilities.c in the proj1 directory clipboard. that one wants to use a copy of or on in the The usage format for dxcu is as follows. proj2 directory. This file can be copied to the proj2 directory using the following sequence of commands. dxcu g pr1 where is the name of a file or directory. The dxco utilities.c command moves the specified file or directory to the g pr2 DICE user clipboard. dxparl Such a file can be retrieved subsequently from any directory by running the dxpar command, which This is equivalent to a copy-and-paste using basic moves the specified file or directory from the DICE mouse-based file operations, but this kind of command- user clipboard to the current working directory. More based sequence can be much more convenient and precisely, the usage format for dxpar is as follows. efficient once one gets used to it. It is even more convenient when used in conjunction with standard file dxpar name auto-completion features in the Bash shell (e.g., where is the name of a file or directory. The see [2]). command moves the file or subdirectory named Note that there are better ways to reuse code than from the DICE user clipboard, assuming that such a file copying code files, so this example should not be taken or subdirectory exists. The utilities dxcu and dxpar as a model for project development practices, but rather are often used in conjunction with one another, but as an illustration of the combined use of navigation- this is not a requirement: a file or subdirectory moved related and MTA utilities in DICE. using dxpar need not have been placed originally in Another, perhaps more common, scenario in which the DICE user clipboard using dxcu. this kind of MTA functionality can be useful is when The utilities dxco and dxpa work like their selecting a template from a repository of document cousins, dxcu and dxpar, except that they copy templates (e.g., templates for business letters, personal rather than move the specified files or directories. Their letters, project reports, oral presentations, etc.). One usage formats are analogous to those for dxcu and can quickly a copy of and starting working with dxpar — i.e., they each take a single argument, which the appropriate template with just a few commands — gives the name of a file or directory. for example: The dxparl and dxpal utilities are variations of plk templates dxpar and dxpa, respectively, that implicitly refer- dxco letter-from-home.tex ence the last file or directory transferred (LFDT) by popd dxcu or dxco. Each call to dxcu or dxco has the dxparl side-effect of updating a DICE internal variable that stores the name of the LFDT. As suggested earlier, the MTA utilities need not Neither dxparl nor dxpal takes any arguments. be used in pairs — e.g., a dxco command need not These commands transfer the LFDT from the DICE be coupled with a corresponding dxpar or dxparl user clipboard to the current working directory. They command. The MTA utilities can be used for any differ in that the LFDT is moved out of the DICE pattern of moving and copying files to and from the user clipboard with dxparl, whereas it is copied with DICE user clipboard. For example, moving or copying dxpal. a file to the DICE user clipboard can be useful if one As described earlier, the DICE MTA utilities can be wants to move a file or directory out of the way from especially convenient to use in conjunction with the the current working directory, but is not completely directory navigation utilities described in Section III-A. sure yet whether or not the file or directory will be As an example of this kind of convenience, suppose needed again in the future.

4 Such forms of usage of the MTA utilities can gener- be exercised before using dxrmcl since files and ally be useful to help fine-tune directory organization. directories in the DICE user clipboard that are removed However, after a while, they can lead to excessive disk by this command are removed permanently. space requirements for the DICE temporary directory It is useful to be aware of the dxrmcl utility when (which contains the DICE user clipboard). Thus, the working with the MTA utilities — specifically, when temporary directory should periodically be cleaned out working with dxcu and dxco. This is because by or “reset”. A good time to do this is when there are no default, the dxcu and dxco commands are safe in pending dxpal or dxparl commands, and just after the sense that the specified file or directory will not be one has backed up the temporary directory (perhaps moved if a file or directory with the same name already as part of a general user space backup routine). That exists in the DICE user clipboard. In other words, one way, in case one needs to refer back to a file or cannot accidentally overwrite a file or directory using directory that was “semi-confidently” discarded into dxco or dxcu. Thus, for example, if one is trying to the temporary directory, there is a means to recover move a file to the DICE user clipboard using dxcu the file or directory. but finds (through the error message reported from Recall that the DICE user clipboard is contained dxcu) that a file with the same name already exists in within the DICE temporary directory. In addition to the DICE user clipboard, one must somehow get rid the DICE user clipboard, the temporary directory of the identically-named DICE user clipboard file. A serves as a repository for miscellaneous intermediate convenient way to do this, assuming that the DICE user files that are generated by various DICE utilities. clipboard file is no longer needed, is with dxrmcl. Because of the importance, in terms of disk space The default “safe” configuration of dxco and dxcu usage, of periodically emptying-out the DICE tem- can be changed through the porary directory, DICE is equipped with a simple DX_MTA_AGGRESSIVE. This environment variable utility called dxclntmp to perform this task. The controls what happens when the file or directory spec- dxclntmp utility removes all of the files and sub- ified to dxco or dxcu conflicts with an identically- directories within the DICE temporary directory, and named file or directory in the DICE user clipboard. resets the directory so that it contains just a single If DX_MTA_AGGRESSIVE is set to a non-null value, file. This file is a small, single-line log file called then the identically-named file or directory in the DICE dxclntmp-log.txt, which contains a record of the user clipboard is silently overwritten. Conversely, if time stamp — as returned by the UNIX date com- DX_MTA_AGGRESSIVE is not defined or is set to a mand — of the recent invocation of dxclntmp. null (empty string) value, then an error message is The name dxclntmp is derived from “clean displayed and the copy or move request is denied. temporary (directory)”. The dx prefix used here is Note that some DICE utilities create or manipulate based on the selectively-applied DICE utility naming files in the DICE temporary directory. For example, convention described in Section III-A. some utilities place diagnostic output in the temporary There is also a DICE convenience utility, called directory that can be examined for debugging user- dxrmcl, for removing individually-specified files or defined command sequences or scripts that invoke directories from the DICE user clipboard. The name DICE utilities. Thus, if one browses the contents of stands for “remove from clipboard.” The usage format the temporary directory, it is not unusual to find files for dxrmcl is as follows. there that one has not explicitly placed.

dxrmcl C. OTHER UTILITIES where is the name of a file or directory in The discussion of utilities in this section provides the DICE user clipboard. If represents a file, a brief illustration of some of the features available then the file is removed from the DICE user clipboard. in DICE. Many more utilities are available in DICE. Conversely, if represents a subdirectory in Documentation for these utilities is being systemati- the DICE user clipboard, then the entire subdirectory cally integrated into an online documentation system (i.e., the entire subdirectory along with all directories that is under development for DICE, and is planned that are nested within it) is removed. Caution should for inclusion in a future release.

5 IV. UNIT TESTING build a driver program) that are needed for the DICE includes a framework for implementation and test. In DICE, we use the convention that files execution of tests for software projects. Although the that do not have file name extensions are Bash emphasis in this framework is on unit tests, and scripts. Thus, tests that are developed as part therefore, it is often referred to as the DICE unit of DICE have their makeme files implemented testing framework, the framework can also be applied as Bash scripts. Note that the compilation steps to testing at higher levels of abstraction, including performed in the makeme file for a test typically subsystem- and system-level testing. do not include compilation of the source code that A major goal of the testing capabilities in DICE is is being tested. It is assumed that source code to provide a lightweight and flexible unit testing envi- for a project under test is compiled separately ronment. It is lightweight in that it requires minimal before a test suite associated with the project is learning of new syntax or specialized languages, and exercised. Thus, compilation functionality within flexible in that it can be used to test source code in any the test suite specifies only compilation steps that language, including C, Java, Verilog, and VHDL. This are specific to the tests. is useful in heterogeneous development environments Note also that for some kinds of tests, no so that a common framework can be used to test compilation steps are needed apart from the com- across all of the relevant platforms. It is also useful pilation that is performed on the source code that in instructional settings so that students can focus on is being tested. For example, if a test is invoked the core principles and practices of unit testing while by running an executable program that is part of spending minimal effort learning framework-specific the project being tested, then it is likely that no conventions and syntax. test-specific compilation needs to be performed. Each specific test in a DICE-based test suite In such a case, a makeme file should still be is implemented in a separate directory, which present in the ITS directory; however, its contents is referred to as an individual test subdirectory can be empty or can consist only of comments (ITS). To be processed by the DICE facilities for (e.g., comments that indicate that nothing needs automated test suite execution, the name of an ITS to be done to build the test). must begin with “test” (e.g., test01, test02, • An executable file called runme that runs the test-A, test-B, test_square_matrix_1, test associated with the enclosing ITS, and directs test_square_matrix_2). To exclude a test from the normal output associated with the test to test suite evaluation, one can simply change its name standard output, and the error output associated so that it does not begin with “test”. with the test to standard error. As with makeme files, runme files are typically scripts, and within A. Required components of an ITS DICE test suites, runme scripts are Bash scripts. The following are required components of an ITS. If the test takes input from standard input, then Each of these components takes the form of a separate the runme script should generally redirect that file. input to come from a file that is stored within the • A README.txt file that provides a brief expla- ITS. nation of what is being tested by the test — that • A file called correct-output.txt that con- is, what is distinguishing about this test compared tains the standard output text that should result to the other tests in the test suite. Technically, from the test — i.e., the text that should appear a README.txt file is not required within an if runme is executed, and the project function- ITS, but we list it here among all of the actual ality that is being tested has been implemented requirements because it is of foremost importance correctly. If the correct operation of the test does to have tests properly documented in a place that not produce any standard output text, then the is easy to find. correct-output.txt file should exist within • An executable file (e.g., some of script) called the ITS as an empty file (i.e., a file that contains makeme that performs all necessary compilation no characters). steps (e.g., compilation steps that are used to • A file called expected-errors.txt that

6 contains the standard error text that should result Each time dxtest visits a new directory, the script from the test — i.e., the text that should appear checks whether or not the directory contains a file on standard error if runme is executed, and the called runme. If a runme file is found, then the project error handling capability (if any) that is directory is treated as an ITS, and all of the re- being tested has been implemented correctly. If quired ITS files listed above are expected to exist, the test does not exercise any error handling and are processed based on the descriptions given capability, then the expected-errors.txt above. Specifically, the makeme file of the ITS is first file should exist within the ITS as an empty file. executed to perform any necessary steps required to build the test. Then the runme file is executed to B. Examples exercise the test. The output generated by runme is correct-output.txt As a supplement to the DICE User’s Guide [3], then compared with the and expected-errors.txt one can find two simple project examples that involve files to determine whether program and function versions of vector inner product or not the test succeeded. computation. These examples illustrate construction After the entire recursive directory traversal is com- dxtest of ITSs and basic use of DICE project testing fea- plete, produces a summary of how many tures. These examples are in the form of simple C- tests (ITSs) were exercised, how many of these tests language projects with test suites that are implemented succeeded, and how many failed. Furthermore, if any according to the DICE ITS conventions described in test failures were encountered, a listing of the directory this section. These examples can easily be adapted to paths corresponding to the failed ITSs is provided in autotest-output/test_summary.txt provide basic demonstrations of, and starting points for . experimenting with DICE testing capabilities in other Thus, with a high degree of automation, one can programming languages. assess the overall success rate of a test suite and identify any specific tests that are failing. To try out these testing examples, it is recommended that users start with the program version rather than D. Running tests in verbose mode the function version, as this version is a little easier The -v option can be used with dxtest to provide to understand. To try either version, one should first verbose output as the test suite is exercised. This can cd to the project src directory, and run ./makeme, be useful if the test suite is exhibiting some sort of which compiles the project. Then one can cd to the unexpected behavior. For example, if the test suite is project test directory, and run the DICE command taking longer than expected to finish execution because dxtest to exercise all of the tests in the test suite. one of the tests is “hanging” (e.g., due to an infinite loop), then verbose output can be enabled to the C. The DICE dxtest command offending test. The DICE dxtest command is the core utility It is useful, however, to run tests with verbose available in DICE for exercising test suites. The usage output “off” (i.e., by leaving out the -v option) before format of this command is as follows. any sort of finalization of a testing pass (e.g., before dxtest [-v] committing changes to a shared code repository). This is because some errors that occur when running a test The dxtest utility recursively traverses the direc- suite (e.g., problems executing a makeme or runme tory subtree located in the current working directory script) can be hard to notice amidst the normal verbose (the directory from which dxtest is called). During output. On the other hand, these kinds of problems are this traversal, only directories whose names begin with exposed clearly when verbose output is turned off. “test” are actually visited; all other directories are ignored. For any directory that is encountered with E. More about runme files a name that does not begin with “test”, the entire As described earlier, the success or failure of directory subtree rooted at that directory is ignored an individual DICE test (ITS evaluation) is deter- (even if the subtree contains subdirectories whose mined by comparing the standard output and stan- names start with “test”). dard error text generated from the associated runme

7 script with the given correct-output.txt and put if and only if the files being compared differ expected-errors.txt files, respectively. in at least one character. Under such a convention, This convention provides significant flexibility the correct-output.txt file for our hardware in how test output is actually defined and man- description language test would simply be an empty aged. In particular, it is not necessary for all file. This empty correct-output.txt file to- of the output produced by the project code un- gether with the three files correct-sim1.txt, der test to be treated directly as test output (i.e., correct-sim2.txt, and correct-sim3.txt to be compared with correct-output.txt and comprise the normal (error-free) output verification expected-errors.txt) during each test evalua- files associated with this ITS. tion. Instead, the runme file can serve as a wrapper In summary, it is the standard output produced from to filter or reorganize the output generated by a test in runme that is used by dxtest to validate an ITS a form that the user finds most efficient or convenient against the associated correct-output.txt file. for test management. Through appropriate programming of the runme file, For example, suppose that the project under test is the standard output of runme is in general highly a hardware description language (HDL) implementa- configurable by the person who develops the test. tion in a language such as Verilog or VHDL, and Creative design of runme files can help to make more the relevant output for one of the tests consists of powerful and convenient test organizations within the three simulator output files sim1.txt, sim2.txt DICE testing framework. and sim3.txt. The “brute force” way to develop a runme script for this test would be to invoke V. DICELANG the HDL simulator in the runme script, and then concatenate the files sim1.txt, sim2.txt, and The dicelang package, which can be viewed as sim3.txt to standard output (e.g., by using the a companion package of DICE, provides a collection UNIX command). The correct-output.txt of language-specific plug-ins that extend the features file for such a test configuration would contain the of DICE, and provide new features to facilitate ef- concatenated contents of sim1.txt, sim2.txt, and ficient software project development, implementation sim3.txt that should result from a correct project management, and testing for selected programming implementation — i.e., the concatenated result of the languages. In contrast, the features in DICE emphasize three, pre-verified, “golden” simulation output files. generality, and applicability across different kinds of An alternative approach for this testing scenario, programming languages and development tools. which may be preferable in many contexts to such There is a benign, but possibly confusing (at a brute force approach, is to maintain the golden first) circular dependence between DICE and simulation output files in separate files — e.g., dicelang-C, which is the C language plug-in correct-sim1.txt, correct-sim2.txt, and within dicelang. This dependency arises because correct-sim3.txt within the ITS. The runme C, along with Bash and Python, is one of the script could then use the UNIX command languages in which DICE is implemented. Unlike to compare the files sim1.txt, sim2.txt, and programs in Bash and Python, C programs need to sim3.txt produced from a test run with the cor- be compiled before they can be executed, and for responding golden output files — the trailing code in the purpose of compiling the C-based components the runme script would then look something like: in DICE, we use some features in dicelang-C for building projects that are developed in C. Thus, diff sim1.txt correct-sim1.txt dicelang must be installed and built before DICE diff sim2.txt correct-sim2.txt can be built. However, DICE must be started up diff sim3.txt correct-sim3.txt (without building the C-based components in DICE) The exact operation of the UNIX diff utility is before dicelang-C can be built. This is where the not completely standardized across different platforms. “circular dependency” described above arises. However, a typical convention used in implementa- The DICE User’s Guide [3] includes instructions for tions of diff is to produce output to standard out- handling this circular dependency, and getting started

8 using both DICE, including all of its C-based compo- effort is saved by having a formal, unambiguous ap- nents, and dicelang-C. plication description to base the implementation on. More information about the dicelang package is Quality is controlled with a high degree of automation available from the DICE User’s Guide [3]. through the direct reuse of unit tests in DICE. . RELATIONSHIP TO DIF VII. RELATIONSHIP TO OTHER UNIT The dataflow interchange format (DIF), which in- TESTING FRAMEWORKS cludes The DIF Language (TDL) and The DIF Package Typically when software designers employ unit test- (TDP), is another tool developed by the Maryland ing, they use frameworks that are language specific [6], DSPCAD Research Group [4], [5]. TDL and TDP pro- [7]. More than just a syntactic customization, such vide tools for model-based design and implementation frameworks are often tied to fundamental constructs of signal processing systems using dataflow graphs. of the language. For example, in CppUnit a unit test DIF is orthogonal to DICE, so that one can use DICE inherits from a base class defined by CppUnit [8]. without DIF and vice versa. A test writer then overloads various methods of the Even with best practices in industry, embedded base class to put the specific unit test in this frame- software development involves an initial application work. Tests requiring the specific features that lever- description in a design environment, which is then age the constructs of a language (e.g., in an object manually transcoded and tuned to target the final de- oriented language, checking that the method exhibits sign platform. Often separated by languages, tools, and the proper form of polymorphism) are well served by even different teams, going from an initial application these approaches. Furthermore, these language-specific description to a final implementation tends to be a man- approaches work well when designers are using only ual, error-prone, time-consuming problem. To improve a single language or a single platform for their fi- quality and performance while reducing development nal implementation. But when designers must move time, a cross platform design environment is needed between languages with different constructs (such as that accommodates both early design exploration and between C++ and Verilog), the existing tests must be final implementation tuning. rewritten. This creates extra design effort and creates DIF and DICE are complementary tools, which a new verification challenge to ensure that unit tests when used in tandem, enhance software development between the two languages are in fact performing the processes for dataflow-based design and implementa- same test. tion of signal processing systems. A designer starts Embedded and high performance software must with a platform-independent description of the ap- often utilize multiple languages and multiple plat- plication in DIF. This structured, formal application forms, and transcoding between an initial application description is an effective starting point for capturing specification and software for the final implementa- concurrency and optimizing and analyzing the applica- tion. DICE is language-agnostic to support this design tion. After settling on the DIF description, a designer need. By simplifying and streamlining the processes can refine this description to an optimized implemen- of test bench design and implementation, the same tation by employing platform specific tools including test fixture can be used in a variety of scenarios. compilers, debuggers, and simulators. Any transcoding DICE encourages that tests be written in a language- or platform specific enhancements are accommodated agnostic way, prompting designers to provide input and by DICE via its flexible but standardized build and expected output streams using primitive data types. test framework. This allows designers to utilize the DICE tests are simpler to (even non-language- same design framework at inception as they do at final experts can write them), easier to maintain, and much implementation. more portable. Software developed jointly with DIF and DICE Probably the most related framework to DICE is the enjoys a single, cross platform software management Test Anything Protocol (TAP) [9]. TAP is language- framework, where verification of modules is handled agnostic by defining the protocol that manages the consistently throughout each phase of development. By communication between unit tests and a testing har- leveraging the reference DIF description, transcoding ness. Individual tests (TAP producers) communicate

9 test results to the testing harness (TAP consumers). report has also provided brief introductions to some TAP enables multi-platform, multi-language design, of the general utility commands in DICE; the unit but only at the communication boundary. Unit tests testing features in DICE; and the companion package, need only adhere to the communication design, leav- dicelang, which provides programming-language- ing test writers with no specific language-agnostic specific plug-ins that extend the capabilities of DICE mechanism for writing the tests themselves. Indeed, in ways that are customized to specific languages. many language specific unit tests have TAP compatible For detailed information on DICE, including more outputs so they may be hooked into a larger multi- comprehensive documentation, as well as information language testing environment. on downloading and setting up DICE, we refer the DICE provides a language-agnostic approach to unit reader to the DICE Project Website [1], and the DICE test writing by leveraging common dataflow constructs. User’s Guide [3]. More detailed discussions are also Some unit test frameworks have data generators, but available on applications of DICE to specific kinds of DICE encourages designers to think of module in- design problems. For example, the application of DICE terfaces in terms of streaming data primitives into to design and implementation of high performance and out of them. DICE captures these input/output field-programmable gate array systems is discussed sequences in files and then ensures that the output in [11], and applications to analysis and optimization files match with a structured build-and-run framework. of precision in signal processors are discussed in [12]. These assumptions allow test writers in DICE to build more complete language-agnostic solutions than a test IX. ACKNOWLEDGMENTS communication protocol alone. This work is sponsored in part by the U. S. National Note that the testing features provided in DICE Science Foundation under grant NSF-ECCS0823989, are oriented towards test implementation, test exe- the Laboratory for Telecommunication Science, and the cution, and general practices of test-driven project US Air Force Research Laboratory. development — they are not developed as a framework We are grateful also to the following people oriented towards any particular methodology for test who have made valuable contributions to DICE and design or test generation, such as those discussed in the dicelang, and to earlier software components that extensive survey by Hierons et al. [10]. DICE allows have evolved into parts of DICE and dicelang: Bish- one to apply different methods for test suite design, nupriya Bhattacharya, Nitin Chandrachoodan, Sou- while providing features of cross-platform operation; janya Kedilaya, and Robert Ricketts. cross-language testing; efficient test retargetability; au- tomated test suite execution and test status reporting; REFERENCES and seamless integration as part of the overall feature [1] “DICE project website,” http://www.ece.umd.edu/ set of DICE (e.g., use of dxco, and dxparl to copy DSPCAD/projects/dice/dice.htm. test directory templates from one place to another, and use of navigation utilities to jump back and forth [2] C. Newham and B. Rosenblatt, Learning the Bash between test directories and project source code). - shell, O’Reilly & Associates, Inc., third edition, 2005. ploring ways to integrate DICE-based project and test development with systematic approaches to test design [3] S. S. Bhattacharyya, C. Shen, . Plishker, N. Sane, and and generation is a useful direction for further study. G. Zaki, “Using the DSPCAD integrative command- line environment: User’s guide for DICE version 1.1,” VIII. SUMMARY Tech. Rep. DSPCAD-TR-2011-13, Institute for Ad- This report has provided a motivation and overview vanced Computer Studies, University of Maryland at College Park, 2011. of DICE, the DSPCAD integrative command-line en- vironment. DICE is geared towards promoting produc- [4] C. Hsu, M. Ko, and S. S. Bhattacharyya, “Software tivity and efficiency in the management of software synthesis from the dataflow interchange format,” in implementations. Significant emphasis has been placed Proceedings of the International Workshop on Software in DICE on features that can be used directly or easily and Compilers for Embedded Systems, Dallas, Texas, adapted across different programming languages. This September 2005, pp. 37–49.

10 [5] W. Plishker, N. Sane, M. Kiemb, K. Anand, and S. S. Bhattacharyya, “Functional DIF for rapid prototyping,” in Proceedings of the International Symposium on Rapid System Prototyping, Monterey, California, June 2008, pp. 17–23.

[6] Paul Hamill, Unit Test Frameworks, O’Reilly & Associates, Inc., 2004.

[7] H. Gollee T. Dohmke, “Test-driven development of a PID controller,” IEEE Software, vol. 24, no. 3, pp. 44–50, 2007.

[8] P. Hamill, Unit test frameworks, chapter 7, O’Reilly & Associates, Inc., 2004.

[9] S. Cozens, Advanced programming, O’Reilly & Associates, Inc., second edition, 2005.

[10] R. M. Hierons et al., “Using formal specifications to support testing,” ACM Computing Surveys, vol. 41, no. 2, February 2009.

[11] W. Plishker, C. Shen, S. S. Bhattacharyya, G. Zaki, S. Kedilaya, N. Sane, K. Sudusinghe, T. Gregerson, J. Liu, and M. Schulte, “Model-based DSP imple- mentation on FPGAs,” in Proceedings of the In- ternational Symposium on Rapid System Prototyping, Fairfax, Virginia, June 2010, Invited paper, DOI 10.1109/RSP 2010.SS4, 7 pages.

[12] S. Kedilaya, W. Plishker, A. Purkovic, B. Johnson, and S. S. Bhattacharyya, “Model-based precision analysis and optimization for digital signal processors,” in Proceedings of the European Signal Processing Conference, Barcelona, Spain, August 2011, To appear.

11