Browse Prior Art Database

Technique to Synchronize an Emulator or Simulation Accelerator to Multiple, Asynchronous Target Systems

IP.com Disclosure Number: IPCOM000118167D
Original Publication Date: 1996-Oct-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 4 page(s) / 186K

Publishing Venue

IBM

Related People

Ng, T: AUTHOR [+3]

Abstract

This technique applies to hardware emulators and/or hardware simulation acceleration engines. It describes a way to synchronize several external systems (referred to as "target systems") to a single emulator or simulation accelerator. The target systems may have independent, asynchronous clocks with respect to each other and to the emulator/simulator accelerator. The emulator/simulation accelerator however has only one synchronous clock. The technique described herein addresses the challenge of having the emulator/simulation accelerator model several different logic segments, each synchronized with a different target system clock, while still remaining a synchronous clock internal to its operation.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 29% of the total text.

Technique to Synchronize an Emulator or Simulation Accelerator to
Multiple, Asynchronous Target Systems

      This technique applies to hardware emulators and/or hardware
simulation acceleration engines.  It describes a way to synchronize
several external systems (referred to as "target systems") to a
single emulator or simulation accelerator.  The target systems may
have independent, asynchronous clocks with respect to each other and
to the emulator/simulator accelerator.  The emulator/simulation
accelerator however has only one synchronous clock.  The technique
described herein addresses the challenge of having the
emulator/simulation accelerator model several different logic
segments, each synchronized with a different target system clock,
while still remaining a synchronous clock internal to its operation.

      Let EIS represent the clock domain for the "Emulation Internal
Simulator", which may consist of any type of non-physically realized
representation of a logic circuit that produces the same output
responses as the logic circuit for the same input conditions.
Further, the EIS may use a synchronized internal clock (or other
means of internal synchronization) across all portions of its
implementation so that time-multiplexing of signals across shared
physical interconnections (i.e., wires, cables) can occur unknown to
the user or attached devices.

      Let TARG n (n=A,B,C,...) represent a clock domain of the target
system which is physically attached to the EIS inputs and outputs
(e.g., TARG A and TARG B are two different clock domains attached to
the EIS.).

      A straight-forward approach is to synchronize the EIS and a
single target clock domain (TARG A) in lock-step (or in some integer
relationship) to one another.  To illustrate this, let .. denote the
passage of neclock cycle in the EIS domain.  For illustration
purposes, assume this is 10 ns.  Assume that the EIS requires 6 EIS
cycles to duplicate the response of a single cycle of the logic
circuit being modelled.

We now have the following picture:
  |.....|.....|.....|.....|   6 EIS steps/emulated cycle
  |.....|.....|.....|.....|   TARG A clocks have a period of 60 ns
  *     *     *     *     *   TARG A and EIS "clocks" are in sync,
                              the combined system will work

If the EIS required 9 steps/emulated cycle, TARG A would have to have
a clock period no less than 90 ns.
  |........|........|........|  9 EIS steps/emulated cycle
  |........|........|........|  TARG A clock period is slowed
                                 to 90 ns

      If TARG A ran any faster than 90 ns, say at 80 ns instead, the
EIS system would not be able to complete the calculations in time,
thus the two "clocks" would be out of step and the system would not
work.
  |........|........|........|  9 EIS steps/emulated cycle
  |.......|.......|.......|   ...