| Behavior processor system and method -> Monitor Keywords |
|
|
  Behavior processor system and methodUSPTO Application #: 20060117274Title: Behavior processor system and method Abstract: The debug system described in this patent specification provides a system that generates hardware elements from normally non-synthesizable code elements for placement on an FPGA device. This particular FPGA device is called a Behavior Processor. This Behavior Processor executes in hardware those code constructs that were previously executed in software. When some condition is satisfied (e.g., If . . . then . . . else loop) which requires some intervention by the workstation or the software model, the Behavior Processor works with an Xtrigger device to send a callback signal to the workstation for immediate response. (end of abstract) Agent: Raymond R. Moser Jr., Esq. MoserIPLaw Group - Shrewsbury, NJ, US Inventors: Ping-Sheng Tseng, Yogesh Goel, Su-Jen Hwang, James Lee, Kun-Hsu Shen USPTO Applicaton #: 20060117274 - Class: 716001000 (USPTO) Related Patent Categories: Data Processing: Design And Analysis Of Circuit Or Semiconductor Mask, Circuit Design The Patent Description & Claims data below is from USPTO Patent Application 20060117274. Brief Patent Description - Full Patent Description - Patent Application Claims
RELATED U.S. APPLICATION [0001] This is a continuation-in-part of U.S. patent application Ser. No. 09/900,124, filed Jul. 6, 2001, entitled "Inter-Chip Communication System"; which is a continuation-in-part of U.S. patent application Ser. No. 09/373,014, filed Aug. 11, 1999, entitled "VCD-on-Demand System and Method"; which is a continuation-in-part of U.S. patent application Ser. No. 09/144,222, filed Aug. 31, 1998, entitled "Timing-Insensitive and Glitch-Free Logic System and Method". BACKGROUND OF THE INVENTION [0002] 1. Field of the Invention [0003] The present invention generally relates to electronic design automation (EDA). More particularly, the present invention relates to dynamically changing the evaluation period to accelerate design debug sessions. [0004] 2. Description of Related Art [0005] In general, electronic design automation (EDA) is a computer-based tool configured in various workstations to provide designers with automated or semi-automated tools for designing and verifying user's custom circuit designs. EDA is generally used for creating, analyzing, and editing any electronic design for the purpose of simulation, emulation, prototyping, execution, or computing. EDA technology can also be used to develop systems (i.e., target systems) which will use the user-designed subsystem or component. The end result of EDA is a modified and enhanced design, typically in the form of discrete integrated circuits or printed circuit boards, that is an improvement over the original design while maintaining the spirit of the original design. [0006] The value of software simulating a circuit design followed by hardware emulation is recognized in various industries that use and benefit from EDA technology. Nevertheless, current software simulation and hardware emulation/acceleration are cumbersome for the user because of the separate and independent nature of these processes. For example, the user may want to simulate or debug the circuit design using software simulation for part of the time, use those results and accelerate the simulation process using hardware models during other times, inspect various register and combinational logic values inside the circuit at select times, and return to software simulation at a later time, all in one debug/test session. Furthermore, as internal register and combinational logic values change as the simulation time advances, the user should be able to monitor these changes even if the changes are occurring in the hardware model during the hardware acceleration/emulation process. [0007] Co-simulation arose out of a need to address some problems with the cumbersome nature of using two separate and independent processes of pure software simulation and pure hardware emulation/acceleration, and to make the overall system more user-friendly. However, co-simulators still have a number of drawbacks: (1) co-simulation systems require manual partitioning, (2) co-simulation uses two loosely coupled engines, (3) co-simulation speed is as slow as software simulation speed, and (4) co-simulation systems encounter race conditions. [0008] First, partitioning between software and hardware is done manually, instead of automatically, further burdening the user. In essence, co-simulation requires the user to partition the design (starting with behavior level, then RTL, and then gate level) and to test the models themselves among the software and hardware at very large functional blocks. Such a constraint requires some degree of sophistication by the user. [0009] Second, co-simulation systems utilize two loosely coupled and independent engines, which raise inter-engine synchronization, coordination, and flexibility issues. Co-simulation requires synchronization of two different verification engines--software simulation and hardware emulation. Even though the software simulator side is coupled to the hardware accelerator side, only external pin-out data is available for inspection and loading. Values inside the modeled circuit at the register and combinational logic level are not available for easy inspection and downloading from one side to the other, limiting the utility of these co-simulator systems. Typically, the user may have to re-simulate the whole design if the user switches from software simulation to hardware acceleration and back. Thus, if the user wanted to switch between software simulation and hardware emulation/acceleration during a single debug session while being able to inspect register and combinational logic values, co-simulator systems do not provide this capability. [0010] Third, co-simulation speed is as slow as simulation speed. Co-simulation requires synchronization of two different verification engines--software simulation and hardware emulation. Each of the engines has its own control mechanism for driving the simulation or emulation. This implies that the synchronization between the software and hardware pushes the overall performance to a speed that is as low as software simulation. The additional overhead to coordinate the operation of these two engines adds to the slow speed of co-simulation systems. [0011] Fourth, co-simulation systems encounter set-up, hold time, and clock glitch problems due to race conditions in the hardware logic element or hardware accelerator among clock signals. Co-simulators use hardware driven clocks, which may find themselves at the inputs to different logic elements at different times due to different wire line lengths. This raises the uncertainty level of evaluation results as some logic elements evaluate data at some time period and other logic elements evaluate data at different time periods, when these logic elements should be evaluating the data together. [0012] Accordingly, a need exists in the industry for a system or method that addresses problems raised above by currently known simulation systems, hardware emulation systems, hardware accelerators, co-simulation, and coverification systems. SUMMARY OF THE INVENTION [0013] An object of the present invention is to use less hardware resources than the dedicated hardware cross-bar technology while achieving similar performance levels. [0014] Another object of the present invention is to be more resourceful than the virtual wires technology without the decrease in performance arising from the use of extra evaluation cycles for the transfer of inter-chip data. [0015] One embodiment of the present invention is an inter-chip communication system that transfers signals across FPGA chip boundaries only when these signals change values. This is accomplished with a series of event detectors that detect changes in signal values and packet schedulers which can then schedule the transfer of these changed signal values to another designated chip. [0016] These and other embodiments are fully discussed and illustrated in the following sections of the specification. BRIEF DESCRIPTION OF THE FIGURES [0017] The above objects and description of the present invention may be better understood with the aid of the following text and accompanying drawings. [0018] FIG. 1 shows a high level overview of one embodiment of the present invention, including the workstation, reconfigurable hardware emulation model, emulation interface, and the target system coupled to a PCI bus. [0019] FIG. 2 shows one particular usage flow diagram of the present invention. [0020] FIG. 3 shows a high level diagram of the software compilation and hardware configuration during compile time and run time in accordance with one embodiment of the present invention. Continue reading... Full patent description for Behavior processor system and method Brief Patent Description - Full Patent Description - Patent Application Claims Click on the above for other options relating to this Behavior processor system and method patent application. ###  How KEYWORD MONITOR works... a FREE service from FreshPatents1. Sign up (takes 30 seconds). 2. Fill in the keywords to be monitored. 3. Each week you receive an email with patent applications related to your keywords. Start now! - Receive info on patent apps like Behavior processor system and method or other areas of interest. ### Previous Patent Application: Asynchronous communication network for multi-element integrated circuit system Next Patent Application: Semiconductor integrated circuit designing method and program Industry Class: Data processing: design and analysis of circuit or semiconductor mask ### FreshPatents.com Support Thank you for viewing the Behavior processor system and method patent info. IP-related news and info Results in 0.77696 seconds Other interesting Feshpatents.com categories: Computers: Graphics , I/O , Processors , Dyn. Storage , Static Storage , Printers |
||
