U.S. patent application number 12/266479 was filed with the patent office on 2009-03-05 for printer controller configured to compensate for dead printhead nozzles.
This patent application is currently assigned to Silverbrook Research Pty Ltd.. Invention is credited to Kia Silverbrook, Simon Robert Walmsley.
Application Number | 20090058903 12/266479 |
Document ID | / |
Family ID | 32471018 |
Filed Date | 2009-03-05 |
United States Patent
Application |
20090058903 |
Kind Code |
A1 |
Walmsley; Simon Robert ; et
al. |
March 5, 2009 |
PRINTER CONTROLLER CONFIGURED TO COMPENSATE FOR DEAD PRINTHEAD
NOZZLES
Abstract
A printer controller for compensating for an inoperative nozzle
in a printhead is provided. The printhead includes a plurality of
nozzles associated with each pixel to be printed, the printer
controller being operative to control one or more operative nozzles
associated with the same pixel as the inoperative nozzle to
increase the amount of printing substance expelled by the one or
more operative nozzles.
Inventors: |
Walmsley; Simon Robert;
(Balmain, AU) ; Silverbrook; Kia; (Balmain,
AU) |
Correspondence
Address: |
SILVERBROOK RESEARCH PTY LTD
393 DARLING STREET
BALMAIN
2041
AU
|
Assignee: |
Silverbrook Research Pty
Ltd.
|
Family ID: |
32471018 |
Appl. No.: |
12/266479 |
Filed: |
November 6, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11442131 |
May 30, 2006 |
7465005 |
|
|
12266479 |
|
|
|
|
10727233 |
Dec 2, 2003 |
7165824 |
|
|
11442131 |
|
|
|
|
Current U.S.
Class: |
347/9 |
Current CPC
Class: |
B41J 2/0451 20130101;
B41J 2/04541 20130101; B41J 2/04508 20130101; G06F 21/64 20130101;
B41J 2/04573 20130101; G06F 21/73 20130101; H03K 5/1252 20130101;
G06F 21/71 20130101; B41J 2/04586 20130101; B41J 2/04563 20130101;
G06F 21/575 20130101; G06F 21/78 20130101; G06F 21/74 20130101;
Y10S 707/99939 20130101; B41J 2/04543 20130101; Y10S 707/99933
20130101; H04N 1/405 20130101; G06F 21/554 20130101; B41J 2202/20
20130101; G06F 21/57 20130101; B41J 2/04505 20130101; B41J 2/04528
20130101; Y10T 29/49401 20150115 |
Class at
Publication: |
347/9 |
International
Class: |
B41J 29/38 20060101
B41J029/38 |
Foreign Application Data
Date |
Code |
Application Number |
Dec 2, 2002 |
AU |
2002953134 |
Dec 2, 2002 |
AU |
2002953135 |
Claims
1. A printer controller for compensating for an inoperative nozzle
in a printhead, the printhead including a plurality of nozzles
associated with each pixel to be printed, the printer controller
being operative to control one or more operative nozzles associated
with the same pixel as the inoperative nozzle to increase the
amount of printing substance expelled by the one or more operative
nozzles.
2. A printer controller as claimed in claim 1, wherein the printer
controller compensates for the inoperative nozzle by increasing the
amount of printing substance expelled by one or more operative
nozzles expelling printing substance with a color substantially
similar to the color expelled by the inoperative nozzle.
3. A printer controller as claimed in claim 1, wherein there are
six nozzles associated with each pixel and the amount of printing
substance expelled by each nozzle is bi-level.
4. A printer controller as claimed in claim 1, wherein information
indicating inoperative nozzles is stored in a table.
5. A printer controller as claimed in claim 4, wherein the table is
updated by performing an inoperative nozzle test including the
steps of: running a printhead nozzle test sequence; converting
inoperative nozzle information into an inoperative nozzle table;
and, writing the inoperative nozzle table to a memory of the
printer controller.
6. A printer controller as claimed in claim 1, wherein the
inoperative nozzle is associated with a black print channel, and
wherein dot data intended for the inoperative nozzle is mapped into
a plurality of operative nozzles associated with the same pixel as
the inoperative nozzle in other color channels to produce a process
black output substantially at a location on print media where the
inoperative nozzle would have deposited a dot of a black printing
substance in accordance with the dot data.
7. A printer controller as claimed in claim 1, wherein the
increased amounts of printing substance expelled by the one or more
operative nozzles forms a pixel with a color substantially similar
to the color expelled by the inoperative nozzle.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation of U.S. Ser. No.
11/442,131 filed May 30, 2006, which is a continuation of U.S. Ser.
No. 10/727,233 filed Dec. 2, 2003, now issued U.S. Pat. No.
7,165,824, the entire contents of which are herein incorporated by
reference.
FIELD OF INVENTION
[0002] The present invention relates to the compensating a channel
in a printhead where one or more ink nozzles in the printhead are
dead.
[0003] The invention has primarily been developed for use with a
printhead comprising one or more printhead modules constructed
using microelectromechanical systems (MEMS) techniques, and will be
described with reference to this application. However, it will be
appreciated that the invention can be applied to other types of
printing technologies in which analogous problems are faced.
BACKGROUND OF INVENTION
[0004] Manufacturing a printhead that has relatively high
resolution and print-speed raises a number of problems.
Difficulties in manufacturing pagewidth printheads of any
substantial size arise due to the relatively small dimensions of
standard silicon wafers that are used in printhead (or printhead
module) manufacture. For example, if it is desired to make an 8
inch wide pagewidth printhead, only one such printhead can be laid
out on a standard 8-inch wafer, since such wafers are circular in
plan. Manufacturing a pagewidth printhead from two or more smaller
modules can reduce this limitation to some extent, but raises other
problems related to providing a joint between adjacent printhead
modules that is precise enough to avoid visible artefacts (which
would typically take the form of noticeable lines) when the
printhead is used. The problem is exacerbated in relatively
high-resolution applications because of the tight tolerances
dictated by the small spacing between nozzles.
[0005] The quality of a joint region between adjacent printhead
modules relies on factors including a precision with which the
abutting ends of each module can be manufactured, the accuracy with
which they can be aligned when assembled into a single printhead,
and other more practical factors such as management of ink channels
behind the nozzles. It will be appreciated that the difficulties
include relative vertical displacement of the printhead modules
with respect to each other.
[0006] Whilst some of these issues may be dealt with by careful
design and manufacture, the level of precision required renders it
relatively expensive to manufacture printheads within the required
tolerances. It would be desirable to provide a solution to one or
more of the problems associated with precision manufacture and
assembly of multiple printhead modules to form a printhead, and
especially a pagewidth printhead.
[0007] In some cases, it is desirable to produce a number of
different printhead module types or lengths on a substrate to
maximise usage of the substrate's surface area. However, different
sizes and types of modules will have different numbers and layouts
of print nozzles, potentially including different horizontal and
vertical offsets. Where two or more modules are to be joined to
form a single printhead, there is also the problem of dealing with
different seam shapes between abutting ends of joined modules,
which again may incorporate vertical or horizontal offsets between
the modules. Printhead controllers are usually dedicated
application specific integrated circuits (ASICs) designed for
specific use with a single type of printhead module, that is used
by itself rather than with other modules. It would be desirable to
provide a way in which different lengths and types of printhead
modules could be accounted for using a single printer
controller.
[0008] Printer controllers face other difficulties when two or more
printhead modules are involved, especially if it is desired to send
dot data to each of the printheads directly (rather than via a
single printhead connected to the controller). One concern is that
data delivered to different length controllers at the same rate
will cause the shorter of the modules to be ready for printing
before any longer modules. Where there is little difference
involved, the issue may not be of importance, but for large length
differences, the result is that the bandwidth of a shared memory
from which the dot data is supplied to the modules is effectively
left idle once one of the modules is full and the remaining module
or modules is still being filled. It would be desirable to provide
a way of improving memory bandwidth usage in a system comprising a
plurality of printhead modules of uneven length.
[0009] In any printing system that includes multiple nozzles on a
printhead or printhead module, there is the possibility of one or
more of the nozzles failing in the field, or being inoperative due
to manufacturing defect. Given the relatively large size of a
typical printhead module, it would be desirable to provide some
form of compensation for one or more "dead" nozzles. Where the
printhead also outputs fixative on a per-nozzle basis, it is also
desirable that the fixative is provided in such a way that dead
nozzles are compensated for.
[0010] A printer controller can take the form of an integrated
circuit, comprising a processor and one or more peripheral hardware
units for implementing specific data manipulation functions. A
number of these units and the processor may need access to a common
resource such as memory.
[0011] One way of arbitrating between multiple access requests for
a common resource is timeslot arbitration, in which access to the
resource is guaranteed to a particular requester during a
predetermined timeslot.
[0012] One difficulty with this arrangement lies in the fact that
not all access requests make the same demands on the resource in
terms of timing and latency. For example, a memory read requires
that data be fetched from memory, which may take a number of
cycles, whereas a memory write can commence immediately. Timeslot
arbitration does not take into account these differences, which may
result in accesses being performed in a less efficient manner than
might otherwise be the case. It would be desirable to provide a
timeslot arbitration scheme that improved this efficiency as
compared with prior art timeslot arbitration schemes.
[0013] Also of concern when allocating resources in a timeslot
arbitration scheme is the fact that the priority of an access
request may not be the same for all units. For example, it would be
desirable to provide a timeslot arbitration scheme in which one
requester (typically the memory) is granted special priority such
that its requests are dealt with earlier than would be the case in
the absence of such priority.
[0014] In systems that use a memory and cache, a cache miss (in
which an attempt to load data or an instruction from a cache fails)
results in a memory access followed by a cache update. It is often
desirable when updating the cache in this way to update data other
than that which was actually missed. A typical example would be a
cache miss for a byte resulting in an entire word or line of the
cache associated with that byte being updated. However, this can
have the effect of tying up bandwidth between the memory (or a
memory manager) and the processor where the bandwidth is such that
several cycles are required to transfer the entire word or line to
the cache. It would be desirable to provide a mechanism for
updating a cache that improved cache update speed and/or
efficiency.
[0015] Most integrated circuits an externally provided signal as
(or to generate) a clock, often provided from a dedicated clock
generation circuit. This is often due to the difficulties of
providing an onboard clock that can operate at a speed that is
predictable. Manufacturing tolerances of such on-board clock
generation circuitry can result in clock rates that vary by a
factor of two, and operating temperatures can increase this margin
by an additional factor of two. In some cases, the particular rate
at which the clock operates is not of particular concern. However,
where the integrated circuit will be writing to an internal circuit
that is sensitive to the time over which a signal is provided, it
may be undesirable to have the signal be applied for too long or
short a time. For example, flash memory is sensitive to being
written too for too long a period. It would be desirable to provide
a mechanism for adjusting a rate of an on-chip system clock to take
into account the impact of manufacturing variations on
clockspeed.
SUMMARY OF THE INVENTION
[0016] In a broad form, the present invention provides a printer
controller able to compensate for an inoperative nozzle in a
printhead, the printhead including a plurality of sets of nozzles
for printing a corresponding plurality of channels of dot data, the
printhead operated by the printer controller which is able to
determine one or more operative nozzles capable of printing a dot
on a print media near a position at which the inoperative nozzle
would have printed a dot had it been operative.
[0017] In a particular form, the printhead is segmented as a
bi-lithic printhead. In other particular forms: the printer
controller compensates for an inoperative nozzle in the printhead
by using color redundancy; the channels of dot data are mapped from
the inoperative nozzle to the determined one or more operative
nozzles; the channels of dot data are mapped from the inoperative
nozzle to a color plane of the determined one or more operative
nozzles; the mapping of the channels of dot data to the color plane
is programmable; there are six channels of dot data and the dot
data is bi-level dot data; the channels of dot data are loaded from
DRAM and are then passed to the printer controller via a FIFO
buffer; and/or information indicating inoperative nozzles is stored
in a table.
[0018] In another non-limiting embodiment, the table is updated by
performing an inoperative nozzle test including the steps of:
running a printhead nozzle test sequence; converting inoperative
nozzle information into an inoperative nozzle table; and, writing
the inoperative nozzle table to a memory of the printer
controller.
[0019] In another non-limiting embodiment, the printer controller
is additionally able to: (a) form a compressed bi-level layer for a
given print line intended for the bi-lithic printhead; (b) expand
the compressed bi-level layer; (c) composite the bi-level layer to
produce bi-level dots; (d) determine which combination of one or
more available operative nozzles near the inoperative nozzle
reduces perceived error in an image that the dot data forms part
of, the determination being performed on the basis of a color
model; (e) map the dot data intended for the inoperative nozzle to
the combination of one or more operative nozzles; and, (f) pass
resultant bi-level channel dot data to the bi-lithic printhead.
[0020] According to various other forms, the one or more operative
nozzles capable of printing a dot on the print media are
immediately adjacent the position at which the inoperative nozzle
would have printed a dot had it been operative; during successive
firings of the printhead, the dot data is remapped alternately to
operative nozzles capable of printing a dot on the print media
either side of that which would have been printed by the
inoperative nozzle; during successive firings of the printhead, the
dot data is remapped randomly, pseudo-randomly, or arbitrarily to
operative nozzles capable of printing a dot on the print media
either side of that which would have been printed by the
inoperative nozzle; the inoperative nozzle is associated with a
black print channel, and wherein the dot data intended for the
inoperative nozzle is mapped into a plurality of operative nozzles
in other color channels to produce a process black output at or
adjacent a location on print media where the inoperative nozzle
would have deposited a dot of a black printing substance in
accordance with the dot data.
BRIEF DESCRIPTION OF THE DRAWINGS
[0021] Preferred and other embodiments of the invention will now be
described, by way of example only, with reference to the
accompanying drawings, in which:
[0022] FIG. 1 shows document data flow in a printer;
[0023] FIG. 2 shows pages containing different numbers of
bands;
[0024] FIG. 3 shows the contents of a page band;
[0025] FIG. 4 illustrates a page data path from host to SoPEC;
[0026] FIG. 5 shows a page structure;
[0027] FIG. 6 shows a SoPEC system top level partition;
[0028] FIG. 7 shows a SoPEC CPU memory map (not to scale);
[0029] FIG. 8 shows a SoPEC system top level partition;
[0030] FIG. 9 shows an outline of contone data flow with respect to
CDU;
[0031] FIG. 10 shows a DRAM storage arrangement for a single line
of JPEG 8.times.8 blocks in 4 colors;
[0032] FIG. 11 shows a high level block diagram showing the HCU and
its external interfaces;
[0033] FIG. 12 shows a block diagram of the HCU;
[0034] FIG. 13 shows a block diagram of the control unit;
[0035] FIG. 14 shows a block diagram of determine advdot unit;
[0036] FIG. 15 shows a page structure;
[0037] FIG. 16 shows a block diagram of a margin unit;
[0038] FIG. 17 shows a block diagram of a dither matrix table
interface;
[0039] FIG. 18 shows an example of reading lines of dither matrix
from DRAM;
[0040] FIG. 19 shows a state machine to read dither matrix
table;
[0041] FIG. 20 shows a contone dotgen unit;
[0042] FIG. 21 shows a block diagram of dot reorg unit;
[0043] FIG. 22 shows an HCU to DNC interface (also used in DNC to
DWU, LLU to PHI);
[0044] FIG. 23 shows SFU to HCU interface (all feeders to HCU);
[0045] FIG. 24 shows representative logic of the SFU to HCU
interface;
[0046] FIG. 25 shows a high-level block diagram of DNC;
[0047] FIG. 26 shows a dead nozzle table format;
[0048] FIG. 27 shows set of dots operated on for error
diffusion;
[0049] FIG. 28 shows a block diagram of DNC;
[0050] FIG. 29 shows a sub-block diagram of ink replacement
unit;
[0051] FIG. 30 shows a dead nozzle table state machine;
[0052] FIG. 31 shows logic for dead nozzle removal and ink
replacement;
[0053] FIG. 32 shows a sub-block diagram of error diffusion
unit;
[0054] FIG. 33 shows a maximum length 32-bit LFSR used for random
bit generation;
[0055] FIG. 34 shows a high-level data flow diagram of DWU in
context;
[0056] FIG. 35 shows a printhead nozzle layout for 36-nozzle
bi-lithic printhead;
[0057] FIG. 36 shows a printhead nozzle layout for a 36-nozzle
bi-lithic printhead;
[0058] FIG. 37 shows a dot line store logical representation;
[0059] FIG. 38 shows a conceptual view of printhead row
alignment;
[0060] FIG. 39 shows a conceptual view of printhead rows (as seen
by the LLU and PHI);
[0061] FIG. 40 shows a comparison of 1.5.times. v 2.times.
buffering;
[0062] FIG. 41 shows an even dot order in DRAM (increasing sense,
13320 dot wide line);
[0063] FIG. 42 shows an even dot order in DRAM (decreasing sense,
13320 dot wide line);
[0064] FIG. 43 shows a dotline FIFO data structure in DRAM;
[0065] FIG. 44 shows a DWU partition;
[0066] FIG. 45 shows a buffer address generator sub-block;
[0067] FIG. 46 shows a DIU Interface sub-block;
[0068] FIG. 47 shows an interface controller state diagram;
[0069] FIG. 48 shows a high level data flow diagram of LLU in
context;
[0070] FIG. 49 shows paper and printhead nozzles relationship
(example with D.sub.1=D.sub.2=5);
[0071] FIG. 50 shows printhead structure and dot generate
order;
[0072] FIG. 51 shows an order of dot data generation and
transmission;
[0073] FIG. 52 shows a conceptual view of printhead rows;
[0074] FIG. 53 shows a dotline FIFO data structure in DRAM (LLU
specification);
[0075] FIG. 54 shows an LLU partition;
[0076] FIG. 55 shows a dot generator RTL diagram;
[0077] FIG. 56 shows a DIU interface;
[0078] FIG. 57 shows an interface controller state diagram; and
[0079] FIG. 58 shows high-level data flow diagram of PHI in
context.
DETAILED DESCRIPTION OF PREFERRED AND OTHER EMBODIMENTS
[0080] Imperative phrases such as "must", "requires", "necessary"
and "important" (and similar language) should be read as being
indicative of being necessary only for the preferred embodiment
actually being described. As such, unless the opposite is clear
from the context, imperative wording should not be interpreted as
such. Nothing in the detailed description is to be understood as
limiting the scope of the invention, which is intended to be
defined as widely as is defined in the accompanying claims.
[0081] Indications of expected rates, frequencies, costs, and other
quantitative values are exemplary and estimated only, and are made
in good faith. Nothing in this specification should be read as
implying that a particular commercial embodiment is or will be
capable of a particular performance level in any measurable
area.
[0082] It will be appreciated that the principles, methods and
hardware described throughout this document can be applied to other
fields. Much of the security-related disclosure, for example, can
be applied to many other fields that require secure communications
between entities, and certainly has application far beyond the
field of printers.
[0083] The preferred of the present invention is implemented in a
printer using microelectromechanical systems (MEMS) printheads. The
printer can receive data from, for example, a personal computer
such as an IBM compatible PC or Apple computer. In other
embodiments, the printer can receive data directly from, for
example, a digital still or video camera. The particular choice of
communication link is not important, and can be based, for example,
on USB, Firewire, Bluetooth or any other wireless or hardwired
communications protocol.
Print System Overview
[0084] This document describes the SoPEC (Small office home office
Print Engine Controller) ASIC (Application Specific Integrated
Circuit) suitable for use in, for example, SoHo printer products.
The SoPEC ASIC is intended to be a low cost solution for bi-lithic
printhead control, replacing the multichip solutions in larger more
professional systems with a single chip. The increased cost
competitiveness is achieved by integrating several systems such as
a modified PEC1 printing pipeline, CPU control system, peripherals
and memory sub-system onto one SoC ASIC, reducing component count
and simplifying board design.
Bi-Lithic Printhead Notation
[0085] A bi-lithic based printhead is constructed from 2 printhead
ICs of varying sizes. The notation M:N is used to express the size
relationship of each IC, where M specifies one printhead IC in
inches and N specifies the remaining printhead IC in inches.
DEFINITIONS
[0086] The following terms are used throughout this specification:
Bi-lithic printhead: refers to printhead constructed from 2
printhead ICs; CPU: refers to CPU core, caching system and MMU;
ISI-Bridge chip: a device with a high speed interface (such as
USB2.0, Ethernet or IEEE1394) and one or more ISI interfaces. The
ISI-Bridge would be the ISIMaster for each of the ISI buses it
interfaces to; ISIMaster: the ISIMaster is the only device allowed
to initiate communication on the Inter Sopec Interface (ISI) bus.
The ISIMaster interfaces with the host; ISISlave. Multi-SoPEC
systems will contain one or more ISISlave SoPECs connected to the
ISI bus. ISISlaves can only respond to communication initiated by
the ISIMaster; LEON: refers to the LEON CPU core; LineSyncMaster:
the LineSyncMaster device generates the line synchronisation pulse
that all SoPECs in the system must synchronise their line outputs
to; Multi-SoPEC: refers to SoPEC based print system with multiple
SoPEC devices; Netpage: refers to page printed with tags (normally
in infrared ink); PEC1: refers to Print Engine Controller version
1, precursor to SoPEC used to control printheads constructed from
multiple angled printhead segments; Printhead IC: single MEMS IC
used to construct bi-lithic printhead; PrintMaster: the PrintMaster
device is responsible for coordinating all aspects of the print
operation. There may only be one PrintMaster in a system; QA Chip:
Quality Assurance Chip; Storage SoPEC: an ISISlave SoPEC used as a
DRAM store and which does not print; and Tag: refers to pattern
which encodes information about its position and orientation which
allow it to be optically located and its data contents read.
Acronyms and Abbreviations
[0087] The following acronyms and abbreviations are used in this
specification: CDU Contone Decoder Unit; CFU Contone FIFO Unit; CPU
Central Processing Unit; CPR Clock, Power and Reset block; DIU DRAM
Interface Unit; DNC Dead Nozzle Compensator; DRAM Dynamic Random
Access Memory; DWU Dotline Writer Unit; GPIO General Purpose Input
Output; HCU Halftoner Compositor Unit; ICU Interrupt Controller
Unit; ISI Inter SoPEC Interface; LDB Lossless Bi-level Decoder; LLU
Line Loader Unit; LSS Low Speed Serial interface; MEMS Micro
Electro Mechanical System; MMU Memory Management Unit; PCU SoPEC
Controller Unit/PEP controller; PHI PrintHead Interface; PSS Power
Save Storage Unit; RDU Real-time Debug Unit; ROM Read Only
Memory/Boot ROM; SCB Serial Communication Block; SFU Spot FIFO
Unit; SMG4 Silverbrook Modified Group 4; SoPEC Small office home
office Print Engine Controller; SRAM Static Random Access Memory;
TE Tag Encoder; TFU Tag FIFO Unit; TIM Timers Unit/General Timer;
and USB Universal Serial Bus.
Printing Considerations
[0088] A bi-lithic printhead produces 1600 dpi bi-level dots. On
low-diffusion paper, each ejected drop forms a 22.5 .mu.m diameter
dot. Dots are easily produced in isolation, allowing dispersed-dot
dithering to be exploited to its fullest. Since the bi-lithic
printhead is the width of the page and operates with a constant
paper velocity, color planes are printed in perfect registration,
allowing ideal dot-on-dot printing. Dot-on-dot printing minimizes
`muddying` of midtones caused by inter-color bleed.
[0089] A page layout may contain a mixture of images, graphics and
text. Continuous-tone (contone) images and graphics are reproduced
using a stochastic dispersed-dot dither. Unlike a clustered-dot (or
amplitude-modulated) dither, a dispersed-dot (or
frequency-modulated) dither reproduces high spatial frequencies
(i.e. image detail) almost to the limits of the dot resolution,
while simultaneously reproducing lower spatial frequencies to their
full color depth, when spatially integrated by the eye. A
stochastic dither matrix is carefully designed to be free of
objectionable low-frequency patterns when tiled across the image.
As such its size typically exceeds the minimum size required to
support a particular number of intensity levels (e.g.
16.times.16.times.8 bits for 257 intensity levels).
[0090] Human contrast sensitivity peaks at a spatial frequency of
about 3 cycles per degree of visual field and then falls off
logarithmically, decreasing by a factor of 100 beyond about 40
cycles per degree and becoming immeasurable beyond 60 cycles per
degree. At a normal viewing distance of 12 inches (about 300 mm),
this translates roughly to 200-300 cycles per inch (cpi) on the
printed page, or 400-600 samples per inch according to Nyquist's
theorem.
[0091] In practice, contone resolution above about 300 ppi is of
limited utility outside special applications such as medical
imaging. Offset printing of magazines, for example, uses contone
resolutions in the range 150 to 300 ppi. Higher resolutions
contribute slightly to color error through the dither.
[0092] Black text and graphics are reproduced directly using
bi-level black dots, and are therefore not anti-aliased (i.e.
low-pass filtered) before being printed. Text should therefore be
supersampled beyond the perceptual limits discussed above, to
produce smoother edges when spatially integrated by the eye. Text
resolution up to about 1200 dpi continues to contribute to
perceived text sharpness (assuming low-diffusion paper, of
course).
[0093] A Netpage printer, for example, may use a contone resolution
of 267 ppi (i.e. 1600 dp 6), and a black text and graphics
resolution of 800 dpi. A high end office or departmental printer
may use a contone resolution of 320 ppi (1600 dpi/5) and a black
text and graphics resolution of 1600 dpi. Both formats are capable
of exceeding the quality of commercial (offset) printing and
photographic reproduction.
Document Data Flow
[0094] Because of the page-width nature of the bi-lithic printhead,
each page must be printed at a constant speed to avoid creating
visible artifacts. This means that the printing speed can't be
varied to match the input data rate. Document rasterization and
document printing are therefore decoupled to ensure the printhead
has a constant supply of data. A page is never printed until it is
fully rasterized. This can be achieved by storing a compressed
version of each rasterized page image in memory.
[0095] This decoupling also allows the RIP(s) to run ahead of the
printer when rasterizing simple pages, buying time to rasterize
more complex pages. Because contone color images are reproduced by
stochastic dithering, but black text and line graphics are
reproduced directly using dots, the compressed page image format
contains a separate foreground bi-level black layer and background
contone color layer. The black layer is composited over the contone
layer after the contone layer is dithered (although the contone
layer has an optional black component). A final layer of Netpage
tags (in infrared or black ink) is optionally added to the page for
printout. FIG. 1 shows the flow of a document from computer system
to printed page.
[0096] At 267 ppi for example, a A4 page (8.26 inches.times.11.7
inches) of contone CMYK data has a size of 26.3 MB. At 320 ppi, an
A4 page of contone data has a size of 37.8 MB. Using lossy contone
compression algorithms such as JPEG, contone images compress with a
ratio up to 10:1 without noticeable loss of quality, giving
compressed page sizes of 2.63 MB at 267 ppi and 3.78 MB at 320
ppi.
[0097] At 800 dpi, a A4 page of bi-level data has a size of 7.4 MB.
At 1600 dpi, a Letter page of bi-level data has a size of 29.5 MB.
Coherent data such as text compresses very well. Using lossless
bi-level compression algorithms such as SMG4 fax, ten-point plain
text compresses with a ratio of about 50:1. Lossless bi-level
compression across an average page is about 20:1 with 10:1 possible
for pages which compress poorly. The requirement for SoPEC is to be
able to print text at 10:1 compression. Assuming 10:1 compression
gives compressed page sizes of 0.74 MB at 800 dpi, and 2.95 MB at
1600 dpi. Once dithered, a page of CMYK contone image data consists
of 116 MB of bi-level data. Using lossless bi-level compression
algorithms on this data is pointless precisely because the optimal
dither is stochastic, since it introduces hard-to-compress
disorder.
[0098] Netpage tag data is optionally supplied with the page image.
Rather than storing a compressed bi-level data layer for the
Netpage tags, the tag data is stored in its raw form. Each tag is
supplied up to 120 bits of raw variable data (combined with up to
56 bits of raw fixed data) and covers up to a 6 mm.times.6 mm area
(at 1600 dpi). The absolute maximum number of tags on a A4 page is
15,540 when the tag is only 2 mm.times.2 mm (each tag is 126
dots.times.126 dots, for a total coverage of 148 tags.times.105
tags). 15,540 tags of 128 bits per tag gives a compressed tag page
size of 0.24 MB. The multi-layer compressed page image format
therefore exploits the relative strengths of lossy JPEG contone
image compression, lossless bi-level text compression, and tag
encoding. The format is compact enough to be storage-efficient, and
simple enough to allow straightforward real-time expansion during
printing.
[0099] Since text and images normally don't overlap, the normal
worst-case page image size is image only, while the normal
best-case page image size is text only. The addition of worst case
Netpage tags adds 0.24 MB to the page image size. The worst-case
page image size is text over image plus tags. The average page size
assumes a quarter of an average page contains images. Table 1 shows
data sizes for compressed Letter page for these different
options.
TABLE-US-00001 TABLE 1 Data sizes for A4 page (8.26 inches .times.
11.7 inches) 267 ppi contone 320 ppi contone 800 dpi bi-level 1600
dpi bi-level Image only (contone), 2.63 MB 3.78 MB 10:1 compression
Text only (bi-level), 0.74 MB 2.95 MB 10:1 compression Netpage
tags, 1600 dpi 0.24 MB 0.24 MB Worst case (text + 3.61 MB 6.67 MB
image + tags) Average (text + 25% 1.64 MB 4.25 MB image + tags)
Document Data Flow
[0100] The Host PC rasterizes and compresses the incoming document
on a page by page basis. The page is restructured into bands with
one or more bands used to construct a page. The compressed data is
then transferred to the SoPEC device via the USB link. A complete
band is stored in SoPEC embedded memory. Once the band transfer is
complete the SoPEC device reads the compressed data, expands the
band, normalizes contone, bi-level and tag data to 1600 dpi and
transfers the resultant calculated dots to the bi-lithic printhead.
The document data flow is: [0101] The RIP software rasterizes each
page description and compress the rasterized page image. [0102] The
infrared layer of the printed page optionally contains encoded
Netpage tags at a programmable density. [0103] The compressed page
image is transferred to the SoPEC device via the USB normally on a
band by band basis. [0104] The print engine takes the compressed
page image and starts the page expansion. [0105] The first stage
page expansion consists of 3 operations performed in parallel
[0106] expansion of the JPEG-compressed contone layer [0107]
expansion of the SMG4 fax compressed bi-level layer [0108] encoding
and rendering of the bi-level tag data. [0109] The second stage
dithers the contone layer using a programmable dither matrix,
producing up to four bi-level layers at full-resolution. [0110] The
second stage then composites the bi-level tag data layer, the
bi-level SMG4 fax de-compressed layer and up to four bi-level JPEG
de-compressed layers into the full-resolution page image. [0111] A
fixative layer is also generated as required. [0112] The last stage
formats and prints the bi-level data through the bi-lithic
printhead via the printhead interface.
[0113] The SoPEC device can print a full resolution page with 6
color planes. Each of the color planes can be generated from
compressed data through any channel (either JPEG compressed,
bi-level SMG4 fax compressed, tag data generated, or fixative
channel created) with a maximum number of 6 data channels from page
RIP to bi-lithic printhead color planes.
[0114] The mapping of data channels to color planes is
programmable, this allows for multiple color planes in the
printhead to map to the same data channel to provide for redundancy
in the printhead to assist dead nozzle compensation.
[0115] Also a data channel could be used to gate data from another
data channel. For example in stencil mode, data from the bilevel
data channel at 1600 dpi can be used to filter the contone data
channel at 320 dpi, giving the effect of 1600 dpi contone
image.
Page Considerations Due to SoPEC
[0116] The SoPEC device typically stores a complete page of
document data on chip. The amount of storage available for
compressed pages is limited to 2 Mbytes, imposing a fixed maximum
on compressed page size. A comparison of the compressed image sizes
in Table 2 indicates that SoPEC would not be capable of printing
worst case pages unless they are split into bands and printing
commences before all the bands for the page have been downloaded.
The page sizes in the table are shown for comparison purposes and
would be considered reasonable for a professional level printing
system. The SoPEC device is aimed at the consumer level and would
not be required to print pages of that complexity. Target document
types for the SoPEC device are shown Table 2.
TABLE-US-00002 TABLE 2 Page content targets for SoPEC Page Content
Size Description Calculation (MByte) Best Case picture 8.26 .times.
11.7 .times. 267 .times. 267 .times. 3 1.97 Image, 267 ppi with 3 @
10:1 colors, A4 size Full page text, 800 8.26 .times. 11.7 .times.
800 .times. 800 @ 0.74 dpi A4 size 10:1 Mixed Graphics and Text 6
.times. 4 .times. 267 .times. 267 .times. 3 @ 5:1 1.55 Image of 6
inches .times. 4 800 .times. 800 .times. 73 @ 10:1 inches @ 267 ppi
and 3 colors Remaining area text ~73 inches.sup.2, 800 dpi Best
Case Photo, 3 Colors, 6.6 Mpixel @ 10:1 2.00 6.6 Megapixel
Image
[0117] If a document with more complex pages is required, the page
RIP software in the host PC can determine that there is
insufficient memory storage in the SoPEC for that document. In such
cases the RIP software can take two courses of action. It can
increase the compression ratio until the compressed page size will
fit in the SoPEC device, at the expense of document quality, or
divide the page into bands and allow SoPEC to begin printing a page
band before all bands for that page are downloaded. Once SoPEC
starts printing a page it cannot stop, if SoPEC consumes compressed
data faster than the bands can be downloaded a buffer underrun
error could occur causing the print to fail. A buffer underrun
occurs if a line synchronisation pulse is received before a line of
data has been transferred to the printhead.
[0118] Other options which can be considered if the page does not
fit completely into the compressed page store are to slow the
printing or to use multiple SoPECs to print parts of the page. A
Storage SoPEC could be added to the system to provide guaranteed
bandwidth data delivery. The print system could also be constructed
using an ISI-Bridge chip to provide guaranteed data delivery.
Memjet Printer Architecture
[0119] The SoPEC device can be used in several printer
configurations and architectures.
In the general sense every SoPEC based printer architecture will
contain: [0120] One or more SoPEC devices. [0121] One or more
bi-lithic printheads. [0122] Two or more LSS busses. [0123] Two or
more QA chips. [0124] USB 1.1 connection to host or ISI connection
to Bridge Chip. [0125] ISI bus connection between SoPECs (when
multiple SoPECs are used).
System Components
SoPEC Print Engine Controller
[0126] The SoPEC device contains several system on a chip (SoC)
components, as well as the print engine pipeline control
application specific logic.
Print Engine Pipeline (PEP) Logic
[0127] The PEP reads compressed page store data from the embedded
memory, optionally decompresses the data and formats it for sending
to the printhead. The print engine pipeline functionality includes
expanding the page image, dithering the contone layer, compositing
the black layer over the contone layer, rendering of Netpage tags,
compensation for dead nozzles in the printhead, and sending the
resultant image to the bi-lithic printhead.
Embedded CPU
[0128] SoPEC contains an embedded CPU for general purpose system
configuration and management. The CPU performs page and band header
processing, motor control and sensor monitoring (via the GPIO) and
other system control functions. The CPU can perform buffer
management or report buffer status to the host. The CPU can
optionally run vendor application specific code for general print
control such as paper ready monitoring and LED status update.
Embedded Memory Buffer
[0129] A 2.5 Mbyte embedded memory buffer is integrated onto the
SoPEC device, of which approximately 2 Mbytes are available for
compressed page store data. A compressed page is divided into one
or more bands, with a number of bands stored in memory. As a band
of the page is consumed by the PEP for printing a new band can be
downloaded. The new band may be for the current page or the next
page.
[0130] Using banding it is possible to begin printing a page before
the complete compressed page is downloaded, but care must be taken
to ensure that data is always available for printing or a buffer
underrun may occur. A Storage SoPEC acting as a memory buffer or an
ISI-Bridge chip with attached DRAM could be used to provide
guaranteed data delivery.
Embedded USB 1.1 Device
[0131] The embedded USB 1.1 device accepts compressed page data and
control commands from the host PC, and facilitates the data
transfer to either embedded memory or to another SoPEC device in
multi-SoPEC systems.
Bi-Lithic Printhead
[0132] The printhead is constructed by abutting 2 printhead ICs
together. The printhead ICs can vary in size from 2 inches to 8
inches, so to produce an A4 printhead several combinations are
possible. For example two printhead ICs of 7 inches and 3 inches
could be used to create a A4 printhead (the notation is 7:3).
Similarly 6 and 4 combination (6:4), or 5:5 combination. For an A3
printhead it can be constructed from 8:6 or an 7:7 printhead IC
combination. For photographic printing smaller printheads can be
constructed.
LSS Interface Bus
[0133] Each SoPEC device has 2 LSS system buses for communication
with QA devices for system authentication and ink usage accounting.
The number of QA devices per bus and their position in the system
is unrestricted with the exception that PRINTER_QA and INK_QA
devices should be on separate LSS busses.
QA Devices
[0134] Each SoPEC system can have several QA devices. Normally each
printing SoPEC will have an associated PRINTER_QA. Ink cartridges
will contain an INK_QA chip. PRINTER_QA and INK_QA devices should
be on separate LSS busses. All QA chips in the system are
physically identical with flash memory contents defining PRINTER_QA
from INK_QA chip.
ISI interface
[0135] The Inter-SoPEC Interface (ISI) provides a communication
channel between SoPECs in a multi-SoPEC system. The ISIMaster can
be SoPEC device or an ISI-Bridge chip depending on the printer
configuration. Both compressed data and control commands are
transferred via the interface.
ISI-Bridge Chip
[0136] A device, other than a SoPEC with a USB connection, which
provides print data to a number of slave SoPECs. A bridge chip will
typically have a high bandwidth connection, such as USB2.0,
Ethernet or IEEE1394, to a host and may have an attached external
DRAM for compressed page storage. A bridge chip would have one or
more ISI interfaces. The use of multiple ISI buses would allow the
construction of independent print systems within the one printer.
The ISI-Bridge would be the ISIMaster for each of the ISI buses it
interfaces to.
Page Format and Printflow
[0137] When rendering a page, the RIP produces a page header and a
number of bands (a non-blank page requires at least one band) for a
page. The page header contains high level rendering parameters, and
each band contains compressed page data. The size of the band will
depend on the memory available to the RIP, the speed of the RIP,
and the amount of memory remaining in SoPEC while printing the
previous band(s). FIG. 3 shows the high level data structure of a
number of pages with different numbers of bands in the page.
[0138] Each compressed band contains a mandatory band header, an
optional bi-level plane, optional sets of interleaved contone
planes, and an optional tag data plane (for Netpage enabled
applications). Since each of these planes is optional, the band
header specifies which planes are included with the band. FIG. 4
gives a high-level breakdown of the contents of a page band. A
single SoPEC has maximum rendering restrictions as follows: [0139]
1 bi-level plane [0140] 1 contone interleaved plane set containing
a maximum of 4 contone planes [0141] 1 tag data plane [0142] a
bi-lithic printhead with a maximum of 2 printhead ICs [0143] The
requirement for single-sided A4 single SoPEC printing is [0144]
average contone JPEG compression ratio of 10:1, with a local
minimum compression ratio of 5:1 for a single line of interleaved
JPEG blocks. [0145] average bi-level compression ratio of 10:1,
with a local minimum compression ratio of 1:1 for a single
line.
[0146] If the page contains rendering parameters that exceed these
specifications, then the RIP or the Host PC must split the page
into a format that can be handled by a single SoPEC. In the general
case, the SoPEC CPU must analyze the page and band headers and
generate an appropriate set of register write commands to configure
the units in SoPEC for that page. The various bands are passed to
the destination SoPEC(s) to locations in DRAM determined by the
host.
[0147] The host keeps a memory map for the DRAM, and ensures that
as a band is passed to a SoPEC, it is stored in a suitable free
area in DRAM. Each SoPEC is connected to the ISI bus or USB bus via
its Serial communication Block (SCB). The SoPEC CPU configures the
SCB to allow compressed data bands to pass from the USB or ISI
through the SCB to SoPEC DRAM. FIG. 5 shows an example data flow
for a page destined to be printed by a single SoPEC. Band usage
information is generated by the individual SoPECs and passed back
to the host.
[0148] SoPEC has an addressing mechanism that permits circular band
memory allocation, thus facilitating easy memory management.
However it is not strictly necessary that all bands be stored
together. As long as the appropriate registers in SoPEC are set up
for each band, and a given band is contiguous, the memory can be
allocated in any way.
Print Engine Example Page Format
[0149] The format is generated by software in the host PC and
interpreted by embedded software in SoPEC. This section indicates
the type of information in a page format structure, but
implementations need not be limited to this format. The host PC can
optionally perform the majority of the header processing.
[0150] The compressed format and the print engines are designed to
allow real-time page expansion during printing, to ensure that
printing is never interrupted in the middle of a page due to data
underrun.
[0151] The page format described here is for a single black
bi-level layer, a contone layer, and a Netpage tag layer. The black
bi-level layer is defined to composite over the contone layer. The
black bi-level layer consists of a bitmap containing a 1-bit
opacity for each pixel. This black layer matte has a resolution
which is an integer or non-integer factor of the printer's dot
resolution. The highest supported resolution is 1600 dpi, i.e. the
printer's full dot resolution.
[0152] The contone layer, optionally passed in as YCrCb, consists
of a 24-bit CMY or 32-bit CMYK color for each pixel. This contone
image has a resolution which is an integer or non-integer factor of
the printer's dot resolution. The requirement for a single SoPEC is
to support 1 side per 2 seconds A4/Letter printing at a resolution
of 267 ppi, i.e. one-sixth the printer's dot resolution.
Non-integer scaling can be performed on both the contone and
bi-level images. Only integer scaling can be performed on the tag
data. The black bi-level layer and the contone layer are both in
compressed form for efficient storage in the printer's internal
memory.
Page Structure
[0153] A single SoPEC is able to print with full edge bleed for
Letter and A3 via different stitch part combinations of the
bi-lithic printhead. It imposes no margins and so has a printable
page area which corresponds to the size of its paper. The target
page size is constrained by the printable page area, less the
explicit (target) left and top margins specified in the page
description. These relationships are illustrated below.
Compressed Page Format
[0154] Apart from being implicitly defined in relation to the
printable page area, each page description is complete and
self-contained. There is no data stored separately from the page
description to which the page description refers..sup.1 The page
description consists of a page header which describes the size and
resolution of the page, followed by one or more page bands which
describe the actual page content. .sup.1SoPEC relies on dither
matrices and tag structures to have already been set up, but these
are not considered to be part of a general page format. It is
trivial to extend the page format to allow exact specification of
dither matrices and tag structures.
Page Header
[0155] Table 3 shows an example format of a page header.
TABLE-US-00003 TABLE 3 Page header format Field Format Description
signature 16-bit Page header format signature. integer Version
16-bit Page header format version number. integer structure size
16-bit Size of page header. integer band count 16-bit Number of
bands specified for this page. integer target resolution 16-bit
Resolution of target page. This is always 1600 for the (dpi)
integer Memjet printer. target page width 16-bit Width of target
page, in dots. integer target page height 32-bit Height of target
page, in dots. integer target left margin 16-bit Width of target
left margin, in dots, for black and for black and integer contone.
contone target top margin for 16-bit Height of target top margin,
in dots, for black and black and contone integer contone. target
right margin 16-bit Width of target right margin, in dots, for
black and for black and integer contone. contone Target bottom
16-bit Height of target bottom margin, in dots, for black and
margin for black integer contone. and contone target left margin
16-bit Width of target left margin, in dots, for tags. for tags
integer target top margin for 16-bit Height of target top margin,
in dots, for tags. tags integer target right margin 16-bit Width of
target right margin, in dots, for tags. for tags integer target
bottom 16-bit Height of target bottom margin, in dots, for tags.
margin for tags integer Generate tags 16-bit Specifies whether to
generate tags for this page (0 - integer no, 1 - yes). fixed tag
data 128 bit This is only valid if generate tags is set. integer
tag vertical scale 16-bit Scale factor in vertical direction from
tag data factor integer resolution to target resolution. Valid
range = 1-511. Integer scaling only tag horizontal scale 16-bit
Scale factor in horizontal direction from tag data factor integer
resolution to target resolution. Valid range = 1-511. Integer
scaling only. bi-level layer 16-bit Scale factor in vertical
direction from bi-level vertical scale factor integer resolution to
target resolution (must be 1 or greater). May be non-integer.
Expressed as a fraction with upper 8-bits the numerator and the
lower 8 bits the denominator. bi-level layer 16-bit Scale factor in
horizontal direction from bi-level horizontal scale factor integer
resolution to target resolution (must be 1 or greater). May be
non-integer. Expressed as a fraction with upper 8-bits the
numerator and the lower 8 bits the denominator. bi-level layer page
16-bit Width of bi-level layer page, in pixels. width integer
bi-level layer page 32-bit Height of bi-level layer page, in
pixels. height integer contone flags 16 bit Defines the color
conversion that is required for the integer JPEG data. Bits 2-0
specify how many contone planes there are (e.g. 3 for CMY and 4 for
CMYK). Bit 3 specifies whether the first 3 color planes need to be
converted back from YCrCb to CMY. Only valid if b2-0 = 3 or 4; 0 -
no conversion, leave JPEG colors alone; 1 - color convert. Bits 7-4
specifies whether the YCrCb was generated directly from CMY, or
whether it was converted to RGB first via the step: R = 255-C, G =
255-M, B = 255-Y. Each of the color planes can be individually
inverted. Bit 4: 0 - do not invert color plane 0; 1 - invert color
plane 0. Bit 5: 0 - do not invert color plane 1; 1 - invert color
plane 1. Bit 6: 0 - do not invert color plane 2; 1 - invert color
plane 2. Bit 7: 0 - do not invert color plane 3; 1 - invert color
plane 3. Bit 8 specifies whether the contone data is JPEG
compressed or non-compressed: 0 - JPEG compressed; 1 -
non-compressed. The remaining bits are reserved (0). Contone
vertical 16-bit Scale factor in vertical direction from contone
channel scale factor integer resolution to target resolution. Valid
range = 1-255. May be non-integer. Expressed as a fraction with
upper 8-bits the numerator and the lower 8 bits the denominator.
Contone horizontal 16-bit Scale factor in horizontal direction from
contone scale factor integer channel resolution to target
resolution. Valid range = 1-255. May be non-integer. Expressed as a
fraction with upper 8-bits the numerator and the lower 8 bits the
denominator. Contone page width 16-bit Width of contone page, in
contone pixels. integer Contone page height 32-bit Height of
contone page, in contone pixels. integer Reserved up to 128
Reserved and 0 pads out page header to multiple of bytes 128
bytes.
[0156] The page header contains a signature and version which allow
the CPU to identify the page header format. If the signature and/or
version are missing or incompatible with the CPU, then the CPU can
reject the page.
[0157] The contone flags define how many contone layers are
present, which typically is used for defining whether the contone
layer is CMY or CMYK. Additionally, if the color planes are CMY,
they can be optionally stored as YCrCb, and further optionally
color space converted from CMY directly or via RGB. Finally the
contone data is specified as being either JPEG compressed or
non-compressed.
[0158] The page header defines the resolution and size of the
target page. The bi-level and contone layers are clipped to the
target page if necessary. This happens whenever the bi-level or
contone scale factors are not factors of the target page width or
height.
[0159] The target left, top, right and bottom margins define the
positioning of the target page within the printable page area. The
tag parameters specify whether or not Netpage tags should be
produced for this page and what orientation the tags should be
produced at (landscape or portrait mode). The fixed tag data is
also provided. The contone, bi-level and tag layer parameters
define the page size and the scale factors.
Band Format
[0160] Table 4 shows the format of the page band header.
TABLE-US-00004 TABLE 4 Band header format Field Format Description
7signature 16-bit integer Page band header format signature.
Version 16-bit integer Page band header format version number.
structure size 16-bit integer Size of page band header. bi-level
layer band height 16-bit integer Height of bi-level layer band, in
black pixels. bi-level layer band data 32-bit integer Size of
bi-level layer band data, in bytes. size Contone band height 16-bit
integer Height of contone band, in contone pixels. Contone band
data size 32-bit integer Size of contone plane band data, in bytes.
tag band height 16-bit integer Height of tag band, in dots. tag
band data size 32-bit integer Size of unencoded tag data band, in
bytes. Can be 0 which indicates that no tag data is provided.
Reserved up to 128 Reserved and 0 pads out band header to bytes
multiple of 128 bytes.
[0161] The bi-level layer parameters define the height of the black
band, and the size of its compressed band data. The variable-size
black data follows the page band header. The contone layer
parameters define the height of the contone band, and the size of
its compressed page data. The variable-size contone data follows
the black data. The tag band data is the set of variable tag data
half-lines as required by the tag encoder. The format of the tag
data is found in. The tag band data follows the contone data. Table
5 shows the format of the variable-size compressed band data which
follows the page band header.
TABLE-US-00005 TABLE 5 Page band data format Field Format
Description Black data Modified G4 facsimile Compressed bi-level
layer. bitstream Contone JPEG bytestream Compressed contone
datalayer. data Tag data Tag data array Tag data format. map
[0162] The start of each variable-size segment of band data should
be aligned to a 256-bit DRAM word boundary.
Bi-Level Data Compression
[0163] The (typically 1600 dpi) black bi-level layer is losslessly
compressed using Silverbrook Modified Group 4 (SMG4) compression
which is a version of Group 4 Facsimile compression without Huffman
and with simplified run length encodings. Typically compression
ratios exceed 10:1.
[0164] SMG4 has a pass through mode to cope with local negative
compression. Pass through mode is activated by a special run-length
code. Pass through mode continues to either end of line or for a
pre-programmed number of bits, whichever is shorter. The special
run-length code is always executed as a run-length code, followed
by pass through. The pass through escape code is a medium length
run-length w. Since the compression is a bitstream, the encodings
are read right (least significant bit) to left (most significant
bit). The run lengths are read in the same way (least significant
bit at the right to most significant bit at the left).
[0165] Each band of bi-level data is optionally self contained. The
first line of each band therefore is based on a `previous` blank
line or the last line of the previous band.
Group 3 and 4 Facsimile Compression
[0166] The Group 3 Facsimile compression algorithm losslessly
compresses bi-level data for transmission over slow and noisy
telephone lines. The bi-level data represents scanned black text
and graphics on a white background, and the algorithm is tuned for
this class of images (it is explicitly not tuned, for example, for
halftoned bi-level images). The 1D Group 3 algorithm
runlength-encodes each scanline and then Huffman-encodes the
resulting runlengths. Runlengths in the range 0 to 63 are coded
with terminating codes. Runlengths in the range 64 to 2623 are
coded with make-up codes, each representing a multiple of 64,
followed by a terminating code.
[0167] Runlengths exceeding 2623 are coded with multiple make-up
codes followed by a terminating code. The Huffman tables are fixed,
but are separately tuned for black and white runs (except for
make-up codes above 1728, which are common). When possible, the 2D
Group 3 algorithm encodes a scanline as a set of short edge deltas
(0, .+-.1, .+-.2, .+-.3) with reference to the previous scanline.
The delta symbols are entropy-encoded (so that the zero delta
symbol is only one bit long etc.) Edges within a 2D-encoded line
which can't be delta-encoded are runlength-encoded, and are
identified by a prefix. 1D- and 2D-encoded lines are marked
differently. 1D-encoded lines are generated at regular intervals,
whether actually required or not, to ensure that the decoder can
recover from line noise with minimal image degradation. 2D Group 3
achieves compression ratios of up to 6:1.
[0168] The Group 4 Facsimile algorithm losslessly compresses
bi-level data for transmission over error-free communications lines
(i.e. the lines are truly error-free, or error-correction is done
at a lower protocol level). The Group 4 algorithm is based on the
2D Group 3 algorithm, with the essential modification that since
transmission is assumed to be error-free, 1D-encoded lines are no
longer generated at regular intervals as an aid to error-recovery.
Group 4 achieves compression ratios ranging from 20:1 to 60:1 for
the CCITT set of test images.
[0169] The design goals and performance of the Group 4 compression
algorithm qualify it as a compression algorithm for the bi-level
layers. However, its Huffman tables are tuned to a lower scanning
resolution (100-400 dpi), and it encodes runlengths exceeding 2623
awkwardly.
Contone Data Compression
[0170] The contone layer (CMYK) is either a non-compressed
bytestream or is compressed to an interleaved JPEG bytestream. The
JPEG bytestream is complete and self-contained. It contains all
data required for decompression, including quantization and Huffman
tables.
[0171] The contone data is optionally converted to YCrCb before
being compressed (there is no specific advantage in color-space
converting if not compressing). Additionally, the CMY contone
pixels are optionally converted (on an individual basis) to RGB
before color conversion using R=255-C, G=255-M, B=255-Y. Optional
bitwise inversion of the K plane may also be performed. Note that
this CMY to RGB conversion is not intended to be accurate for
display purposes, but rather for the purposes of later converting
to YCrCb. The inverse transform will be applied before
printing.
JPEG Compression
[0172] The JPEG compression algorithm lossily compresses a contone
image at a specified quality level. It introduces imperceptible
image degradation at compression ratios below 5:1, and negligible
image degradation at compression ratios below 10:1.
[0173] JPEG typically first transforms the image into a color space
which separates luminance and chrominance into separate color
channels. This allows the chrominance channels to be subsampled
without appreciable loss because of the human visual system's
relatively greater sensitivity to luminance than chrominance. After
this first step, each color channel is compressed separately.
[0174] The image is divided into 8.times.8 pixel blocks. Each block
is then transformed into the frequency domain via a discrete cosine
transform (DCT). This transformation has the effect of
concentrating image energy in relatively lower-frequency
coefficients, which allows higher-frequency coefficients to be more
crudely quantized. This quantization is the principal source of
compression in JPEG. Further compression is achieved by ordering
coefficients by frequency to maximize the likelihood of adjacent
zero coefficients, and then runlength-encoding runs of zeroes.
Finally, the runlengths and non-zero frequency coefficients are
entropy coded. Decompression is the inverse process of
compression.
Non-Compressed Format
[0175] If the contone data is non-compressed, it must be in a
block-based format bytestream with the same pixel order as would be
produced by a JPEG decoder. The bytestream therefore consists of a
series of 8.times.8 block of the original image, starting with the
top left 8.times.8 block, and working horizontally across the page
(as it will be printed) until the top rightmost 8.times.8 block,
then the next row of 8.times.8 blocks (left to right) and so on
until the lower row of 8.times.8 blocks (left to right). Each
8.times.8 block consists of 64 8-bit pixels for color plane 0
(representing 8 rows of 8 pixels in the order top left to bottom
right) followed by 64 8-bit pixels for color plane 1 and so on for
up to a maximum of 4 color planes. If the original image is not a
multiple of 8 pixels in X or Y, padding must be present (the extra
pixel data will be ignored by the setting of margins).
Compressed Format
[0176] If the contone data is compressed the first memory band
contains JPEG headers (including tables) plus MCUs (minimum coded
units). The ratio of space between the various color planes in the
JPEG stream is 1:1:1:1. No subsampling is permitted. Banding can be
completely arbitrary i.e there can be multiple JPEG images per band
or 1 JPEG image divided over multiple bands. The break between
bands is only memory alignment based.
Conversion of RGB to YCrCb (in RIP)
[0177] YCrCb is defined as per CCIR 601-1 except that Y, Cr and Cb
are normalized to occupy all 256 levels of an 8-bit binary encoding
and take account of the actual hardware implementation of the
inverse transform within SoPEC. The exact color conversion
computation is as follows:
Y*=(9805/32768)R+(19235/32768)G+(3728/32768)B
Cr*=(16375/32768)R-(13716/32768)G-(2659/32768)B+128
Cb*=-(5529/32768)R-(10846/32768)G+(16375/32768)B+128
Y, Cr and Cb are obtained by rounding to the nearest integer. There
is no need for saturation since ranges of Y*, Cr* and Cb* after
rounding are [0-255], [1-255] and [1-255] respectively. Note that
Full Accuracy is Possible with 24 Bits.
SoPEC ASIC
[0178] The Small Office Home Office Print Engine Controller (SoPEC)
is a page rendering engine ASIC that takes compressed page images
as input, and produces decompressed page images at up to 6 channels
of bi-level dot data as output. The bi-level dot data is generated
for the Memjet bi-lithic printhead. The dot generation process
takes account of printhead construction, dead nozzles, and allows
for fixative generation.
[0179] A single SoPEC can control 2 bi-lithic printheads and up to
6 color channels at 10,000 lines/sec.sup.2, equating to 30 pages
per minute. A single SoPEC can perform full-bleed printing of A3,
A4 and Letter pages. The 6 channels of colored ink are the expected
maximum in a consumer SOHO, or office Bi-lithic printing
environment: [0180] CMY, for regular color printing. [0181] K, for
black text, line graphics and gray-scale printing. [0182] IR
(infrared), for Netpage-enabled applications. [0183] F (fixative),
to enable printing at high speed. Because the bi-lithic printer is
capable of printing so fast, a fixative may be required to enable
the ink to dry before the page touches the page already printed.
Otherwise the pages may bleed on each other. In low speed printing
environments the fixative may not be required. .sup.210,000 lines
per second equates to 30 A4/Letter pages per minute at 1600 dpi
[0184] SoPEC is color space agnostic. Although it can accept
contone data as CMYX or RGBX, where X is an optional 4th channel,
it also can accept contone data in any print color space.
Additionally, SoPEC provides a mechanism for arbitrary mapping of
input channels to output channels, including combining dots for ink
optimization, generation of channels based on any number of other
channels etc. However, inputs are typically CMYK for contone input,
K for the bi-level input, and the optional Netpage tag dots are
typically rendered to an infra-red layer. A fixative channel is
typically generated for fast printing applications.
[0185] SoPEC is resolution agnostic. It merely provides a mapping
between input resolutions and output resolutions by means of scale
factors. The expected output resolution is 1600 dpi, but SoPEC
actually has no knowledge of the physical resolution of the
Bi-lithic printhead.
[0186] SoPEC is page-length agnostic. Successive pages are
typically split into bands and downloaded into the page store as
each band of information is consumed and becomes free. SoPEC
provides an interface for synchronization with other SoPECs. This
allows simple multi-SoPEC solutions for simultaneous A3/A4/Letter
duplex printing. However, SoPEC is also capable of printing only a
portion of a page image. Combining synchronization functionality
with partial page rendering allows multiple SoPECs to be readily
combined for alternative printing requirements including
simultaneous duplex printing and wide format printing.
Printing Rates
[0187] The required printing rate for SoPEC is 30 sheets per minute
with an inter-sheet spacing of 4 cm. To achieve a 30 sheets per
minute print rate, this requires: 300 mm.times.63 (dot/mm)/2
sec=105.8 .mu.seconds per line, with no inter-sheet gap; 340
mm.times.63 (dot/mm)/2 sec=93.3 .mu.seconds per line, with a 4 cm
inter-sheet gap. A printline for an A4 page consists of 13824
nozzles across the page. At a system clock rate of 160 MHz 13824
dots of data can be generated in 86.4 .mu.seconds. Therefore data
can be generated fast enough to meet the printing speed
requirement. It is necessary to deliver this print data to the
print-heads.
[0188] Printheads can be made up of 5:5, 6:4, 7:3 and 8:2 inch
printhead combinations. Print data is transferred to both print
heads in a pair simultaneously. This means the longest time to
print a line is determined by the time to transfer print data to
the longest print segment. There are 9744 nozzles across a 7 inch
printhead. The print data is transferred to the printhead at a rate
of 106 MHz (2/3 of the system clock rate) per color plane. This
means that it will take 91.9 .mu.s to transfer a single line for a
7:3 printhead configuration. So we can meet the requirement of 30
sheets per minute printing with a 4 cm gap with a 7:3 printhead
combination. There are 11160 across an 8 inch printhead. To
transfer the data to the printhead at 106 MHz will take 105.3
.mu.s. So an 8:2 printhead combination printing with an inter-sheet
gap will print slower than 30 sheets per minute.
SoPEC Basic Architecture
[0189] From the highest point of view the SoPEC device consists of
3 distinct subsystems: CPU Subsystem; DRAM Subsystem; and Print
Engine Pipeline (PEP) Subsystem. See FIG. 6 for a block level
diagram of SoPEC.
CPU Subsystem
[0190] The CPU subsystem controls and configures all aspects of the
other subsystems. It provides general support for interfacing and
synchronising the external printer with the internal print engine.
It also controls the low speed communication to the QA chips. The
CPU subsystem contains various peripherals to aid the CPU, such as
GPIO (includes motor control), interrupt controller, LSS Master and
general timers. The Serial Communications Block (SCB) on the CPU
subsystem provides a full speed USB 1.1 interface to the host as
well as an Inter SoPEC Interface (ISI) to other SoPEC devices.
DRAM Subsystem
[0191] The DRAM subsystem accepts requests from the CPU, Serial
Communications Block (SCB) and blocks within the PEP subsystem. The
DRAM subsystem (in particular the DIU) arbitrates the various
requests and determines which request should win access to the
DRAM. The DIU arbitrates based on configured parameters, to allow
sufficient access to DRAM for all requesters. The DIU also hides
the implementation specifics of the DRAM such as page size, number
of banks, refresh rates etc.
Print Engine Pipeline (PEP) Subsystem
[0192] The Print Engine Pipeline (PEP) subsystem accepts compressed
pages from DRAM and renders them to bi-level dots for a given print
line destined for a printhead interface that communicates directly
with up to 2 segments of a bi-lithic printhead.
[0193] The first stage of the page expansion pipeline is the CDU,
LBD and TE. The CDU expands the JPEG-compressed contone (typically
CMYK) layer, the LBD expands the compressed bi-level layer
(typically K), and the TE encodes Netpage tags for later rendering
(typically in IR or K ink). The output from the first stage is a
set of buffers: the CFU, SFU, and TFU. The CFU and SFU buffers are
implemented in DRAM.
[0194] The second stage is the HCU, which dithers the contone
layer, and composites position tags and the bi-level spot0 layer
over the resulting bi-level dithered layer. A number of options
exist for the way in which compositing occurs. Up to 6 channels of
bi-level data are produced from this stage. Note that not all 6
channels may be present on the printhead. For example, the
printhead may be CMY only, with K pushed into the CMY channels and
IR ignored. Alternatively, the position tags may be printed in K if
IR ink is not available (or for testing purposes).
[0195] The third stage (DNC) compensates for dead nozzles in the
printhead by color redundancy and error diffusing dead nozzle data
into surrounding dots.
[0196] The resultant bi-level 6 channel dot-data (typically
CMYK-IRF) is buffered and written out to a set of line buffers
stored in DRAM via the DWU. Finally, the dot-data is loaded back
from DRAM, and passed to the printhead interface via a dot FIFO.
The dot FIFO accepts data from the LLU at the system clock rate
(pclk), while the PHI removes data from the FIFO and sends it to
the printhead at a rate of 2/3 times the system clock rate.
SoPEC Block Description
[0197] Looking at FIG. 6, the various units are described in Table
6 summary form:
TABLE-US-00006 TABLE 6 Units within SoPEC Subsystem Unit
Description DRAM DIU Provides the interface for DRAM read and write
access for the various SoPEC units, CPU and the SCB block. The DIU
provides arbitration between competing units controls DRAM access.
DRAM 20 Mbits of embedded DRAM, CPU CPU CPU for system
configuration and control MMU Limits access to certain memory
address areas in CPU user mode RDU Facilitates the observation of
the contents of most of the CPU addressable registers in SoPEC in
addition to some pseudo-registers in realtime. TIM Contains
watchdog and general system timers LSS Low level controller for
interfacing with the QA chips GPIO General IO controller, with
built-in Motor control unit, LED pulse units and de-glitch
circuitry ROM 16 KBytes of System Boot ROM code ICU General Purpose
interrupt controller with configurable priority, and masking. CPR
Central Unit for controlling and generating the system clocks and
resets and powerdown mechanisms PSS Storage retained while system
is powered down USB USB device controller for interfacing with the
host USB. ISI ISI controller for data and control communication
with other SoPEC's in a multi-SoPEC system SCB Contains both the
USB and ISI blocks. PEP PCU Provides external CPU with the means to
read and write PEP Unit registers, and read and write DRAM in
single 32-bit chunks. CDU Expands JPEG compressed contone layer and
writes decompressed contone to DRAM CFU Provides line buffering
between CDU and HCU LBD Expands compressed bi-level layer. SFU
Provides line buffering between LBD and HCU TE Encodes tag data
into line of tag dots. TFU Provides tag data storage between TE and
HCU HCU Dithers contone layer and composites the bi-level spot 0
and position tag dots. DNC Compensates for dead nozzles by color
redundancy and error diffusing dead nozzle data into surrounding
dots. DWU Writes out the 6 channels of dot data for a given
printline to the line store DRAM LLU Reads the expanded page image
from line store, formatting the data appropriately for the
bi-lithic printhead. PHI Is responsible for sending dot data to the
bi-lithic printheads and for providing line synchronization between
multiple SoPECs. Also provides test interface to printhead such as
temperature monitoring and Dead Nozzle Identification.
SoPEC Use Cases
[0198] There are many miscellaneous use cases such as the following
examples. Software running on the SoPEC CPU or host will decide on
what actions to take in these scenarios. For example, a sequence is
typically performed when dead nozzle information in a Dead-nozzle
table needs to be updated by performing a printhead dead nozzle
test: 1) Run printhead nozzle test sequence; 2) Either host or
SoPEC CPU converts dead nozzle information into dead nozzle table;
3) Store dead nozzle table on host; and 4) Write dead nozzle table
to SoPEC DRAM.
Dram Subsystem
DRAM Interface Unit (DIU)
[0199] FIG. 8 shows how the DIU provides the interface between the
on-chip 20 Mbit embedded DRAM and the rest of SoPEC. In addition to
outlining the functionality of the DIU, this chapter provides a
top-level overview of the memory storage and access patterns of
SoPEC and the buffering required in the various SoPEC blocks to
support those access requirements.
[0200] The main functionality of the DIU is to arbitrate between
requests for access to the embedded DRAM and provide read or write
accesses to the requesters. The DIU must also implement the
initialisation sequence and refresh logic for the embedded DRAM.
The arbitration scheme uses a fully programmable timeslot mechanism
for non-CPU requesters to meet the bandwidth and latency
requirements for each unit, with unused slots re-allocated to
provide best effort accesses. The CPU is allowed high priority
access, giving it minimum latency, but allowing bounds to be placed
on its bandwidth consumption.
[0201] The interface between the DIU and the SoPEC requesters is
similar to the interface on PEC1 i.e. separate control, read data
and write data busses. The embedded DRAM is used principally to
store: [0202] CPU program code and data. [0203] PEP (re)programming
commands. [0204] Compressed pages containing contone, bi-level and
raw tag data and header information. [0205] Decompressed contone
and bi-level data. [0206] Dotline store during a print. [0207]
Print setup information such as tag format structures, dither
matrices and dead nozzle information.
Contone Decoder Unit (CDU)
[0208] The Contone Decoder Unit (CDU) is responsible for performing
the optional decompression of the contone data layer.
[0209] The input to the CDU is up to 4 planes of compressed contone
data in JPEG interleaved format. This will typically be 3 planes,
representing a CMY contone image, or 4 planes representing a CMYK
contone image. The CDU must support a page of A4 length (11.7
inches) and Letter width (8.5 inches) at a resolution of 267 ppi in
4 colors and a print speed of 1 side per 2 seconds.
[0210] The CDU and the other page expansion units support the
notion of page banding. A compressed page is divided into one or
more bands, with a number of bands stored in memory. As a band of
the page is consumed for printing a new band can be downloaded. The
new band may be for the current page or the next page. Band-finish
interrupts have been provided to notify the CPU of free buffer
space.
[0211] The compressed contone data is read from the on-chip DRAM.
The output of the CDU is the decompressed contone data, separated
into planes. The decompressed contone image is written to a
circular buffer in DRAM with an expected minimum size of 12 lines
and a configurable maximum. The decompressed contone image is
subsequently read a line at a time by the CFU, optionally color
converted, scaled up to 1600 ppi and then passed on to the HCU for
the next stage in the printing pipeline. The CDU also outputs a
cdu_finishedband control flag indicating that the CDU has finished
reading a band of compressed contone data in DRAM and that area of
DRAM is now free. This flag is used by the PCU and is available as
an interrupt to the CPU.
Storage Requirements for Decompressed Contone Data in Dram
[0212] A single SoPEC must support a page of A4 length (11.7
inches) and Letter width (8.5 inches) at a resolution of 267 ppi in
4 colors and a print speed of 1 side per 2 seconds. The printheads
specified in the Bi-lithic Printhead Specification [2] have 13824
nozzles per color to provide full bleed printing for A4 and Letter.
At 267 ppi, there are 2304 contone pixels.sup.3 per line
represented by 288 JPEG blocks per color. However each of these
blocks actually stores data for 8 lines, since a single JPEG block
is 8.times.8 pixels. The CDU produces contone data for 8 lines in
parallel, while the HCU processes data linearly across a line on a
line by line basis. The contone data is decoded only once and then
buffered in DRAM. This means we require two sets of 8
buffer-lines--one set of 8 buffer lines is being consumed by the
CFU while the other set of 8 buffer lines is being generated by the
CDU. .sup.3Pixels may be 8, 16, 24 or 32 bits depending on the
number of color planes (8-bits per color)
[0213] The buffer requirement can be reduced by using a 1.5
buffering scheme, where the CDU fills 8 lines while the CFU
consumes 4 lines. The buffer space required is a minimum of 12 line
stores per color, for a total space of 108 KBytes.sup.4. A circular
buffer scheme is employed whereby the CDU may only begin to write a
line of JPEG blocks (equals 8 lines of contone data) when there are
8-lines free in the buffer. Once the full 8 lines have been written
by the CDU, the CFU may now begin to read them on a line by line
basis. .sup.412 lines.times.4 colors.times.2304 bytes (assumes 267
ppi, 4 color, full bleed A4/Letter)
[0214] This reduction in buffering comes with the cost of an
increased peak bandwidth requirement for the CDU write access to
DRAM. The CDU must be able to write the decompressed contone at
twice the rate at which the CFU reads the data. To allow for
trade-offs to be made between peak bandwidth and amount of storage,
the size of the circular buffer is configurable. For example, if
the circular buffer is configured to be 16 lines it behaves like a
double-buffer scheme where the peak bandwidth requirements of the
CDU and CFU are equal. An increase over 16 lines allows the CDU to
write ahead of the CFU and provides it with a margin to cope with
very poor local compression ratios in the image.
[0215] SoPEC should also provide support for A3 printing and
printing at resolutions above 267 ppi. This increases the storage
requirement for the decompressed contone data (buffer) in DRAM.
Table 7 gives the storage requirements for the decompressed contone
data at some sample contone resolutions for different page sizes.
It assumes 4 color planes of contone data and a 1.5 buffering
scheme.
TABLE-US-00007 TABLE 7 Storage requirements for decompressed
contone data (buffer) Contone Scale Storage required Page size
resolution (ppi) factor.sup.a Pixels per line (kBytes)
A4/Letter.sup.b 267 6 2304 108.sup.d 400 4 3456 162 800 2 6912 324
A3.sup.c 267 6 3248 152.25 400 4 4872 228.37 800 2 9744 456.75
.sup.aRequired for CFU to convert to final output at 1600 dpi
.sup.bBi-lithic printhead has 13824 nozzles per color providing
full bleed printing for A4/Letter .sup.cBi-lithic printhead has
19488 nozzles per color providing full bleed printing for A3
.sup.d12 lines .times. 4 colors .times. 2304 bytes.
Decompression Performance Requirements
[0216] The JPEG decoder core can produce a single color pixel every
system clock (pclk) cycle, making it capable of decoding at a peak
output rate of 8 bits/cycle. SoPEC processes 1 dot (bi-level in 6
colors) per system clock cycle to achieve a print speed of 1 side
per 2 seconds for full bleed A4/Letter printing. The CFU replicates
pixels a scale factor (SF) number of times in both the horizontal
and vertical directions to convert the final output to 1600 ppi.
Thus the CFU consumes a 4 color pixel (32 bits) every SF.times.SF
cycles. The 1.5 buffering scheme means that the CDU must write the
data at twice this rate. With support for 4 colors at 267 ppi, the
decompression output bandwidth requirement is 1.78
bits/cycle.sup.5. .sup.52.times.((4 colors.times.8 bits)/(6.times.6
cycles))=1.78 bits/cycle
[0217] The JPEG decoder is fed directly from the main memory via
the DRAM interface. The amount of compression determines the input
bandwidth requirements for the CDU. As the level of compression
increases, the bandwidth decreases, but the quality of the final
output image can also decrease. Although the average compression
ratio for contone data is expected to be 10:1, the average
bandwidth allocated to the CDU allows for a local minimum
compression ratio of 5:1 over a single line of JPEG blocks. This
equates to a peak input bandwidth requirement of 0.36 bits/cycle
for 4 colors at 267 ppi, full bleed A4/Letter printing at 1 side
per 2 seconds.
[0218] Table 8 gives the decompression output bandwidth
requirements for different resolutions of contone data to meet a
print speed of 1 side per 2 seconds. Higher resolution requires
higher bandwidth and larger storage for decompressed contone data
in DRAM. A resolution of 400 ppi contone data in 4 colors requires
4 bits/cycle.sup.6, which is practical using a 1.5 buffering
scheme. However, a resolution of 800 ppi would require a double
buffering scheme (16 lines) so the CDU only has to match the CFU
consumption rate. In this case the decompression output bandwidth
requirement is 8 bits/cycle.sup.7, the limiting factor being the
output rate of the JPEG decoder core. .sup.62.times.((4
colors.times.8 bits)/(4.times.4 cycles))=4 bits/cycle.sup.7(4
colors.times.8 bits)/(2.times.2 cycles)=8 bits/cycle
TABLE-US-00008 TABLE 8 CDU performance requirements for full bleed
A4/Letter printing at 1 side/2 secs Contone resolution
Decompression output bandwidth (ppi) Scale factor requirement
(bits/cycle).sup.a 267 6 1.78 400 4 4 800 2 8.sup.b .sup.aAssumes 4
color pixel contone data and a 12 line buffer. .sup.bScale factor 2
requires at least a 16 line buffer.
Data Flow
[0219] FIG. 9 shows the general data flow for contone
data--compressed contone planes are read from DRAM by the CDU, and
the decompressed contone data is written to the 12-line circular
buffer in DRAM. The line buffers are subsequently read by the
CFU.
[0220] The CDU allows the contone data to be passed directly on,
which will be the case if the color represented by each color plane
in the JPEG image is an available ink. For example, the four colors
may be C, M, Y, and K, directly represented by CMYK inks. The four
colors may represent gold, metallic green etc. for multi-SoPEC
printing with exact colors.
[0221] However JPEG produces better compression ratios for a given
visible quality when luminance and chrominance channels are
separated. With CMYK, K can be considered to be luminance, but C,
M, and Y each contain luminance information, and so would need to
be compressed with appropriate luminance tables. We therefore
provide the means by which CMY can be passed to SoPEC as YCrCb. K
does not need color conversion. When being JPEG compressed, CMY is
typically converted to RGB, then to YCrCb and then finally JPEG
compressed. At decompression, the YCrCb data is obtained and
written to the decompressed contone store by the CDU. This is read
by the CFU where the YCrCb can then be optionally color converted
to RGB, and finally back to CMY.
[0222] The external RIP provides conversion from RGB to YCrCb,
specifically to match the actual hardware implementation of the
inverse transform within SoPEC, as per CCIR 601-2 [24] except that
Y, Cr and Cb are normalized to occupy all 256 levels of an 8-bit
binary encoding.
[0223] The CFU provides the translation to either RGB or CMY. RGB
is included since it is a necessary step to produce CMY, and some
printers increase their color gamut by including RGB inks as well
as CMYK.
Halftoner Compositor Unit (HCU)
[0224] The Halftoner Compositor Unit (HCU) produces dots for each
nozzle in the destination printhead taking account of the page
dimensions (including margins). The spot data and tag data are
received in bi-level form while the pixel contone data received
from the CFU must be dithered to a bi-level representation. The
resultant 6 bi-level planes for each dot position on the page are
then remapped to 6 output planes and output dot at a time (6 bits)
to the next stage in the printing pipeline, namely the dead nozzle
compensator (DNC).
Data Flow
[0225] FIG. 11 shows a simple dot data flow high level block
diagram of the HCU. The HCU reads contone data from the CFU,
bi-level spot data from the SFU, and bi-level tag data from the
TFU. Dither matrices are read from the DRAM via the DIU. The
calculated output dot (6 bits) is read by the DNC.
[0226] The HCU is given the page dimensions (including margins),
and is only started once for the page. It does not need to be
programmed in between bands or restarted for each band. The HCU
will stall appropriately if its input buffers are starved. At the
end of the page the HCU will continue to produce 0 for all dots as
long as data is requested by the units further down the pipeline
(this allows later units to conveniently flush pipelined data).
[0227] The HCU performs a linear processing of dots calculating the
6-bit output of a dot in each cycle. The mapping of 6 calculated
bits to 6 output bits for each dot allows for such example mappings
as compositing of the spot0 layer over the appropriate contone
layer (typically black), the merging of CMY into K (if K is present
in the printhead), the splitting of K into CMY dots if there is no
K in the printhead, and the generation of a fixative output
bitstream.
Dram Storage Requirements
[0228] SoPEC allows for a number of different dither matrix
configurations up to 256 bytes wide. The dither matrix is stored in
DRAM. Using either a single or double-buffer scheme a line of the
dither matrix must be read in by the HCU over a SoPEC line time.
SoPEC must produce 13824 dots per line for A4/Letter printing which
takes 13824 cycles.
[0229] The following give the storage and bandwidths requirements
for some of the possible configurations of the dither matrix.
[0230] 4 Kbyte DRAM storage required for one 64.times.64
(preferred) byte dither matrix [0231] 6.25 Kbyte DRAM storage
required for one 80.times.80 byte dither matrix [0232] 16 Kbyte
DRAM storage required for four 64.times.64 byte dither matrices
[0233] 64 Kbyte DRAM storage required for one 256.times.256 byte
dither matrix
[0234] It takes 4 or 8 read accesses to load a line of dither
matrix into the dither matrix buffer, depending on whether we're
using a single or double buffer (configured by DoubleLineBuff
register).
Implementation
[0235] A block diagram of the HCU is given in FIG. 12.
Control Unit
[0236] The control unit is responsible for controlling the overall
flow of the HCU. It is responsible for determining whether or not a
dot will be generated in a given cycle, and what dot will actually
be generated--including whether or not the dot is in a margin area,
and what dither cell values should be used at the specific dot
location. A block diagram of the control unit is shown in FIG.
13.
[0237] The inputs to the control unit are a number of avail flags
specifying whether or not a given dotgen unit is capable of
supplying `real` data in this cycle. The term `real` refers to data
generated from external sources, such as contone line buffers,
bi-level line buffers, and tag plane buffers. Each dotgen unit
informs the control unit whether or not a dot can be generated this
cycle from real data. It must also check that the DNC is ready to
receive data.
[0238] The contone/spot margin unit is responsible for determining
whether the current dot coordinate is within the target
contone/spot margins, and the tag margin unit is responsible for
determining whether the current dot coordinate is within the target
tag margins.
[0239] The dither matrix table interface provides the interface to
DRAM for the generation of dither cell values that are used in the
halftoning process in the contone dotgen unit.
Determine Advdot
[0240] The HCU does not always require contone planes, bi-level or
tag planes in order to produce a page. For example, a given page
may not have a bi-level layer, or a tag layer. In addition, the
contone and bi-level parts of a page are only required within the
contone and bi-level page margins, and the tag part of a page is
only required within the tag page margins. Thus output dots can be
generated without contone, bi-level or tag data before the
respective top margins of a page has been reached, and 0s are
generated for all color planes after the end of the page has been
reached (to allow later stages of the printing pipeline to
flush).
[0241] Consequently the HCU has an AvailMask register that
determines which of the various input avail flags should be taken
notice of during the production of a page from the first line of
the target page, and a TMMask register that has the same behaviour,
but is used in the lines before the target page has been reached
(i.e. inside the target top margin area). The dither matrix mask
bit TMask[0] is the exception, it applies to all margins areas not
just the top margin. Each bit in the AvailMask refers to a
particular avail bit: if the bit in the AvailMask register is set,
then the corresponding avail bit must be 1 for the HCU to advance a
dot. The bit to avail correspondence is shown in Table 9. Care
should be taken with TMMask--if the particular data is not
available after the top margin has been reached, then the HCU will
stall. Note that the avail bits for contone and spot colors are
ANDed with in_target_age after the target page area has been
reached to allow dot production in the contone/spot margin areas
without needing any data in the CFU and SFU. The avail bit for tag
color is ANDed with in_tag_target_page after the target tag page
area has been reached to allow dot production in the tag margin
areas without needing any data in the TFU.
TABLE-US-00009 TABLE 9 Correspondence between bit in AvailMask and
avail flag bit # in AvailMask avail flag description 0 dm_avail
dither matrix data available 1 cp_avail contone pixels available 2
s_avail spot color available 3 tp_avail tag plane available
[0242] Each of the input avail bits is processed with its
appropriate mask bit and the after_top_margin flag (note the dither
matrix is the exception it is processed with in_target_page). The
output bits are ANDed together along with Go and output_buff_full
(which specifies whether the output buffer is ready to receive a
dot in this cycle) to form the output bit advdot. We also generate
wr_advdot. In this way, if the output buffer is full or any of the
specified avail flags is clear, the HCU will stall. When the end of
the page is reached, in_page will be deasserted and the HCU will
continue to produce 0 for all dots as long as the DNC requests
data. A block diagram of the determine advdot unit is shown in FIG.
14.
[0243] The advance dot block also determines if current page needs
dither matrix, it indicates to the dither matrix table interface
block via the dm_read_enable signal. If no dither is required in
the margins or in the target page then dm_read_enable will be 0 and
no dither will be read in for this page.
Position Unit
[0244] The position unit is responsible for outputting the position
of the current dot (curr_pos, curr_line) and whether or not this
dot is the last dot of a line (advline). Both curr_pos and
curr_line are set to 0 at reset or when Go transitions from 0 to 1.
The position unit relies on the advdot input signal to advance
through the dots on a page. Whenever an advdot pulse is received,
curr_pos gets incremented. If curr_pos equals max_dot then an
advline pulse is generated as this is the last dot in a line,
curr_line gets incremented, and the curr_pos is reset to 0 to start
counting the dots for the next line.
[0245] The position unit also generates a filtered version of
advline called dm_advline to indicate to the dither matrix pointers
to increment to the next line. The dm_advline is only incremented
when dither is required for that line.
TABLE-US-00010 if ((after_top_margin AND avail_mask[0]) OR
tm_mask[0]) then dm_advline = advline else dm_advline = 0
Margin Unit
[0246] The responsibility of the margin unit is to determine
whether the specific dot coordinate is within the page at all,
within the target page or in a margin area (see FIG. 15). This unit
is instantiated for both the contone/spot margin unit and the tag
margin unit.
[0247] The margin unit takes the current dot and line position, and
returns three flags. [0248] the first, in_page is 1 if the current
dot is within the page, and 0 if it is outside the page. [0249] the
second flag, in_target_page, is 1 if the dot coordinate is within
the target page area of the page, and 0 if it is within the target
top/left/bottom/right margins. [0250] the third flag,
after_top_margin, is 1 if the current dot is below the target top
margin, and 0 if it is within the target top margin.
[0251] A block diagram of the margin unit is shown in FIG. 16.
Dither Matrix Table Interface
[0252] The dither matrix table interface provides the interface to
DRAM for the generation of dither cell values that are used in the
halftoning process in the contone dotgen unit. The control flag
dm_read_enable enables the reading of the dither matrix table line
structure from DRAM. If dm_read_enable is 0, the dither matrix is
not specified in DRAM and no DRAM accesses are attempted. The
dither matrix table interface has an output flag dm_avail which
specifies if the current line of the specified matrix is available.
The HCU can be directed to stall when dm_avail is 0 by setting the
appropriate bit in the HCU's AvailMask or TMMask registers. When
dm_avail is 0 the value in the DitherConstant register is used as
the dither cell values that are output to the contone dotgen
unit.
[0253] The dither matrix table interface consists of a state
machine that interfaces to the DRAM interface, a dither matrix
buffer that provides dither matrix values, and a unit to generate
the addresses for reading the buffer. FIG. 17 shows a block diagram
of the dither matrix table interface. When the HCU first requests
data from DRAM, the 64-bits word transfer order will be
D0,D1,D2,D3. On the second request the transfer order will be
D4,D5,D6,D7 and so on for other requests.
Contone Dotgen Unit
[0254] The contone dotgen unit is responsible for producing a dot
in up to 4 color planes per cycle. The contone dotgen unit also
produces a cp_avail flag which specifies whether or not contone
pixels are currently available, and the output hcu_cfu_advdot to
request the CFU to provide the next contone pixel in up to 4 color
planes. The block diagram for the contone dotgen unit is shown in
FIG. 20.
[0255] A dither unit provides the functionality for dithering a
single contone plane. The contone image is only defined within the
contone/spot margin area. As a result, if the input flag
in_target_page is 0, then a constant contone pixel value is used
for the pixel instead of the contone plane.
[0256] The resultant contone pixel is then halftoned. The dither
value to be used in the halftoning process is provided by the
control data unit. The halftoning process involves a comparison
between a pixel value and its corresponding dither value. If the
8-bit contone value is greater than or equal to the 8-bit dither
matrix value a 1 is output. If not, then a 0 is output. This means
each entry in the dither matrix is in the range 1-255 (0 is not
used).
[0257] Note that constant use is dependant on the in_target_page
signal only, if in_target_age is 1 then the cfu_hcu_c*_data should
be allowed to pass through, regardless of the stalling behaviour or
the avail_mask/[1] setting. This allows a constant value to be
setup on the CFU output data, and the use of different constants
while inside and outside the target page. The hcu_cfu_advdot will
always be zero if the avail_mask/[1] is zero.
Spot Dotgen Unit
[0258] The spot dotgen unit is responsible for producing a dot of
bi-level data per cycle. It deals with bi-level data (and therefore
does not need to halftone) that comes from the LBD via the SFU.
Like the contone layer, the bi-level spot layer is only defined
within the contone/spot margin area. As a result, if input flag
in_target_page is 0, then a constant dot value (typically this
would be 0) is used for the output dot.
[0259] The spot dotgen unit also produces a s_avail flag which
specifies whether or not spot dots are currently available for this
spot plane, and the output hcu_sfu_advdot to request the SFU to
provide the next bi-level data value.
[0260] Note that constant use is dependant on the in_target_page
signal only, if in_target_age is 1 then the sfu_hcu_data should be
allowed to pass through, regardless of the stalling behaviour or
the avail_mask setting. This allows a constant value to be setup on
the SFU output data, and the use of different constants while
inside and outside the target page. The hcu_sfu_advdot will always
be zero if the avail_mask[2] is zero.
Dot Reorg Unit
[0261] The dot reorg unit provides a means of mapping the bi-level
dithered data, the spot0 color, and the tag data to output inks in
the actual printhead. Each dot reorg unit takes a set of 6 1-bit
inputs and produces a single bit output that represents the output
dot for that color plane.
[0262] The output bit is a logical combination of any or all of the
input bits. This allows the spot color to be placed in any output
color plane (including infrared for testing purposes), black to be
merged into cyan, magenta and yellow (in the case of no black ink
in the Memjet printhead), and tag dot data to be placed in a
visible plane. An output for fixative can readily be generated by
simply combining desired input bits.
[0263] The dot reorg unit contains a 64-bit lookup to allow
complete freedom with regards to mapping. Since all possible
combinations of input bits are accounted for in the 64 bit lookup,
a given dot reorg unit can take the mapping of other reorg units
into account. For example, a black plane reorg unit may produce a 1
only if the contone plane 3 or spot color inputs are set (this
effectively composites black bi-level over the contone). A fixative
reorg unit may generate a 1 if any 2 of the output color planes is
set (taking into account the mappings produced by the other reorg
units).
[0264] If dead nozzle replacement is to be used, the dot reorg can
be programmed to direct the dots of the specified color into the
main plane, and 0 into the other. If a nozzle is then marked as
dead in the DNC, swapping the bits between the planes will result
in 0 in the dead nozzle, and the required data in the other
plane.
[0265] If dead nozzle replacement is to be used, and there are no
tags, the TE can be programmed with the position of dead nozzles
and the resultant pattern used to direct dots into the specified
nozzle row. If only fixed background TFS is to be used, a limited
number of nozzles can be replaced. If variable tag data is to be
used to specify dead nozzles, then large numbers of dead nozzles
can be readily compensated for.
[0266] The dot reorg unit can be used to average out the nozzle
usage when two rows of nozzles share the same ink and tag encoding
is not being used. The TE can be programmed to produce a regular
pattern (e.g. 0101 on one line, and 1010 on the next) and this
pattern can be used as a directive as to direct dots into the
specified nozzle row.
[0267] Each reorg unit contains a 64-bit IOMapping value
programmable as two 32-bit HCU registers, and a set of selection
logic based on the 6-bit dot input (2.sup.6=64 bits), as shown in
FIG. 21. The mapping of input bits to each of the 6 selection bits
is as defined in Table 10.
TABLE-US-00011 TABLE 10 Mapping of input bits to 6 selection bits
address bit likely of lookup tied to interpretation 0 bi-level dot
from contone layer 0 cyan 1 bi-level dot from contone layer 1
magenta 2 bi-level dot from contone layer 2 yellow 3 bi-level dot
from contone layer 3 black 4 bi-level spot0 dot black 5 bi-level
tag dot infra-red
Output Buffer
[0268] The output buffer de-couples the stalling behaviour of the
feeder units from the stalling behaviour of the DNC. The larger the
buffer the greater de-coupling. Currently the output buffer size is
2, but could be increased if needed at the cost of extra area.
[0269] If the Go bit is set to 0 no read or write of the output
buffer is permitted. On a low to high transition of the Go bit the
contents of the output buffer are cleared.
[0270] The output buffer also implements the interface logic to the
DNC. If there is data in the output buffer the hcu_dnc_avail signal
will be 1, otherwise is will be 0. If both hcu_dnc_avail and
dnc_hcu_ready are 1 then data is read from the output buffer.
[0271] On the write side if there is space available in the output
buffer the logic indicates to the control unit via the
output_buff_full signal. The control unit will then allow writes to
the output buffer via the wr_advdot signal. If the writes to the
output buffer are after the end of a page (indicated by in_page
equal to 0) then all dots written into the output buffer are set to
zero.
HCU to DNC Interface
[0272] FIG. 22 shows the timing diagram and representative logic of
the HCU to DNC interface. The hcu_dnc_avail signal indicate to the
DNC that the HCU has data available. The dnc_hcu_ready signal
indicates to the HCU that the DNC is ready to accept data. When
both signals are high data is transferred from the HCU to the DNC.
Once the HCU indicates it has data available (setting the
hcu_dnc_avail signal high) it can only set the hcu_dnc_avail low
again after a dot is accepted by the DNC.
Feeder to HCU Interfaces
[0273] FIG. 23 shows the feeder unit to HCU interface timing
diagram, and FIG. 24 shows representative logic of the interface
with the register positions. sfu_hcu_data and sfu_hcu_avail are
always registered while the sfu_hcu_advdot is not. The
hcu_sfu_avail signal indicates to the HCU that the feeder unit has
data available, and sfu_hcu_advdot indicates to the feeder unit
that the HCU has captured the last dot. The HCU can never produce
an advance dot pulse while the avail is low. The diagrams show the
example of the SFU to HCU interface, but the same interface is used
for the other feeder units TFU and CFU.
Dead Nozzle Compensator (DNC)
[0274] The Dead Nozzle Compensator (DNC) is responsible for
adjusting Memjet dot data to take account of non-functioning
nozzles in the Memjet printhead. Input dot data is supplied from
the HCU, and the corrected dot data is passed out to the DWU. The
high level data path is shown by the block diagram in FIG. 25. The
DNC compensates for a dead nozzles by performing the following
operations: [0275] Dead nozzle removal, i.e. turn the nozzle off
[0276] Ink replacement by direct substitution i.e. K->K [0277]
Ink replacement by indirect substitution i.e. K->CMY [0278]
Error diffusion to adjacent nozzles [0279] Fixative corrections
[0280] The DNC is required to efficiently support up to 5% dead
nozzles, under the expected DRAM bandwidth allocation, with no
restriction on where dead nozzles are located and handle any
fixative correction due to nozzle compensations. Performance must
degrade gracefully after 5% dead nozzles.
Dead Nozzle Identification
[0281] Dead nozzles are identified by means of a position value and
a mask value. Position information is represented by a 10-bit delta
encoded format, where the 10-bit value defines the number of dots
between dead nozzle columns.sup.8. With the delta information it
also reads the 6-bit dead nozzle mask (dn_mask) for the defined
dead nozzle position. Each bit in the dn_mask corresponds to an ink
plane. A set bit indicates that the nozzle for the corresponding
ink plane is dead. The dead nozzle table format is shown in FIG.
26. The DNC reads dead nozzle information from DRAM in single
256-bit accesses. A 10-bit delta encoding scheme is chosen so that
each table entry is 16 bits wide, and 16 entries fit exactly in
each 256-bit read. Using 10-bit delta encoding means that the
maximum distance between dead nozzle columns is 1023 dots. It is
possible that dead nozzles may be spaced further than 1023 dots
from each other, so a null dead nozzle identifier is required. A
null dead nozzle identifier is defined as a 6-bit dn_mask of all
zeros. These null dead nozzle identifiers should also be used so
that: [0282] the dead nozzle table is a multiple of 16 entries (so
that it is aligned to the 256-bit DRAM locations) [0283] the dead
nozzle table spans the complete length of the line, i.e. the first
entry dead nozzle table should have a delta from the first nozzle
column in a line and the last entry in the dead nozzle table should
correspond to the last nozzle column in a line. .sup.8for a 10-bit
delta value of d, if the current column n is a dead nozzle column
then the next dead nozzle column is given by n+(d+1).
[0284] Note that the DNC deals with the width of a page. This may
or may not be the same as the width of the printhead (the PHI may
introduce some margining to the page so that its dot output matches
the width of the printhead). Care must be taken when programming
the dead nozzle table so that dead nozzle positions are correctly
specified with respect to the page and printhead.
DRAM Storage and Bandwidth Requirement
[0285] The memory required is largely a factor of the number of
dead nozzles present in the printhead (which in turn is a factor of
the printhead size). The DNC is required to read a 16-bit entry
from the dead nozzle table for every dead nozzle. Table 11 shows
the DRAM storage and average.sup.9 bandwidth requirements for the
DNC for different percentages of dead nozzles and different page
sizes. .sup.9Average bandwidth assumes an even spread of dead
nozzles. Clumps of dead nozzles may cause delays due to
insufficient available DRAM bandwidth. These delays will occur
every line causing an accumulative delay over a page.
TABLE-US-00012 TABLE 11 Dead Nozzle storage and average bandwidth
requirements Dead nozzle table Bandwidth Page size % Dead Nozzles
Memory (KBytes) (bits/cycle) A4.sup.a 5% 1.4.sup.c 0.8.sup.d 10%
2.7 1.6 15% 4.1 2.4 A3.sup.b 5% 1.9 0.8 10% 3.8 1.6 15% 5.7 2.4
.sup.aBi-lithic printhead has 13824 nozzles per color providing
full bleed printing for A4/Letter .sup.bBi-lithic printhead has
19488 nozzles per color providing full bleed printing for A3
.sup.c16 bits .times. 13824 nozzles .times. 0.05 dead .sup.d(16
bits read/20 cycles) = 0.8 bits/cycle
Nozzle Compensation
[0286] DNC receives 6 bits of dot information every cycle from the
HCU, 1 bit per color plane. When the dot position corresponds to a
dead nozzle column, the associated 6-bit dn_mask indicates which
ink plane(s) contains a dead nozzle(s). The DNC first deletes dots
destined for the dead nozzle. It then replaces those dead dots,
either by placing the data destined for the dead nozzle into an
adjacent ink plane (direct substitution) or into a number of ink
planes (indirect substitution). After ink replacement, if a dead
nozzle is made active again then the DNC performs error diffusion.
Finally, following the dead nozzle compensation mechanisms the
fixative, if present, may need to be adjusted due to new nozzles
being activated, or dead nozzles being removed.
Dead Nozzle Removal
[0287] If a nozzle is defined as dead, then the first action for
the DNC is to turn off (zeroing) the dot data destined for that
nozzle. This is done by a bit-wise ANDing of the inverse of the
dn_mask with the dot value.
Ink Replacement
[0288] Ink replacement is a mechanism where data destined for the
dead nozzle is placed into an adjacent ink plane of the same color
(direct substitution, i.e. K->K.sub.alternative), or placed into
a number of ink planes, the combination of which produces the
desired color (indirect substitution, i.e. K->CMY). Ink
replacement is performed by filtering out ink belonging to nozzles
that are dead and then adding back in an appropriately calculated
pattern. This two step process allows the optional re-inclusion of
the ink data into the original dead nozzle position to be
subsequently error diffused. In the general case, fixative data
destined for a dead nozzle should not be left active intending it
to be later diffused.
[0289] The ink replacement mechanism has 6 ink replacement
patterns, one per ink plane, programmable by the CPU. The dead
nozzle mask is ANDed with the dot data to see if there are any
planes where the dot is active but the corresponding nozzle is
dead. The resultant value forms an enable, on a per ink basis, for
the ink replacement process. If replacement is enabled for a
particular ink, the values from the corresponding replacement
pattern register are ORed into the dot data. The output of the ink
replacement process is then filtered so that error diffusion is
only allowed for the planes in which error diffusion is enabled.
The output of the ink replacement logic is ORed with the resultant
dot after dead nozzle removal.
[0290] For example if we consider the printhead color configuration
C,M,Y,K.sub.1,K.sub.2,IR and the input dot data from the HCU is
b101100. Assuming that the K.sub.1 ink plane and IR ink plane for
this position are dead so the dead nozzle mask is b000101. The DNC
first removes the dead nozzle by zeroing the K.sub.1 plane to
produce b101000. Then the dead nozzle mask is ANDed with the dot
data to give b000100 which selects the ink replacement pattern for
K.sub.1 (in this case the ink replacement pattern for K.sub.1 is
configured as b000010, i.e. ink replacement into the K.sub.2
plane). Providing error diffusion for K.sub.2 is enabled, the
output from the ink replacement process is b000010. This is ORed
with the output of dead nozzle removal to produce the resultant dot
b101010. As can be seen the dot data in the defective K.sub.1
nozzle was removed and replaced by a dot in the adjacent K.sub.2
nozzle in the same dot position, i.e. direct substitution.
[0291] In the example above the K.sub.1 ink plane could be
compensated for by indirect substitution, in which case ink
replacement pattern for K.sub.1 would be configured as b111000
(substitution into the CMY color planes), and this is ORed with the
output of dead nozzle removal to produce the resultant dot b111000.
Here the dot data in the defective K.sub.1 ink plane was removed
and placed into the CMY ink planes.
Error Diffusion
[0292] Based on the programming of the lookup table the dead nozzle
may be left active after ink replacement. In such cases the DNC can
compensate using error diffusion. Error diffusion is a mechanism
where dead nozzle dot data is diffused to adjacent dots.
[0293] When a dot is active and its destined nozzle is dead, the
DNC will attempt to place the data into an adjacent dot position,
if one is inactive. If both dots are inactive then the choice is
arbitrary, and is determined by a pseudo random bit generator. If
both neighbor dots are already active then the bit cannot be
compensated by diffusion.
[0294] Since the DNC needs to look at neighboring dots to determine
where to place the new bit (if required), the DNC works on a set of
3 dots at a time. For any given set of 3 dots, the first dot
received from the HCU is referred to as dot A, and the second as
dot B, and the third as dot C. The relationship is shown in FIG.
27.
[0295] For any given set of dots ABC, only B can be compensated for
by error diffusion if B is defined as dead. A 1 in dot B will be
diffused into either dot A or dot C if possible. If there is
already a 1 in dot A or dot C then a 1 in dot B cannot be diffused
into that dot.
[0296] The DNC must support adjacent dead nozzles. Thus if dot A is
defined as dead and has previously been compensated for by error
diffusion, then the dot data from dot B should not be diffused into
dot A. Similarly, if dot C is defined as dead, then dot data from
dot B should not be diffused into dot C.
[0297] Error diffusion should not cross line boundaries. If dot B
contains a dead nozzle and is the first dot in a line then dot A
represents the last dot from the previous line. In this case an
active bit on a dead nozzle of dot B should not be diffused into
dot A. Similarly, if dot B contains a dead nozzle and is the last
dot in a line then dot C represents the first dot of the next line.
In this case an active bit on a dead nozzle of dot B should not be
diffused into dot C. Thus, as a rule, a 1 in dot B cannot be
diffused into dot A if [0298] a 1 is already present in dot A,
[0299] dot A is defined as dead, [0300] or dot A is the last dot in
a line. Similarly, a 1 in dot B cannot be diffused into dot C if
[0301] a 1 is already present in dot C, [0302] dot C is defined as
dead, [0303] or dot C is the first dot in a line. If B is defined
to be dead and the dot value for B is 0, then no compensation needs
to be done and dots A and C do not need to be changed. If B is
defined to be dead and the dot value for B is 1, then B is changed
to 0 and the DNC attempts to place the 1 from B into either A or C:
[0304] If the dot can be placed into both A and C, then the DNC
must choose between them. The preference is given by the current
output from the random bit generator, 0 for "prefer left" (dot A)
or 1 for "prefer right" (dot C). [0305] If dot can be placed into
only one of A and C, then the 1 from B is placed into that
position. [0306] If dot cannot be placed into either one of A or C,
then the DNC cannot place the dot in either position. Table 12
shows the truth table for DNC error diffusion operation when dot B
is defined as dead.
TABLE-US-00013 [0306] TABLE 12 Error Diffusion Truth Table when dot
B is dead Input C A OR OR C dead A dead OR OR C first in Output A
last in line B line Rand{grave over ( )}a A B C 0 0 0 X A input 0 C
input 0 0 1 X A input 0 C input 0 1 0 0 1{grave over ( )}b 0 C
input 0 1 0 1 A input 0 1 0 1 1 X 1 0 C input 1 0 0 X A input 0 C
input 1 0 1 X A input 0 C input 1 1 0 X A input 0 1 1 1 1 X A input
0 C input a. Output from random bit generator. Determines direction
of error diffusion (0 = left, 1 = right) b. Bold emphasis is used
to show the DNC inserted a 1
[0307] The random bit value used to arbitrarily select the
direction of diffusion is generated by a 32-bit maximum length
random bit generator. The generator generates a new bit for each
dot in a line regardless of whether the dot is dead or not. The
random bit generator can be initialized with a 32-bit programmable
seed value.
Fixative Correction
[0308] After the dead nozzle compensation methods have been applied
to the dot data, the fixative, if present, may need to be adjusted
due to new nozzles being activated, or dead nozzles being removed.
For each output dot the DNC determines if fixative is required
(using the FixativeRequiredMask register) for the new compensated
dot data word and whether fixative is activated already for that
dot. For the DNC to do so it needs to know the color plane that has
fixative, this is specified by the FixativeMask1 configuration
register. See Table 15 below which indicates the actions to take
based on these calculations.
[0309] The DNC also allows the specification of another fixative
plane, specified by the FixativeMask2 configuration register, with
FixativeMask1 having the higher priority over FixativeMask2. When
attempting to add fixative the DNC first tries to add it into the
planes defined by FixativeMask1. However, if any of these planes is
dead then it tries to add fixative by placing it into the planes
defined by FixativeMask2.
[0310] Note that the fixative defined by FixativeMask1 and
FixativeMask2 could possibly be multi-part fixative, i.e. 2 bits
could be set in FixativeMask1 with the fixative being a combination
of both inks.
Implementation
[0311] A block diagram of the DNC is shown in FIG. 28.
TABLE-US-00014 TABLE 13 DNC port list and description Port name
Pins I/O Description Clocks and Resets Pclk 1 In System Clock.
prst_n 1 In System reset, synchronous active low. PCU interface
pcu_dnc_sel 1 In Block select from the PCU. When pcu_dnc_sel is
high both pcu_adr and pcu_dataout are valid. pcu_rwn 1 In Common
read/not-write signal from the PCU. pcu_adr[6:2] 5 In PCU address
bus. Only 5 bits are required to decode the address space for this
block. pcu_dataout[31:0] 32 In Shared write data bus from the PCU.
dnc_pcu_rdy 1 Out Ready signal to the PCU. When dnc_pcu_rdy is high
it indicates the last cycle of the access. For a write cycle this
means pcu_dataout has been registered by the block and for a read
cycle this means the data on dnc_pcu_datain is valid.
dnc_pcu_datain[31:0] 32 Out Read data bus to the PCU. DIU interface
dnc_diu_rreq 1 Out DNC unit requests DRAM read. A read request must
be accompanied by a valid read address. dnc_diu_radr[21:5] 17 Out
Read address to DIU, 256-bit word aligned. diu_dnc_rack 1 In
Acknowledge from DIU that read request has been accepted and new
read address can be placed on dnc_diu_radr diu_dnc_rvalid 1 In Read
data valid, active high. Indicates that valid read data is now on
the read data bus, diu_data. diu_data[63:0] 64 In Read data from
DIU. HCU interface dnc_hcu_ready 1 Out Indicates that DNC is ready
to accept data from the HCU. hcu_dnc_avail 1 In Indicates valid
data present on hcu_dnc_data. hcu_dnc_data[5:0] 6 In Output
bi-level dot data in 6 ink planes. DWU interface dwu_dnc_ready 1 In
Indicates that DWU is ready to accept data from the DNC.
dnc_dwu_avail 1 Out Indicates valid data present on dnc_dwu_data.
dnc_dwu_data[5:0] 6 Out Output bi-level dot data in 6 ink
planes.
Configuration Registers
[0312] The configuration registers in the DNC are programmed via
the PCU interface. Note that since addresses in SoPEC are byte
aligned and the PCU only supports 32-bit register reads and writes,
the lower 2 bits of the PCU address bus are not required to decode
the address space for the DNC. When reading a register that is less
than 32 bits wide zeros should be returned on the upper unused
bit(s) of dnc_pcu_datain. Table 14 lists the configuration
registers in the DNC.
TABLE-US-00015 TABLE 14 DNC configuration registers Address
Register Value (DNC_base+) name #bits on reset Description Control
registers 0x00 Reset 1 0x1 A write to this register causes a reset
of the DNC. 0x04 Go 1 0x0 Writing 1 to this register starts the
DNC. Writing 0 to this register halts the DNC. When Go is asserted
all counters, flags etc. are cleared or given their initial value,
but configuration registers keep their values. When Go is
deasserted the state-machines go to their idle states but all
counters and configuration registers keep their values. This
register can be read to determine if the DNC is running (1 =
running, 0 = stopped). Setup registers (constant during processing)
0x10 MaxDot 16 0x0000 This is the maximum dot number -1 present
across a page. For example if a page contains 13824 dots, then
MaxDot will be 13823. Note that this number may or may not be the
same as the number of dots across the printhead as some margining
may be introduced in the PHI. 0x14 LSFR 32 0x0000_0000 The current
value of the LFSR register used as the 32-bit maximum length random
bit generator. Users can write to this register to program a seed
value for the 32- bit maximum length random bit generator. Must not
be all 1s for taps implemented in XNOR form. (It is expected that
writing a seed value will not occur during the operation of the
LFSR). This LSFR value could also have a possible use as a random
source in program code. 0x20 FixativeMask1 6 0x00 Defines the
higher priority fixative plane(s). Bit 0 represents the settings
for plane 0, bit 1 for plane 1 etc. For each bit: 1 = the ink plane
contains fixative. 0 = the ink plane does not contain fixative.
0x24 FixativeMask2 6 0x00 Defines the lower priority fixative
plane(s). Bit 0 represents the settings for plane 0, bit 1 for
plane 1 etc. Used only when FixativeMask1 planes are dead. For each
bit: 1 = the ink plane contains fixative. 0 = the ink plane does
not contain fixative. 0x28 FixativeRequiredMask 6 0x00 Identifies
the ink planes that require fixative. Bit 0 represents the settings
for plane 0, bit 1 for plane 1 etc. For each bit: 1 = the ink plane
requires fixative; 0 = the ink plane does not require fixative
(e.g. ink is self-fixing) 0x30 DnTableStartAdr[21:5] 17 0x0_0000
Start address of Dead Nozzle Table in DRAM, specified in 256-bit
words. 0x34 DnTableEndAdr[21:5] 17 0x0_0000 End address of Dead
Nozzle Table in DRAM, specified in 256-bit words, i.e. the location
containing the last entry in the Dead Nozzle Table. The Dead Nozzle
Table should be aligned to a 256-bit boundary, if necessary it can
be padded with null entries. 0x40-0x54 PlaneReplacePattern[5:0] 6
.times. 6 0x00 Defines the ink replacement pattern for each of the
6 ink planes. PlaneReplacePattern[0] is the ink replacement pattern
for plane 0, PlaneRelace Pattern[1] is the ink replacement pattern
for plane 1, etc. For each 6-bit replacement pattern for a plane, a
1 in any bit positions indicates the alternative ink planes to be
used for this plane. 0x58 DiffuseEnable 6 0x3F Defines whether,
after ink replacement, error diffusion is allowed to be performed
on each plane. Bit 0 represents the settings for plane 0, bit 1 for
plane 1 etc. For each bit: 1 = error diffusion is enabled; 0 =
error diffusion is disabled Debug registers (read only) 0x60
DncOutputDebug 8 N/A Bit 7 = dwu_dnc_ready Bit 6 = dnc_dwu_avail
Bits 5-0 = dnc_dwu_data 0x64 DncReplaceDebug 14 N/A Bit 13 =
edu_ready Bit 12 = iru_avail Bits 11-6 = iru_dn_mask Bits 5-0 =
iru_data 0x68 DncDiffuseDebug 14 N/A Bit 13 = dwu_dnc_ready Bit 12
= dnc_dwu_avail Bits 11-6 = edu_dn_mask Bits 5-0 = edu_data
Ink Replacement Unit
[0313] FIG. 29 shows a sub-block diagram for the ink replacement
unit.
Control Unit
[0314] The control unit is responsible for reading the dead nozzle
table from DRAM and making it available to the DNC via the dead
nozzle FIFO. The dead nozzle table is read from DRAM in single
256-bit accesses, receiving the data from the DIU over 4 clock
cycles (64-bits per cycle). Reading from DRAM is implemented by
means of the state machine shown in FIG. 30.
[0315] All counters and flags should be cleared after reset. When
Go transitions from 0 to 1 all counters and flags should take their
initial value. While the Go bit is 1, the state machine requests a
read access from the dead nozzle table in DRAM provided there is
enough space in its FIFO.
[0316] A modulo-4 counter, rd_count, is used to count each of the
64-bits received in a 256-bit read access. It is incremented
whenever diu_dnc_rvalid is asserted. When Go is 1, dn_table_radr is
set to dn_table_start_adr. As each 64-bit value is returned,
indicated by diu_dnc_rvalid being asserted, dn_table_radr is
compared to dn_table_end_adr: [0317] If rd_count equals 3 and
dn_table_radr equals dn_table_end_adr, then dn_table_radr is
updated to dn_table_start_adr. [0318] If rd_count equals 3 and
dn_table_radr does not equal dn_table_end_adr, then dn_table_radr
is incremented by 1.
[0319] A count is kept of the number of 64-bit values in the FIFO.
When diu_dnc_rvalid is 1 data is written to the FIFO by asserting
wr_en, and fifo_contents and fifo_wr_adr are both incremented.
[0320] When fifo_contents[3:0] is greater than 0 and edu_ready is
1, dnc_hcu_ready is asserted to indicate that the DNC is ready to
accept dots from the HCU. If hcu_dnc_avail is also 1 then a dotadv
pulse is sent to the GenMask unit, indicating the DNC has accepted
a dot from the HCU, and iru_avail is also asserted. After Go is
set, a single preload pulse is sent to the GenMask unit once the
FIFO contains data.
[0321] When a rd_adv pulse is received from the GenMask unit,
fifo_rd_adr[4:0] is then incremented to select the next 16-bit
value. If fifo_rd_adr[1:0]=11 then the next 64-bit value is read
from the FIFO by asserting rd_en, and fifo_contents[3:0] is
decremented.
Dead Nozzle FIFO
[0322] The dead nozzle FIFO conceptually is a 64-bit input, and
16-bit output FIFO to account for the 64-bit data transfers from
the DIU, and the individual 16-bit entries in the dead nozzle table
that are used in the GenMask unit. In reality, the FIFO is actually
8 entries deep and 64-bits wide (to accommodate two 256-bit
accesses).
[0323] On the DRAM side of the FIFO the write address is 64-bit
aligned while on the GenMask side the read address is 16-bit
aligned, i.e. the upper 3 bits are input as the read address for
the FIFO and the lower 2 bits are used to select 16 bits from the
64 bits (1st 16 bits read corresponds to bits 15-0, second 16 bits
to bits 31-16 etc.).
GenMask Unit
[0324] The GenMask unit generates the 6-bit dn_mask that is sent to
the replace unit. It consists of a 10-bit delta counter and a mask
register.
[0325] After Go is set, the GenMask unit will receive a preload
pulse from the control unit indicating the first dead nozzle table
entry is available at the output of the dead nozzle FIFO and should
be loaded into the delta counter and mask register. A rd_adv pulse
is generated so that the next dead nozzle table entry is presented
at the output of the dead nozzle FIFO. The delta counter is
decremented every time a dotadv pulse is received. When the delta
counter reaches 0, it gets loaded with the current delta value
output from the dead nozzle FIFO, i.e. bits 15-6, and the mask
register gets loaded with mask output from the dead nozzle FIFO,
i.e. bits 5-0. A rd_adv pulse is then generated so that the next
dead nozzle table entry is presented at the output of the dead
nozzle FIFO.
[0326] When the delta counter is 0 the value in the mask register
is output as the dn_mask, otherwise the dn_mask is all 0s. The
GenMask unit has no knowledge of the number of dots in a line, it
simply loads a counter to count the delta from one dead nozzle
column to the next. Thus the dead nozzle table should include null
identifiers if necessary so that the dead nozzle table covers the
first and last nozzle column in a line.
Replace Unit
[0327] Dead nozzle removal and ink replacement are implemented by
the combinatorial logic shown in FIG. 31. Dead nozzle removal is
performed by bit-wise ANDing of the inverse of the dn_mask with the
dot value.
[0328] The ink replacement mechanism has 6 ink replacement
patterns, one per ink plane, programmable by the CPU. The dead
nozzle mask is ANDed with the dot data to see if there are any
planes where the dot is active but the corresponding nozzle is
dead. The resultant value forms an enable, on a per ink basis, for
the ink replacement process. If replacement is enabled for a
particular ink, the values from the corresponding replacement
pattern register are ORed into the dot data. The output of the ink
replacement process is then filtered so that error diffusion is
only allowed for the planes in which error diffusion is
enabled.
[0329] The output of the ink replacement process is ORed with the
resultant dot after dead nozzle removal. If the dot position does
not contain a dead nozzle then the dn_mask will be all 0s and the
dot, hcu_dnc_data, will be passed through unchanged.
Error Diffusion Unit
[0330] FIG. 32 shows a sub-block diagram for the error diffusion
unit.
Random Bit Generator
[0331] The random bit value used to arbitrarily select the
direction of diffusion is generated by a maximum length 32-bit
LFSR. The tap points and feedback generation are shown in FIG. 33.
The LFSR generates a new bit for each dot in a line regardless of
whether the dot is dead or not, i.e shifting of the LFSR is enabled
when advdot equals 1. The LFSR can be initialised with a 32-bit
programmable seed value, random_seed. This seed value is loaded
into the LFSR whenever a write occurs to the RandomSeed register.
Note that the seed value must not be all 1s as this causes the LFSR
to lock-up.
Advance Dot Unit
[0332] The advance dot unit is responsible for determining in a
given cycle whether or not the error diffuse unit will accept a dot
from the ink replacement unit or make a dot available to the
fixative correct unit and on to the DWU. It therefore receives the
dwu_dnc_ready control signal from the DWU, the iru_avail flag from
the ink replacement unit, and generates dnc_dwu_avail and edu_ready
control flags.
[0333] Only the dwu_dnc_ready signal needs to be checked to see if
a dot can be accepted and asserts edu_ready to indicate this. If
the error diffuse unit is ready to accept a dot and the ink
replacement unit has a dot available, then a advdot pulse is given
to shift the dot into the pipeline in the diffuse unit. Note that
since the error diffusion operates on 3 dots, the advance dot unit
ignores dwu_dnc_ready initially until 3 dots have been accepted by
the diffuse unit. Similarly dnc_dwu_avail is not asserted until the
diffuse unit contains 3 dots and the ink replacement unit has a dot
available.
Diffuse Unit
[0334] The diffuse unit contains the combinatorial logic to
implement the truth table. The diffuse unit receives a dot
consisting of 6 color planes (1 bit per plane) as well as an
associated 6-bit dead nozzle mask value.
[0335] Error diffusion is applied to all 6 planes of the dot in
parallel. Since error diffusion operates on 3 dots, the diffuse
unit has a pipeline of 3 dots and their corresponding dead nozzle
mask values. The first dot received is referred to as dot A, and
the second as dot B, and the third as dot C. Dots are shifted along
the pipeline whenever advdot is 1. A count is also kept of the
number of dots received. It is incremented whenever advdot is 1,
and wraps to 0 when it reaches max_dot. When the dot count is 0 dot
C corresponds to the first dot in a line. When the dot count is 1
dot A corresponds to the last dot in a line.
[0336] In any given set of 3 dots only dot B can be defined as
containing a dead nozzle(s). Dead nozzles are identified by bits
set in iru_dn_mask. If dot B contains a dead nozzle(s), the
corresponding bit(s) in dot A, dot C, the dead nozzle mask value
for A, the dead nozzle mask value for C, the dot count, as well as
the random bit value are input to the truth table logic and the
dots A, B and C assigned accordingly. If dot B does not contain a
dead nozzle then the dots are shifted along the pipeline
unchanged.
Fixative Correction Unit
[0337] The fixative correction unit consists of combinatorial logic
to implement fixative correction as defined in Table 15. For each
output dot the DNC determines if fixative is required for the new
compensated dot data word and whether fixative is activated already
for that dot. [0338] FixativePresent=((FixativeMask1|FixativeMask2)
& edu_data) !=0 [0339] FixativeRequired=(FixativeRequiredMask
& edu_data) !=0 It then looks up the truth table to see what
action, if any, needs to be taken.
TABLE-US-00016 [0339] TABLE 15 Truth table for fixative correction
Fixative Fixative Present required Action Output 1 1 Output dot as
is. dnc_dwu_data = edu_data 1 0 Clear fixative dnc_dwu_data =
(edu_data) & plane. ~(FixativeMask1 | FixativeMask2) 0 1
Attempt to if (FixativeMask1 & DnMask) != 0 add fixative.
dnc_dwu_data = (edu_data) | (FixativeMask2 & ~DnMask) else
dnc_dwu_data = (edu_data) | (FixativeMask1) 0 0 Output dot as is.
dnc_dwu_data = edu_data
[0340] When attempting to add fixative the DNC first tries to add
it into the plane defined by FixativeMask1. However, if this plane
is dead then it tries to add fixative by placing it into the plane
defined by FixativeMask2. Note that if both FixativeMask1 and
FixativeMask2 are both all 0s then the dot data will not be
changed.
Dotline Writer Unit (DWU)
[0341] The Dotline Writer Unit (DWU) receives 1 dot (6 bits) of
color information per cycle from the DNC. Dot data received is
bundled into 256-bit words and transferred to the DRAM. The DWU (in
conjunction with the LLU) implements a dot line FIFO mechanism to
compensate for the physical placement of nozzles in a printhead,
and provides data rate smoothing to allow for local complexities in
the dot data generate pipeline.
[0342] The physical placement of nozzles in the printhead means
that in one firing sequence of all nozzles, dots will be produced
over several print lines. The printhead consists of 12 rows of
nozzles, one for each color of odd and even dots. Odd and even
nozzles are separated by D.sub.2 print lines and nozzles of
different colors are separated by D.sub.1 print lines. See FIG. 35
for reference. The first color to be printed is the first row of
nozzles encountered by the incoming paper. In the example this is
color 0 odd, although is dependent on the printhead type. Paper
passes under printhead moving downwards.
[0343] For example if the physical separation of each half row is
80 .quadrature.m equating to D.sub.1=D.sub.2=5 print lines at 1600
dpi. This means that in one firing sequence, color 0 odd nozzles
will fire on dotline L, color 0 even nozzles will fire on dotline
L-D.sub.1, color 1 odd nozzles will fire on dotline
L-D.sub.1-D.sub.2 and so on over 6 color planes odd and even
nozzles. The total number of lines fired over is given as 0+5+5 . .
. +5=0+11.times.5=55. See FIG. 36 for example diagram.
[0344] It is expected that the physical spacing of the printhead
nozzles will be 80 .mu.m (or 5 dot lines), although there is no
dependency on nozzle spacing. The DWU is configurable to allow
other line nozzle spacings.
Line Loader Unit (LLU)
[0345] The Line Loader Unit (LLU) reads dot data from the line
buffers in DRAM and structures the data into even and odd dot
channels destined for the same print time. The blocks of dot data
are transferred to the PHI and then to the printhead. FIG. 48 shows
a high level data flow diagram of the LLU in context.
[0346] The DWU re-orders dot data into 12 separate dot data line
FIFOs in the DRAM. Each FIFO corresponds to 6 colors of odd and
even data. The LLU reads the dot data line FIFOs and sends the data
to the printhead interface. The LLU decides when data should be
read from the dot data line FIFOs to correspond with the time that
the particular nozzle on the printhead is passing the current line.
The interaction of the DWU and LLU with the dot line FIFOs
compensates for the physical spread of nozzles firing over several
lines at once. FIG. 49 shows the physical relationship of nozzle
rows and the line time the LLU starts reading from the dot line
store.
[0347] Within each line of dot data the LLU is required to generate
an even and odd dot data stream to the PHI block. FIG. 50 shows the
even and dot streams as they would map to an example bi-lithic
printhead. The PHI block determines which stream should be directed
to which printhead IC.
PrintHead Interface (PHI)
[0348] The Printhead interface (PHI) accepts dot data from the LLU
and transmits the dot data to the printhead, using the printhead
interface mechanism. The PHI generates the control and timing
signals necessary to load and drive the bi-lithic printhead. The
CPU determines the line update rate to the printhead and adjusts
the line sync frequency to produce the maximum print speed to
account for the printhead IC's size ratio and inherent latencies in
the syncing system across multiple SoPECs. The PHI also needs to
consider the order in which dot data is loaded in the printhead.
This is dependent on the construction of the printhead and the
relative sizes of printhead ICs used to create the printhead.
[0349] The printing process is a real-time process. Once the
printing process has started, the next printline's data must be
transferred to the printhead before the next line sync pulse is
received by the printhead. Otherwise the printing process will
terminate with a buffer underrun error. The PHI can be configured
to drive a single printhead IC with or without synchronization to
other SoPECs. For example the PHI could drive a single IC printhead
(i.e. a printhead constructed with one IC only), or dual IC
printhead with one SoPEC device driving each printhead IC.
[0350] The PHI interface provides a mechanism for the CPU to
directly control the PHI interface pins, allowing the CPU to access
the bi-lithic printhead to: [0351] determine printhead temperature
[0352] test for and determine dead nozzles for each printhead IC
[0353] initialize each printhead IC [0354] pre-heat each printhead
IC FIG. 58 shows a high level data flow diagram of the PHI in
context.
* * * * *