Patent Publication Number: US-7721036-B2

Title: System and method for providing flexible signal routing and timing

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
   This application claims priority to U.S. Provisional Application Ser. No. 60/576,611 and U.S. Provisional Application Ser. No. 60/576,691, each being filed on Jun. 1, 2004. Priority to these prior applications is expressly claimed, and the disclosures of respective applications are hereby incorporated by reference in their entireties. 

   FIELD 
   The present invention relates generally to hardware emulation systems for verifying electronic circuit designs and more particularly, but not exclusively, to interface systems for coupling such hardware emulation systems with other system components in emulation. 
   BACKGROUND 
   Emulation systems are used to verify electronic circuit designs prior to fabrication as chips or manufacture as electronic systems. Typical emulation systems utilize either interconnected programmable logic chips or interconnected processor chips. Examples of hardware logic emulation systems using programmable logic devices can be seen in, for example, U.S. Pat. Nos. 5,109,353, 5,036,473, 5,475,830 and 5,960,191. U.S. Pat. Nos. 5,109,353, 5,036,473, 5,475,830 and 5,960,191 are incorporated herein by reference. Examples of hardware logic emulation systems using processor chips can be seen in, for example, U.S. Pat. Nos. 5,551,013, 6,035,117 and 6,051,030. U.S. Pat. Nos. 5,551,013, 6,035,117 and 6,051,030 are incorporated herein by reference. 
   The design under verification (or test) (“DUV”) is usually provided in the form of a netlist description of the design. The netlist may have been derived from many sources, including from a hardware description language. A netlist description (or “netlist” as it to by those of ordinary skill in the art) is a description of the circuit&#39;s components and electrical interconnections between the components. The components include all those circuit elements necessary for implementing a logic circuit, such as combinational logic (e.g., gates) and sequential logic (e.g., flip-flops and latches). In prior art emulation systems, the netlist is compiled such that it is placed in a form that can be used by the emulation system. In an FPGA-based emulator, the DUV is compiled into a form that allows the logic gates (both sequential and combinational) to be implemented in the FPGAs. In a processor-based emulation system, the DUV is compiled into a series of statements that will be executed by the processors on the processor chips. No logic is implemented into these processors. 
   Conventional hardware emulation systems include target interface systems for coupling with one or more user testbenches and/or target systems. A “target system” is, generally speaking, the actual operating environment that the DUV, once manufactured, will be installed. Thus, the target system for a microprocessor DUV can be a personal computer. A “testbench,” in this context, is an application that may apply a set of stimuli (such as a test vector) to a model to produce a set of information used in analyzing the timing or performance of a system block. The target interface systems of these hardware emulation systems suffer from several limitations. For example, the input/output (I/O) technologies employed by such target interface systems are not suitable for supporting differential signaling technologies. Connection to a differential target system requires the use of additional technology conversion hardware, which generally must be custom made. The design under test thereby is required to expose a single logical signal as a primary I/O (as opposed to possibly two nets), requiring manual intervention into the netlist of the design. 
   Other disadvantages of the target interface systems of conventional hardware emulation systems include the use of fixed input/output (I/O) technologies. The target interface systems likewise provide limited I/O timing control as well as a limited number of directional signals for bidirectional signals. Further, conventional target interface systems cannot verify the validity of the I/O voltage of the target system and are unable to detect whether the target system is powered on, powered off, or unconnected. 
   In view of the foregoing, a need exists for an improved hardware emulation system that overcomes the aforementioned obstacles and deficiencies of currently-available hardware emulation systems. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  is an exemplary top-level block diagram illustrating an embodiment of a communication system in which the communication system includes a host system and a target system. 
       FIG. 2  is an exemplary block diagram illustrating an embodiment of the communication system of  FIG. 1  in which the communication system comprises a hardware emulation system for developing one or more components of the target system. 
       FIG. 3A  is an exemplary top-level block diagram illustrating an embodiment of a target interface system for the communication systems of  FIGS. 1 and 2  in which the target interface system includes target interface logic. 
       FIG. 3B  is an exemplary block diagram illustrating an alternative embodiment of the target interface system of  FIG. 3A  in which the target interface logic comprises a plurality of field-programmable gate arrays. 
       FIG. 4  is an exemplary timing diagram illustrating the operation of the target interface logic of  FIGS. 3A-B . 
       FIG. 5  is a block diagram illustrating an exemplary datapath for a selected target I/O connection (or pin) of the target interface logic of  FIGS. 3A-B . 
       FIG. 6  is a block diagram illustrating the exemplary datapath of  FIG. 5  in which the datapath is provided in a static configuration. 
       FIGS. 7A-E  are a series of block diagrams illustrating the exemplary datapath of  FIG. 5  in which the operation of the datapath is shown over a series of target interface cycles. 
       FIG. 8  is a block diagram illustrating an exemplary configuration memory space of the target interface logic of  FIGS. 3A-B . 
   

   It should be noted that the figures are not drawn to scale and that elements of similar structures or functions are generally represented by like reference numerals for illustrative purposes throughout the figures. It also should be noted that the figures are only intended to facilitate the description of the preferred embodiments of the present invention. The figures do not describe every aspect of the present invention and do not limit the scope of the invention. 
   DETAILED DESCRIPTION OF THE DRAWINGS 
   Since conventional hardware emulation systems suffer from several limitations, such as fixed input/output (I/O) technologies and limited I/O timing control, a communication system that includes a target interface system for providing flexible signal routing and timing can prove much more desirable and provide a basis for a wide range of system applications, such as hardware emulation systems. This result can be achieved, according to one embodiment disclosed herein, by employing a communication system  100  as shown in  FIG. 1 . 
   The communication system  100  can be provided in any suitable manner, including the manner disclosed in co-pending United States Patent Application, entitled “SYSTEM AND METHOD FOR CONFIGURING COMMUNICATION SYSTEMS,” Ser. No. 10/992,165, filed on Nov. 17, 2004, which is assigned to the assignee of the present application and the disclosure of which is hereby incorporated herein by reference in its entirety. As shown in  FIG. 1  herein, the exemplary communication system  100  can comprise a host system  200  and at least one target system  300 . Typically being coupled via one or more communication cable assemblies  400  (shown in  FIG. 2 ), the host system  200  and each target system  300  are configured to communicate such that communication signals  500  can be exchanged among the host system  200  and the target systems  300 . 
   Turning to  FIG. 2 , the communication system  100  is illustrated as comprising a hardware emulation system  200 ′, such as an accelerator, a simulator, and/or an emulator, for developing the target system  300  and/or one or more components of the target system  300 . Prior to manufacture of an integrated circuit, designers generally verify the functionality of their designs (referred to herein as the “design under verification”). The communication system  100  therefore preferably is provided as a hardware emulation system  200 ′ to allow the designers to verify that a design under verification will function in the system in which the integrated circuit will eventually reside (i.e., the target system  300 ). Exemplary hardware emulation systems include the Palladium acceleration/emulation system and the NC-Sim simulation system each produced by Cadence Design Systems, Inc., of San Jose, Calif. 
   Further details and features relating to the structure and operation of the communication system  100  and/or the hardware emulation system  200 ′ are disclosed in the following co-pending United States Patent Applications filed on the same date herewith: “SYSTEM AND METHOD FOR RELIABLY SUPPORTING MULTIPLE SIGNALING TECHNOLOGIES,” application Ser. No. 11/140,722; “EXTENSIBLE MEMORY ARCHITECTURE AND COMMUNICATION PROTOCOL FOR SUPPORTING MULTIPLE DEVICES IN LOW-BANDWIDTH, ASYNCHRONOUS APPLICATIONS,” application Ser. No. 11/141,599; and “SYSTEM AND METHOD FOR RESOLVING ARTIFACTS IN DIFFERENTIAL SIGNALS,” application Ser. No. 11/141,141, which are assigned to the assignee of the present application and the respective disclosures of which are hereby incorporated herein by reference in their entireties. 
   The hardware emulation system  200 ′ shown in  FIG. 2  includes a logic board  210  and a buffer card assembly  220 . The logic board  210  is a printed circuit board carrying either logic devices and interconnect devices or processor chips. Illustrated as being coupled with the logic board  210  via one or more internal high-speed communication cables  230 , the buffer card assembly  220  provides an input/output (I/O) system for the hardware emulation system  200 ′. The buffer card assembly  220  includes at least one interface buffer card  222  for providing buffering to electrically protect the emulation modules of the logic board  210  from external effects and a buffer power backplane  224 . Preferably providing power to each interface buffer card  222 , the buffer power backplane  224  likewise provides information regarding the location of each interface buffer card  222  for the purposes of configuration detection and verification. 
   The target system  300  likewise can include other peripheral systems and subsystems of the hardware emulation system  200 ′, as desired. Because such emulated representations allow a circuit designer flexibly to operate or develop the target system  300  coupled to the emulated representation, even before the prototype circuit design or hardware is actually manufactured, overall design time and cost is reduced significantly. As desired, other peripheral systems (not shown), such as one or more additional hardware or software development platforms, computers, and/or test equipment, also may be coupled with the host system  200  and/or the target system  300 . By providing an emulation environment for the target system  300 , the host system  200  can for perform functional verification for all of, or at least one component of, the target system  300  in any appropriate manner. The host system  200 , for instance, can provide co-simulation and/or simulation acceleration and/or can be configured for in-circuit use. The host system  200  likewise can provide a platform for performing hardware and software co-verification for the target system  300 . 
   For example, the target system  300  can include a logic circuit and can be assembled, along with one or more electronic components, such as integrated components and/or discrete components, on a hardware development platform (not shown) in the manner known in the art. Exemplary logic circuits can include reconfigurable logic circuits, such as one or more field-programmable gate arrays (FPGAs), and/or non-reconfigurable logic circuits, such as one or more application-specific integrated circuits (ASICs). Once assembled, the reconfigurable logic circuit can be customized to implement a user design by loading configuration data into the reconfigurable logic circuit. By programming the internal memory cells, a customized configuration is established within the reconfigurable logic circuit. Thereby, the user design can be implemented by the reconfigurable logic circuit and evaluated by operating the reconfigurable logic circuit on the hardware development platform and in conjunction with the hardware emulation system and any other peripheral systems. 
   Each interface buffer card  222  includes at least one communication port  226  for coupling the hardware emulation system  200 ′ with one or more target systems  300 , communication cable assemblies  400 , and/or other external systems or devices. Each communication port  226  includes a connector assembly  226 A having a plurality of contacts, pins, or terminals  226 B, such as user-definable terminals and/or reserved terminals. Each communication port  226  can have any appropriate number of terminals  226 B, which number can be related to the number of communication signals  500  (shown in  FIG. 1 ) to be supported by the communication port  226 . The communication signals  500  thereby can be exchanged among the hardware emulation system  200 ′ with one or more target systems  300 , communication cable assemblies  400 , and/or other external systems or devices, as desired. 
   The buffer card assembly  220  of the hardware emulation system  200 ′ is illustrated in  FIG. 2  as being configured to couple with the target systems  300  via communication cable assemblies  400 . Therefore, the buffer card assembly  220  and the communication cable assemblies  400  can form a target interface system  450  for coupling the hardware emulation system  200 ′ and the target systems  300 . Although any suitable type of communication cable assemblies  400  can be used to couple the hardware emulation system  200 ′ with the target systems  300 , the communication cable assemblies  400  preferably comprise at least one high-density data cable  400 ′ and/or at least one direct attach stimulus cable (not shown). 
   As shown in  FIG. 2 , each of the high-density data cables  400 ′ can include an emulator connector assembly  410  and a target connector assembly  420  that are coupled via a communication cable  430 . Although shown and described as being provided adjacent to the opposite end regions of the communication cable  430  for purposes of illustration, the emulator connector assembly  410  and the target connector assembly  420  can be associated with any suitable portion, such as an intermediate region, of the communication cable  430  and can be provided in any suitable manner. Being configured to couple with, and/or mate with, communication ports (not shown) of the target systems  300 , the target connector assembly  420  is illustrated as comprising a connector assembly  422  and an interface system (or pod)  424 . The interface system (or pod)  424  can include analog and/or digital devices and is configured to perform one or more functions associated with the target interface system  450 . Preferably, the bulk of the functions associated with the target interface system  450  are performed by the interface system (or pod)  424 . 
   As desired, a legacy target adapter  440  can disposed between the target connector assembly  420  and the target systems  300  as illustrated in  FIG. 2 . The legacy target adapter  440  can be configured to provide back-compatibility to the legacy form factor for conventional target systems  300 , such as conventional target systems  300  supported by Cadence Design Systems, Inc., of San Jose, Calif. In the manner discussed above with regard to the target connector assembly  420 , the emulator connector assembly  410  can include a connector assembly (not shown) for coupling with, and/or mating with, the communication ports  226  of the hardware emulation system  200 ′. Thereby, the hardware emulation system  200 ′ and the target systems  300  can be coupled, and configured to communicate, such that the communication signals  500  are exchanged via the communication cable assemblies  400 . 
   Turning to  FIG. 3A , the target interface system  450  can include target interface logic  600  for facilitating exchanges of communication signals  500  between the hardware emulation system  200 ′ (shown in  FIG. 2 ) and the target system  300  (shown in  FIG. 2 ). Being coupled with, and configured to communicate with, the hardware emulation system  200 ′ and the target system  300 , the target interface logic  600  can exchange communication signals  500  with the hardware emulation system  200 ′ and the target system  300 . For example, the target interface logic  600  includes one or more control signal connections (or pins)  610  for exchanging control signals  510  with the hardware emulation system  200 ′. 
   The target interface logic  600  is illustrated as including at least one emulator data output connections (or pins)  620  for receiving emulator output data (XBO[ 0 :N- 1 ]) signals  520  from the hardware emulation system  200 ′ and at least one emulator data input connections (or pins)  630  for providing emulator input data (XBI[ 0 :M- 1 ]) signals  530  to the hardware emulation system  200 ′. One or more target I/O connections (or pins)  640  are shown in  FIG. 3A  whereby the target interface logic  600  and the target system  300  can exchange target data (TARGET IO[ 0 :P- 1 ]) signals  540 . Comprising configurable (or reconfigurable) as input connections, output connections, and/or bidirectional connections, the target I/O connections  640  can be configured, as desired, to provide the target data signals  540  to the target system  300  and/or to receive the target data signals  540  from the target system  300 . Thereby, the target interface logic  600  can facilitate the exchange of communication signals  500  between the emulation system  200 ′ and the target system  300 . 
   The target interface logic  600  can be provided in any conventional manner and, as shown in  FIG. 3B , preferably comprises one or more field-programmable gate arrays (FPGAs)  650 . A plurality of field-programmable gate arrays  650  can be applied to implement the target interface logic  600  because the required quantity of programmable logic is relatively small and can reduce overall system costs. The field-programmable gate arrays  650  can be programmed via the hardware emulation system  200 ′ (shown in  FIG. 2 ) and are designed such that each field-programmable gate array  650  is programmed with the same file and at the same time. Thereby, the field-programmable gate arrays  650  effectively operate as a single logical (or composite) field-programmable gate array, and the distribution of the target interface logic  600  among the field-programmable gate arrays  650  is transparent to software. 
   As shown in  FIG. 3B , the control signals  510  can include interface control signals  510 A, a synchronization (TIF_SYNC) signal  510 B for synchronizing the hardware emulation system  200 ′ and the target system  300  (shown in  FIG. 2 ), and a system clock (TIF_CLK) signal  510 C. The synchronization (TIF_SYNC) signal  510 B initiates a sequence of target interface (or TIF) cycles, each of which comprise a complete clock cycle of the system clock signal  510 C. The interface control signals  510 A provide configuration data for the target interface logic  600 ; whereas, the synchronization signal  510 B and the system clock signal  510 C provide synchronization information for the target interface logic  600 . Since the effective operating speed for the target system  300  typically is many times slower than the maximum clock rate of the emulation system  200 ′ itself, a number of internal system clock signal  510 C are required to emulate one clock cycle of the target system  300 . In the conventional manner, the rising edges of the synchronization signal  510 B initiate the emulation cycles, which comprise a plurality of cycles of the system clock signal  510 C (or TIF cycles) and which are each approximately equal to one clock cycle of the target system  300 . 
   The target interface logic  600  can receive N emulator output data (XBO[ 0 :N- 1 ]) signals  520  from the hardware emulation system  200 ′ and can provide M emulator input data (XBI[ 0 :M- 1 ]) signals  530  to the hardware emulation system  200 ′. Similarly, the target interface logic  600  and the target system  300  can exchange P target data (TARGET I/O[ 0 :P- 1 ]) signals  540 . The emulator output data signals  520 , the emulator input data signals  530 , and the target data signals  540  can comprise any suitable number N, M, P of signals, respectively. As desired, the number N, M, P of signals can be uniform and/or different among the emulator output data signals  520 , the emulator input data signals  530 , and the target data signals  540 . 
   As shown in  FIG. 3B , for example, the target interface logic  600  is configured to receive forty-eight (48) emulator output data signals  520  from the hardware emulation system  200 ′ and to provide forty-eight (48) emulator input data signals  530  to the hardware emulation system  200 ′. Although the emulator output data signals  520  and the emulator input data signals  530  are shown and described as being exchanged via separate connections for purposes of illustration, the target interface logic  600  and the hardware emulation system  200 ′ can exchange the emulator output data signals  520  and the emulator input data signals  530  in any suitable manner, including via one or more bidirectional connections. The target interface logic  600  likewise is illustrated as exchanging one hundred, ninety-two (192) target data signals  540  with the target system  300 . In the manner discussed above, the target interface logic  600  and the target system  300  can exchange the target data signals  540  in any conventional manner, including any suitable number of separate connections and/or bidirectional connections. 
   When the target interface logic  600  comprises four field-programmable gate arrays  650 A-D as illustrated in  FIG. 3B , the interface control signals  510 A, the synchronization signal  5101 B, and the system clock signal  510 C are provided to each of the field-programmable gate arrays  650 A-D. The forty-eight emulator output data signals  520  and the forty-eight emulator input data signals  530 , in contrast, are distributed among the four field-programmable gate arrays  650 A-D. For example, the forty-eight emulator output data signals  520  and the forty-eight emulator input data signals  530  can be respectively divided into four (4) groups  520 A-D of twelve (12) emulator output data signals  520  and four (4) groups  530 A-D of twelve (12) emulator input data signals  530 . 
   As shown in  FIG. 3B , the hardware emulation system  200 ′ and the field-programmable gate array  650 A can exchange the twelve emulator output data signals  520  in the first group  520 A and the twelve emulator input data signals  530  in the first group  520 A; whereas, the second group  520 B of emulator output data signals  520  and the second group  530 B of emulator input data signals  530  can be exchanged between the hardware emulation system  200 ′ and the field-programmable gate array  650 B. The hardware emulation system  200 ′ and the field-programmable gate arrays  650 C,  650 D likewise can respectively exchange the emulator output data signals  520  in the third and fourth groups  520 C,  520 D and the emulator input data signals  530  in the third and fourth groups  530 C,  530 D as set forth above. 
   In a similar manner, the one hundred, ninety-two target data signals  540  likewise can be divided into groups  540 A-N of target data signals  540  when the target interface logic  600  has more than one field-programmable gate array  650 . The target data signals  540  thereby can be distributed among the field-programmable gate arrays  650 . If the target interface logic  600  comprises the four field-programmable gate arrays  650 A-D, for example, the one hundred, ninety-two target data signals  540  can be divided into four (4) groups  540 A-D of target data signals  540 . Each of the groups  540 A-D can include forty-eight (48) of the target data signals  540  as illustrated in  FIG. 3B . 
   In the manner set forth above, the field-programmable gate array  650 A and the target system  300  can exchange the first group  540 A of forty-eight target data signals  540 , and the second group  540 B of forty-eight target data signals  540  can be exchanged between the field-programmable gate array  650 B and the target system  300 . The field-programmable gate arrays  650 C,  650 D and the target system  300  likewise can exchange the target data signals  540  in the third and fourth groups  540 C,  540 D, respectively, as discussed above. Although shown and described as being approximately uniformly distributed among the four field-programmable gate arrays  650 A-D for purposes of illustration, the emulator output data signals  520 , the emulator input data signals  530 , and the target data signals  540  can be divided in any suitable manner among any appropriate number of field-programmable gate arrays  650 . 
   When operating as a single logical (or composite) field-programmable gate array, the field-programmable gate arrays  650 A-D preferably are coupled via a serial link (not shown). The serial link forms a ring structure and is clocked by an external clock signal, such as the system clock (TIF_CLK) signal  510 C. A frame of data thereby can be sequentially transmitted to each field-programmable gate array  650 A-D. The data frame can comprise a fixed-length packet of data, such as a 26-bit word, and circulates among the field-programmable gate arrays  650 A-D in the same direction. Upon receiving the data frame, each field-programmable gate array  650 A-D can forward the data frame to the next field-programmable gate array  650 A-D after a selected number of clock cycles during which the field-programmable gate array  650 A-D can process and otherwise manipulate the data. 
   The operation of the target interface logic  600  of  FIGS. 3A-B  is illustrated with reference to the exemplary timing diagram  700  shown in  FIG. 4 . Synchronization of the target interface logic  600  is achieved via the synchronization (TIF_SYNC) signal  510 B and the system clock (TIF_CLK) signal  510 C. The hardware emulation system  200 &#39; (shown in  FIG. 2 ) provides the synchronization (TIF_SYNC) signal  510 B and the system clock (TIF_CLK) signal  510 C to dedicated input connections of the target interface logic  600 . A manner in which the hardware emulation system  200 &#39; provides the synchronization (TIF_SYNC) signal  510 B and the system clock (TIF_CLK) signal  510 C is set forth in the co-pending application, entitled “SYSTEM AND METHOD FOR RELIABLY SUPPORTING MULTIPLE SIGNALING TECHNOLOGIES,” application Ser. No. 11/140,722, which is assigned to the assignee of the present application and the disclosure of which is hereby incorporated herein by reference in its entirety. 
   As illustrated in  FIG. 4 , the target interface logic  600  samples the emulator output data signals  520  and drives the emulator input data signals  530  coincident with the edges of the system clock (TIF_CLK) signal  510 C. The system clock (TIF_CLK) signal  510 C is shown as being associated with a sequence of emulation steps  550 . When performing the emulation, the emulation system  200 ′ sequentially executes each of the emulation steps  550  in the conventional manner. During each emulation step  550 , the emulation system  200 ′ can provide the emulator output data signals  520  to, and/or receive the emulator input data signals  530  from, the target interface logic  600  and, therefore, the target system  300  (shown in  FIG. 2 ). The duration of the emulation steps  550  is related to the frequency of the system clock (TIF_CLK) signal  510 C and typically range between approximately five nanoseconds (5 nsec.) and twenty nanoseconds (20 nsec.). Although each TIF cycle is shown and described as being associated with four steps  550  for purposes of illustration, the TIF cycles can be associated with any suitable number of emulation steps, as desired. 
   The emulation system  200 ′ is illustrated as beginning the emulation at time t 0 . The target interface logic  600  is scheduled in terms of TIF cycles, and the synchronization (TIF_SYNC) signal  510 B indicates the initiation of a new TIF cycle, such as first TIF cycle TIF 0 . The emulator output data signals  520  are provided via the communication port  226  of the hardware emulation system  200 ′ and are sampled on the positive edge of the system clock (TIF_CLK) signal  510 C at time t 1 . The interface control signals  510 A (shown in  FIG. 3B ) therefore preferably update the emulator output data signals  520  on the negative edge of the system clock (TIF_CLK) signal  510 C. Since there is no restriction as to how many times or how often I/O operations can be scheduled, the target interface logic  600  can be configured to sample the emulator output data signals  520  on any TIF cycle and/or to drive the emulator input data signals  530  on any TIF cycle, including the same TIF cycle and/or any subsequent TIF cycle, as desired. 
   In the manner discussed above with reference to  FIG. 2 , communication signals  500  are transmitted from the hardware emulation system  200 ′ to the target interface logic  600  of the interface system (or pod)  424  via the communication cable  430  (shown in  FIG. 2 ). Due to the length of the communication cable  430 , the communication signals  500  experience a propagation delay T while traveling from the hardware emulation system  200 ′ to the target interface logic  600 . The synchronization (TIF_SYNC) signal  510 B, the system clock (TIF_CLK) signal  510 C, and the emulator output data signals  520  therefore are illustrated as being available to the target interface logic  600  as the propagation-delayed synchronization (TIF_SYNC) signal  510 B′, system clock (TIF_CLK) signal  510 C′, and emulator output data signals  520 ′, respectively, at time t 1 +T. Once sampled, the propagation-delayed emulator output data signals  520 ′ can be processed by the target interface logic  600  to produce associated target data signals  540 . As illustrated in  FIG. 4 , the target data signals  540  can be provided to the target system  300  (shown in  FIG. 2 ) at time t 2 . 
   The transmission of the communication signals  500  from the target system  300  to the target interface logic  600  and, therefore, the hardware emulation system  200 ′ is provided in a similar manner. The target system  300  is shown as providing the target data signals  540 ′. The target data signals  540 ′ are sampled on the positive edge of the propagation-delayed system clock (TIF_CLK) signal  510 C′ at time t 3 . By sampling the target data signals  540 ′ on the positive edge of the propagation-delayed system clock (TIF_CLK) signal  510 C′, the target interface logic  600  can be configured to drive other target data signals  540  to the target system  300  during the same TIF cycle via a bidirectional communication connection. The target interface logic  600  subsequently processes the target data signals  540 ′ to produce associated emulator output data signals  520 ″, which can be provided to the emulator output data signals  520 ″ on any TIF cycle, including the same TIF cycle and/or any subsequent TIF cycle, as desired. At time t 4 , the target interface logic  600  can provide the emulator output data signals  520 ″ as illustrated in  FIG. 4 . The emulator output data signals  520 ″ reach the hardware emulation system  200 ′ as the emulator output data signals  520  at time t 4 +T due to the propagation delay T induced by the communication cable  430  in the manner set forth in more detail above. 
   Since the effective operating speed for the target system  300  typically is many times slower than the maximum clock rate of the emulation system  200 ′, the emulator output data signals  520  can change several times during a selected emulation cycle. The target data signals  540 , in contrast, typically are static during each emulation cycle. Therefore, the number N of the emulator output data signals  520  and the number M of the emulator input data signals  530  each can be smaller than the number P of the target data signals  540 . The target interface logic  600  thereby can receive the emulator output data signals  520  from the emulation system  200 ′ and/or provide the emulator input data signals  530  to the emulation system  200 ′ over several TIF cycles during the emulation cycle while maintaining the target data signals  540 . 
   Within the target interface logic  600 , the emulator data output connections (or pins)  620  and the emulator data input connections (or pins)  630  are coupled with the target I/O connections (or pins)  640 . To enhance the flexibility of the target interface logic  600 , each emulator data output pin  620  and each the emulator data input pin  630  preferably are configured to communicate with each of the target I/O pins  640  of the target interface logic  600 .  FIG. 5  illustrates an exemplary datapath  660  for a selected target I/O pin  640  of the target interface logic  600 . When the target interface logic  600  is implemented via the plurality of field-programmable gate arrays  650  as discussed in more detail above, the datapath  660  shown in  FIG. 5  can be replicated in each field-programmable gate array  650 . Each of the target I/O connections (or pins)  640  for a selected field-programmable gate array  650  thereby can share the emulator data output connections (or pins)  620  and the emulator data input connections (or pins)  630  for that field-programmable gate array  650 . Although shown and described as comprising an illustrative arrangement of latches (or registers or flipflops)  662 , multiplexers  664 , and drivers (or buffers)  666  for purposes of illustration, the datapath  660  can be provided via any suitable configuration of conventional components, as desired. 
   During each TIF cycle, the target interface logic  600  can prestore the emulator output data signals  520  for a succeeding TIF cycle for each emulator data output pin  620 . The target interface logic  600 , in other words, can provide the target data signals  540  to the target I/O pins  640  immediately based on the emulator output data signals  520  for the current TIF cycle and/or can provide the target data signals  540  based upon the stored emulator output data signals  520  during any subsequent TIF cycle. Similarly, to provide the input data signals  530  to the hardware emulation system  200 ′, the target interface logic  600  can sample the incoming target data signals  540  during any TIF cycle and can provide the input data signals  530  based upon the incoming target data signals  540  during any TIF cycle, including the same TIF cycle and/or any subsequent TIF cycle. The emulator output data signals  520 , the input data signals  530 , and the target data signals  540  typically are stored via one or more of the latches  662  forming the datapath  660 . 
   The target interface logic  600  likewise can drive one or more of the target I/O pins  640  at a preselected logic level. Turning to  FIG. 6 , the datapath  660  is shown as including a multiplexer  664 ′ that is coupled with a selected emulator data output pin  620 ′. The emulator output data signal  520 ′ associated with the selected emulator data output pin  620 ′ thereby can be provided to a first input connection of the multiplexer  664 ′. As illustrated in  FIG. 6 , the multiplexer  664 ′ also has second and third connections that are respectively driven to a low logic level  560 A and a high logic level  560 B. A selected target I/O pins  640 ′ is coupled with, and configured to communicate with, the selected emulator data output pin  620 ′ via the multiplexer  664 ′. Therefore, the multiplexer  664 ′ is configured to selectably provide the emulator output data signal  520 ′, the low logic level  560 A, and/or the high logic level  560 B to the selected target I/O pins  640 ′, as desired. 
   Each of the target I/O pins  640  preferably include biasing circuitry  668 , such as pull-up circuitry and/or pull-down circuitry, for biasing the associated target data signals  540 . The biasing circuitry  668  can be provided in any conventional manner and, as shown in  FIG. 6 , can include a driver  666  and a resistive element  667 . The biasing circuitry  668  in an inactive mode is illustrated by biasing circuitry  668 ′ in which the driver  666 ′ does not drive the resistive element  667 ′. The target data signal  540 ′ associated with the selected target I/O pin  640 ′ therefore is not biased. When activated, the exemplary biasing circuitry  668 ″ is configured to bias the target data signal  540 ″ associated with the selected target I/O pin  640 ″ toward a high logic level. As illustrated in  FIG. 6 , the biasing circuitry  668 ″ is in the activated mode such that the driver  666 ″ drives the resistive element  667 ″. The datapath  660  likewise is shown as including a latch  662 ′ that is coupled with the selected target I/O pin  640 ′. The latch  662 ′ includes an asynchronous clear function that can force the driver  666 ′ to be in an output enable always mode. 
   The operation of the exemplary datapath  660  of the target interface logic  600  is shown in  FIGS. 7A-E . The datapath  660  is examined over a series of target interface (or TIF) cycles to illustrate one manner by which the target interface logic  600  can process communication signals  500 .  FIGS. 7A-E  illustrate the datapath  660  as the target interface logic  600  receives and processes exemplary first and second emulator output data signals  520 A,  520 B and provides first and second outgoing target data signals  540 A,  540 B to the target system  300 . The datapath  660  likewise is shown as the target interface logic  600  receives and processes first and second incoming target data signals  540 A,  540 B, subsequently providing first and second emulator input data signals  530 A,  530 B to the hardware emulation system  200 ′. 
   Turning to  FIG. 7A , the datapath  660  is shown during a first target interface cycle TIF 1 . During the first target interface cycle TIF 1 , selected emulator output data signals  520 A′,  520 B′ are respectively received by the target interface logic  600  via the emulator data output pins  620 A,  620 B. The datapath  660  is configured to route the emulator output data signal  520 A′ from the emulator data output pin  620 A to a multiplexer  664 A via a latch  662 A. Upon selecting the emulator output data signal  520 A′, the multiplexer  664 A provides the emulator output data signal  520 A′ to output latch  662 D. The emulator output data signal  520 A′ thereby is captured by the output latch  662 D. The output latch  662 D is illustrated as being associated with selected target I/O pin  640 A. For purposes of this example, the target I/O pin  640 A is configured as an output connection for providing outgoing target data signals  540 A during second and fourth target interface cycles TIF 2 , TIF 4 . 
   The datapath  660  also routes the emulator output data signal  520 B′ from the emulator data output pin  620 B to a multiplexer  664 B via a latch  662 B during the first target interface cycle TIF 1 . The multiplexer  664 B is configured to select the emulator output data signal  520 B′ and to provide the emulator output data signal  520 B′ to internal latch  662 E. The latch  662 E can capture and store the emulator output data signal  520 B′ for later propagation to selected target I/O pin  640 B during a subsequent TIF cycle. For purposes of this example, the target I/O pin  640 B is configured as a bidirectional connection for providing outgoing target data signals  540 B during a third target interface cycle TIF 3  and for sampling incoming target data signals  540 B during the fourth target interface cycle TIF 4 . The target I/O pin  640 B likewise is shown as being biased to a high logic level via active biasing circuitry  668 B. 
   The operation of the datapath  660  is illustrated during the second target interface cycle TIF 2  in  FIG. 7B . The output latch  662 D provides the emulator output data signal  520 A′ to the target I/O pin  640 A via driver  666 A as outgoing target data signal  540 A′. The outgoing target data signal  540 A′ thereby can be provided to the target system  300  in the manner set forth in more detail above. During the second target interface cycle TIF 2 , the emulator output data signal  520 B′ stored by the latch  662 E can be retrieved and routed from the latch  662 E to tristate-enable output latch  662 F. As shown in  FIG. 7B , the emulator output data signal  520 B′ is routed from the latch  662 E to the tristate-enable output latch  662 F via the multiplexer  664 B. 
   Emulator output data signals  520 A″,  520 B″ likewise are shown as being received by the target interface logic  600  via the emulator data output pins  620 A,  620 B, respectively, during the second target interface cycle TIF 2 . As discussed above with reference to the emulator output data signal  520 A′ (shown in  FIG. 7A ), the datapath  660  is configured to route the emulator output data signal  520 A″ from the emulator data output pin  620 A to the multiplexer  664 A. The multiplexer  664 A can select the emulator output data signal  520 A″ and provide the emulator output data signal  520 A″ to internal latch  662 C. The latch  662 C can capture and store the emulator output data signal  520 A″ for later propagation to selected target I/O pin  640 A during a subsequent TIF cycle. The datapath  660  also routes the emulator output data signal  520 B″ from the emulator data output pin  620 B to a multiplexer  664 C in the manner set forth above with reference to the emulator output data signal  520 B′ (shown in  FIG. 7A ). Upon being selected by the multiplexer  664 C, the emulator output data signal  520 B″ is provided to, and captured by, output latch  662 G, which is associated with selected target I/O pin  640 B. 
     FIG. 7C  shows the datapath  660  during the third target interface cycle TIF 3 . As shown in  FIG. 7C , the output latch  662 D continues to provide the emulator output data signal  520 A′ to the target I/O pin  640 A as the outgoing target data signal  540 A′; whereas, the emulator output data signal  520 A″ stored by the latch  662 C can be retrieved and routed to the output latch  662 D via the multiplexer  664 A. The signal state of the target I/O pin  640 B is determined as a function of the emulator output data signals  520 B′,  520 B″. If the emulator output data signal  520 B′ comprises a high logic level, driver  666 B is enabled such that the output latch  662 G can provide the emulator output data signal  520 B″ to the target I/O pin  640 B as the outgoing target data signal  540 B′. Otherwise, if driven by the target system  300 , the target I/O pin  640 B can receive an incoming target data signal  540 B″ (shown in  FIG. 7D ) from the target system  300 . The biasing circuitry  668 B pulls the bidirectional target I/O pin  640 B to a high logic state when the target I/O pin  640 B is not driven via the datapath  660  or the target system  300 . 
   Turning to  FIG. 7D , the datapath  660  is shown during the fourth target interface cycle TIF 4 . During the fourth target interface cycle TIF 4 , the emulator output data signal  520 A″ is illustrated as being captured by the output latch  662 D. In the manner set forth in more detail above, the output latch  662 D provides the emulator output data signal  520 A″ to the target I/O pin  640 A as outgoing target data signal  540 A″, which can be provided, in turn, to the target system  300 . The target interface logic  600  likewise receives a selected incoming target data signal  540 B″ from the target system  300  during the fourth target interface cycle TIF 4 . The incoming target data signal  540 B″ is received by the target interface logic  600  via the selected bidirectional target I/O pin  640 B, which is driven by the target system  300 . The datapath  660  is configured to route the incoming target data signal  540 B″ from the target I/O pin  640 B to a latch  662 H via a driver  666 C. 
   As illustrated in  FIG. 7E , the incoming target data signal  540 B″ is captured by the latch  662 H during the fifth target interface cycle TIF 5 . The datapath  660  is configured to route the incoming target data signal  540 B″ from the latch  662 H to a multiplexer  664 D, which is illustrated as being associated with selected emulator data input pin  630 B. Upon selecting the incoming target data signal  540 B″, the multiplexer  664 A provides the incoming target data signal  540 B″ to the emulator data input pin  630 B via a latch  6621 . The incoming target data signal  540 B″ is provided to the emulator data input pin  630 B as emulator input data signal  530 B″. Although shown and described as comprising a datapath  660  for routing exemplary signals for purposes of illustration, the target interface logic  600  can comprise any configuration of conventional components for routing emulator output data signals  520 , emulator input data signals  530 , and/or target data signals  540 . 
   The processing of differential target data signals  540  often give rise to complications in conventional emulations systems; however, the target interface logic  600  provides the flexibility to process both single-ended and differential target data signals  540 . For conventional target systems  300 , the hardware emulation system  200 ′ typically does not know in advance whether the netlist for the target system  300  will provide the differential target data signals  540  via one or two target I/O pins  640 . The number of target I/O pins  640  for providing the differential target data signals  540  can depend, for example, on the netlist type, such as whether the netlist comprises a register transfer level (RTL) netlist or a structural netlist, and/or the I/O models used for the target I/O pins  640 . The target interface logic  600  advantageously supports a wide range of netlist types and I/O models without requiring changes to the user interface, the pin assignments, the setup information, the precompiler, and/or the scheduler. 
   The manner by which the target interface logic  600  processes differential target data signals  540  can be illustrated by an exemplary netlist that includes a selected logical net that is to appear as a differential target data signal  540  on a selected pair of adjacent target I/O pins  640 . If the netlist identifies only one pin for the selected net, the selected net is assigned to the identified pin for the selected net. Since the associated communication cable  430  (shown in  FIG. 2 ) can be downloaded as a Low-Voltage Differential Signaling (LVDS) cable, the selected pair of the target I/O pins  640  is automatically formed with the appropriate adjacent pin for the selected net, and the target data signals  540  associated with the selected net are provided on the selected pair of adjacent target I/O pins  640 . The formation of the selected pair of adjacent target I/O pins  640  can be performed in any conventional manner, including via software and/or hardware, and can include the use of one or more pre-defined pairs of adjacent target I/O pins  640 . The target I/O pins  640  can be paired in any suitable manner, such as by pairing each odd target I/O pin  640  with an adjacent even target I/O pin  640 . Being implicitly defined via the assignment of the selected net to the identified pin, the second pin in the selected pair need not be identified in any file or via the user interface. 
   The exemplary netlist alternatively can identify a selected pair of adjacent target I/O pins  640  for providing the pair of differential target data signals  540  associated with the selected logical net. The first differential target data signal  540  associated with the selected logical net is provided via the first pin in the selected pair of adjacent target I/O pins  640 ; whereas, the second differential target data signal  540  is provided via the second pin in the selected pair. Although the first and second target data signals  540  are expected to be negations of each other, the first and second target data signals  540  may not necessarily negate if, for example, the first and second target data signals  540  are not updated during the same I/O cycle. To resolve this potential inconsistency, each of the selected pair of adjacent target I/O pins  640  are driven to maintain the values of the selected target data signals  540  until updated with a new value. The selected pair of adjacent target I/O pins  640  therefore transition to the new value when the new values of the selected target data signals  540  agree. 
   The target interface logic  600  can be configured for processing the emulator output data signals  520 , emulator input data signals  530 , and/or target data signals  540  in any conventional manner. If the target interface logic  600  comprises one or more field-programmable gate arrays (FPGAs)  650  in the manner discussed above with reference to  FIG. 3B , the programming of the field-programmable gate arrays  650  and the configuration of the I/O timing functions can be performed via a Joint Test Action Group (JTAG) cable (not shown) from the hardware emulation system  200 ′. The configuration of the field-programmable gate arrays  650  preferably is internally memory mapped, and each primitive JTAG instruction includes an address and data for write operations and/or an address for read operations. Since the amount of data to configure the field-programmable gate arrays  650  typically will be less than that required to program the field-programmable gate arrays  650 , the number of different types of operations to be performed by the field-programmable gate arrays  650  advantageously can be reduced. Preferably, the number of different operation types can be reduced to selecting the field-programmable gate array  650  to be addressed and performing a memory-style operation. 
   The target interface logic  600  includes a configuration memory space  800  for storing configuration information as illustrated in  FIG. 8 . Generally being organized on a per-connections (or per-pins) basis, the target interface logic  600  (shown in  FIGS. 3A-B ) includes a plurality of memory subspaces  810 ,  820 ,  830 ,  840 , and  850  for organizing the configuration information. Exemplary general divisions for the configuration memory space  800  include static memory subspaces, such as memory subspaces  810 ,  820 , and  840 , and dynamic memory subspaces, such as memory subspaces  830 ,  850 . The configuration memory space  800  likewise can be generally divided among global memory subspace  810  and local memory subspaces, including memory subspaces  820 ,  830  for configuring the emulator data input connections (or pins)  630  (shown in  FIGS. 3A-B ) and memory subspaces  840 ,  850  for configuring the target I/O connections (or pins)  640  (shown in  FIGS. 3A-B ). It will be appreciated that the memory subspaces  810 ,  820 ,  830 ,  840 , and  850  as illustrated and described are merely exemplary and not exhaustive. 
   The global memory (GS) subspace  810  is a static memory subspace and includes a plurality of registers  815  for storing information associated with the control and status of the target interface logic  600  as a whole. Exemplary information stored in the global memory subspace  810  can include a software version and an operational status. Respectively comprising a plurality of registers  825 ,  845 , the static pin memory subspaces  820 ,  840  are used to store configuration and/or status information for each input connection (or pin)  630 ,  640  (shown in  FIGS. 3A-B ) on a time-independent basis. The static pin memory (PSX) subspace  820  therefore can store configuration and/or status information for each of the emulator data input pins  630  on a time-independent basis; whereas, the static pin memory (PST) subspace  840  can be used to store configuration and/or status information for each of the target I/O pins  640  on a time-independent basis. 
   The dynamic pin memory subspaces  830 ,  850  respectively comprise a plurality of registers  835 ,  855  and are used to store configuration and/or status information for each input pin  630 ,  640  on a time-dependent basis. Thereby, the dynamic pin memory (PDX) subspace  830  can be used to store configuration and/or status information for each of the emulator data input pins  630  on a time-dependent basis. Configuration and/or status information for each of the target I/O pins  640  likewise can be stored in the dynamic pin memory (PDT) subspace  845  on a time-dependent basis. Essentially comprising a control store for the input pins  630 ,  640 , the dynamic pin memory subspaces  830 ,  850  include information that is needed by the input pins  630 ,  640  for each target interface (or TIF) cycle. 
   As shown in  FIG. 8 , each memory subspace  810 ,  820 ,  830 ,  840 , and  850  in the configuration memory space  800  can include auto-incrementing functionality. The auto-increment function can be provided in any conventional manner and preferably is provided in a manner that is reasonable in light of the functional characteristics of the relevant memory subspace  810 ,  820 ,  830 ,  840 , and  850 . For the dynamic memory subspaces  830 ,  850 , for example, the auto-increment function can be at least partially temporally based; whereas, the auto-increment function for the static memory subspaces  820 ,  840  can be provided in a manner that increments across adjacent input pins  630 ,  640 . As desired, the global memory subspace  810  can be auto-incremented across arbitrary addresses. 
   The various embodiments disclosed herein are susceptible to various modifications and alternative forms, and specific examples thereof have been shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the various embodiments disclosed herein are not to be limited to the particular forms or methods disclosed, but to the contrary, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the claims.