The DSPCAD Integrative Line Environment: Introduction to DICE Version 1

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

Abstract—DICE (the DSPCAD Integrative Command is being developed by the Maryland DSPCAD Re- Line Environment) is a package of utilities that facilitates search Group, which focuses on computer-aided design efficient management of software projects. Key areas of (CAD) techniques for digital signal processing (DSP) emphasis in DICE are cross-platform operation, support systems. However, the features provided in DICE are for projects that integrate heterogeneous programming generally not specific to DSP or CAD-for-DSP appli- languages, and support for applying and integrating different kinds of design and testing methodologies. cations, and can be used be in other domains just as The package is being developed at the University of effectively. Maryland to facilitate the research and teaching of For clarity, we should note what DICE is not. DICE methods for implementation, testing, evolution, and re- is not meant to existing software development vision of engineering software. The package is also being tools. DICE is not a nor is it a compiler or synthe- developed as a foundation for developing experimental sizer. It is not a debugger nor does it provide simulation research software for techniques and tools in the area of capabilities. It does not provide automatic transcoding computer-aided design (CAD) of digital signal process- for porting between platforms and languages. DICE is ing (DSP) systems. The package is intended for cross- instead a command line solution to utilize all of these platform operation, and is currently being developed and used actively on the Windows (equipped with Cygwin), existing kinds of tools effectively, especially for Solaris, and Linux platforms. cross-platform design. This report provides an introduction to DICE, and provides background on some of the key features in II.SETTINGUPDICE DICE. This report also gives a brief introduction to DICE is implemented as a collection of utilities that dicelang, which is a plug-in package for DICE that are in the form of bash scripts, C programs, and python provides additional utilities, libraries, and tools for scripts. Therefore, facilities for interpreting/compiling managing software projects in specific programming these languages must be available to use all of the languages. capabilities in DICE. DICE is developed with signif- icant attention to cross-platform operation. Platforms I.INTRODUCTION on which DICE is used actively include Windows This report provides an introduction to DICE, which (equipped with Cygwin), Solaris, and Linux. stands for the DSPCAD Integrative Command Line En- DICE can be downloaded from the DICE Project vironment. The objective of DICE is to provide a flex- Website (http://www.ece.umd.edu/DSPCAD/projects/ ible, light-weight environment for the research, devel- dice/dice.htm). Details on setting up, using, and trou- opment, testing, and integration of software projects, bleshooting DICE are covered in the DICE User’s particularly those that employ heterogeneous program- Guide [1], which is available through this website. ming languages or models of computation. DICE III.INTRODUCTIONTODICEUTILITIES Technical Report UMIACS-TR-2009-13, Institute for Advanced Computer Studies, University of Maryland at College Park, August DICE includes a variety of utilities to improve 2009. productivity while working in a command-line or shell- based project development environment. This section ˜/projects/proj1 provides a brief introduction to some of the basic utili- dlk p1 ties available in DICE. These utilities help improve the cd ˜/documents/doc1 convenience with which one can do some common and g p1 fundamental tasks. More utilities and further details are After the above sequence of commands, the user will described in the DICE User’s Guide [1] . end up in ˜/projects/proj1. A. DIRECTORY NAVIGATION If the dlk command is called with a 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 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 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 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 directory. dlk

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

3 mvftmp convenient when used in conjunction with standard file name auto-completion features in the bash shell. where is the name of a file or directory. The Note that there are better ways to reuse code than command moves the file or subdirectory named copying code files, so this example should not be taken from the DICE temporary directory, assuming such as a model for project development practices, but rather a file or subdirectory exists. The utilities mvttmp as an illustration of the combined use of navigation- and mvftmp are often used in conjunction with one related and MTA utilities in DICE. another, but this is not a requirement: a file or subdirec- Another, perhaps more common, scenario in which tory moved using mvftmp need not have been placed this kind of MTA functionality can be useful is when originally in the temporary directory using mvttmp. selecting a template from a repository of document cpttmp cpftmp The utilities and work like their templates (e.g., templates for business letters, personal mvttmp mvftmp cousins, and , except that they copy letters, project reports, oral presentations, etc.). One rather than move the specified files or directories. Their can quickly make a copy of and starting working with mvttmp usage formats are analogous to those for and the appropriate template with just a few commands — mvftmp — i.e., they each take a single argument, for example: which gives the name of a file or directory. The mvftmpl and cpftmpl utilities are variations plk templates of mvftmp and cpftmp, respectively, that implicitly cpttmp letter-from-home.tex reference the last file or directory transferred (LFDT) popd by mvttmp or cpttmp. Each call to mvttmp or mvftmpl cpttmp has the side-effect of updating a DICE in- As suggested earlier, the MTA utilities need not be ternal variable that stores the name of the LFDT used in pairs — e.g., a cpttmp command need not be Neither mvftmpl nor cpftmpl takes any argu- coupled with a corresponding mvftmp or mvftmpl ments. These commands transfer the LFDT from the command. The MTA utilities can be used for any DICE temporary directory to the current working di- pattern of moving and copying files to and from the rectory. They differ, as their names suggest, in that the DICE temporary directory. For example, moving or LFDT is moved out of the temporary directory with copying a file to the temporary directory can be useful mvftmpl, whereas it is copied with cpftmpl. if one wants to move a file or directory out of the As described earlier, the DICE MTA utilities can be way from the current working directory, but is not especially convenient to use in conjunction with the completely sure yet whether or not the file or directory directory navigation utilities described in Section III-A. will be needed again in the future. As an example of this kind of convenience, suppose Such forms of usage of the MTA utilities can gener- that proj1 and proj2 are project directories that ally be useful to help fine-tune directory organization. have previously been labeled as pr1 and pr2, re- However, after a while, they can lead to increasing disk spectively, using dlk. Suppose also that there is a space requirements for the DICE temporary directory. file called utilities.c in the proj1 directory Thus, the temporary directory should periodically be that one wants to use a copy of or expand on in the cleaned out or “reset”. A good time to do this is proj2 directory. This file can be copied to the proj2 when there are no pending cpftmpl or mvftmpl directory using the following sequence of commands. commands, and just after one has backed up the g pr1 temporary directory (perhaps as part of a general user cpttmp utilities.c space backup routine). That way, in case one needs g pr2 to refer back to a file or directory that was “semi- mvftmpl confidently” discarded into the temporary directory, there is a means to the file or directory. This is equivalent to a copy-and-paste using basic Because of the importance, in terms of disk space mouse-based file operations, but this kind of command- usage, of periodically emptying-out the DICE tem- based sequence can be much more convenient and porary directory, DICE is a equipped with a simple efficient once one gets used to it. It is even more utility called dxclntmp to perform this task. The

4 dxclntmp utility removes all of the files and sub- variable controls what happens when the file or direc- directories within the DICE temporary directory, and tory specified to cpttmp or mvttmp conflicts with resets the directory so that it contains just a single an identically-named file or directory in the DICE file. This file is a small, single-line log file called user temporary directory. If DX_MTA_AGGRESSIVE dxclntmp-log.txt, which contains a record of the is set to a non-null value, then the identically-named time stamp — as returned by the UNIX date com- file or directory in the temporary directory is silently mand — of the most recent invocation of dxclntmp. overwritten. Conversely, if DX_MTA_AGGRESSIVE is The name dxclntmp is derived from “clean not defined or is set to a null (empty string) value, then temporary (directory)”. The dx prefix used here is an error message is displayed and the copy or move based on the selectively-applied DICE utility naming request is denied. convention described in Section III-A. Note that some DICE utilities create or manipulate There is also a DICE convenience utility, called files in the DICE temporary directory. For example, rmftmp, for removing individually-specified files or some utilities place diagnostic output in the temporary directories from the temporary directory. The name directory that can be examined for debugging user- stands for “remove from temporary directory”. The defined command sequences or scripts that invoke usage format for rmftmp is as follows. DICE utilities. Thus, if one browses the contents of rmftmp the temporary directory, it is not unusual to find files there that one has not explicitly placed. where is the name of a file or directory in the DICE temporary directory. If represents a file, C. OTHER UTILITIES then the file is removed from the temporary directory. The discussion of utilities in this section provides Conversely, if represents a subdirectory in a brief illustration of some of the features available in the temporary directory, then the entire subdirectory DICE. Many more utilities are available in DICE. More (i.e., the entire subdirectory along with all directories thorough documentation on DICE utilities is available that are nested within it) is removed. Caution should in the DICE User’s Guide [1]. be exercised before using rmftmp since files and directories in the temporary directory that are removed IV. UNIT TESTING by this command are removed permanently. It is useful to be aware of the rmftmp utility when DICE includes a framework for implementation and working with the MTA utilities — specifically, when execution of tests for software projects. Although the working with mvttmp and cpttmp. This is because emphasis in this framework is on unit tests, and by default, the mvttmp and cpttmp commands are therefore, it is often referred to as the DICE unit safe in the sense that the specified file or directory testing framework, the framework can also be applied will not be moved if a file or directory with the same to testing at higher levels of abstraction, including name already exists in the temporary directory. In subsystem- and system-level testing. other words, one cannot accidentally overwrite a file or A major goal of the testing capabilities in DICE is directory using cpttmp or mvttmp. Thus, for example, if to provide a lightweight and flexible unit testing envi- one is trying to move a file to the temporary directory ronment. It is lightweight in that it requires minimal using mvttmp but finds (through the error message learning of new syntax or specialized languages, and reported from mvttmp) that a file with the same name flexible in that it can be used to test source code in any already exists in the temporary directory, one must language, including C, Java, Verilog, and VHDL. This somehow get rid of the identically-named temporary is useful in heterogeneous development environments directory file. A convenient way to do this, assuming so that a common framework can be used to test that the temporary directory file is no longer needed, across all of the relevant platforms. It is also useful is with rmftmp. in instructional settings so that students can focus on The default “safe” configuration of cpttmp and the core principles and practices of unit testing while mvttmp can be changed through the environment spending minimal effort learning framework-specific variable DX_MTA_AGGRESSIVE. This environment conventions and syntax.

5 Each specific test in a DICE-based test suite file should still be present in the ITS directory; is implemented in a separate directory, which however, its contents can be empty or can consist is referred to as an individual test subdirectory only of comments (e.g., comments that indicate (ITS). To be processed by the DICE facilities for that nothing needs to be done to build the test). automated test suite execution, the name of an ITS • An executable file called runme that runs the must begin with “test” (e.g., test01, test02, test associated with the enclosing ITS, and directs test-A, test-B, test_square_matrix_1, the normal output associated with the test to test_square_matrix_2). To exclude a test from standard output, and the error output associated test suite evaluation, one can simply change its name with the test to standard error. As with makeme so that it does not begin with “test”. files, runme files are typically scripts, and within DICE test suites, runme scripts are bash scripts. A. Required components of an ITS If the test takes input from standard input, then The following are required components of an ITS. the runme script should generally redirect that Each of these components takes the form of a separate input to come from a file that is stored within the file. ITS. • A README.txt file that provides a brief expla- • A file called correct-output.txt that con- nation of what is being tested by the test — that tains the standard output text that should result is, what is distinguishing about this test compared from the test — i.e., the text that should appear to the other tests in the test suite. Technically, if runme is executed, and the project function- a README.txt file is not required within an ality that is being tested has been implemented ITS, but we list it here among all of the actual correctly. If the correct operation of the test does requirements because it is of foremost importance not produce any standard output text, then the to have tests properly documented in a place that correct-output.txt file should exist within is easy to find. the ITS as an empty file (i.e., a file that contains • An executable file (e.g., some sort of script) called no characters). makeme that performs all necessary compilation • A file called expected-errors.txt that steps (e.g., compilation steps that are used to contains the standard error text that should result build a driver program) that are needed for the from the test — i.e., the text that should appear test. In DICE, we use the convention that files on standard error if runme is executed, and the that do not have file name extensions are bash project error handling capability (if any) that is scripts. Thus, tests that are developed as part being tested has been implemented correctly. If of DICE have their makeme files implemented the test does not exercise any error handling as bash scripts. Note that the compilation steps capability, then the expected-errors.txt performed in the makeme file for a test typically file should exist within the ITS as an empty file. do not include compilation of the source code that is being tested. It is assumed that source code B. Examples for a project under test is compiled separately As a supplement to the DICE User’s Guide [1], before a test suite associated with the project is one can find two simple project examples that involve exercised. Thus, compilation functionality within program and function versions of vector inner product the test suite specifies only compilation steps that computation. These examples illustrate construction are specific to the tests. Note also that for some of ITSs and basic use of DICE project testing fea- kinds of tests, no compilation steps are needed tures. These examples are in the form of simple C- apart from the compilation that is performed on language projects with test suites that are implemented the source code that is being tested. For example, according to the DICE ITS conventions described in if a test is invoked by running an executable this section. These examples can easily be adapted to program that is part of the project being tested, provide basic demonstrations of, and starting points for then it is likely that no test-specific compilation experimenting with DICE testing capabilities in other needs to be performed. In such a case, a makeme programming languages.

6 To try out these testing examples, it is recommended D. Running tests in verbose mode that users with the program version rather than The -v option can be used with dxtest to provide the function version, as this version is a little easier verbose output as the test suite is exercised. This can to understand. To try either version, one should first be useful if the test suite is exhibiting some sort of cd to the project src directory, and run ./makeme, unexpected behavior. For example, if the test suite is which compiles the project. Then one can cd to the taking longer than expected to finish execution because project test directory, and run the DICE command one of the tests is “hanging” (e.g., due to an infinite dxtest to exercise all of the tests in the test suite. loop), then verbose output can be enabled to locate the C. The DICE dxtest command offending test. It is useful, however, to run tests with verbose The DICE dxtest command is the core utility output “off” (i.e., by leaving out the -v option) before available in DICE for exercising test suites. The usage any sort of finalization of a testing pass (e.g., before format of this command is as follows. committing changes to a shared code repository). This dxtest [-v] is because some errors that occur when running a test suite (e.g., problems executing a makeme or runme The dxtest utility recursively traverses the direc- script) can be hard to notice amidst the normal verbose tory subtree located in the current working directory output. On the other hand, these kinds of problems are (the directory from which dxtest is called). During exposed clearly when verbose output is turned off. this traversal, only directories whose names begin with “test” are actually visited; all other directories are E. More about runme files ignored. For any directory that is encountered with As described earlier, the success or failure of a name that does not begin with “test”, the entire an individual DICE test (ITS evaluation) is deter- directory subtree rooted at that directory is ignored mined by comparing the standard output and stan- (even if the subtree contains subdirectories whose dard error text generated from the associated runme names start with “test”). script with the given correct-output.txt and Each time dxtest visits a new directory, the script expected-errors.txt files, respectively. checks whether or not the directory contains a file This convention provides significant flexibility called runme. If a runme file is found, then the in how test output is actually defined and man- directory is treated as an ITS, and all of the re- aged. In particular, it is not necessary for all quired ITS files listed above are expected to exist, of the output produced by the project code un- and are processed based on the descriptions given der test to be treated directly as test output (i.e., above. Specifically, the makeme file of the ITS is first to be compared with correct-output.txt and executed to perform any necessary steps required to expected-errors.txt) during each test evalua- build the test. Then the runme file is executed to tion. Instead, the runme file can serve as a wrapper exercise the test. The output generated by runme is to filter or reorganize the output generated by a test in then compared with the correct-output.txt and a form that the user finds most efficient or convenient expected-errors.txt files to determine whether for test management. or not the test succeeded. For example, suppose that the project under test is After the entire recursive directory traversal is com- a hardware description language (HDL) implementa- plete, dxtest produces a summary of how many tion in a language such as Verilog or VHDL, and tests (ITSs) were exercised, how many of these tests the relevant output for one of the tests consists of succeeded, and how many failed. Furthermore, if any three simulator output files sim1.txt, sim2.txt test failures were encountered, a listing of the directory and sim3.txt. The “brute force” way to develop paths corresponding to the failed ITSs is provided in a runme script for this test would be to invoke autotest-output/test_summary.txt. the HDL simulator in the runme script, and then Thus, with a high degree of automation, one can concatenate the files sim1.txt, sim2.txt, and assess the overall success rate of a test suite and sim3.txt to standard output (e.g., by using the identify any specific tests that are failing. UNIX cat command). The correct-output.txt

7 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 languages script could then use the UNIX diff command in which DICE is implemented. Unlike programs in to compare the files sim1.txt, sim2.txt, and bash and python, C programs need to be compiled sim3.txt produced from a test run with the cor- before they can be executed, and for the purpose of responding golden output files — the trailing code in compiling the C-based components in DICE, we use the runme script would then look something like: some features in dicelang-C for building projects that are developed in C. Thus, dicelang must be diff sim1.txt correct-sim1.txt installed and built before DICE can be built. However, diff sim2.txt correct-sim2.txt DICE must be started up (without building the diff sim3.txt correct-sim3.txt C-based components in DICE) before dicelang-C The exact operation of the UNIX diff utility is can be built. This is where the “circular dependency” not completely standardized across different platforms. described above arises. However, a typical convention used in implementa- The DICE User’s Guide [1] includes instructions for tions of diff is to produce output to standard out- handling this circular dependency, and getting started put if and only if the files being compared differ using both DICE, including all of its C-based compo- in at least one character. Under such a convention, nents, and dicelang-C. the correct-output.txt file for our hardware More information about the dicelang package is description language test would simply be an empty available from the DICE User’s Guide [1]. file. This empty correct-output.txt file to- gether with the three files correct-sim1.txt, VI. RELATIONSHIP TO DIF correct-sim2.txt, and correct-sim3.txt comprise the normal (error-free) output verification The dataflow interchange format (DIF), and the as- files associated with this ITS. sociated DIF package (TDP) are other tools developed In summary, it is the standard output produced from by the Maryland DSPCAD Research Group [2], [3]. runme that is used by dxtest to validate an ITS DIF and TDP provide tools for model-based design against the associated correct-output.txt file. and implementation of signal processing systems using Through appropriate programming of the runme file, dataflow graphs. DIF is orthogonal to DICE, so that the standard output of runme is in general highly one can use DICE without DIF and vice versa. configurable by the person who develops the test. Even with best practices in industry, embedded Creative design of runme files can help to make more software development involves an initial application powerful and convenient test organizations within the description in a design environment, which is then DICE testing framework. manually transcoded and tuned to target the final design platform. Often separated by languages, tools, V. DICELANG and even different teams, going from an initial appli- cation description to a final implementation tends to The dicelang package, which can be viewed as be a manual, error-prone, time-consuming problem. To a companion package of DICE, provides a collection improve the quality and performance while reducing of language-specific plug-ins that extend the features development time, a cross platform design environment

8 is needed that accommodates both early design explo- a new verification challenge to ensure that unit tests ration and final implementation tuning. between the two languages are in fact performing the DIF and DICE are complementary tools, which same test. when used in tandem, enhance software develop- Embedded and high performance software must ment processes. A designer starts with a platform- often utilize multiple languages and multiple plat- independent description of the application in DIF. This forms, and transcoding between an initial application structured, formal application description is an ideal specification and software for the final implementa- starting point for capturing concurrency and optimizing tion. DICE is language-agnostic to support this design and analyzing the application. After settling on the need. By simplifying and streamlining the processes DIF description, a designer can refine this description of test bench design and implementation, the same to a high-performance implementation by employing test fixture can be used in a variety of scenarios. platform specific tools including compilers, debuggers, DICE encourages that tests be written in a language- and simulators. Any transcoding or platform specific agnostic way, prompting designers to provide input and enhancements are accommodated by DICE via its expected output streams using primitive data types. flexible but standardized build and test framework. This DICE tests are simpler to write (even non-language- allows designers to utilize the same design framework experts can write them), easier to maintain, and much at inception as they do at final 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) [7]. 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 effort is saved by having a formal, unambiguous ap- test results to the testing harness (TAP consumers). plication description to base the implementation on. TAP enables multi-platform, multi-language design, Quality is controlled with a high degree of automation but only at the communication boundary. Unit tests through the direct reuse of unit tests in DICE. need only adhere to the communication design, leav- ing test writers with no specific language-agnostic VII.RELATIONSHIPTOOTHERUNIT mechanism for writing the tests themselves. Indeed, TESTINGFRAMEWORKS many language specific unit tests have TAP compatible Typically when software designers employ unit test- outputs so they may be hooked into a larger multi- ing, they use frameworks that are language specific [4], language testing environment. [5]. More than just a syntactic customization, such DICE provides a language-agnostic approach to unit frameworks are often tied to fundamental constructs test writing by leveraging common dataflow constructs. of the language. For example, in CppUnit a unit test Some unit test frameworks have data generators, but inherits from a base class defined by CppUnit [6]. DICE encourages designers to think of module in- A test writer then overloads various methods of the terfaces in terms of streaming data primitives into base class to put the specific unit test in this frame- and out of them. DICE captures these input/output work. Tests requiring the specific features that lever- sequences in files and then ensures that the output age the constructs of a language (e.g., in an object files match with a structured build-and-run framework. oriented language, checking that the method exhibits These assumptions allow test writers in DICE to build the proper form of polymorphism) are well served by more complete language-agnostic solutions than a test these approaches. Furthermore, these language-specific communication protocol alone. approaches work well when designers are using only Note that the testing features provided in DICE a single language or a single platform for their fi- are oriented towards test implementation, test exe- nal implementation. But when designers must move cution, and general practices of test-driven project between languages with different constructs (such as development — they are not developed as a framework between C++ and Verilog), the existing tests must be oriented towards any particular methodology for test rewritten. This creates extra design effort and creates design or test generation, such as those discussed in

