Emulator Board Testing via External Test Files
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current hardware emulator testing methods are laborious and time-consuming, requiring recompilation and redistribution of diagnostic applications for each modification, making it difficult to efficiently test and configure emulator boards.
Innovation Solution
A system and method that allows for the maintenance of test files with lists of commands that can be easily modified without recompilation, where these commands are executed on emulator boards through a server-based architecture, enabling flexible and efficient testing of emulator boards without requiring special software development knowledge.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If diagnostic applications are maintained on emulator boards for testing, then testing functionality is enabled, but any modification requires recompilation and redistribution of the entire application
Solution Approach 1:
The diagnostic application is segmented into a stable executable core and separate modifiable test command lists. The test commands are extracted from the compiled application and stored as external text files, allowing individual test modifications without recompiling the entire application. This segmentation enables independent editing of test sequences while maintaining the stability of the diagnostic engine.
Solution Approach 2:
Text files serve as an intermediary layer between the diagnostic application and test commands. Instead of modifying compiled code directly, users edit text files containing test command sequences. The application reads and executes commands from these text files, providing a buffer that allows easy modification without triggering recompilation. This intermediary text file layer decouples the stable application binary from the flexible test specifications.
2Reliability
If multiple diagnostic applications are maintained on emulator boards, then comprehensive testing coverage is achieved, but tracking and managing each application becomes time-consuming and laborious
Solution Approach 1:
A single diagnostic application is designed to be universal and execute multiple different test sequences by reading commands from text files. Instead of maintaining separate compiled applications for each test, one versatile application can load and execute various test commands from different text files. This multi-functionality allows comprehensive testing coverage while simplifying management, as users only need to manage text files rather than multiple applications.
3Ease of operation
If test commands are embedded in compiled applications, then execution control is precise, but modifications require software development knowledge and recompilation
Solution Approach 1:
Test commands are copied from the compiled application into external text files during an initial compilation or extraction process. These text file copies contain the complete test command sequences and can be edited using simple text editors without requiring compilation knowledge. The application reads these copied commands at runtime, allowing non-programmers to modify tests by editing text rather than compiled code, thus reducing the complexity barrier while maintaining execution precision.
Data Source
AI summary
A system and method is disclosed for testing emulation boards in a hardware emulation environment. In one embodiment, test files can be maintained that identify a list of test commands. Such a list can be easily changed without recompiling. In another embodiment, the list of commands can be read by a first server. The commands can be passed (e.g., sequentially) to a second server associated with one or more emulator boards. The second server can ensure that the commands are executed on the specified emulator boards for testing the emulator boards. In yet another embodiment, a user can request a series of tests to be executed. The tests can be included in a list of test names. Each test name can correspond to a list of test commands associated with the test name. Thus, a first server can read a test name, read a file of test commands associated with the test name and pass the test commands to a second server to ensure the test commands are executed.