Browse Prior Art Database

Self-Identifying CPU and Bus Structures

IP.com Disclosure Number: IPCOM000033528D
Original Publication Date: 2004-Dec-14
Included in the Prior Art Database: 2004-Dec-14
Document File: 3 page(s) / 28K

Publishing Venue

IBM

Abstract

This article will present a self-identification method for use in logic simulation models. The method is used for complex multi-core or multi-bus System-on-Chip (SoC) and ASIC designs running in an event simulation environment. The approach is currently used in IBM's System-on-Chip platform based design kits.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 44% of the total text.

Page 1 of 3

Self-Identifying CPU and Bus Structures

Background of Invention
Highly configurable systems of multiple CPU's and busses require configurable and automated simulation model environments. Todays ASICS are composed of a multitude of CPU's, consisting of various bus configurations and other signals, as well as standalone bus-mastering cores such as DMA, communication controllers, and bus slaves such as UARTs and memory controllers. When using Core Connect (a publicly available IBM IC bus) for example, there are five unique bus types, two unique processors (each containing multiple busses), and a variety of master and slave cores available to use in a chip architectures and designs. System-on-Chip (SoC) and ASIC simulation models are constructed from a known set of these components, in a variety of ways.

The performance of a simulation environment is improved by offloading some parts of design elements into C-based modeling programs. An example is to move CPU logic from a complete RTL or smartmodel representation, to a combination of an Instruction Set Simulator (ISS) and a set of Bus Functional Models (BFMs). The hybrid CPU is presented in a drop-and-replace fashion, which takes the place of the CPU in the simulation model. The objective of drop-and-replace is to allow simulation work to be offloaded to program(s) distributed among many processors, while maintaining the exact port interface of the offloaded unit in the simulation model.

Problem to Solve

This invention extends the art of simulation offloading by providing an automated way to correlate activities occurring in an RTL plug-in with it's associated offload C program that is modeling the logic. A synopsis of the problem is as follows:

     How do you automatically bind the offload C program to it's RTL plug-in replacement? How do you uniquely identify multiple exact copies of a replacement, and interact with each appropriately?

     When the C program needs to interact with the RTL, how do you know when is the proper time to do so?

     When the RTL needs to interact with the C program, when is the proper time and how is this communicated to the C program?

In prior art, offload C code is typically called once per system-wide clock edge; the environment needs to examine the entire design and to decide the action to take at the system clock edge. This is problematic because real hardware (and event simulators) do not guarantee order of arrival of events. For example, 1 fs of clock skew turns one clock ito two events.

     How does the simulation environment decouple the ordering of events occurring in hardware from the processing of events in the offload C program?

To deal with these questions an automated mechanism is defined that allows hybrid design components to self-identify themselves to the simulation environment, at initialization and runtime. The method is able to dynamically correlate characteristics of the RTL and C parts of a hybrid model together properly.

1

Page 2 of 3

Solution

A

B

...