Simulation development tool for an embedded system

[0002] 1. Field of the Invention

[0003] The present invention relates to the field of software emulation. More particularly, the present invention relates to a system and method for simulating characteristics of an embedded system in order to facilitate software development.

[0004] 2. Description of Art Related to the Invention

[0005] Over the last few years, there has been an increasing demand for entertainment systems working in conjunction with various types of content providers such as broadcasters and cable companies. One type of entertainment system is a digital satellite system (DSS) featuring an antenna and an integrated receiver decoder (IRD) to receive a digital bit stream. IRD is responsible for decoding the bit stream and processing the decoded bit stream to produce an output signal of an appropriate format. The output signal is sent to one or more peripherals such as a television for displaying an image. The IRD includes hardware and software responsive to control codes produced by depressing buttons on its front panel or on its remote control. The control codes are interpreted by the IRD as operational commands such as display a selected screen, tune to a selected channel and the like.

[0006] Currently, before testing software, software developers wait until the hardware manufacturer either has completed a working prototype or has completed a prototype having a text-based emulator. While a text-based emulator would allow low-level code to be tested with hardware, it does not enable system-wide testing and/or the testing of higher-level applications such as code relating to or supporting communications with a graphics user interface (GUI). Consequently, software testing is delayed which may adversely affect the release time of entertainment systems.

[0007] Also, text-based emulators do not provide an efficient testing tool because they require code compilation and repetitive loading of the compiled code during testing. Loading and repeated reloading of compiled code is required because the presence of an error condition causes the text-based emulator to crash which, in turn, requires the code to be reloaded. As a result, test time is used in an inefficient manner.

[0008] In light of this increasing demand for entertainment systems, it would be desirable to develop and test software for the IRD through system wide emulation while its hardware is concurrently being developed.

[0009] A technique for system-wide emulation of an embedded system. One technique involves the addition of emulation software and an intermediary operating system. The intermediary operating system is used to avoid modification of system software. The emulation software is used to generate objects that simulate hardware features of the embedded system and to signal when control features of these objects have been selected.

[0010] The features and advantages of the present invention will become apparent from the following detailed description in combination with the figures listed below.

[0011] FIG. 1 is an illustrative embodiment of a software test system.

[0012] FIG. 2 is an illustrative embodiment of a platform architecture of the embedded system of FIG. 1.

[0013] FIG. 3 is an illustrative embodiment of an interactive display produced by the platform architecture of FIG. 2.

[0014] FIG. 4 is an illustrative flowchart of the operations of emulation software and system software associated with the embedded system of FIG. 1.

[0015] In its preferred embodiment, the present invention relates a system and method for software emulation of the functionality of an embedded system in order to test high-level code during hardware development of the embedded system. This high-level code may include, but is not limited or restricted to code associated with a graphics user interface (GUI).

[0016] Herein, various terms are used to describe certain elements or characteristics of the present invention. For example, an “embedded system” is broadly defined as hardware having information processing capabilities. Embodiments of an embedded system include an integrated receiver decoder (IRD), a cable box, an Internet terminal (e.g., WEB TV™) and the like. A “communication line” is generally defined as any medium providing a communication path between a source and a destination. The “medium” may include one or more electrical wire(s), fiber optics, cable(s) or even wireless communications such as infrared (IR) and radio frequency (RF) signaling. A “signal” is defined as information transmitted either in a parallel or in a serial manner. A “control code” is a signal which may be transmitted as a predetermined number and sequence of digital bits, analog signals, a predetermined number and sequence of non-visible, light pulses or another type of format.

[0017] Referring to FIG. 1, an illustrative embodiment of a software test system used to test high-level code during hardware development of an embedded system is shown. The software test system 100 includes a conventional computer 110, which is connected to a monitor 120 through a communication line 130. This allows computer 110 to transfer information to monitor 120 in accordance with either an analog format or a digital format. Computer 110 may include a server, a desktop computer, or a portable computer (e.g., a laptop or hand-held). Monitor 120 may include, but is not limited or restricted to a cathode ray tube (CRT), a flat panel display (e.g., an active matrix display, liquid crystal display, etc.) or even a television adapted for use with computer 110. A control device 140 is connected to computer 110 to select and to deselect control features (e.g., simulated buttons) of one or more objects displayed on monitor 120. The control device 140 may include, but is not limited or restricted to a mouse, a track ball, a joystick, a keyboard, a keypad, a touch pad and the like.

[0018] Referring now to FIG. 2, an illustrative embodiment of a software layer scheme of software test system 100 is shown. In this embodiment, platform 200 comprises a primary operating system 210, an optional intermediary operating system 220, emulation software 230 and embedded system software 240 which will be used in hardware concurrently being developed. The intermediary operating system 220 is a real-time, object-oriented operating system that supports multi-tasking. Examples of intermediary operating system 220 includes Cooperative Real-time Operating System (CROP) previously developed by Sony Corporation of Tokyo, Japan. This intermediary operating system 220 has been modified to work in cooperation with a primary operating system (e.g., a Windows™ operating system such as WINDOWS 95® by Microsoft Corporation of Redmond, Wash.) and to operate as an interface between system software 240 and emulation software 230. As a result, the function call procedures associated with system software 240 would not need modification when the hardware is completed.

