Bay Microsystems, Inc.

Synopsys, Inc.

Goichiro Ono

Man Dieu Trinh

Simon S Chong

Barry T Lee

Jun-Wen Tsong

Charles F Gershman

Steve C Chen

Tony J Chiang

Eric K Yang

Ryzsard Bleszynski

Zhe Zhao

Yuchen Xu

Yu Sui

He Yin

Meng-Tse Chen

Yihui Wu

Chia-Wei Liang

Wenxin Wang

Yang Song

An emulation system traverses trace buffers to read data captured from a design under test (DUT). The emulation system receives a request to read at least a portion of DUT data. The emulation system reads a header of the latest sample of the DUT data, where header of each sample of the DUT data includes one or more pointers to a previously stored sample. The samples of the DUT data are partitioned into frames and sectors. The emulation system can identify samples of the DUT data using the pointers in the header of the samples and compare time stamps of the samples against a specified time stamp in the received request. After identifying a sample having the specified time stamp, the emulation system may read the sample for output to the user (e.g., reconstructing a waveform using the sample).

Trace buffer data management for emulation systems

A configuration to address a bus stall during data packet transmission also allows for bus recover due to data packet transmission errors. If a downstream node is not ready to receive data from a buffer of an upstream node, a timer counts a timeout value. The time count increments on each clock cycle in which the downstream node is not ready to receive data. The buffer is cleared at the upstream node when the count reaches a predetermined threshold value. Alternately, the configuration also operates to receive a packet header from an upstream node, the packet header identifying a number of data in a packet. If no data downstream is received on a clock cycle, a counter triggers and is incremented for each cycle in which no date is received. When a threshold is reached dummy data fills a data packet to then transmit the data.

Self-recovery mechanism for multi-hosts and multi-devices emulation and prototyping system bus

A network processor for processing information elements is described. Each information element is associated with a flow and comprises at least one information element segment. A policy controller stores an information element into at least one information segment storage unit within a memory, and determines whether an information element segment conforms to a predetermined quality of service ('QoS'). A traffic processor selects the information element segment for forwarding based on at least one QoS parameter. A forwarding processor forwards the selected information element segment to an egress port.

Network processor architecture

A hardware-based technique for policing traffic in a network node involves programming a set of algorithm-specific policing primitives that establishes a relationship between condition primitives and action primitives and populating a searchable memory with a set of indexed action primitives. Action primitives are then selected from the searchable memory in response to condition primitives related to a received datagram. Policing actions related to the datagram are performed in response to the action primitive. Because the algorithm-specific policing primitives are programmable, a network node can be adapted to implement a wide variety of policing algorithms. Additionally, multiple different policing algorithms can be implemented in hardware without the need for a different set of combinational logic for each different policing algorithm.

Programmable hardware-based traffic policing

Growing community of inventors

San Jose, CA, United States of America

Goichiro Ono