METHOD AND APPARATUS FOR VIRTUAL IN-CIRCUIT EMULATION CROSS-REFERENCE TO RELATED APPLICATIONS This application is a continuation-in-part of U.S. Patent Application Serial No. 12/495,237, entitled "METHOD AND APPARATUS FOR SYSTEM TESTING USING MULTIPLE INSTRUCTION TYPES" (Attorney Docket No. ALU/130137), U.S. Patent Application Serial No. 12/495,295, entitled "METHOD AND APPARATUS FOR SYSTEM TESTING USING MULTIPLE PROCESSORS" (Attorney Docket No. ALU/130137-2), and U.S. Patent Application Serial No. 12/495,336, entitled "METHOD AND APPARATUS FOR SYSTEM TESTING USING SCAN CHAIN DECOMPOSITION" (Attorney Docket No. ALU/130137-3), each of which was filed on June 30, 2009, and each of which claims the benefit of U.S. Provisional Patent Application Serial No. 61/157,412, filed on March 4 , 2009, entitled TEST INSTRUCTION SET ARCHITECTURE, which applications are incorporated herein by reference in their entirety. FIELD OF THE INVENTION The invention relates to the field of embedded systems and, more specifically but not exclusively, to testing of embedded systems using - Circuit Emulation (ICE). BACKGROUND In testing of embedded systems, In-Circuit Emulation (ICE) is a technique that is used to debug embedded software running on one or more processors. In ICE, embedded software is typically debugged using a debugging infrastructure (e.g., using a debugger such as the GNU Debugger (GDB)). In ICE, components of the processor can be connected to a JTAG infrastructure, so that the debugger can access the components in order to gain knowledge of the remote program execution, and modify the remote program execution as needed. For example, the debugger may gain knowledge of registers (e.g., state and user registers), watchpoints, memory banks, clock control blocks, and other elements. While this provides a powerful mechanism for debugging software in its final environment, it is inhibited by the actual features of JTAG. For example, a typical ICE for a given processor core may need to access dozens of elements, and existing embedded designs may be composed of a large number of processor cores. As a result, efficient handling of JTAG operations is important, and presents a difficult problem given the considerable number of accesses needed in order to perform even the most simple of debug operations. The existing JTAG-based ICE capabilities are deficient in a number of ways. First, existing ICE solutions require use of only one JTAG ICE interface at a time (or require special isolation logic for each processor core in order to enable multiple ICE interfaces to co-exist on the same target board). Second, existing ICE solutions rely heavily on Test Generation Tools (TGTs) for the handling of JTAG operations, which, in turn, rely heavily on user input in order to specify the topology of the scan chain surrounding the processor core. In fact, in existing ICE solutions, JTAG operations can be done only at the vector level, where there is no knowledge of the device internals. Third, existing ICE solutions typically rely on boundary scan access in order to access components of the target board, thereby requiring generation of complete testing vectors regardless of the testing being performed and, further, requiring retargeting of testing vectors when multiple devices are present within the boundary scan chain. As a result of such deficiencies, the TGT must maintain a complete, yet simplified, model of the system in order to be able to generate the required vectors and to interpret and decode the results. Disadvantageously, this requires a considerable amount of computational power, thereby limiting the scalability of the solution, especially for resourceconstrained embedded approaches. Furthermore, the embedded controller can only perform basic input/output solutions and must make reference to a powerful host computer in order to run the TGT, and the interface with the TGT is usually vendor dependent and proprietary, thereby resulting in additional costs and loss in flexibility. Thus, existing ICE solutions make it virtually impossible to support multiple instances of ICEs. The existing ICE capabilities are further deficient in that they cannot efficiently support multiple processor cores concurrently. In existing ICE solutions, in order to support ICE for multiple processor cores concurrently, a substantially more complex TGT, and associated model, is required in order to support coordination of command requests by each of the ICE instances running on the host machine. This involves a substantial and daunting task of retargeting based on the perspective of the entire scan chain that could change in its topology between each scan operation, i.e., the data sent to the target hardware is a variable length bit stream between each scan operation. This is not easily accomplished by existing TGTs that assume fixed length bit stream representations of data vectors to be applied to and recovered from the scan chain of the target hardware. While existing ICE capabilities are deficient in that they cannot efficiently support multiple processor cores concurrently, a potential solution for accessing multiple processor cores within a single target processor is the IEEE 1 9.7 standard, which proposes a standardized ICE-JTAG interface to each processor core which can be used by debuggers to access the target processor. Disadvantageously, however, the complexity involved in handling vectors through the TGT seriously limits the features that may be implemented with the IEEE 1149.7 standard, including completely excluding support for concurrency. SUMMARY Various deficiencies in the prior art are addressed through methods and apparatuses for providing virtual In-Circuit Emulation (ICE). In one embodiment, a method includes receiving a plurality of scan segment operations generated by a plurality of target ICE controllers of at least one ICE host where the plurality of target ICE controllers are associated with a plurality of components of the target hardware, scheduling the received scan segment operations, based at least in part on a scan chain of the target hardware, to form thereby a scheduled set of scan segment operations, and propagating the scheduled set of scan segment operations toward a processor configured for executing the scheduled set of scan segment operations for testing one or one or more components of the target hardware. BRIEF DESCRIPTION OF THE DRAWINGS The teachings presented herein can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which: FIG. 1 depicts a high-level block diagram of a system testing environment including a testing system and a system under test; FIG. 2 depicts a high-level block diagram of one embodiment of the testing system of FIG. 1, including a test generation tool and a software compiler cooperating to generate test instructions for a system under test; FIG. 3 depicts a high-level block diagram of one embodiment of the testing system of FIG. 1, including a test generation tool and a software compiler cooperating to generate test instructions for a system under test; FIGs. 4A - 4E depict an implementation of the TISA using a SPARC V8 ISA, illustrating the details of instruction coding for the implementation of the TISA using a SPARC V8 ISA; FIG. 5 depicts an implementation of the TISA using a SPARC V8 ISA, illustrating an exemplary TISA architecture for implementation of the TISA using a SPARC V8 ISA; FIG. 6 depicts an embodiment of a TISA-based testing environment supporting interactive testing capabilities; FIG. 7 depicts an exemplary implementation of the TISA-based testing environment of FIG. 6; FIG. 8 depicts an exemplary program architecture for performing optimization of the transmitter-receiver channel of the system under test of FIG. 5A; FIG. 9 depicts one embodiment of a method for adapting an Instruction Set Architecture (ISA) flow of a processor to form a Test Instruction Set Architecture (TISA) flow; FIG. 10 depicts one embodiment of a method for generating instructions adapted for use in testing at least a portion of a system under test; FIG. 1 A depicts one embodiment of a method for generating instructions adapted for use in testing at least a portion of a system under test; FIG. 1 B depicts one embodiment of a method for generating instructions adapted for use in testing at least a portion of a system under test; FIG. 12 depicts an exemplary embodiment of a TISA processor architecture; FIG. 13 depicts an exemplary embodiment of a test processor architecture utilizing multiple processors to provide system testing capabilities; FIG. 14 depicts an exemplary embodiment of a test co-processor architecture; FIG. 15 depicts an exemplary embodiment of a test adjunct processor architecture; FIG. 16 depicts an exemplary register set that can be used by a TISA processor; FIG. 17 depicts a high-level block diagram of a system under test, illustrating an exemplary decomposition of an exemplary scan chain of the system under test; FIG. 18 depicts a high-level block diagram of one embodiment of a method for testing a portion of a system under test via a scan chain of the system under test using Scan Segment Level abstraction of the scan chain; FIG. 19 depicts a high-level block diagram of one embodiment of system including a Virtual ICE Driver configured for use in testing a Target Hardware; FIG. 20 depicts one embodiment of a method for using a Virtual ICE Driver for testing a Target Hardware; and FIG. 2 1 depicts a high-level block diagram of a computer suitable for use in performing functions described herein. To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. DETAILED DESCRIPTION Various system testing capabilities are provided for use in performing testing of a system under test (SUT). In one embodiment, a test instruction set architecture (TISA) is provided. The TISA is provided for use in performing system testing. The TISA combines computer science capabilities with system testing capabilities to provide improved system testing capabilities, including interactive testing capabilities, remote testing capabilities, and various other capabilities described herein. The TISA is formed by adapting a software-based instruction set architecture (ISA) using system testing capabilities. The software-based ISA may utilize any suitable software programming language (e.g., C++, Java, and the like, as well as various combinations thereof) and may be implemented using any suitable processor. The system testing capabilities may utilize any suitable TAP, such as IEEE 1149,1 (also known as JTAG) TAPs or any other suitable TAPs. In general, the TISA is formed by combining the atomic operations of a software process with atomic testing operations of a test procedure. In the TISA, the algorithmic portions of the test procedure are handled by the software flow, such that the algorithmic portions of the test procedure are translated into the atomic testing operations. The TISA is formed by combining the atomic operations of the software process with the atomic testing operations of the test procedure, such that the atomic testing operations are treated in the same manner as the atomic operations of the software process that is handling the algorithmic portions of the test procedure. This enables finer-grain control of embedded test execution, remote test execution, and various other improved system testing capabilities as depicted and described herein. FIG. 1 depicts a high-level block diagram of a system testing environment including a testing system and a system under test. As depicted in FIG. 1, system testing environment 100 includes a testing system (TS) 1 0 and a system under test (SUT) 20. The TS 1 0 may be any system suitable for testing SUT 120. The TS 110 is configured for testing SUT 120. The TS 10 may perform any testing of SUT 120, e.g., testing one or more individual components of SUT 120, one or more combinations of components of SUT 120, one or more interconnections between components of SUT 120, one or more system level functions of SUT 120, and the like, as well as various combinations thereof. The TS 0 may perform any of the functions typically associated with testing a system under test, such as executing test procedures, providing input data to the system under test, receiving output data from the system under test, processing output data received from the system under test for determining system testing results, and like functions, as well as various combinations thereof. The design and use of TS 1 0 for testing a system under test is described in additional detail hereinbelow. The SUT 120 may be any system which may be tested using TS 110. The SUT 120 may include any component(s), at least a portion of which may be tested, individually and/or in combination, by TS 110. The TS 120 may include one or more scan chains, having one or more sets of associated input and output access pins, providing access to the component(s) to be tested by SUT 120. The manner in which a scan chain(s) may be utilized in SUT 120 for testing SUT 120 will be appreciated by one skilled in the art. For example, SUT 120 may include one or more boards, testing of which may be performed using one or more scan chains having associated input and output access pins which may be used for applying input testing signals to SUT 120 and collecting output testing signals from SUT 120. As depicted in FIG. 1, TS 1 0 accesses SUT 120 via a test access interface (TAI) 15. The test access interface may be implemented using any suitable test access interface, which may depend on one or more of the TS 110, the SUT 120, the type of testing to be performed, and the like, as well as various combinations thereof. For example, TAI 115 may include a Joint Test Action Group (JTAG) Test Access Port (TAP) as standardized in IEEE 1149.1 standard, which is incorporated by reference herein in its entirety. The IEEE 1149.1 standard defines a TAP that supports the following set of signals: Test Data In (TDI), Test Data Out (TDO), Test Mode Select (TMS), Test Clock (TCK), and, optionally. Test Reset Signal (TRST). The TDI and TDO pins of SUT 120 are interconnected in a boundary scan chain by which TS 110 may access SUT 20 for testing at least a portion of SUT 120. The TAI 115 may include any other suitable test access interface. It will be appreciated by one skilled in the art that TS 1 , TAI 115, and SUT 120 may be implemented in any manner suitable for providing features of the embodiments covered herein. As described herein, the TISA is able to leverage computer science capabilities in combination with system testing capabilities to provide a significant improvement in system testing. A general description of system testing capabilities and computer science capabilities follows, followed by a description of the manner in which computer science capabilities and system testing capabilities may be utilized together to provide the TISA. The TISA improves upon system testing capabilities by leveraging computer science capabilities. The system testing capabilities may include the capabilities generally supported in all stages of the "automated test" flow (which generally includes all of the steps and resources that may be needed to get from a definition of the test algorithm(s) to actual testing operations). In order to help test automation, test resources often are embedded inside the boards and devices, and can be accessed using a standardised interface, usually called the Test Access Port (TAP). This has the effect of limiting the pin count and rationalising resource access and management. A number of languages are available for describing resources inside a system under test, and, thus, which may be used as inputs to Test Generation Tools (TGTs). TGTs can apply algorithms to generate testing sequences which may be used by a Test Control Unit (TCU) to command the TAP and execute the associated testing operations. The features and performances of the testing operations depend on these three elements: the access standard, the data format, and the TCU implementation. The TISA is able to leverage computer science capabilities to provide improved system testing capabilities. This may include use of computer science capabilities that are available in all stages of the "software development flow" (which generally includes any or all of the steps and resources that may be needed to get from a software algorithm coded in a software language(s) of choice to the final debugging and execution on a target processor, such as compilation, an Instruction Set Architecture (ISA), interactive debugging, and the like, as well as various combinations thereof). The use of compilation in computer science reduces an algorithm defined in a programmer-friendly high level abstraction to a series of machineexecutable instructions. This process can vary greatly, depending on the input programming language and project complexity; however, most, if not all, of the approaches share the same basic assumption: any algorithm can be decomposed into basic instructions, regardless of its complexity. This applies to classic languages, as well as to more modern high-level and object oriented languages such as, for example, C++, Java, Python, and the like. The Instruction Set Architecture (ISA) is the core of any processor, and the reason for which compilation is so effective. In general, each processor offers a set of instructions which define the manner in which the processor can be operated. The instructions form at least part of the ISA of the processor. It will be appreciated that the ISA may be considered to include various constructs associated with the instructions, such as registers, addressing modes, opcodes, memory structures, and the like, as well as various combinations thereof. The ISA enables the processor to execute simple instructions, such as reading/writing values from/to memory, perform logical or arithmetical operations on registers, handle interruption, and the like. This basic behaviour has remained essentially unchanged over time, and modem processors achieve exceptional performances because they can efficiently exploit great numbers of resources, and, thus, are able to complete a much larger number of such basic instructions in approximately the same amount of time. Furthermore, even higher performances may be reached from the use of co-processors (e.g., floating-point co-processors, graphical co¬ processors, and the like), which can help the main processor by hard-coding complex operations. The use of debugging in computer science allows monitoring and verification of the software development and execution process. In general, software development is a long and difficult process, which is strictly monitored and verified to assure that the final product is free of defaults, or "bugs" are they are usually called. In order to help test software programs, the software development flow provides many powerful debug features. For example, common software development flow debug features include step-bystep execution; observability/controllability of all registers and memory locations, use of breakpoints and watchpoints, and the like. These debug features, as well as various other debug features, are more often enabled by algorithms and structures embedded into the final code by the software compiler, but may also be assisted by hardware resources available inside of the processor,. From this information the debugger can reconstruct the original code and correlate all the ISA-level operations to the programming abstraction layer. The use of automated test execution capabilities and computer science software capabilities together to enable improved system testing capabilities may be better understood by way of reference to FIG. 2 and FIG. 3. FIG. 2 depicts a high-level block diagram of one embodiment of the testing system of FIG. 1, including a test generation tool and a software compiler cooperating to generate test instructions for a system under test. As depicted in FIG. 2, the TS 110 includes a test generation tool (TGT) 210 and a software compiler (SC) 220. The TGT 210 includes a TGT composer 212 and TGT algorithms 21 . The TGT composer 212 accepts system description files 2 11 as input. The system description files 2 1 include any suitable description files which may be used by a TGT to produce testing instructions/vectors for testing a system under test. For example, system description files 2 11 may include circuit description files, board/fixture netlist files, other description files, and the like, as well as various combinations thereof. The system description files 2 11 may be available on TGT 210 and/or may be obtained from one or more remote components and/or systems. The system description files 2 11 may include one or more circuit description files, The circuit description files may be specified using any suitable description language(s), such as the Boundary Scan Description Language (BSDL, which was developed as part of the IEEE 1149.1 standard for board-level JTAG), the Hierarchical Scan Description Language (HSDL, which was developed as an extension of BSDL), New Scan Description Language (NSDL), and the like, as well as various combinations thereof. The system description files 2 11 may include one or more board/fixture netlist files, The board/fixture netlist files may include files related to the physical description of the device(s), describing the netlist, connections, and like information. The board/fixture netlist files may be specified in any suitable format, such as PCB, Gerber, and/or any other format suitable for board/fixture netlist files. The system description files 2 11 may include one or more other description files. The other description files may include any other suitable description files which may be used as input for producing a circuit model. For example, other description files may include any suitable application-specific and/or tool-specific description language files, such as Asset's Macro Language, Goepel's CASLAN Language, and/or any other suitable description language files. The TGT composer 212 processes the system description files 2 11 to produce a circuit model 2 13. The processing of system description files 2 11 by TGT composer 212 to produce circuit model 213 may be performed in any suitable manner. The circuit model 213 specifies a model of the system under test or portion of the system under test for which TGT 2 10 is being run. The TGT composer 212 provides circuit model 213 to TGT algorithms 214. The TGT algorithms 21 accept circuit model 213. The TGT algorithms 214 process the circuit model 213 to produce TGT atomic test operations 216. The processing of circuit model 2 3 by TGT algorithms 214 to produce the TGT atomic test operations 216 may be performed in any suitable manner. The SC 220 includes SC front-end algorithms 222 and SC back-end algorithms 224. The SC front-end algorithms 222 accept computer science source files 221 as input. The computer science source files 221 include any suitable computer science source files which may be compiled by a compiler. For example, computer science source files 221 may include computer science source files for any suitable computer programming language(s), such as C++, Java, Python, and the like, as well as various combinations thereof. For example, computer science source files 221 may include one or more of one or more C files, one or more C++ files, and/or any other suitable computer science source files. The SC front-end algorithms 222 process the computer science source files 221 to produce a program model 223. The program model 223 specifies an intermediate representation of the computer science source files 221 . The SC front-end algorithms 222 provide the program model 223 to the SC backend algorithms 224. The SC back-end algorithms 224 accept program model 223 as input. The SC back-end algorithms 224 process the program model 223 to produce one or more ISA Binary Files 225 including ISA atomic operations 226. The processing of program model 223 by the SC back-end algorithms 224 to form the ISA Binary Files 225 including the ISA atomic operations 226 may be performed in any suitable manner. The ISA atomic operations 226 are assembly-level instructions supported by the processor for which the TISA is implemented. As depicted in FIG. 2, in addition to the respective processing flows of TGT 210 and SC 220, additional interaction between TGT 210 and SC 220 may be utilized for controlling generation of the TISA atomic operations 235. In one embodiment, SC back-end algorithms 224 may initiate one or more vector computation requests 230 to TGT algorithms 214. The SC back-end algorithms 224 may initiate a vector computation request 230 when the SC back-end algorithms need to access the TAP. The TGT algorithms 214, upon receiving a vector computation request 230 from SC back-end algorithms 224, generate one or more TGT atomic test operations 216 for the TAP based on the received vector computation request 230. The one or more TGT atomic test operations 2 6 may then be applied to the TAP in a manner controlled by SC back-end algorithms 224, because the TGT atomic test operations 216 are combined with the ISA atomic operations 226 to enable algorithmic control over TGT atomic test operations 216 using ISA atomic operations 226. In this manner, the SC 220 provides algorithmic control of access to the TAP. As depicted in FIG. 2, in addition to TGT 210 and SC 220, TS 10 further includes a TISA composer 240. The TISA composer 240 accepts the TGT atomic test operations 216 and the ISA atomic operations 226. The TISA composer 240 converts the TGT atomic test operations 216 into TISA instructions and inserts the TISA instructions into the ISA Binary File(s) 225 (i.e., combining the TISA instructions with the ISA atomic operations 226 to form thereby TISA Binary files 245 including TISA atomic operations 246. The TISA composer 240 may be part of TGT 210, part of SC 220, split across TGT 210 and SC 220, implemented separate from TGT 210 and SC 220, and the like. It will be appreciated that the various inputs and outputs depicted and described with respect to FIG. 2 may be stored, displayed, executed, propagated, and/or handled in any other suitable manner, as well as various combinations thereof. FIG. 3 depicts a high-level block diagram of one embodiment of the testing system of FIG. 1, including a test generation tool and a software compiler cooperating to generate test instructions for a system under test. As depicted in FIG. 3, TS 1 0 of FIG. 3 operates in a manner similar to TS 110 of FIG. 2, in that TISA Binary files including TISA atomic operations are generated using interaction between the test generation tool and the software compiler; however, interaction between the test generation tool and the software compiler in TS 110 of FIG. 3 is different than interaction between the test generation tool and the software compiler in TS 110 of FIG. 2. As depicted in FIG. 3, the TS 10 includes a test generation tool (TGT) 3 10 and a software compiler (SC) 320. The TGT 3 0 includes a TGT composer 312 and TGT algorithms 314. The TGT composer 312 accepts system description files 3 11 as input. The system description files 3 11 include any suitable description files which may be used by a TGT to produce testing instructions/vectors for testing a system under test. For example, system description files 3 1 may include circuit description files, board/fixture netlist files, other description files, and the like, as well as various combinations thereof. The system description files 3 1 of FIG. 3 may include system description files similar to system description filed 211 depicted and described with respect to FIG. 2 (e.g., one or more circuit description files, one or more board/fixture netlist files, one or more other description filed, and the like, as well as various combinations thereof). The system description files 3 1 may be available on TGT 310 and/or obtained from one or more remote components and/or systems. The TGT composer 312 accepts one or more test operation description files 331 1 - 331 N (collectively, test operation description files 331 ) as input. The test operation description files 331 are generated by SC 320. The generation of test operation description files 331 by SC 320 is described in detail hereinbelow. The TGT composer 312 processes the system description files 3 1 and the test operation description files 331 to produce a circuit model 313. The processing of system description files 311 by TGT composer 312 to produce circuit model 313 may be performed in any suitable manner. The circuit model 3 13 specifies a model of the system under test or portion of the system under test for which TGT 310 is being run. The processing of system description files 3 11 in conjunction with test operation description files 331 enables the TGT composer 312 to produce circuit model 313 in a manner for enabling TGT 3 10 to produce appropriate TAP atomic operations. The TGT composer 312 provides circuit model 313 to TGT algorithms 3 . The TGT algorithms 314 accept circuit model 3 13. The TGT algorithms 3 process the circuit model 3 13 to produce TGT atomic test operations 3 16. The processing of circuit model 313 by TGT algorithms 314 to produce the TGT atomic test operations 316 may be performed in any suitable manner. As depicted in FIG. 3, in addition to TGT 310 and SC 320, TS 110 includes a TISA translator 340. The TISA translator 340 receives the TGT atomic test operations 3 16. The TISA translator 340 translates TGT atomic test operations 316 to form TISA atomic test operations 346. The TISA translator 340 provides TISA atomic test operations 346 to SC 320 for inclusion in the software compilation process. The use of TISA atomic test operations 346 by SC 320 is described in detail hereinbelow. The TISA translator 340 may be part of TGT 3 10, part of SC 320, split across TGT 3 10 and SC 320, implemented separate from TGT 310 and SC 320, and the like. The SC 320 includes a SC pre-compiler 330, SC front-end algorithms 322, and SC back-end algorithms 324. The SC pre-compiler 330 accepts computer science source files 321 . The computer science source files 321 include any suitable computer programming source files which may be compiled by a compiler. For example, computer science source files 321 may include computer programming source files for any suitable computer programming language(s), such as C++, Java, Python, and the like, as well as various combinations thereof. IFor example, computer science source files 321 may include one or more of one or more C files, one or more C++ files, and/or any other suitable computer science source files. The SC pre-compiler 330 processes the computer science source files 321. The SC pre-compiler 330 processes the computer science source files 321, producing therefrom pre-processed computer science source files 321P. The computer science source files 321 may be pre-processed by SC pre¬ compiler 330 to form pre-processed computer science source files 321P in any suitable manner. The SC pre-compiler 330 provides the pre-processed computer science source files 321 to front-end algorithms 322. The SC pre-compiler 330 detects test operations during processing of the computer science source files 3 , and generates the test operation description files 331. The test operation description files 331 may be specified using any suitable test description language (e.g., using one or more standard test description languages, using a test description language specific to the TGT 310, and the like, as well as various combinations thereof). The SC pre¬ compiler 330 provides the test operation description files 331 to TGT 3 10 (illustratively, to the TGT composer 312 of TGT 310, which processes the test operation description files 331 in conjunction with the system description files 3 1 to produce circuit model 313. The SC front-end algorithms 322 accept pre-processed computer science source files 321P. The SC front-end algorithms 322 also accept the TISA atomic test operations 346, which are produced by TISA translator 340 using TGT atomic test operations 316 produced by TGT 310 from the test operation description files 331 . The SC front-end algorithms 222 compile the pre-processed computer science source files 321P and TISA atomic test operations 346 to produce a program model 323. The program model 323 specifies an intermediate representation of the pre-processed computer science source files 321P, which includes TISA atomic test operations 346 such that TISA atomic test operations 346 may be integrated within the ISA atomic operations to form TISA atomic operations. The SC front-end algorithms 322 provide the program model 323 to the SC back-end algorithms 324. The SC back-end algorithms 324 accept program model 323. The SC back-end algorithms 324 process program model 223 to produce one or more TISA Binary Files 355 including TISA atomic operations 356. The processing of program model 323 by the SC back-end algorithms 324 to form the TISA Binary Files 355 including the TISA atomic operations 356 may be performed in any suitable manner. The TISA atomic operations 356 include ISA atomic operations (i.e., assembly-level instructions supported by the processor for which the TISA is implemented) and TISA atomic test operations 346. The TISA atomic operations 356 provide algorithmic control (using ISA atomic operations) over TGT atomic test operations 316 (i.e., in the form of the TISA atomic test operations 346), thereby enabling improved system testing of the system under test to which the TISA atomic operations 356 are to be applied. Thus, the TGT atomic test operations 316 (i.e., in the form of the TISA atomic test operations 346) may be applied to the TAP in a manner controlled by SC back-end algorithms 324, because the TGT atomic test operations 316 are combined with the ISA atomic operations to enable algorithmic control over TGT atomic test operations 316 using the ISA atomic operations. In this manner, the SC 220 provides algorithmic control of access to the TAP. It will be appreciated that the various inputs and outputs depicted and described with respect to FIG. 3 may be stored, displayed, executed, propagated, and/or handled in any other suitable manner, as well as various combinations thereof. With respect to FIG. 2 and FIG. 3, although primarily depicted and described with respect to specific numbers of input files, intermediate files, models, output files, and the like, it will be appreciated that the embodiments of FIG. 2 and FIG. 3, as well as various associated teachings provided herein, may be implemented using any suitable numbers of input files, intermediate files, models, output files, and the like. FIG. 2 and FIG. 3 illustrate the manner in which computer science capabilities may be leveraged to improve system testing capabilities (e.g., providing finer-grain control of system testing, enabling interactive system testing, enabling interactive debugging during system testing, and providing various other advantages depicted and described herein). The system testing schemes of FIG. 2 and FIG. 3 provide improvements over existing approaches, such as STAPL, where the goal is to add programming features to vector formats and, therefore, debugging, remote access, and interactivity features are added from scratch. By contrast, the TISA leverages the wealth of information from computer programming and embedded applications to control test access for system testing. Referring to FIGs. 2 and 3, it will be appreciated that the capabilities and features of the TISA are defined by its abstraction level, i.e., the finer the definition of the TISA atomic operations, the better performance the TISA will provide. In one embodiment, in which TISA is implemented in a JTAG architecture, three abstraction levels may be supported for scan operations. The first abstraction level is the Vector Level. The Vector Level is the coarsest grain of the three abstraction levels, where the atomic operations are inputs and outputs of scan vectors. The Vector Level is best represented in a vector format, such as Serial Vector format (SVF) or any other suitable vector format, and gives the highest-level control. The second abstraction level is the TAP Level. In the TAP Level, the atomic operations are enhanced to allow full control over the TAP state machine. This enables more refined control over scan operations, support of non-standard sequences (e.g., like the ones required, for instance, in the Addressable Shadow Protocol or other similar protocols). The third abstraction level is the Scan Segments Level. The Scan Segments Level is the finest grain of the three abstraction levels. The Vector Level and TAP Level abstraction levels use the scan vector as the atomic data format, which is sufficient for traditional continuity tests where the entire scan chain is involved, but is cumbersome for instrument-based testing where there is a need for fine-grain control over the tens or hundreds of instruments that compose the scan chain. The Scan Segments Level allows the definition of "scan segments" inside the overall scan path, which can be handled separately, thereby providing a flexible and powerful set of primitives that can be used to define scan operations directly in the problem space and resolve the scan operations at implementation time. This approach is advantageous in embedded applications, where the available computational resources may be quite limited. The use of Scan Segments Level is depicted and described in additional detail hereinbelow. As depicted in FIG. 2 and FIG. 3, regardless of the abstraction level of the scan operations, the resulting TAP atomic operations (illustratively, TGT atomic test operations 216 and TGT atomic test operations 316) computed by the TGT are converted into corresponding TISA atomic test operations and inserted into the binary executable (i.e., into the ISA atomic operations generated by the SC). Referring to FIG. 2, TGT atomic test operations 216 and ISA atomic operations 226 can be processed to form the TISA atomic operations 246 in the TISA binary executables (illustratively, TISA binary files 245). The TISA atomic operations 246 include TISA atomic test operations and ISA atomic operations. Referring to FIG. 3, TISA atomic test operations (generated by TISA translator 340 from TGT atomic test operations 316 produced by TGT 310) can be input into the SC front end 324 as pre-compiled assembly instructions, without any need to modify the SC front end 324 of SC 3 10. It will be appreciated that almost all programming languages allow for such operations. In C, for example, this operation is obtained using the "asm" command. In one embodiment, minor modifications to SC back-end algorithms 324 may be required (e.g., to handle binary conversion of the TISA assembler instructions). An example of such a process is depicted and described herein with respect to FIG. 11. Although primarily depicted and described with respect to levels of granularity of TISA atomic operations in a JTAG architecture, it will be appreciated by one skilled in the art that the same levels of granularity of TISA atomic operations may be utilized in other architectures, that different levels of granularity of TISA atomic operations may be utilized in a JTAG architecture and/or other architectures, and the like, as well as various combinations thereof. As described hereinabove, the TISA may be implemented using any suitable instruction set architecture (ISA). For example, the TISA may be implemented using the SPARC V8 ISA, an INTEL ISA, and the like. For purposes of clarity in describing implementation of the TISA, an exemplary implementation of the TISA using a SPARC V8 ISA is depicted and described herein with respect to FIGs. 4A-4E. In this exemplary implementation, the TISA is implemented as a Vector Level TISA, which allows direct coding of the instructions that compose the SVF format; however, as described hereinabove, it will be appreciated that implementation of the TISA using the SPARC V8 ISA also may be performed where the TISA is implemented as a TAP Level TISA or a Scan Segment Level TISA. The SPARC V8 ISA is implemented in many products, such as the open-source soft processor family Leon 2 and Leon 3. A review of "The SPARC Architecture Manual Version 8," published by SPARC International, Inc. 992 (hereinafter "SPARC Architecture Manual"), reveals that there are many code words not exploited by the SPARC V8 ISA. This is evident at least from a review of the "opcodes and condition codes" of Appendix F. FIG. 4A depicts the unexploited code words of the SPARC V8 ISA. The unexploited code words depicted in FIG. 4A may be used to code the "test' instructions for the TISA. More specifically, when both "op" and "op2" are set to 0, the instruction is marked as unimplemented in "The SPARC Architecture Manual Version 8," such that the instruction may be used for the TISA. FIG. 4B depicts a coding format able to represent all thirteen of the SVF instructions. As depicted in FIG. 4B, bits 30-25 include the instruction coding itself, bits 21-18 may be used to code a TAP state if one is to be used with the instruction, and bits 17-1 can be used by each instruction to specify optional information where needed. FIG. 4C depicts an exemplary bit coding of the TAP states for an IEEE 149.1 TAP. The bit coding of the TAP states is represented using a first column that identifies the IEEE 149.1 TAP State Name, a second column that identifies the SVF TAP State Name associated with the IEEE 1149.1 TAP State Name, and a third column that identifies the bit coding for bits 21-18 of FIG. 4B. it will be appreciated that the bit codings may be assigned to the TAP states in various other ways. The SVF instructions allow for multiple parameters, which need to be coded inside the final code. In order to represent the parameters, and in the interest of the usual architectural best practice of keeping instruction and data separated, register-based parameter passing is defined for this exemplary implementation of a Vector Level TISA. Thus, the Vector Level TISA presents six dedicated 32-bit registers: GENERIC1, GENERIC2, TDI, TDO, MASK and SMASK. The six dedicated 32-bit registers are depicted in FIG. 4D. The usage of the six dedicated 32-bit registers is described in detail hereinbelow, but, as a general rule, these registers are used either to store a parameter or to point to the memory location in which a parameter is stored. Thus, at compilation time, normal ISA instructions can be used to load these registers before the TISA instruction is invoked. More specifically, in this SPARC V8 ISA implementation of the TISA, coprocessor registers may be used directly as parameters for the usual load/store instructions. The SVF instructions which may be utilized in this SPARC V8 ISA implementation of the TISA include ENDDR, ENDIR, STATE, FREQUENCY, PIO, PIOMAP, HDR, HIR, TDR, TIR, SDR, SIR, and RUNTEST. These SVF instructions may be better understood by way of reference to the "Serial Vector Format Specification," by ASSET InterTech, Inc., 1997 (hereinafter referred to as the SVF Manual), which is herein incorporated by reference in its entirety. The use of these SVF instructions in this SPARC V8 ISA implementation of the TISA is described in more detail hereinbelow. ENDDR. ENDIR. STATE The ENDDR and ENDIR instructions indicate the TAP state at which the TAP interface ends its operation. The STATE instruction forces the TAP interface to a specified state. In this exemplary implementation of the TISA, the SVF codings for the ENDDR, ENDIR, and STATE instructions are "000000", "000001", and 0000 0", respectively, as depicted in FIG. 4E. The SVF coding of these SVF instructions may be performed using the "TAP STATE" file (i.e., the exemplary bit coding of the TAP states as depicted in FIG. 4C) as needed. It will be appreciated, at least from a review of the SVF Manual, that the STATE instruction can optionally take the explicit sequence of states as parameters. In this exemplary implementation of the TISA, taking the explicit sequence of states as parameters would be coded by a series of instructions, one for each state in the sequence. FREQUENCY The FREQUENCY instruction is used to specify the working frequency of the TAP interface. The FREQUENCY instruction is expressed as a 32-bit integer of Hz cycles. In this exemplary implementation of the TISA, the SVF coding for the FREQUENCY instruction is "00001 1", as depicted in FIG. 4E. The value for the FREQUENCY instruction is stored in the GENERIC1 register. PIO. PIOMAP The PIO instruction can be used to handle parallel vectors, in a format previously set by a call to PIOMAP. In this exemplary implementation of the RISA, PIOMAP is seen as a pre-processor directive that generates the appropriate commands to set up the TAP interface. Thus, the PIO instruction merely needs to express the parallel vector, which can be expressed by indicating (in the GENERIC1 register) the address in which the parallel vector is stored. The number of words "n" that compose the vector is specified in bits 13-0 of the instruction, and, thus, the vector has an upper size limit of 213 = 8K words = 32 Kbytes. If the vector size is not an exact multiple of a word, padding and re-alignment may be provided in memory, as needed. In this exemplary implementation of the TISA, the SVF coding for the PIO instruction is "000100". HDR. HI . TDR. TIR The roles of the HDR, HIR, TDR, and TIR instructions are different. Here, these SVF instructions are considered together because (1) these SVF instructions are functionally similar (i.e., they all command shift operations, even if they are of a different nature), and (2) these SVF instructions accept the same parameters: (1) length: a 32-bit number expressing the number of bits to shift; (2) TDI (optional): the input shift vector; (3) TDO(optional): the expected output shift vector; (4) MASK (optional): a mask to be used when comparing actual values with TDO. A '1' indicated a care, a '0' a don't care; and (5) SMASK (optional): a mask to mark which bits are to be considered in TDI. '1' indicates a care, '0' a don't care. In this exemplary implementation of the TISA, the SVF codings for the HDR, HIR, TDR, and TIR instructions are "0001 10", "0001 1", "001 0 10", and "00101 1", respectively, as depicted in FIG. 4E. In this exemplary implementation of the TISA, the following additional codings may be used: (1) length is stored in the GENERIC1 register; (2) O1 is '1' when TDI is present, '0' otherwise. If set, the TDI register contains the address at which the input vector is stored; (3) O2 is '1' when TDO is present, '0' otherwise. If set, the TDO register contains the address at which the expected output is stored; (4) O3 is '1' when MASK is present, '0' otherwise. If set, the MASK register contains the address at which the output mask is stored; and (5) O4 is '1' when S ASK is present, '0' otherwise. If set, the SMASK register contains the address at which the output mask is stored. SDR. SIR The SDR and SIR instructions have the same syntax as the HDR, HIR, TDR, and TIR instructions, but have a functional difference: SDR and SIR trigger the actual scan operation on the TAP. In interactive testing the actual output vector read from the system is fundamental for the algorithm, so the TISA offers the possibility of storing the actual output vector in memory. When the "TAP STATE" field (bits 21-18, as depicted in FIG. 4B) is different than zero, the GENERIC2 register indicates the storage location of the actual output vector. Thus, SDR and SIR can support a maximum of seven parameters. If TDO is specified and the actual output vector is different from the expected output vector, an overflow flag is set in the Processor State Register (PSR), as described in Section 4.2 of the SPARC Architecture Manual. RUNTEST The RUNTEST instruction forces the TAP interface to run a test at a specified state for a specified amount of time, and is used mainly to control RUNBIST operations (e.g., as defined in IEEE 1149.1). The RUNTEST instruction accepts one or more of the following parameters (all of which are optional): (1) run_state: the state the interface must maintain during test execution; (2) run_count: the number of clock cycles the test must take; (3) run_cik: which clock run_count refers to(TCK: TAP clock, SCK: system clock); (4) min_time: minimum run time in seconds, expressed as a real number; (5) max_time: maximum run time in seconds, expressed as a real number; and (6) endstate: the state the interface must reach at the end of the command. In this exemplary implementation of the TISA, the SVF coding for the RUNTEST instruction may be "0001 01" or " 1 00101". In this exemplary implementation of the TISA, the following additional codings may be used: (1) TAP_STATE: it contains run_state of which it is defined; (2) O1: '1' if TAP_STATE is defined, '0' otherwise; (3) O2: '1' if min_count is specified, '0' otherwise. If set, the GENERIC1 register contains the 32-bit unsigned representation of min_count; (4) O3: '1' if max_time is set, '0' otherwise. If set, the GENERIC2 register contains the 32-bit unsigned representation of max_count; (5) O4: '1' if endstate is set, '0' otherwise. If set, Bits 13-10 contain the end state. (6) Bits 9-0: if run_count is specified, expressed as an unsigned integer (max run_count=2 =1024). If this field is not "0", then Bit 30 indicates run_clock ('1'=TCK, '0'=SCK). Although primarily depicted and described herein with respect to use of specific SVF instructions in this SPARC V8 ISA implementation of the TISA (i.e., namely, ENDDR, ENDIR, STATE, FREQUENCY, PIO, PIOMAP, HDR, HIR, TDR, TIR, SDR, SIR, and RUNTEST), it will be appreciated that fewer or more SVF instructions may be used. Although primarily depicted and described herein with respect to an implementation of the TISA using the SPARC V8 ISA, it will be appreciated that various other ISAs may be utilized to implement a TISA in accordance with the TISA teachings depicted and described herein. In interactive testing approaches, the data handoff point is quite important. As described hereinabove, a test program is composed of two main portions: the algorithmic portion (as represented by the software compiler) and the test access portion (as represented by the test generation tool). During a test operation using a testing program, there will be moments when the test program is accessing the system under test, and moments when the test program is examining the testing results and deciding the next step(s) required. The hand-off between these two operations is important for obtaining efficient interactive testing. In existing script-based approaches, such as SVF and STAPL, a script takes care of all TAP operations at the Vector Level. At this level, the interface (or "player") is able to communicate with the TAP protocol, and send/receive vectors to/from the system under test. Furthermore, STAPL also allows some basic flow control (if-then-else) and algorithmic operations on the bit vectors. If there is need for more sophisticated processing (e.g., identifying a register inside a received vector, or computing the vector to access a specific device), the player hands control over to the algorithmic portion. In STAPL, this is done through the "export" command. Disadvantageously, however, neither SVF nor STAPL has a standardized format for this (e.g., in the case of STAPL, the handoff process is usually proprietary to a given vendor). In existing embedded approaches, like Master Test Controller (MTC) from Ericsson and the System BIST Processor, the same partitioning between the algorithmic portion and the test access portion is used. In such embedded approaches, the algorithmic portion and the test access portion are executed by different coprocessors that must be programmed separately. Furthermore, the memory spaces of the algorithmic portion and the test access portion are physically different, such that the resulting handoff mechanisms are similar to the handoff mechanisms of STAPL. The result is that the coprocessor for the test access portion is forced to store a lot of scan operations before handoff to the algorithmic portion, which, given the increasing size of scan chains, may require a huge amount of resources. In contrast with existing approaches to integrated testing (e.g., scriptbased approaches such as SVF and STAPL, and embedded approaches such as MTC and System BIST Processor), the TISA integrates the test access portion (i.e. the test operations) inside the algorithmic portion (i.e., the classical ISA), such that the test access portion and the algorithmic portion share the same physical memory space, thereby making handoff (and, thus, data passing) between the test access portion and the algorithmic portion automatic. In TISA, handoff between the test access portion and the algorithmic portion is made at the instruction level, such that the processor can freely mix scan and algorithm (i.e., freely mix test operations and algorithmic operations) as required according to the associated scheduling strategy. In this exemplary implementation of the TISA, using the SPARC V8 ISA, all operations handling vectors use absolute addressing (as described hereinabove with respect to the SVF instructions). As a result, testing vectors may be used like normal variables inside the ISA program, thereby making the interface between the test access portion and the algorithmic portion automatic. As an example, based on the exemplary implementation of the TISA using the SPARC V8 ISA as described hereinabove, the following steps exemplify an archetypical testing sequence: ( 1) An SDR instruction is used to obtain testing output data from the system under test. The resulting output data is places in a specific memory location (e.g., the "actual" parameter in the GENERIC2 register); (2) A classical LOAD instruction can transfer this output data to be loaded into a register; (3) Once the output data is loaded in the register, arithmetic operations and/or logical operations may be used to process the output data (note that since the SPARC V8 ISA is a load/store architecture, all data must be loaded into a register before being handled); (4) A classical STORE instruction is used to transfer the result of the algorithm into memory; and (5) An SDR instruction can send new testing input data to the TAP (e.g., using the "TDI" parameter in the TDI register). Note that the classical algorithmic operations (2) through (4) are standard for any ISA algorithm implementation, and are not modified in any way by the TISA. Thus, from this simple example, it is clear that TISA can be supported using any given algorithm or computer program, with a natural and efficient hand-off between the algorithmic portion and the test access portion. In this exemplary implementation of the TISA, using the SPARC V8 ISA, absolute addressing is used (for purposes of clarity in describing the TISA); however, one skilled in the art and informed by the teachings herein would be able to modify this exemplary implementation of the TISA to support all legal SPARC V8 addressing modes described in the SPARC Architecture Manual. Although primarily depicted and described herein with respect to an exemplary implementation of the TISA in which SVF is used, SVF was used in the exemplary implementation because it is a well-known format proven to provide a complete, even if basic, handling of 149.1 TAPs. It will be appreciated, by one skilled in the art and informed by the teachings herein, that the TISA may be implemented using any other suitable control formats, many of which may allow finer grain control of the TAP state machine and support more sophisticated testing operations. Although primarily depicted and described herein with respect to an exemplary implementation of the TISA in which the abstraction level is the Vector Level, it will be appreciated, by one skilled in the art and informed by the teachings herein, that the exemplary TISA implementation depicted and described herein may be modified such that the abstraction level of the TISA is the TAP Level or the Scan Segment Level. For purposes of clarity in describing the TISA, an exemplary use of the TISA to perform testing on an exemplary system under test is depicted and described herein with respect to FIGs. 5 and 6. In this exemplary use of the TISA, the TISA is implemented as a Vector Level TISA using a SPARC V8 ISA and SVF (i.e., in continuation of the exemplary implementation depicted and described with respect to FIGs. 4A - 4E). FIG. 5A and FIG. 5B depicts an exemplary use of the TISA to perform testing on a system under test. FIG. 5A depicts a system test environment 500 including a JTAG TAP 5 0 and a system under test 520. The JTAG TAP 510 provides test access to a system under test 520. The JTAG TAP 510 provides test access to the system under test 520, for sending input data to system under test 520 and receiving output data from system under test 520. The JTAG TAP 510 includes an instruction register (IR) 512, which is an 8-bit instruction register. The JTAG TAP 510 is controlled by a testing system (e.g., such as testing system 1 0 depicted and described with respect to FIG. 3, which is omitted for purposes of clarity). The system under test 520 includes a first board 521 (denoted as B1) and a second board 525 (denoted as B2). The first board 521 includes a transmitter 522 (denoted as T). The second board 525 includes a receiver 526 (denoted as R). The transmitter 522 sends data, on a connection 529, to receiver 526. In this example, the connection 529 is an 8-bit connection. As depicted in FIG. 5A, each board is accessible from JTAG TAP 510 via its own scan chain. Namely, first board 521 is accessible via a first scan chain 523 and second board 525 is accessible via a second scan chain 527. The first scan chain 523 and second scan chain 527 are selectable by the IR 512 of JTAG TAP 510 (e.g., IR=0 selects first board B1, IR=1 selects second board B2). The transmitter 522 and the receiver 526 are not alone on their boards; rather, they are part of wider scan chains (e.g., for purposes of this example, 24 bits and 6 bits, respectively). In a test program, input data is sent to transmitter 522 via the first scan chain 523, and the resulting output data is collected from the receiver 526 by exploiting the second scan chain 527. In order to perform an exhaustive test, all possible values are sent through the connection 529, such that 2 =256 vectors are sent through the connection 529. Using C, an exemplary program could be the following: I include 2 include 3 4 char sent_value, received value; 5 6 define MAX_COUIMT 256; 7 8 void main(void) 9 { 10 for (sent value=0;sent_value 2 include 3 4 char sent_value, received value; 5 6 define MAX_COUNT 256; 78 void main(void) 9 { 10 for (sent_value=0;sent_value, • This opcode is used to traverse the TAP state machine using the value of TMS for the given number of TCK clock cycles. This opcode is used to perform general state transitions between states of the TAP state machine. The represents a single bit, while the represents the remaining data bits of the opcode. RunTest , , • This opcode is used to transition from to , and to loop in for the number of TCK cycles as specified by the ScanLength Register. This opcode is used to transition to the as the conclusion of looping. ScanRegister , destination register>[,] [,] • This opcode is used to scan the data in the user data register and store the captured value into the user data register destination register>. If the is present, compare captured data with it and raise error accordingly, eventually using the , if present. The number of bits scanned is defined in the ScanLengthRegister (0 <= n < 32). The start, scan, and end states are defined in the ScanStateRegister. ScanRegisterZero [,] [,] • This opcode is used to scan the vector value of all "0" and store the captured value into the user data register destination register>. The number of bits scanned is defined in ScanLengthRegister (0 <= n < 32). The start, scan, and end states are defined in the ScanStateRegister. and are used as in the ScanRegister instruction. ScanRegisterOne [,] [,] • This opcode is used to scan the vector value of all "1" and store the captured value into the user data register destination register>. The number of bits scanned is defined in ScanLengthRegister (0 <= n < 32). The start, scan, and end states are defined in the ScanStateRegister. and are used as in the ScanRegister instruction. ScanBlock • This opcode is used to scan the data pointed to by the BlockRegister to the SUT starting at the , scanning the data in the , with the finalizing the operation state as defined by the Block's StateTraversalField. The ScanStateRegister is populated with the data from the StateTraversal Field prior to the scan operation. The ScanLengthRegister is populated with the data from the ScanLengthField prior to the scan operation. No data from TDO is preserved. If the ExpectedValueField and Maskfield are set, comparison and error generation are done accordingly. ScanBlockCapture • This opcode is used to scan the data pointed to by the BlockRegister to the SUT starting at the , scanning the data in the , with the finalizing the operation state as defined by the Block's StateTraversalField. The ScanStateRegister is populated with the data from the StateTraversal Field prior to the scan operation. The ScanLengthRegister is populated with the data from the ScanLengthField prior to the scan operation. The data captured from TDO is preserved. If the ExpectedValueField and Maskfield are set, comparison and error generation are done accordingly. ScanBlockZeroCapture • This opcode is used to scan the data vector of all "0" to the SUT starting at the , scanning the data in the with the finalizing the operation state as defined by the Block's StateTraversalField capturing the result in the register defined to by the BlockRegister. The ScanStateRegister is populated with the data from the StateTraversal Field prior to the scan operation. The ScanLengthRegister is populated with the data from the ScanLengthField prior to the scan operation. If the ExpectedValueField and Maskfield are set, comparison and error generation are done accordingly. ScanBlockZero • This opcode is used to scan the data vector of all "0" to the SUT starting at the , scanning the data in the , with the finalizing the operation state as defined by the Block's StateTraversalField without capturing the result. The ScanStateRegister is populated with the data from the StateTraversal Field prior to the scan operation. The ScanLengthRegister is populated with the data from the ScanLengthField prior to the scan operation. If the ExpectedValueField and Maskfield are set, comparison and error generation are done accordingly. ScanBlockOneCapture • This opcode is used to scan the data vector of all "1" to the SUT starting at the , scanning the data in the , with the finalizing the operation state as defined by the Block's StateTraversalField capturing the result in the register defined to by the BlockRegister. The ScanStateRegister is populated with the data from the StateTraversal Field prior to the scan operation. The ScanLengthRegister is populated with the data from the ScanLengthField prior to the scan operation. If the ExpectedValueField and Maskfield are set, comparison and error generation are done accordingly. ScanBlockOne • This opcode is used to scan the data vector of all 1 to the SUT starting at the , scanning the data in the , with the finalizing the operation state as defined by the Block's StateTraversalField without capturing the result. The ScanStateRegister is populated with the data from the StateTraversal Field prior to the scan operation. The ScanLengthRegister is populated with the data from the ScanLengthField prior to the scan operation. If the ExpectedValueField and Maskfield are set, comparison and error generation are done accordingly. The exemplary TISA instruction set includes the following register modification instructions that use explicit values: LoadRegisterExplicit , • This instruction loads the constant value of into the register named by . CopyRegister , ^destination register> • This instruction copies the contents of the register named as into the register named by destination register^. The exemplary TISA instruction set includes the following register modification instruction that use implicit values: LoadRegisterImplicit , • This instruction uses the value in the named as a pointer reference to a memory location where the real data resides and stores the referenced value into the register named by The exemplary TISA instruction set includes the following register preservation instructions: StoreRegisterImplicit , • This instruction uses the value in the named as a pointer reference to a memory location where the value in the register named by is to be stored. StoreRegisterExplicit , • This instruction stores the value of register named by into the memory location specified by . The exemplary TISA instruction set includes the following logical operations on registers: AND , destination register> • This operation performs a logical AND operation between the and the and places the resulting value in the destination register>. OR , destination register> • This operation performs a logical OR operation between the and the and places the resulting value in the destination register>. XOR , • This operation performs a logical XOR operation between the and the destination register> and places the resulting value in the destination register>. NOT , destination register> • This operation performs a logical NOT operation on the and places the resulting value in the destination register>. XORM , , • This operation performs a logical XOR operation between the user data register and the user data register , comparing only those bits aligning with the user data register bit containing a value of "1", and places the resulting value in the destination register>. Note that uncompared bits will result in a "0" value in the destination register>. The exemplary TISA instruction set includes the following miscellaneous operation on registers: NOP • A no operation opcode to be used as a filler to provide alignment in some ISA instruction sets. The exemplary TISA instruction set includes the following instructions for extending support for streaming for an embodiment using the adjunct processor architecture: MemoryWrite • This instruction writes to the local test memory using the following arguments: , , , , data byte(s)>. MemoryRead • This instruction reads from the local test memory using the following arguments: , dumber of bytes to transfer>, . This instruction returns a stream of data bytes tagged with the sequence number and the number of bytes being transferred. The exemplary TISA instruction set includes the following values for scan state: StartState, ScanState, EndState • The scan state codes include: TestLogicReset (TLR), RunTest/Idle (RTI), PauseDR (PDR), PauseIR (PIR), ScanDR (SDR), ScanIR (SIR). There is a 4-bit representation per state code, and 12 bits are used to describe the entire state transition sequence for a scan operation. It will be appreciated, by one skilled in the art and informed by the teachings herein, that various other TISA implementations may be used with the TISA processor architectures depicted and described herein. For example, other TISA implementations may use fewer, more, and/or different registers, may use fewer, more, and/or different instruction sets, and the like, as well as various combinations thereof. In one embodiment, other TISA implementations may be utilized where different processor architectures are used, in order to provide TISA implementations better-suited to specific applications, and/or for any other suitable reasons. As described hereinabove, use of TISA in a JTAG architecture enables scan operations to be performed at the Scan Segments Level, which allows the definition of independently controllable "scan segments" inside the overall scan path, thereby providing a flexible and powerful set of primitives that can be used to define scan operations directly in the problem space and resolve the scan operations at implementation time. In general, JTAG operations are based on the scan operation in which all bits are scanned in serially one-by-one while at the same time bits are being scanned out serially one-by-one. This means that, in order to be able to perform a scan operation, knowledge of which value is needed for each bit in the scan chain (i.e., the input and output vectors) is required. TGTs typically provide this capability for traditional structural testing by computing the required vectors from a system model obtained through description languages such as BSDL. Additionally, formats like SVF and STAPL mirror this, as they allow the user to manipulate those vectors. While testing in this manner is sufficient for structural (and other types) of testing, testing in this manner is highly inefficient for interactive setups in which there is no real need to access the whole scan chain. The inefficiency may be seen by considering an example. For example, consider a scan chain composed of 100 instruments, each one having 16 bits. If the user needed to write 0x1 234 in the registers of the 76th instrument in the scan chain, the TGT would need to generate the vector for the whole scan chain (100*16=1600 bits) and send it to the TAP interface to be input into the scan chain. Similarly, if the user wanted to read the associated output, the TGT would need to receive the entire 1600 bit vector before being able to extract the desired output information. In this example, the fact that a majority of the scan bits are useless is not important, as scan efficiency is not one of the goals (rather, in this example, the goal is primarily to be able to efficiently access one particular entity of the scan chain). This type of approach is a problem at least for the following reasons: (a) there is the computational need of handling long vectors (e.g., lots of memory transfers have a high impact on performances); (b) there is a need to store the entire vector(s) in memory (which may be a problem for long chains); (c) memory storage is not limited to data inputs and data outputs, but also includes expected data, input and output mask, and the like (thereby multiplying memory requirements which are already potentially strained just from the input and output data); and (d) the transformation from instrumentvector- instrument must be made each time (which demands computational power and time). The Scan Segments Level abstraction level is a powerful tool for providing efficient access to individual entities, or groups of entities, of the scan chain of a system under test, without any special emphasis on scan efficiency (even if, of course, still enabling it if needed). In one embodiment, Scan Segments Level abstraction is implemented by decomposing a scan chain into a succession of segments and defining one or more scan operations on each of the segments. The scan chain is composed of a plurality of elements, and each segment includes at least one of the elements of the scan chain. The elements may be defined at many levels of the system under test (e.g., elements may be devices, instruments, registers, segments of a register, and the like, as well as various combinations thereof), and, thus, that the segments into which the scan chain is decomposed may be defined at many levels of the system under test (e.g., segments may include one or more devices, a portion of a device(s), one or more instruments, a portion of an instrument(s), one or more registers, a portion of a registers), one or more register segments, and the like, as well as various combinations thereof). In this manner, a segment may represent the smallest control unit of the scan chain. In one embodiment, decomposition of a scan chain into segments may be hierarchical. For example, the scan chain may be decomposed into segments, at least some of which may be composed by sub-segments, at least some of which may be composed by sub-segments, and so forth. In this manner, the hierarchical decomposition of the scan chain may be viewed as having a tree-based structure in which a segment may be composed of other segments. In one such embodiment, the segments at the leaves of the tree may be referred to as segments (in that they represent the smallest control unit of the scan chain), which the segments located above the leaves of the tree may be referred to as super-segments. It will be appreciated that, in one embodiment, one or more of the segments of the scan chain may be composed of virtual sub-segments which are controllable, but only in a manner that is transparent to the user/system). The hierarchical decomposition of a scan chain may be defined in any other suitable manner. The use of segmentation enables definition of entities for types of segments and/or types of segment combinations. An entity is a generic description of a type of target, which is valid for and may be reused for each physical instance of that type of target. For example, an entity may define a description of a device, a group of devices, a portion of a device, an instrument, a group of instruments, a portion of an instrument, and the like, as well as various combinations thereof. Thus, since a scan chain may be decomposed such that segments of the scan chain include specific elements or combinations of elements, entities may be defined for respective segments and/or respective combinations of segments, of a scan chain. For example, where a scan chain is decomposed such that a segment includes an instrument, an entity may be defined for that type of segment (i.e., each segment including that type of instrument), such that the entity may be reused for each physical instance of that type of segment in the scan chain. Similarly, for example, where a scan chain is decomposed such that a segment includes multiple instruments, an entity may be defined for that type of segment (i.e., each segment including that type combination of instruments), such that the entity may be reused for each physical instance of that type of segment in the scan chain. This enables additional features and functions to be supported, as described below. The use of segmentation allows an entity (i.e., a description of a type of segment under control) to be correlated with a physical protocol that is used to communicate with the entity. As a result, description languages (e.g., such as NSDL, P1687 IJTAG PDL, and the like) could be written specifically for the entity, and the connectivity description portion (e.g., the structure of the NSDL or the IJTAG HDL) would describe the ordering of the segmentation instructions. TISA provides a reusable modularity that can be defined once for all occurrences of a particular entity type, as the TISA instructions are segmentbased operations rather than model-based operations. Thus, since TISA is both modular and autonomous for the entity under test in a particular segment, TISA provides significant advantages over existing architectures. TISA enables a direct mapping of the Test Data Register definition into a reusable and portable module that may be plugged into the execution flow at any point in the scan process, in any order that is necessary, without needing to define the entire connectivity as a static model up front as existing tools require. TISA enables integration of the port/signal interfaces that are non-scan with the scan operations as a single solution space architecture based on a unified control flow and standard computer science techniques (providing significant advantages over solutions in which native language constructs are used to provide access to non-scan operations). TISA enables reuse of instruction sequences for multiple instances of the same entity, thereby enabling a reduction in code storage requirements in the system. For example, a generalized function, which maps to description language functions which are called by a managing program, may be written. In this example, each of the functions are methods of native language objects that represent the entity, and there may be separate instances of these objects for each entity defined in the system, but there could be a single copy of code used to communicate with each of these instances. In this manner, the native language implementation models directly control the description language used to specify the connectivity and functionality of the circuit. In reference to the example given above, use of Scan Segments Level abstraction would enable definition of three segments as follows: segment S 1 including instruments 1 through 75, segment S2 including the instrument 76, and segment S3 including instruments 77 through 100. In this manner, access to instrument 76 is greatly simplified. For example, access to instrument 76 could be obtained by making a "dummy shift" (e.g., ScanBlockZero) for segment S3, executing the instruction(s) for segment S2 (i.e., instrument 76), making another dummy shift for segment S1, and then terminating with an update. In such a sequence, access to segment S2 (i.e., to a specific instrument in the scan chain) is provided without a need of any knowledge of segment S1 or segment S3 apart from their length. It will be appreciated that this is merely one example, and, thus, that other decompositions of the 100 instrument-long chains are possible to enable access to other instruments or instrument groups. FIG. 1 depicts a high-level block diagram of a system under test, illustrating an exemplary decomposition of an exemplary scan chain of the system under test. The exemplary SUT 1700 includes four devices 17101 - 17104 (collectively, devices 1710; and denoted in FIG. 17 as Device 1, Device 2, Device 3, and Device 4, respectively). The devices 1710 are arranged serially within SUT 700 to form a scan chain 1720. The scan chain 1720 is as follows: the TDI of the TAP is connected to the input port of device 17 0 , the output port of device 17104 is connected to the input port of device 17103, the output port of device 17103 is connected to the input port of device 171 02, the output port of device 171 02 is connected to the input port of device 17101, and the output port of device 17101 is connected to the TDO of the TAP. In the exemplary SUT 1700, each of the devices 1710 includes (1) an input de-multiplexer providing inputs to a test instruction register (TIR) and a test data register (TDR), and (2) an output multiplexer for collecting outputs from the TIR and the TDR. The TIR and TDR of each device 1710 are parallel registers. The device 17103 includes one additional TDR, such that the input de-multiplexer provides inputs to one TIR and two TDRs and collects outputs from the one TIR and the two TDRs, where the one TIR and two TDRs are all in parallel. The TIRs and TDRs each are depicted as serial shift registers, each including nine associated elements (e.g., flip-flops ) . In this manner, (a) the TIRs form one scan chain (denoted as an test instruction scan chain) that includes thirty-six serial elements and (b) the TDRs form another scan chain (denoted as a test data scan chain) that includes forty-five total elements and thirty-six serial elements (i.e., because the two TDRs of device 17103 are in parallel). In the exemplary SUT 1700, the test instruction scan chain has been decomposed into four segments follows: a first segment SI4 which includes the nine elements of the T R of device 1710 , a second segment SI3 which includes the nine elements of the TIR of device 17103, a third segment SI2 which includes the nine elements of the TIR of device I7102, and a fourth segment SI1 which includes the nine elements of the TIR of device 17101. In this manner, the testing system may access any of the TIRs of SUT 1700, individually or in combination, with minimal knowledge of the other TIRs of SUT 1700 (other than the number of elements of which they are composed). In the exemplary SUT 1700, the test data scan chain has been decomposed into six serial segments (seven total segments) as follows: a first segment SD4 that includes the nine elements of the TDR of device 7 0 ; a second segment SD3 that includes the nine elements of the TDR of device 171O3; a third segment SD2 that includes either the nine elements of the first TDR of device 17102 (denoted as sub-segment SD2.1) or the nine elements of the second TDR of device 171 02 (denoted as sub-segment SD2.2), where these are counted as separate segments for purposes of counting the total number of segments); and a fourth segment which is further decomposed into three serial sub-segments as follows: a first sub-segment that includes the first three elements of the TDR of device 17101 (denoted as sub-segment SD1 .1) , a second sub-segment that includes the next four elements of the TDR of device 7 01 (denoted as sub-segment SD1.2), and a third subsegment that includes the last two elements of the TDR of device 171 0, (denoted as sub-segment SD1 .3). In this manner, the testing system may access any of the TDRs of SUT 1700 (or even sub-portions of the TDR of device 17101) , individually or in combination, with minimal knowledge of the other TDRs of SUT 1700 (other than the number of elements of which they are composed). It will be appreciated that SUT 1700 of FIG. 17 is merely one example of the manner in which the scan chain(s) of a system under test may be decomposed for use in providing Scan Segments Level abstraction. Although depicted and described herein with respect to specific types, numbers, and arrangements of elements, components, and the like, it will be appreciated that a system under test for which a scan chain(s) is decomposed may be include various other types, numbers, and/or arrangements of elements, components, and the like. As described herein, decomposition of the scan chain of a system under test enables scan operations to be defined on the segments, thereby improving testing efficiency. A method, according to one embodiment, for generating a set of instructions including scan operations for segments of a decomposed scan chain is depicted and described herein with respect to FIG. 18. A more detailed example of scan decomposition and generation of scan segment operations is provided follows. As a general example, consider a scan chain that includes three boards where each board includes a segment (denoted as segments A, B, and C associated with a first board, a second board, and a third board, respectively). In this example, where the scan segments are hierarchical, the segment A on the first board may be composed of a plurality of sub-segments (e.g., sub-segments A1 through An), the segment B on the second board may be composed of a plurality of sub-segments (e.g., sub-segments Bi through Bn), and/or the segment C on the third board may be composed of a plurality of sub-segments (e.g., sub-segments C1 through Cn) . As a more specific example, following the application and the SUT, a segment could be: one or more registers inside an instrument, an instrument, a cluster of registers, one or more boards, and the like, as well as various combinations thereof. The overall scan operation is therefore decomposed in a series of segment scan operations. As a result, all that is required in order to obtain the final scan chain operation is a series of simple atomic operations. Thus, the embodiments of Scan Segments Level abstraction, while not exclusively limited to, are especially effective in implementations in which the atomic test operations are treated like processor operations (e.g., such as in the various TISA implementations depicted and described herein, or in any other similar implementations in which atomic test operations are treated like processor operations). In such embodiments of Scan Segments Level abstraction, the actual implementation of the Scan Segments Level scan operations may require that one or more technological constraints linked to JTAG be addressed. For example, constraints such as the need to define the state of the TAP machine and the risk of using the Pause-DR state (not always implemented), among others, may need to be addressed. In order to identify instrument/segment outputs in the output bitstream received via the scan chain, based on the position of the instrument/segment in the scan chain, the scan chain may be treated as a first-in-first-out (FIFO) system (given its serial nature) such that the first segment that is scanned in is also the first segment that is scanned out (as it is closest to the end of the scan chain). In order to make the SUT "experience" the sequence of scan segment operations like a single scan operation, the TCK may be frozen between segment operations. As all elements inside the scan chain are synchronous, the effect of freezing TCK in this manner is that the scan chain is frozen together with TCK. The use of Scan Segments Level in a TISA-based testing system may be better understood by way of a few examples, In the examples that follow, assume that a system under test (SUT) is composed of three segments (denoted as A, B, and C, in that order), and that a user needs to write a value V inside of segment B. As a first example, assume that the three segments of the system (A, B, and C) are implemented inside the same JTAG device. In this first example, once the three segments are defined in memory, the TISA operations would become: i. Set Startstate = Run-Test-Idle, Scanstate=Endstate=ShiftDR; ii. Set ScanLenghtField to the length of Segment A; iii. Scan a bypass sequence into segment A; iv. Set Startstate = Scanstate=Endstate=ShiftDR; v. Set ScanLenghtField to the length of Segment B; vi. Scan V into segment B; vii. Set Startstate = Scanstate= ShiftDR, Endstate=Run-Test-Idle; viii. Set ScanLenghtField to the length of Segment C; ix. Scan a bypass sequence into segment C. With respect to the first example, keeping the TAP Finite State Machine (FSM) in the ShiftDR state ensures that there is no update on the scan chain. This may be seen from the first example, in which keeping the TAP FSM in the ShiftDR state from step (i) to step (ix) ensures that there is no update on the scan chain, given that the UpdateDR State will be reached only once leaving ShiftDr. Further with respect to the first example, the scan clock TCK is active only during the scan operations (i.e., steps (iii), (vi), and (ix)), and is frozen in the remaining states. The effect is that the SUT, from the point of view of the SUT based on operations synchronous with TCK, will see steps (iii), (vi), and (ix) as a continuous bitstream. Further with respect to the first example, the "bypass sequence" is a property of the scan segment, and can be, for instance, a given sequence (all zeros, all ones, or any other suitable sequence), or "don't care", where it is up to the TGT to decide such sequence. As a second example, assume that the three segments of the system (A, B, and C) are implemented on different JTAG devices (in one or more cards). In this second example, once the three segments are defined in memory, the TISA operations would become:: i. Set Segment A states: StartState=RunTest/Idle, ScanState=ShiftIR, EndState=ShiftIR (gateTCK indicator); ii. Set Segment A ScanLengthField to length of Segment A IR; iii. Run ScanBlock with BYPASS instruction pattern for Segment A; iv. Set Segment B states: StartState=ShiftIR, ScanState=ShiftIR, EndState=ShiftIR (gateTCK indicator); v. Set Segment B ScanLengthField to length of Segment B IR; vi. Run ScanBlock with EXTEST instruction pattern for Segment B; vii. Set Segment C states: StartState=ShiftIR, ScanState=ShiftIR, EndState=RunTest/Idle; viii. Set Segment C ScanLengthField to length of Segment C IR; ix. Run ScanBlock with BYPASS instruction pattern for Segment C; x. Set Segment A states: StartState=RunTest/Idle, ScanState=ShiftDR, EndState=ShiftDR (gateTCK); xi. Set Segment A ScanLengthField to length of Segment A selected DR (1 bit BYPASS DR); xii. Run ScanBlock with BYPASS data pattern for Segment A; xiii. Set Segment B states: StartState=ShiftDR, ScanState=ShiftDR, EndState=ShiftDR (gateTCK); xiv. Set Segment B ScanLengthField to length of Segment B selected OR (n bit BSR DR to pins); xv. Run ScanBlock with EXTEST data pattern for Segment B; xvi. Set Segment C states: StartState=ShiftDR, ScanState=ShiftDR, EndState=RunTest/Idle; xvii. Set Segment C ScanLengthField to length of Segment C selected DR (1 bit BYPASS DR); xviii. Run ScanBlock with BYPASS data pattern for Segment C. In comparing the first example and the second example, it will be understood that the additional complexity associated with the second example comes from the need to use the Instruction Register (IR) of each JTAG device to select/deselect the segments. In that case, unused segments are directly taken out of the chain by putting the related JTAG device in the BYPASS mode of the 1149. 1 standard (as indicated in steps (iii) and (xvii) of the second example). It will be appreciated that all compositions of the above two examples are possible, with any number of segments defined on one or more JTAG devices. It will be further appreciated that the above-two examples are merely examples provided for the purpose of illustrating use of the Scan Segments Level for testing a system under test, and, thus, that embodiments in which the Scan Segments Level is used for testing a system under test are not intended to be limited by these examples. In such embodiments, the actual sequence of TISA instructions can have multiple origins, including one or more of the following: (1) the TISA instructions may be statically computed by the TGT, in which case, each time the user wants to access a segment, the entire chain must be scanned (it will be appreciated that, while this solution is not optimized for scan time, it can be useful for embedded systems with limited computational resources and little or no time constraints); (2) the TISA instructions may be issued by a software scheduler, which receives access requests and composes them into scan operations; and or (3) the TISA instructions may be issued by a hardware scheduler (e.g., such as, but not limited to, what is done for instruction reordering and bypass in some high-performance processors). It will be appreciated that TISA instructions associated with Scan Segments Level control may be issued in any other suitable way, which may include a combination of the methods described above and/or one or more other suitable methods which may be used in place of or in addition to one or more of the methods described above. The Scan Segments Level abstraction level is a powerful tool for handling dynamic topologies, such as the ones proposed by the IEEE P 1687 standard and other dynamic topologies. If a section of the scan chain can be taken in and out the active scan path (e.g., using an SIB cell proposed by the IEEE P1687 standard or any other suitable hierarchy-enabling component(s)), that section can be marked as one (or more) segments. The testing scheduler then has knowledge, from the system state, as to whether or not this segment(s) is active, and, therefore, if the segment should be included in the TISA instruction scheduling. It will be appreciated by those skilled in the art and informed by the teachings herein that this principle also may be used for other dynamic elements, such as hot-swap boards (e.g., by detecting their presence from a status register) or any other suitable dynamic elements. FIG. 18 depicts a high-level block diagram of one embodiment of a method for testing a portion of a system under test via a scan chain of the system under test using Scan Segments Level abstraction of the scan chain. Although primarily depicted and described herein as being performed serially, at least a portion of the steps of method 1800 may be performed contemporaneously, or in a different order than depicted and described with respect to FIG. 18. At step 802, method 1800 begins. At step 18704, the scan chain is decomposed into a plurality of segments. The scan chain is composed of a plurality of elements, and each segment includes at least one of the elements of the scan chain. The scan chain may be decomposed into segments in any suitable manner, as described hereinabove. As described herein, decomposition of the scan chain into segments may be applied anywhere in the development flow (e.g., by the test developer, by the test generation tool, by an embedded circuit model, and the like). At step 1806, a set of instructions is generated. The set of instructions includes processor instructions associated with an ISA and test instructions for testing the portion of the system under test. The test instructions include, for each of the segments of the scan chain, at least one scan operation to be performed on the segment. The test instructions may be any type of test instructions, such as conventional test instructions, test instructions of a TISA, and the like, and, thus, may be generated in any suitable manner. The set of instructions may be generated in any suitable manner (e.g., in a manner the same as or similar to as depicted and described hereinabove respect to At step 1808, the set of instructions is executed for testing the portion of the system under test. The set of instructions may be executed in any suitable manner, which may depend on the type of instructions of the set of instructions. At step 1810, method 1800 ends. Although primarily depicted and described herein with respect to embodiments in which embodiments of TISA are used to enable scan operations to be performed at the Scan Segments Level, it will be appreciated that one or more of the Scan Segments Level embodiments depicted and described herein also may be provided in environments using TISA-like instructions architectures, non-TISA instruction architectures and/or non-TISA testing environment implementations, and the like. Although references are made herein to "the TISA" for purposes of describing the enhanced system testing capabilities enabled by exe lary embodiments of TISAs which may be formed and utilized as depicted and described herein, it will be appreciated that many different TISAs may be formed depending on various factors, such as one or more of the ISA of the processor for which the TISA is formed, characteristics of the SUT for which the TISA is formed, characteristics of the test algorithm the TISA is supposed to execute, and the like, as well as various combinations thereof. Thus, references made herein to "the TISA" also may be read more generally as a TISA" in that many different types of TISAs may be formed. A virtual IrvCircuit Emulation (ICE) capability is provided herein for supporting testing of Joint Test Action Group (JTAG) hardware. In one embodiment, virtual In-Circuit Emulation (ICE) capability includes a Virtual ICE Driver, various embodiments of which are depicted and described herein. The Virtual ICE Driver is configured to enable any standard debug software to interface with JTAG-enabled hardware in a flexible and scalable manner. The Virtual ICE Driver is configured such that the test instruction set used with the Virtual ICE Driver is not required to compute vectors, as the JTAG operations are expressed as local native instructions on scan segments, thereby enabling ICE-resources to be accessed directly. The Virtual ICE Driver is configured such that ICE may be combined with instrument-based JTAG approaches (e.g., such as the IEEE P1687 standard and other suitable approaches). The Virtual ICE Driver provides various other capabilities and advantages as will be understood from the description of the Virtual ICE Driver provided herein. Although primarily depicted and described herein within the context of embodiments in which the Virtual ICE Driver is utilized with the Test Instruction Set Architecture (TISA), it will be appreciated that the Virtual ICE Driver may be utilized with any suitable test instruction set. In TISA, the concurrent control of registers can be performed using high-level software calls, leveraging high level programming languages and operating systems. As a result, with TISA, ICE interfacing may be reduced to a set of coordinated, queued command calls to a TISA-based Circuit Control Model which manages the issuance of TISA scan segment operations according to the scan topology of the Target Hardware. Thus, with TISA, each of the ICE interfaces may be written as a standalone, yet hierarchical, set of operations on the device registers which map to TISA opcodes. In other words, each of the ICE interfaces can be seen as an autonomous instrument register and, due to the JTAG abstraction level supported by the TISA, the TISA can control each of these registers autonomously by representing them as independent scan segments. This is much simpler than the circuit models used by TGTs to handle vectors, because the TISA Processor only needs to schedule the scan segment operations (rather than retargeting testing vectors as is required in existing solutions). These and various other embodiments of the Virtual ICE Driver, and associated Virtual ICE Driver capabilities, may be better understood by way of reference to FIGs. 19 and 20. FIG. 19 depicts a high-level block diagram of one embodiment of system including a Virtual ICE Driver configured for use in testing a Target Hardware. What is claimed is: 1. A method for use in testing one or more components of target hardware using In-Circuit Emulation (ICE), the method comprising: receiving a plurality of scan segment operations generated by a plurality of target ICE controllers of at least one ICE host, the plurality of target ICE controllers associated with a plurality of components of the target hardware; scheduling the received scan segment operations, based at least in part on a scan chain of the target hardware, to form thereby a scheduled set of scan segment operations; and propagating the scheduled set of scan segment operations toward a processor configured for executing the scheduled set of scan segment operations for testing one or one or more components of the target hardware. 2. The method of claim 1, wherein, for at least one of the received scan segment operations, the received scan segment operation is generated by a target ICE controller of the at least one ICE host and intended for a processor core on the target hardware. 3. The method of claim 1, wherein, for at least one of the received scan segment operations, the received scan segment operation is generated by an application of the at least one ICE host and intended for at least one processor core of an application specific integrated circuit (ASIC) on the target hardware. 4. The method of claim , wherein the method is performed by a queued state machine, wherein the queued state machine comprises: an event loop, a command handler, and a circuit control model; wherein the event loop is configured for receiving the scan segment operations generated by the target ICE controllers and providing the scan segment operations to the command handler; wherein the command handler is configured for receiving the scan segment operations from the event loop and providing the scan segment operations to the circuit model; and wherein the circuit control model is configured for producing the scheduled set of scan segment operations. 5. The method of claim 1, wherein the scheduled set of scan segment operations is produced using a circuit control model. 6. The method of claim 5, wherein the circuit control model comprises: circuit model information of a plurality of circuit models associated with the target ICE controllers; and scan topology information for modelling the scan topology of the target hardware, wherein the circuit control model produces the scheduled set of scan segment operations using the scan topology information. 7. The method of claim 5, wherein, for each of the received scan segment operations, the circuit control model: processes the scan segment operation for recognizing an intended destination of the scan segment operation, the intended destination being one of the components of the target hardware; delegates the scan segment operation to a portion of the circuit control model that is associated with the intended destination of the scan segment operation. 8. The method of claim , wherein the plurality of target ICE controllers are associated with a single ICE host, wherein the processor is a first processor, wherein the single ICE host comprises a second processor, wherein the second processor operates as a central processing unit (CPU) and the first processor operates as a co-processor for handing the scheduled set of scan segment operations for the second processor. 9. An apparatus for use in testing one or more components of target hardware, the apparatus comprising: a queued state machine configured to: receive scan segment operations generated by a plurality of target ICE managers of at least one ICE host, the plurality of target ICE managers associated with a plurality of components of the target hardware; schedule the received scan segment operations based at least in part on a scan chain of the target hardware; and propagate the scheduled set of scan segment operations toward a processor configured for executing the scheduled set of scan segment operations for testing one or more devices of the target hardware. 10. A computer readable storage medium storing instructions which, when executed by a processor, causes the processor to perform a method for use in testing one or more components of target hardware using In-Circuit Emulation (ICE), the method comprising: receiving a plurality of scan segment operations generated by a plurality of target ICE controllers of at least one ICE host, the plurality of target ICE controllers associated with a plurality of components of the target hardware; scheduling the received scan segment operations, based at least in part on a scan chain of the target hardware, to form thereby a scheduled set of scan segment operations; and propagating the scheduled set of scan segment operations toward a processor configured for executing the scheduled set of scan segment operations for testing one or one or more components of the target hardware.