[0019] The software layer scheme also includes emulation software 230 which is a single task that produces one or more interactive displays. In one instance, emulation software 230 produces an interactive display featuring one or more objects such as a simulated remote control and/or a simulated front panel as shown in FIG. 3. The emulation software 230 further generates other interactive displays (e.g., menu, electronic program guide, etc.) in response to selection of a particular area in a prior object as described below.

[0020] Referring now to FIG. 3, an illustrative embodiment of an interactive display 300 produced through the execution of emulation software (described below) by computer 110 is shown. The interactive display 300 provides a user interface in order to perform a system-wide test of software developed for implementation within an embedded system such as an integrated receiver decoder (IRD) or any other type of set-top box having software to decode wireless transmissions.

[0021] In this embodiment, interactive display 300 includes a plurality of windows 310, 330, 350 and 370. A first window 310 is used to display an object replicating the structural layout of a remote control of an embedded system. This replication is referred to as a “simulated remote control” 315. Upon selecting one of the areas 320 (displayed as buttons) associated with simulated remote control 315 by control device 140 of FIG. 1 for example, the emulation software produces a control code identical to the control code that would be produced by a hardware remote control after development. This control code is routed to various software tasks of system software 240 of FIG. 2 which convert the control code into a corresponding function call.

[0022] In particular, area 320₁represents a number of directional buttons to control movement of a virtual cursor and/or to change channels. Selection of any of the directional buttons prompts emulation software to access information stored at a particular location in internal memory of software test system 100, instead of retrieving information from an incoming bit stream via a communication port of the hardware being developed. Likewise, selection of areas 320₂and 320₃causes emulation software to produce (i) a display object of a menu screen which lists various options such as setting the color palette or font used in the object, and (ii) a program guide display object which lists a number of television shows currently broadcast or scheduled to be broadcast in the future, respectively. The information associated with each of these display objects is static (instead of dynamic) for test purposes and is retrieved from memory within software test system 100 during testing operations.

[0023] More specifically, upon selecting one of these areas (e.g., area 320₃featuring the program guide display object), emulation software produces a control code which would be produced by a hardware remote control after development. Examples of these control codes include, but are not limited or restricted to (i) code for displaying a selected screen such as a guide screen or main menu; (ii) code for navigating through the selected screen by selecting arrow keys; (iii) code for tune to a particular channel and the like. The simulated remote control 315 enables testing of software involved in the reception of control codes as well as the code involved in the operations produced by the control codes.

[0024] The second window 330 of interactive display 300 is further used to display an object which generally representing the structural layout of a front panel of the embedded system (referred to as a “simulated front panel”) 335. As shown, simulated front panel 335 includes a plurality of areas 336-339 responsive to selection by a cursor control device attached to a computer. For example, a first area 336 represents a power button which, when selected, signals the system software 240 of FIG. 2 of a power-on or power-off condition. A second area 337 represents a select button which, when selected, signals system software that a particular object pointed to by a visual cursor is selected. A third area 338 represents a menu button which transmits a control code to the system software to produce a menu display when the menu button is selected. A fourth area 339 represents a number of directional buttons to control movement of the virtual cursor.

[0025] In addition, the third window 350 of the interactive display 300 is reserved to provide a simulated screen of a television monitor in order to test software used to produce and to generate the output signal destined for a television. The interactive display 300 further includes a fourth window 370 which provides a user-interactive debug mechanism enables a user to place test statements (e.g., print statements, breakpoints, etc.) in the code of the system software. This allows the user to monitor values of certain variables and debug the code in case an error condition occurs during execution of the system software being tested.

[0026] Referring now to FIG. 4, an illustrative flowchart of the operations of the software test system are described. After selection of a control feature of an object (e.g., selecting a simulated program guide button of simulated remote controller 315 of FIG. 3), the primary operating system (e.g., Windows 95™) notifies the emulation software that the control feature has been selected (Step 400). Consequently, the emulation software generates a control code corresponding to the selected control feature and places the control code into a transmission queue to effectively operate as an interrupt (Step 410). Thereafter, the emulation software waits for a response from the system software asynchronously to the operations performed on the control code.

[0027] The intermediary operating system services the interrupt when the control code is loaded in the transmission queue (Step 420). More specifically, upon detecting information in the transmission queue, the intermediary operating system transfers information associated with the control code to system software; namely, a device driver task (DDT) of system software (Step 430). Based on the control code received, DDT generates a message to an user interface task (UIT) requesting various information (Step 440). For example, if the area corresponding to the program guide button is selected, information related to the program guide is fetched. The UIT realizes that the program guide information has been requested, and thus, requests program guide information from a program guide task (PGT) of the system software (Step 450). PGT is capable of retrieving information from a file on the hard disk drive of the computer (Step 460).

[0028] Upon receiving the information from PGT, the UIT draws an object on the screen by making a function call to emulation software. This is normally handled by the developed hardware or its device driver; instead, in this testing technique, it is now handled by emulation software which translates the function call into a function call recognized by the primary operating system (referred to as “Window function calls”). These Window function calls are used to create a window, to draw bitmaps, to fill rectangles and the like (Step 470). Some of these Window function calls are set forth in Table A and are well known in the art.

[0029] The present invention described herein may be designed in many different embodiments and using many different configurations. As discussed herein, the technique for system-wide emulation is flexible. While the present invention has been described in terms of various embodiments, other embodiments may come to mind to those skilled in the art without departing from the spirit and scope of the present invention. The invention should, therefore, be measured in terms of the claims which follow.