Event-driven circuit emulator with packet routing debugger

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current circuit emulators require repetitive reprogramming and re-running of simulations to collect data on unmonitored signals, leading to increased debugging time, and existing snapshot systems disrupt emulation to transfer state data, causing inefficiencies in the debugging process.

Innovation Solution

A system that integrates a logic analyzer, a computer-based debugger, and resource boards via a packet routing network, allowing the debugger to control and modify the emulation process by asserting trigger signals to halt the emulation, transfer data, and restart from specific states without interrupting the emulation process.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Quantity of substance

If the emulator monitors a limited set of signals during emulation, then the data acquisition memory can store the data, but if the user wants to review unmonitored signals, it is necessary to reprogram the emulator and repeat the emulation, greatly increasing debugging time

Engineering Contradiction:
Improveamount of signal data collectedVSAvoiddebugging time
Core Design Contradiction:
Quantity of substanceVSLoss of time

Solution Approach 1:

The system divides signal monitoring into two segments: a limited set of signals monitored during high-speed emulation (stored in data acquisition memory) and additional signals captured when the emulation is paused (stored in memory). This segmentation allows the system to efficiently handle monitored signals while providing on-demand capture of unmonitored signals without requiring full reprograming and re-emulation.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system performs preliminary monitoring of a core set of signals during emulation and stores this data in advance in the data acquisition memory. When debugging needs arise for additional signals, the system has already captured and stored the emulation state data, allowing the debugger to retrieve both the pre-captured limited set data and additional unmonitored signal data without repeating the entire emulation process.

Inventive Principle:
Principle #10Preliminary action

2Quantity of substance

If the emulation is halted frequently to flush data acquisition memory to hard disk, then data storage capacity is managed, but the time required to carry out emulation is substantially increased

Engineering Contradiction:
Improvedata storage capacityVSAvoidemulation speed
Core Design Contradiction:
Quantity of substanceVSProductivity

Solution Approach 1:

The system merges the data acquisition memory (with limited capacity) and the hard disk memory (with large capacity) into a unified storage architecture. The data acquisition memory continues to operate at high speed for active emulation data, while the hard disk serves as extended storage. When the data acquisition memory becomes full, the system pauses emulation briefly to transfer data to the hard disk, but the debugger can still access both memory types, effectively combining their capacities without frequent interruptions.

Inventive Principle:
Principle #5Merging (Combining)

3Speed

If the emulator uses high-speed memory to store data during emulation, then data can be accessed quickly, but the storage capacity is limited

Engineering Contradiction:
Improvedata access speedVSAvoidstorage capacity
Core Design Contradiction:
SpeedVSQuantity of substance

Solution Approach 1:

The system adds a spatial dimension to the storage architecture by introducing a second storage medium (hard disk) with different characteristics (large capacity, slower access). The data acquisition memory maintains high-speed access for frequently accessed emulation data, while the hard disk provides extensive capacity for storing complete emulation datasets. The system manages data distribution across these two dimensions (speed vs. capacity) based on access patterns and debugging needs.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

Data Source

PatentUS7970597B2Event-driven emulation system
Publication Date: 2011.06.28 SYNOPSYS INC
  • US7970597B2 patent drawing
  • US7970597B2 patent drawing
  • US7970597B2 patent drawing

AI summary

A circuit emulator includes emulation resources programmed to emulate a circuit, a clocking system for clocking logic implemented by the emulation resources, a resource interface circuit, a logic analyzer, and a debugger. The resource interface circuit supplies input signals to the emulation resources, stores data representing behavior of signals generated by the emulation resources produces in response to the input signals and configures operating characteristics of the clocking system. Upon detecting a specified event in the selected signals of the emulation resources, the logic analyzer asserts a trigger signal telling the clocking system to stop clocking the emulation resources. Communicating with the resource interface circuit and the logic analyzer via a packet routing network, the debugger acquires and processes the data stored by the resource interface circuit and transmits commands to the resource interface circuit and the logic analyzer specifying clocking system operating characteristics, controlling signal data transfer to the debugger, and defining the signal events the logic analyzer is to detect.