Browse Prior Art Database

High speed access by RAM-buffered bus cycles for hardware accelerators

IP.com Disclosure Number: IPCOM000015908D
Original Publication Date: 2002-Jun-26
Included in the Prior Art Database: 2003-Jun-21
Document File: 4 page(s) / 85K

Publishing Venue

IBM

Abstract

Abstract This publication describes an advanced method accessing embedded busses in simulation models running on hardware accelerators as well as on workstations. An advanced “instrumentation-logic” and the matching method is introduced, which accesses the stimuli-data out of a preloaded RAM. This publication will be used for IML-code-verification (initial micro program) during virtual poweron. Virtual poweron is the process to verify the IML code before the real hardware prototype is available. The “Virtual-hardware” consists of a simulation model loaded into a hardware accelerator box and a program connecting the service-element to the hardware accelerator as shown in figure 1. 1.Introduction The subject of IML testing is to access registers by means of the (embedded) localbus and to read/write scanrings of the simulation model. This can be done by: 1. Accessing the scanrings of any chip in the model using the simulator API. This is called a broadside load.

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 42% of the total text.

Page 1 of 4

High speed access by RAM-buffered bus cycles for hardware accelerators

Abstract --- This publication describes an advanced method accessing embedded busses in simulation models running on hardware accelerators as well as on workstations. An advanced "instrumentation-logic" and the matching method is introduced, which accesses the stimuli-data out of a preloaded RAM. This publication will be used for IML-code-verification (initial micro program) during virtual poweron. Virtual poweron is the process to verify the IML code before the real hardware prototype is available. The "Virtual-hardware" consists of a simulation model loaded into a hardware accelerator box and a program connecting the service-element to the hardware accelerator as shown in figure 1.

1.Introduction

The subject of IML testing is to access registers by means of the (embedded) localbus and to read/write scanrings of the simulation model. This can be done by:
1. Accessing the scanrings of any chip in the model using the simulator API. This is called a broadside load.
2.Generating stimuli for the localbus, which selects a localbus engine inside the clock-chip. The localbus controls the entire simulation model. Localbus accesses do not appear as single instances but in bulks of up to 64k accesses, especially in IML step-4, which heavily utilizes service word communication to load millicode etc.

DAS

  Laptop Service-Element

Control Hardware WorkstationAccelerator

TCP/IP

          Simulation Hypervisormodel

SCSI

figure 1: simulation setup

2.0 Accelerator

The accelerator platform is a ET3/ET4 or AWAN. The current ET3 has 8 boards with 64k emulation processors, which hold the simulation model. The model load is performed via SCSI-connections. Any API access is also done via the SCSI-cables. An additional low latency connection, called DAS, is also provided. This is a PCI-card plugged in the control workstation slot, which can directly access objects in the model.The DAS connection is no ready to use solution, but depends directly on the realization of instrumentation logic and the software to stimulate it.

1

[This page contains 3 pictures or other non-text objects]

Page 2 of 4


2.2 Control workstation: The ET3 machine is attached to its workstation by SCSI-fast-wide cables. A C-programm called hypervisor resides on the control workstation. It connects to the SE, receives the IML data stream and applies the stimuli to the model either by the simulator API or by the DAS-card.

2.3 Service Element (SE) The SE is a laptop running OS/2 and connecting to the LAN. It generates the IML data stream, which is subject to test.

2.4 Hypervisor

Hypervisor connects the SE to the hardware accelerator by means of socket-services (TCP/IP). It uses a special protocol to receive/send commands from/to the SE. In the TCP/IP-connection, hypervisor is configured as the server, while the SE runs as the client. Any command received from the SE is processed in the clock chip.

3. Running state of the art buscycles...