Browse Prior Art Database

Data Flow Checking Device for Address Generation and Address Path

IP.com Disclosure Number: IPCOM000035769D
Original Publication Date: 1989-Aug-01
Included in the Prior Art Database: 2005-Jan-28
Document File: 3 page(s) / 56K

Publishing Venue

IBM

Related People

Aschenbrenner, JM: AUTHOR [+2]

Abstract

This article describes an arrangement for verifying the ability of one card to read the memory on another card. It verifies the data path, the address path, and the address generation. Specifically, it checks the ability of a Printer Data Card to unload data correctly from Raster Buffer Memory in an All-Points-Addressable printer controller. This arrangement uses software and a minimal amount of hardware. This test is part of the power-on diagnostics which are run on the printer. The extra memory modules, extra logic, and wider bus associated with parity are avoided. Little hardware is required beyond the existing, functional hardware so the arrangement provides significant cost savings. The simplicity of the design reduces the probability of failure by the error-checking logic.

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

Page 1 of 3

Data Flow Checking Device for Address Generation and Address Path

This article describes an arrangement for verifying the ability of one card to read the memory on another card. It verifies the data path, the address path, and the address generation. Specifically, it checks the ability of a Printer Data Card to unload data correctly from Raster Buffer Memory in an All-Points- Addressable printer controller. This arrangement uses software and a minimal amount of hardware. This test is part of the power-on diagnostics which are run on the printer. The extra memory modules, extra logic, and wider bus associated with parity are avoided. Little hardware is required beyond the existing, functional hardware so the arrangement provides significant cost savings. The simplicity of the design reduces the probability of failure by the error-checking logic.

In the system under test, there are two bus masters and one memory card which functions as a bus slave. The Command Sequencer (CSeq) can perform both writes and reads of the Raster Buffer Memory (RBM). At the start of the test described, these functions are assumed to have been tested and to be working correctly. Fig. 1 shows the components and their connections.

The Printer Data Interface card (PDI) unloads data from the Raster Buffer Memory (RBM), reorganizes it, and passes it to the Printing Mechanism (PM). The PDI accesses the RBM with a read/clear operation only. It cannot write to the RBM.

The RBM stores a bit-wise representation of the pels to be printed on a page. The PDI transfers the data from the RBM to the PM. An occasional single pel error is not serious because a few incorrect pels on the page are not noticeable, but permanent errors must be detectable. Therefore, this error-checking is done only at power-on or when manually invoked.

Before the test begins, the CSeq fills several rows in the RBM with selected data. This operation is independent of the PDI. Then, the CSeq instructs the PDI to unload one row at a time.

The CSeq sends a command signal to the PDI to unload a row of all binary ones (black pels). This causes the PDI to initialize its address generation logic and to address and access all positions in the row. When the PDI has finished reading the row, the CSeq reads the RBM row and verifies that the data is all zeros. This assures that the PDI has addressed, and thus cleared, every location. This checks the address generation on the PDI card as well as the PDI's ability to access all memory locations in one row of the RBM. The test depends on the fact that...