9 the extensive survey by Hierons et al. [8]. DICE allows REFERENCES one to apply different methods for test suite design, [1] S. S. Bhattacharyya, S. Kedilaya, W. Plishker, N. Sane, while providing features of cross-platform operation; C. Shen, and G. Zaki, “Using the DSPCAD itegrative cross-language testing; efficient test retargetability; au- command-line environment: Users guide for DICE - tomated test suite execution and test status reporting; sion 1.0,” Maryland DSPCAD Research Group, Depart- and seamless integration as part of the overall feature ment of Electrical and Computer Engineering, Univer- set of DICE (e.g., use of cpttmp, and mvftmpl sity of Maryland at College Park, Tech. Rep. DSPCAD- to copy test directory templates from one place to TR-2009-01, 2009. another, and use of navigation utilities to jump back and forth between test directories and project source [2] C. Hsu, M. Ko, and S. S. Bhattacharyya, “Software synthesis from the dataflow interchange format,” in code). Exploring ways to integrate DICE-based project Proceedings of the International Workshop on Software and test development with systematic approaches to and Compilers for Embedded Systems, Dallas, Texas, test design and generation is a useful direction for September 2005, pp. 37–49. further study. [3] W. Plishker, N. Sane, M. Kiemb, K. Anand, and S. S. Bhattacharyya, “Functional DIF for rapid prototyping,” VIII. SUMMARY in Proceedings of the International Symposium on Rapid System Prototyping, Monterey, California, June 2008, This document has provided a motivation and pp. 17–23. overview of DICE, the DSPCAD integrative command- [4] P. Hamill, Unit Test Frameworks. O’Reilly & Asso- line environment. DICE is geared towards promot- ciates, Inc., 2004. ing productivity and efficiency in the management of software implementations. Significant emphasis has [5] H. G. T. Dohmke, “Test-driven development of a PID been placed in DICE on features that can be used controller,” IEEE Software, . 24, no. 3, pp. 44–50, directly or easily adapted across different program- 2007. ming languages. This document has also provided brief introductions to some of the general utility com- [6] P. Hamill, Unit test frameworks. O’Reilly & Associates, mands in DICE; the unit testing features in DICE; and Inc., 2004, ch. 7. the companion package, dicelang, which provides [7] S. Cozens, Advanced perl programming, 2nd ed. programming-language-specific plug-ins that extend O’Reilly & Associates, Inc., 2005. the capabilities of DICE in ways that are customized to specific languages. [8] R. M. Hierons et al., “Using formal specifications to For detailed information on DICE, including more support testing,” ACM Computing Surveys, vol. 41, comprehensive documentation, as well as informa- no. 2, February 2009. tion on downloading and setting up DICE, we refer the reader to the DICE Project Website (http://www. ece.umd.edu/DSPCAD/projects/dice/dice.htm), and the DICE User’s Guide [1].

IX.ACKNOWLEDGMENTS

This work was supported in part by the U.S. National Science Foundation under grant NSF-ECCS0823989. We are grateful also to the following people who have made valuable contributions to DICE and dicelang: Bishnupriya Bhattacharya, Nitin Chan- drachoodan, Robert Ricketts.

10