Abstract:
A system and method are disclosed for communicating in a programmable core. The programmable core is within a single integrated circuit and is divided into multiple independent sub-cores. The sub-cores are coupled together using a multiplexer based network. In another aspect, the multiplexer-based network includes multiplexers associated with some of the sub-cores for sending data and demultiplexers associated with other sub-cores for receiving data. In yet another aspect, a clock is included in the multiplexer-based network for synchronizing communication between the multiplexers and demultiplexers.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This is a 35 U.S.C. §371 U.S. National Stage of International Application No. PCT/EP2007/051652, filed Feb. 21, 2007, which was published in English under PCT Article 21(2), which in turn claims the benefit of U.S. Provisional Application No. 60/775,595, filed Feb. 21, 2006. Both applications are incorporated herein in their entirety. 
    
    
     FIELD OF THE INVENTION 
     The present invention generally relates to hardware emulators, and more particularly to communication between programmable sub-cores in a hardware emulator. 
     BACKGROUND 
     Today&#39;s sophisticated SoC (System on Chip) designs are rapidly evolving and nearly doubling in size with each generation. Indeed, complex designs have nearly exceeded 50 million gates. This complexity, combined with the use of devices in industrial and mission-critical products, has made complete design verification an essential element in the semiconductor development cycle. Ultimately, this means that every chip designer, system integrator, and application software developer must focus on design verification. 
     Hardware emulation provides an effective way to increase verification productivity, speed up time-to-market, and deliver greater confidence in the final SoC product. Even though individual intellectual property blocks may be exhaustively verified, previously undetected problems appear when the blocks are integrated within the system. Comprehensive system-level verification, as provided by hardware emulation, tests overall system functionality, IP subsystem integrity, specification errors, block-to-block interfaces, boundary cases, and asynchronous clock domain crossings. Although design reuse, intellectual property, and high-performance tools all help by shortening SoC design time, they do not diminish the system verification bottleneck, which consumes 60-70% of the design cycle. As a result, designers can implement a number of system verification strategies in a complementary methodology including software simulation, simulation acceleration, hardware emulation, and rapid prototyping. But, for system-level verification, hardware emulation remains a favorable choice due to superior performance, visibility, flexibility, and accuracy. 
     A short history of hardware emulation is useful for understanding the emulation environment. Initially, software programs would read a circuit design file and simulate the electrical performance of the circuit very slowly. To speed up the process, special computers were designed to run simulators as fast as possible. IBM&#39;s Yorktown “simulator” was the earliest (1982) successful example of this—it used multiple processors running in parallel to run the simulation. Each processor was programmed to mimic a logical operation of the circuit for each cycle and may be reprogrammed in subsequent cycles to mimic a different logical operation. This hardware ‘simulator’ was faster than the current software simulators, but far slower than the end-product ICs. When Field Programmable Gate Arrays (FPGAs) became available in the mid-80&#39;s, circuit designers conceived of networking hundreds of FPGAs together in order to map their circuit design onto the FPGAs and the entire FPGA network would mimic, or emulate, the entire circuit. In the early 90&#39;s the term “emulation” was used to distinguish reprogrammable hardware that took the form of the design under test (DUT) versus a general purpose computer (or work station) running a software simulation program. 
     Soon, variations appeared. Custom FPGAs were designed for hardware emulation that included on-chip memory (for DUT memory as well as for debugging), special routing for outputting internal signals, and for efficient networking between logic elements. Another variation used custom IC chips with networked single bit processors (so-called processor based emulation) that processed in parallel and usually assumed a different logic function every cycle. 
     Physically, a hardware emulator resembles a large server. Racks of large printed circuit boards are connected by backplanes in ways that most facilitate a particular network configuration. A workstation connects to the hardware emulator for control, input, and output. 
     Before the emulator can emulate a DUT, the DUT design must be compiled. That is, the DUT&#39;s logic must be converted (synthesized) into code that can program the hardware emulator&#39;s logic elements (whether they be processors or FPGAs). Also, the DUT&#39;s interconnections must be synthesized into a suitable network that can be programmed into the hardware emulator. The compilation is highly emulator specific and can be time consuming. 
     Emulators contain a network of crossbar switches to facilitate communication between the different emulator components. A crossbar switch is an interconnect device that receives multiple inputs and maps the inputs to any of its desired outputs. For example, a 32×32 crossbar switch may be programmed to connect any of its 32 inputs to any of its 32 outputs. A crossbar switch may be used for inter-chip communication within the emulator, but also intra-chip to allow communication between components within a chip. 
     Although the tendency in the electronics industry is to provide smaller and smaller wires, in certain applications it is desirable to use larger wires. Larger wires offer less resistance and, consequently, are faster. Unfortunately, larger wires also increase cross-talk and require more spacing with respect to neighboring wires. The larger wires are particularly problematic with interconnections within a crossbar switch. More specifically, when using larger wires, the number of larger wires and the required spacing there between make the crossbar switch impractical. 
     Thus, a new communication scheme is needed in an emulation environment that lessens the dependency on crossbar switches. 
     SUMMARY 
     A system and method are disclosed for communicating in a programmable core. The programmable core is within a single integrated circuit and is divided into multiple independent sub-cores. The sub-cores are coupled together using a multiplexer-based network. 
     In another aspect, the multiplexer-based network includes multiplexers associated with some of the sub-cores for sending data and demultiplexers associated with other sub-cores for receiving data. 
     In another aspect, the programmable core is an FPGA core. 
     In yet another aspect, a clock is included in the multiplexer-based network for synchronizing communication between the multiplexers and demultiplexers. 
     These features and others of the described embodiments will be more readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a system diagram of a hardware emulator environment including a plurality of printed circuit boards. 
         FIG. 2  is a diagram showing multiple ASICS on a printed circuit board of  FIG. 1 . 
         FIG. 3  shows further details of an ASIC as including an FPGA core. 
         FIG. 4  shows that the FPGA core can include multiple sub-cores coupled together by a multiplexer-based network. 
         FIG. 5  shows further details of the multiplexer-based network. 
         FIG. 6  is a specific example wherein each sub-core may include multiple multiplexers and demultiplexers. 
         FIG. 7  is a flowchart of a method for communicating between programmable sub-cores within an integrated circuit. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  shows an emulator environment  10  including a hardware emulator  12  coupled to a hardware emulator host  14 . The emulator host  14  may be any desired type of computer hardware and generally includes a user interface through which a user can load, compile and download a hardware design to the emulator  12  for emulation. 
     The emulator  12  includes multiple printed circuit boards  16  coupled to a midplane  18 . The midplane  18  allows physical connection of the printed circuit boards into the emulator  12  on both sides of the midplane. A backplane may also be used in place of the midplane, the backplane allowing connection of printed circuit boards on one side of the backplane. Any desired type of printed circuit boards may be used. For example, programmable boards  20  generally include an array of FPGAs, or other programmable circuitry, that may be programmed with the user&#39;s design downloaded from the emulator host  14 . One or more I/O boards  22  allow communication between the emulator  12  and hardware external to the emulator. For example, the user may have a preexisting processor board that is used in conjunction with the emulator and such a processor board connects to the emulator through I/O board  22 . Clock board  24  generates any number of desired clock signals. And interconnect boards  26  allow integrated circuits on the programmable boards  20  to communicate together and with integrated circuits on the I/O boards  22 . 
       FIG. 2  shows further details of one of the programmable boards  20  as including a plurality of Application Specific Integrated Circuits (ASICS)  40  arranged in columns and rows. As further described below, the ASICS include a programmable portion (e.g., an FPGA core) that is programmed with a user design to be emulated. The programmable board may include, instead of ASICS, programmable ICs, such as FPGAs. 
       FIG. 3  shows further details of one of the ASICS  40 . Each ASIC includes a plurality of pins  50  for physically and electrically connecting the ASIC package  52  (e.g., any type of surface mount or through hole package types) to the programmable board  20 . The ASIC also includes an FPGA core  54  that is programmable with the user design. The FPGA is a semiconductor device containing programmable logic and programmable interconnects between the logic. 
       FIG. 4  shows further details of the FPGA core  54 . The FPGA core may be formed of a single die and includes multiple sub-cores  60  communicating together through a multiplexer-based network  62 . A typical FPGA core includes millions of programmable gates and interconnects. A wire from any part of the FPGA core can be coupled through programmable gates to any other part of the FPGA core on the same die. Instead,  FIG. 4  shows that the FPGA core includes multiple sub-cores. Although six sub-cores are shown, any number of sub-cores may be included in the design. Each sub-core  60  acts like an independent FPGA core. Indeed any logic element in an FPGA sub-core can be coupled to another logic element in the same sub-core through programmable interconnects. However, elements between sub-cores cannot be coupled together through programmable gates as in standard FPGAs. Instead, elements between sub-cores can only communicate through the multiplexer-based network  62 . As described further below, the multiplexer-based network  62  includes a plurality of multiplexers and demultiplexers to enable communication between the sub-cores. A sending sub-core uses a multiplexer in order to send signals through the network  62 . A receiving sub-core uses a demultiplexer to receive the sent signal. The multiplexer-based network is not part of the user design being emulated. Rather, the sub-cores are programmed with the user design and elements of the user design in one sub-core can communicate with other elements of the user design in another sub-core only through a network that contains multiplexers and demultiplexers that are not part of the user design. The multiplexer-based network may or may not include a crossbar switch between the sending multiplexer and receiving demultiplexer for statically or dynamically programming the network. Alternatively, the multiplexers may be directly connected (hard-wired) to demultiplexers within the network. 
       FIG. 5  shows further details of the multiplexer-based network  62 . Each FPGA sub-core  60  has an associated I/O  70  that is part of the network  62  and that includes a set of multiplexers and demultiplexers. Each FPGA sub-core  60  is not connectable to the other sub-cores in the FPGA core  54 . The primary (and possibly only) means of communication between the sub-cores is through the multiplexer-based network  62 . The I/O  70  represents the edge of the user model. More specifically, the user model is programmed into the sub-core  60 . The I/O  70  has dedicated multiplexers and demultiplexers that are independent from or otherwise not associated with the user design, but only serve for communication from the sub-core  60  over the network  62 . Physical routing  74  allows a connection between a multiplexer on a sending FPGA sub-core and a demultiplexer on a receiving FPGA core. The routing  74  may or may not include a crossbar switch or other logic elements (e.g., buffers, etc.). 
       FIG. 6  shows a particular embodiment of the multiplexer-based network  62 . In this embodiment, a first sub-core  80  is adjacent to an I/O portion  84  of the network. The I/O portion  84  includes multiple multiplexers (designated with an “M”) and demultiplexers (designated with a “DM”) positioned on the periphery of the sub-core  80 . A second sub-core  86  has an associated I/O portion  90 , which is part of the network  62 . The I/O portion  90  includes multiple multiplexers and demultiplexers for coupling to the network  62 . As is shown at  92 ,  94 , there are direct electrical connections between sub-core  80  and sub-core  86 . Specifically, the multiplexer  96 , which is part of I/O portion  84 , is directly connected to a demultiplexer  98 , which is part of I/O portion  90 . Similarly, the FPGA sub-core  86  can communicate with sub-core  80  through a multiplexer  110  that is directly connected to a demultiplexer  112  on sub-core  80 . The multiplexers in I/O portion  84  and I/O portion  90  are controlled by a source clock  100  used to coordinate the transmission timing. Of course, direct connection is not required and there may be logic elements or a crossbar switch between the multiplexer and demultiplexer. 
       FIG. 7  shows a flowchart of a method for communicating between sub-cores in an FPGA. In process block  120 , an FPGA core is provided that has a plurality of FPGA sub-cores with a multiplexer-based network between the sub-cores. The FPGA core is a single die located within a single IC package. In process block  122 , a communication from one sub-core is multiplexed and transmitted over the multiplexer-based network. In process block  124 , the signal is received in another sub-core and demultiplexed. 
     Having illustrated and described the principles of the illustrated embodiments, it will be apparent to those skilled in the art that the embodiments can be modified in arrangement and detail without departing from such principles. 
     In view of the many possible embodiments, it will be recognized that the illustrated embodiments include only examples of the invention and should not be taken as a limitation on the scope of the invention. Rather, the invention is defined by the following claims. We therefore claim as the invention all such embodiments that come within the scope of these claims.