U.S. patent application number 12/790945 was filed with the patent office on 2010-09-23 for method for dead nozzle remapping.
This patent application is currently assigned to Silverbrook Research Pty Ltd. Invention is credited to Richard Thomas Plunkett, Simon Robert Walmsley.
Application Number | 20100238213 12/790945 |
Document ID | / |
Family ID | 32471018 |
Filed Date | 2010-09-23 |
United States Patent
Application |
20100238213 |
Kind Code |
A1 |
Plunkett; Richard Thomas ;
et al. |
September 23, 2010 |
METHOD FOR DEAD NOZZLE REMAPPING
Abstract
A method of accounting for dead nozzle remapping in a
multi-nozzle printhead includes defining a first fixative plane and
a second fixative plane; determining a first color plane requiring
the fixative; determining if fixative is present in the first color
plane; determining if the first color plane is dead; and adding
fixative to a second color plane when it is determined that the
first color plane is dead.
Inventors: |
Plunkett; Richard Thomas;
(Balmain, AU) ; Walmsley; Simon Robert; (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/790945 |
Filed: |
May 31, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10727181 |
Dec 2, 2003 |
|
|
|
12790945 |
|
|
|
|
Current U.S.
Class: |
347/9 |
Current CPC
Class: |
G06F 21/57 20130101;
B41J 2/04543 20130101; B41J 2/04563 20130101; H04N 1/405 20130101;
B41J 2/04505 20130101; B41J 2/04586 20130101; G06F 21/64 20130101;
G06F 21/71 20130101; B41J 2/04573 20130101; Y10S 707/99939
20130101; G06F 21/554 20130101; G06F 21/78 20130101; H03K 5/1252
20130101; B41J 2/0451 20130101; Y10S 707/99933 20130101; B41J
2202/20 20130101; Y10T 29/49401 20150115; G06F 21/575 20130101;
B41J 2/04528 20130101; B41J 2/04541 20130101; B41J 2/04508
20130101; G06F 21/73 20130101; G06F 21/74 20130101 |
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 method of accounting for dead nozzle remapping in a
multi-nozzle printhead, the method comprising: defining a first
fixative plane and a second fixative plane; determining a first
color plane requiring the fixative; determining if fixative is
present in the first color plane; determining if the first color
plane is dead; and adding fixative to a second color plane when it
is determined that the first color plane is dead.
2. The method according to claim 1, wherein the first fixative
plane has a higher priority than the second fixative plane.
3. The method according to claim 1, wherein the fixative defined by
the first fixative plane and the second fixative plane is a
multi-part fixative.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] The present application is a Continuation of U.S.
application Ser. No. 10/727,181 filed Dec. 2, 2003, all of which
are herein incorporated by reference.
FIELD OF INVENTION
[0002] The present invention relates to techniques for outputting
one or more lines of a dither matrix from a memory containing the
dither matrix.
BACKGROUND OF INVENTION
[0003] Manufacturing a printhead that has relatively high
resolution and print-speed raises a number of problems.
[0004] 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] 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.
SUMMARY OF INVENTION
[0009] According to an aspect of the present disclosure, a method
of accounting for dead nozzle remapping in a multi-nozzle printhead
includes defining a first fixative plane and a second fixative
plane; determining a first color plane requiring the fixative;
determining if fixative is present in the first color plane;
determining if the first color plane is dead; and adding fixative
to a second color plane when it is determined that the first color
plane is dead.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] Preferred and other embodiments of the invention will now be
described, by way of example only, with reference to the
accompanying drawings, in which:
[0011] FIG. 1 is an example of state machine notation
[0012] FIG. 2 shows document data flow in a printer
[0013] FIG. 3 is an example of a single printer controller
(hereinafter "SoPEC") A4 simplex printer system
[0014] FIG. 4 is an example of a dual SoPEC A4 duplex printer
system
[0015] FIG. 5 is an example of a dual SoPEC A3 simplex printer
system
[0016] FIG. 6 is an example of a quad SoPEC A3 duplex printer
system
[0017] FIG. 7 is an example of a SoPEC A4 simplex printing system
with an extra SoPEC used as DRAM storage
[0018] FIG. 8 is an example of an A3 duplex printing system
featuring four printing SoPECs
[0019] FIG. 9 shows pages containing different numbers of bands
[0020] FIG. 10 shows the contents of a page band
[0021] FIG. 11 illustrates a page data path from host to SoPEC
[0022] FIG. 12 shows a page structure
[0023] FIG. 13 shows a SoPEC system top level partition
[0024] FIG. 14 shows a SoPEC CPU memory map (not to scale)
[0025] FIG. 15 is a block diagram of CPU
[0026] FIG. 16 shows CPU bus transactions
[0027] FIG. 17 shows a state machine for a CPU subsystem slave
[0028] FIG. 18 shows a SoPEC CPU memory map (not to scale)
[0029] FIG. 19 shows an external signal view of a memory management
unit (hereinafter "MMU") sub-block partition
[0030] FIG. 20 shows an internal signal view of an MMU sub-block
partition
[0031] FIG. 21 shows a DRAM write buffer
[0032] FIG. 22 shows DIU waveforms for multiple transactions
[0033] FIG. 23 shows a SoPEC LEON CPU core
[0034] FIG. 24 shows a cache data RAM wrapper
[0035] FIG. 25 shows a realtime debug unit block diagram
[0036] FIG. 26 shows interrupt acknowledge cycles for single and
pending interrupts
[0037] FIG. 27 shows an A3 duplex system featuring four printing
SoPECs with a single SoPEC DRAM device
[0038] FIG. 28 is an SCB block diagram
[0039] FIG. 29 is a logical view of the SCB of FIG. 28
[0040] FIG. 30 shows an ISI configuration with four SoPEC
devices
[0041] FIG. 31 shows half-duplex interleaved transmission from
ISIMaster to ISISlave
[0042] FIG. 32 shows ISI transactions
[0043] FIG. 33 shows an ISI long packet
[0044] FIG. 34 shows an ISI ping packet
[0045] FIG. 35 shows a short ISI packet
[0046] FIG. 36 shows successful transmission of two long packets
with sequence bit toggling
[0047] FIG. 37 shows sequence bit operation with errored long
packet
[0048] FIG. 38 shows sequence bit operation with ACK error
[0049] FIG. 39 shows an ISI sub-block partition
[0050] FIG. 40 shows an ISI serial interface engine functional
block diagram
[0051] FIG. 41 is an SIE edge detection and data IO diagram
[0052] FIG. 42 is an SIE Rx/Tx state machine Tx cycle state
diagram
[0053] FIG. 43 shows an SIE Rx/Tx state machine Tx bit stuff `0`
cycle state diagram
[0054] FIG. 44 shows an SIE Rx/Tx state machine Tx bit stuff `1`
cycle state diagram
[0055] FIG. 45 shows an SIE Rx/Tx state machine Rx cycle state
diagram
[0056] FIG. 46 shows an SIE Tx functional timing example
[0057] FIG. 47 shows an SIE Rx functional timing example
[0058] FIG. 48 shows an SIE Rx/Tx FIFO block diagram
[0059] FIG. 49 shows SIE Rx/Tx FIFO control signal gating
[0060] FIG. 50 shows an SIE bit stuffing state machine Tx cycle
state diagram
[0061] FIG. 51 shows an SIE bit stripping state machine Rx cycle
state diagram
[0062] FIG. 52 shows a CRC 16 generation/checking shift
register
[0063] FIG. 53 shows circular buffer operation
[0064] FIG. 54 shows duty cycle select
[0065] FIG. 55 shows a GPIO partition
[0066] FIG. 56 shows a motor control RTL diagram
[0067] FIG. 57 is an input de-glitch RTL diagram
[0068] FIG. 58 is a frequency analyser RTL diagram
[0069] FIG. 59 shows a brushless DC controller
[0070] FIG. 60 shows a period measure unit
[0071] FIG. 61 shows line synch generation logic
[0072] FIG. 62 shows an ICU partition
[0073] FIG. 63 is an interrupt clear state diagram
[0074] FIG. 63A Timers sub-block partition diagram
[0075] FIG. 64 is a watchdog timer RTL diagram
[0076] FIG. 65 is a generic timer RTL diagram
[0077] FIG. 66 is a schematic of a timing pulse generator
[0078] FIG. 67 is a Pulse generator RTL diagram
[0079] FIG. 68 shows a SoPEC clock relationship
[0080] FIG. 69 shows a CPR block partition
[0081] FIG. 70 shows reset deglitch logic
[0082] FIG. 71 shows reset synchronizer logic
[0083] FIG. 72 is a clock gate logic diagram
[0084] FIG. 73 shows a PLL and Clock divider logic
[0085] FIG. 74 shows a PLL control state machine diagram
[0086] FIG. 75 shows a LSS master system-level interface
[0087] FIG. 76 shows START and STOP conditions
[0088] FIG. 77 shows an LSS transfer of 2 data bytes
[0089] FIG. 78 is an example of an LSS write to a QA Chip
[0090] FIG. 79 is an example of an LSS read from QA Chip
[0091] FIG. 80 shows an LSS block diagram
[0092] FIG. 81 shows an LSS multi-command transaction
[0093] FIG. 82 shows start and stop generation based on previous
bus state
[0094] FIG. 83 shows an LSS master state machine
[0095] FIG. 84 shows LSS master timing
[0096] FIG. 85 shows a SoPEC system top level partition
[0097] FIG. 86 shows an ead bus with 3 cycle random DRAM read
accesses
[0098] FIG. 87 shows interleaving of CPU and non-CPU read
accesses
[0099] FIG. 88 shows interleaving of read and write accesses with 3
cycle random DRAM accesses
[0100] FIG. 89 shows interleaving of write accesses with 3 cycle
random DRAM accesses
[0101] FIG. 90 shows a read protocol for a SoPEC Unit making a
single 256-bit access
[0102] FIG. 91 shows a read protocol for a SoPEC Unit making a
single 256-bit access
[0103] FIG. 92 shows a write protocol for a SoPEC Unit making a
single 256-bit access
[0104] FIG. 93 shows a protocol for a posted, masked, 128-bit write
by the CPU
[0105] FIG. 94 shows a write protocol shown for CDU making four
contiguous 64-bit accesses
[0106] FIG. 95 shows timeslot-based arbitration
[0107] FIG. 96 shows timeslot-based arbitration with separate
pointers
[0108] FIG. 97 shows a first example (a) of separate read and write
arbitration
[0109] FIG. 98 shows a second example (b) of separate read and
write arbitration
[0110] FIG. 99 shows a third example (c) of separate read and write
arbitration
[0111] FIG. 100 shows a DIU partition
[0112] FIG. 101 shows a DIU partition
[0113] FIG. 102 shows multiplexing and address translation logic
for two memory instances
[0114] FIG. 103 shows a timing of dau dcu valid, dcu dau adv and
dcu dau wady
[0115] FIG. 104 shows a DCU state machine
[0116] FIG. 105 shows random read timing
[0117] FIG. 106 shows random write timing
[0118] FIG. 107 shows refresh timing
[0119] FIG. 108 shows page mode write timing
[0120] FIG. 109 shows timing of non-CPU DIU read access
[0121] FIG. 110 shows timing of CPU DIU read access
[0122] FIG. 111 shows a CPU DIU read access
[0123] FIG. 112 shows timing of CPU DIU write access
[0124] FIG. 113 shows timing of a non-CDU/non-CPU DIU write
access
[0125] FIG. 114 shows timing of CDU DIU write access
[0126] FIG. 115 shows command multiplexor sub-block partition
[0127] FIG. 116 shows command multiplexor timing at DIU requestors
interface
[0128] FIG. 117 shows generation of re arbitrate and re arbitrate
wady
[0129] FIG. 118 shows CPU interface and arbitration logic
[0130] FIG. 119 shows arbitration timing
[0131] FIG. 120 shows setting RotationSync to enable a new
rotation.
[0132] FIG. 121 shows a timeslot based arbitration
[0133] FIG. 122 shows a timeslot based arbitration with separate
pointers
[0134] FIG. 123 shows a CPU pre-access write lookahead pointer
[0135] FIG. 124 shows arbitration hierarchy
[0136] FIG. 125 shows hierarchical round-robin priority
comparison
[0137] FIG. 126 shows a read multiplexor partition
[0138] FIG. 127 shows a read command queue (4 deep buffer)
[0139] FIG. 128 shows state-machines for shared read bus
accesses
[0140] FIG. 129 shows a write multiplexor partition
[0141] FIG. 130 shows a read multiplexer timing for back-to-back
shared read bus transfer
[0142] FIG. 131 shows a write multiplexer partition
[0143] FIG. 132 shows a block diagram of a PCU
[0144] FIG. 133 shows PCU accesses to PEP registers
[0145] FIG. 134 shows command arbitration and execution
[0146] FIG. 135 shows DRAM command access state machine
[0147] FIG. 136 shows an outline of contone data flow with respect
to CDU
[0148] FIG. 137 shows a DRAM storage arrangement for a single line
of JPEG 8.times.8 blocks in 4 colors
[0149] FIG. 138 shows a read control unit state machine
[0150] FIG. 139 shows a memory arrangement of JPEG blocks
[0151] FIG. 140 shows a contone data write state machine
[0152] FIG. 141 shows lead-in and lead-out clipping of contone data
in multi-SoPEC environment
[0153] FIG. 142 shows a block diagram of CFU
[0154] FIG. 143 shows a DRAM storage arrangement for a single line
of JPEG blocks in 4 colors
[0155] FIG. 144 shows a block diagram of color space converter
[0156] FIG. 145 shows a converter/invertor
[0157] FIG. 146 shows a high-level block diagram of LBD in
context
[0158] FIG. 147 shows a schematic outline of the LBD and the
SFU
[0159] FIG. 148 shows a block diagram of lossless bi-level
decoder
[0160] FIG. 149 shows a stream decoder block diagram
[0161] FIG. 150 shows a command controller block diagram
[0162] FIG. 151 shows a state diagram for command controller (CC)
state machine
[0163] FIG. 152 shows a next edge unit block diagram
[0164] FIG. 153 shows a next edge unit buffer diagram
[0165] FIG. 154 shows a next edge unit edge detect diagram
[0166] FIG. 155 shows a state diagram for the next edge unit state
machine
[0167] FIG. 156 shows a line fill unit block diagram
[0168] FIG. 157 shows a state diagram for the Line Fill Unit (LFU)
state machine
[0169] FIG. 158 shows a bi-level DRAM buffer
[0170] FIG. 159 shows interfaces between LBD/SFU/HCU
[0171] FIG. 160 shows an SFU sub-block partition
[0172] FIG. 161 shows an LBDPrevLineFifo sub-block
[0173] FIG. 162 shows timing of signals on the LBDPrevLineFIFO
interface to DIU and address generator
[0174] FIG. 163 shows timing of signals on LBDPrevLineFIFO
interface to DIU and address generator
[0175] FIG. 164 shows LBDNextLineFifo sub-block
[0176] FIG. 165 shows timing of signals on LBDNextLineFIFO
interface to DIU and address generator
[0177] FIG. 166 shows LBDNextLineFIFO DIU interface state
diagram
[0178] FIG. 167 shows an LDB to SFU write interface
[0179] FIG. 168 shows an LDB to SFU read interface (within a
line)
[0180] FIG. 169 shows an HCUReadLineFifo Sub-block
[0181] FIG. 170 shows a DIU write Interface
[0182] FIG. 171 shows a DIU Read Interface multiplexing by
select_hrfplf
[0183] FIG. 172 shows DIU read request arbitration logic
[0184] FIG. 173 shows address generation
[0185] FIG. 174 shows an X scaling control unit
[0186] FIG. 175 Y shows a scaling control unit
[0187] FIG. 176 shows an overview of X and Y scaling at HCU
interface
[0188] FIG. 177 shows a high level block diagram of TE in
context
[0189] FIG. 178 shows a QR Code
[0190] FIG. 179 shows Netpage tag structure
[0191] FIG. 180 shows a Netpage tag with data rendered at 1600 dpi
(magnified view)
[0192] FIG. 181 shows an example of 2.times.2 dots for each block
of QR code
[0193] FIG. 182 shows placement of tags for portrait &
landscape printing
[0194] FIG. 183 shows agGeneral representation of tag placement
[0195] FIG. 184 shows composition of SoPEC's tag format
structure
[0196] FIG. 185 shows a simple 3.times.3 tag structure
[0197] FIG. 186 shows 3.times.3 tag redesigned for 21.times.21 area
(not simple replication)
[0198] FIG. 187 shows a TE Block Diagram
[0199] FIG. 188 shows a TE Hierarchy
[0200] FIG. 189 shows a block diagram of PCU accesses
[0201] FIG. 190 shows a tag encoder top-level FSM
[0202] FIG. 191 shows generated control signals
[0203] FIG. 192 shows logic to combine dot information and encoded
data
[0204] FIG. 193 shows generation of Lastdotintag/1
[0205] FIG. 194 shows generation of Dot Position Valid
[0206] FIG. 195 shows generation of write enable to the TFU
[0207] FIG. 196 shows generation of Tag Dot Number
[0208] FIG. 197 shows TDI Architecture
[0209] FIG. 198 shows data flow through the TDI
[0210] FIG. 199 shows raw tag data interface block diagram
[0211] FIG. 200 shows an RTDI State Flow Diagram
[0212] FIG. 201 shows a relationship between TE_endoftagdata,
cdu_startofbandstore and cdu_endofbandstore
[0213] FIG. 202 shows a TDi State Flow Diagram
[0214] FIG. 203 shows mapping of the tag data to codewords 0-7
[0215] FIG. 204 shows coding and mapping of uncoded fixed tag data
for (15,5) RS encoder
[0216] FIG. 205 shows mapping of pre-coded fixed tag data
[0217] FIG. 206 shows coding and mapping of variable tag data for
(15,7) RS encoder
[0218] FIG. 207 shows coding and mapping of uncoded fixed tag data
for (15,7) RS encoder
[0219] FIG. 208 shows mapping of 2D decoded variable tag data
[0220] FIG. 209 shows a simple block diagram for an m=4 Reed
Solomon encoder
[0221] FIG. 210 shows an RS encoder I/O diagram
[0222] FIG. 211 shows a (15,5) & (15,7) RS encoder block
diagram
[0223] FIG. 212 shows a (15,5) RS encoder timing diagram
[0224] FIG. 213 shows a (15,7) RS encoder timing diagram
[0225] FIG. 214 shows a circuit for multiplying by alpha3
[0226] FIG. 215 shows adding two field elements
[0227] FIG. 216 shows an RS encoder implementation
[0228] FIG. 217 shows an encoded tag data interface
[0229] FIG. 218 shows an encoded fixed tag data interface
[0230] FIG. 219 shows an encoded variable tag data interface
[0231] FIG. 220 shows an encoded variable tag data sub-buffer
[0232] FIG. 221 shows a breakdown of the tag format structure
[0233] FIG. 222 shows a TFSI FSM state flow diagram
[0234] FIG. 223 shows a TFS block diagram
[0235] FIG. 224 shows a table A interface block diagram
[0236] FIG. 225 shows a table A address generator
[0237] FIG. 226 shows a table C interface block diagram
[0238] FIG. 227 shows a table B interface block diagram
[0239] FIG. 228 shows interfaces between TE, TFU and HCU
[0240] FIG. 229 shows a 16-byte FIFO in TFU
[0241] FIG. 230 shows a high level block diagram showing the HCU
and its external interfaces
[0242] FIG. 231 shows a block diagram of the HCU
[0243] FIG. 232 shows a block diagram of the control unit
[0244] FIG. 233 shows a block diagram of determine advdot unit
[0245] FIG. 234 shows a page structure
[0246] FIG. 235 shows a block diagram of a margin unit
[0247] FIG. 236 shows a block diagram of a dither matrix table
interface
[0248] FIG. 237 shows an example of reading lines of dither matrix
from DRAM
[0249] FIG. 238 shows a state machine to read dither matrix
table
[0250] FIG. 239 shows a contone dotgen unit
[0251] FIG. 240 shows a block diagram of dot reorg unit
[0252] FIG. 241 shows an HCU to DNC interface (also used in DNC to
DWU, LLU to PHI)
[0253] FIG. 242 shows SFU to HCU interface (all feeders to HCU)
[0254] FIG. 243 shows representative logic of the SFU to HCU
interface
[0255] FIG. 244 shows a high-level block diagram of DNC
[0256] FIG. 245 shows a dead nozzle table format
[0257] FIG. 246 shows set of dots operated on for error
diffusion
[0258] FIG. 247 shows a block diagram of DNC
[0259] FIG. 248 shows a sub-block diagram of ink replacement
unit
[0260] FIG. 249 shows a dead nozzle table state machine
[0261] FIG. 250 shows logic for dead nozzle removal and ink
replacement
[0262] FIG. 251 shows a sub-block diagram of error diffusion
unit
[0263] FIG. 252 shows a maximum length 32-bit LFSR used for random
bit generation
[0264] FIG. 253 shows a high-level data flow diagram of DWU in
context
[0265] FIG. 254 shows a printhead nozzle layout for 36-nozzle
bi-lithic printhead
[0266] FIG. 255 shows a printhead nozzle layout for a 36-nozzle
bi-lithic printhead
[0267] FIG. 256 shows a dot line store logical representation
[0268] FIG. 257 shows a conceptual view of printhead row
alignment
[0269] FIG. 258 shows a conceptual view of printhead rows (as seen
by the LLU and PHI)
[0270] FIG. 259 shows a comparison of 1.5.times.v 2.times.
buffering
[0271] FIG. 260 shows an even dot order in DRAM (increasing sense,
13320 dot wide line)
[0272] FIG. 261 shows an even dot order in DRAM (decreasing sense,
13320 dot wide line)
[0273] FIG. 262 shows a dotline FIFO data structure in DRAM
[0274] FIG. 263 shows a DWU partition
[0275] FIG. 264 shows a buffer address generator sub-block
[0276] FIG. 265 shows a DIU Interface sub-block
[0277] FIG. 266 shows an interface controller state diagram
[0278] FIG. 267 shows a high level data flow diagram of LLU in
context
[0279] FIG. 268 shows paper and printhead nozzles relationship
(example with D1=D2=5)
[0280] FIG. 269 shows printhead structure and dot generate
order
[0281] FIG. 270 shows an order of dot data generation and
transmission
[0282] FIG. 271 shows a conceptual view of printhead rows
[0283] FIG. 272 shows a dotline FIFO data structure in DRAM (LLU
specification)
[0284] FIG. 273 shows an LLU partition
[0285] FIG. 274 shows a dot generator RTL diagram
[0286] FIG. 275 shows a DIU interface
[0287] FIG. 276 shows an interface controller state diagram
[0288] FIG. 277 shows high-level data flow diagram of PHI in
context
[0289] FIG. 278 shows power on reset
[0290] FIG. 279 shows printhead data rate equalization
[0291] FIG. 280 shows a printhead structure and dot generate
order
[0292] FIG. 281 shows an order of dot data generation and
transmission
[0293] FIG. 282 shows an order of dot data generation and
transmission (single printhead case)
[0294] FIG. 283 shows printhead interface timing parameters
[0295] FIG. 284 shows printhead timing with margining
[0296] FIG. 285 shows a PHI block partition
[0297] FIG. 286 shows a sync generator state diagram
[0298] FIG. 287 shows a line sync de-glitch RTL diagram
[0299] FIG. 288 shows a fire generator state diagram
[0300] FIG. 289 shows a PHI controller state machine
[0301] FIG. 290 shows a datapath unit partition
[0302] FIG. 291 shows a dot order controller state diagram
[0303] FIG. 292 shows a data generator state diagram
[0304] FIG. 293 shows data serializer timing
[0305] FIG. 294 shows a data serializer RTL Diagram
[0306] FIG. 295 shows printhead types 0 to 7
[0307] FIG. 296 shows an ideal join between two dilithic printhead
segments
[0308] FIG. 297 shows an example of a join between two bilithic
printhead segments
[0309] FIG. 298 shows printable vs non-printable area under new
definition (looking at colors as if 1 row only)
[0310] FIG. 299 shows identification of printhead nozzles and
shift-register sequences for printheads in arrangement 1
[0311] FIG. 300 shows demultiplexing of data within the printheads
in arrangement 1
[0312] FIG. 301 shows double data rate signalling for a type 0
printhead in arrangement 1
[0313] FIG. 302 shows double data rate signalling for a type 1
printhead in arrangement 1
[0314] FIG. 303 shows identification of printheads nozzles and
shift-register sequences for printheads in arrangement 2
[0315] FIG. 304 shows demultiplexing of data within the printheads
in arrangement 2
[0316] FIG. 305 shows double data rate signalling for a type 0
printhead in arrangement 2
[0317] FIG. 306 shows double data rate signalling for a type 1
printhead in arrangement 2
[0318] FIG. 307 shows all 8 printhead arrangements
[0319] FIG. 308 shows a printhead structure
[0320] FIG. 309 shows a column Structure
[0321] FIG. 310 shows a printhead dot shift register dot mapping to
page
[0322] FIG. 311 shows data timing during printing
[0323] FIG. 312 shows print quality
[0324] FIG. 313 shows fire and select shift register setup for
printing
[0325] FIG. 314 shows a fire pattern across butt end of printhead
chips
[0326] FIG. 315 shows fire pattern generation
[0327] FIG. 316 shows determination of select shift register
value
[0328] FIG. 317 shows timing for printing signals
[0329] FIG. 318 shows initialisation of printheads
[0330] FIG. 319 shows a nozzle test latching circuit
[0331] FIG. 320 shows nozzle testing
[0332] FIG. 321 shows a temperature reading
[0333] FIG. 322 shows CMOS testing
[0334] FIG. 323 shows a reticle layout
[0335] FIG. 324 shows a stepper pattern on Wafer
[0336] FIG. 325 shows relationship between datasets
[0337] FIG. 326 shows a validation hierarchy
[0338] FIG. 327 shows development of operating system code
[0339] FIG. 328 shows protocol for directly verifying reads from
ChipR
[0340] FIG. 329 shows a protocol for signature translation
protocol
[0341] FIG. 330 shows a protocol for a direct authenticated
write
[0342] FIG. 331 shows an alternative protocol for a direct
authenticated write
[0343] FIG. 332 shows a protocol for basic update of
permissions
[0344] FIG. 333 shows a protocol for a multiple-key update
[0345] FIG. 334 shows a protocol for a single-key authenticated
read
[0346] FIG. 335 shows a protocol for a single-key authenticated
write
[0347] FIG. 336 shows a protocol for a single-key update of
permissions
[0348] FIG. 337 shows a protocol for a single-key update
[0349] FIG. 338 shows a protocol for a multiple-key single-M
authenticated read
[0350] FIG. 339 shows a protocol for a multiple-key authenticated
write
[0351] FIG. 340 shows a protocol for a multiple-key update of
permissions
[0352] FIG. 341 shows a protocol for a multiple-key update
[0353] FIG. 342 shows a protocol for a multiple-key multiple-M
authenticated read
[0354] FIG. 343 shows a protocol for a multiple-key authenticated
write
[0355] FIG. 344 shows a protocol for a multiple-key update of
permissions
[0356] FIG. 345 shows a protocol for a multiple-key update
[0357] FIG. 346 shows relationship of permissions bits to M[n]
access bits
[0358] FIG. 347 shows 160-bit maximal period LFSR
[0359] FIG. 348 shows clock filter
[0360] FIG. 349 shows tamper detection line
[0361] FIG. 350 shows an oversize nMOS transistor layout of Tamper
Detection Line
[0362] FIG. 351 shows a Tamper Detection Line
[0363] FIG. 352 shows how Tamper Detection Lines cover the Noise
Generator
[0364] FIG. 353 shows a prior art FET Implementation of CMOS
inverter
[0365] FIG. 354 shows non-flashing CMOS
[0366] FIG. 355 shows components of a printer-based refill
device
[0367] FIG. 356 shows refilling of printers by printer-based refill
device
[0368] FIG. 357 shows components of a home refill station
[0369] FIG. 358 shows a three-ink reservoir unit
[0370] FIG. 359 shows refill of ink cartridges in a home refill
station
[0371] FIG. 360 shows components of a commercial refill station
[0372] FIG. 361 shows an ink reservoir unit
[0373] FIG. 362 shows refill of ink cartridges in a commercial
refill station (showing a single refill unit)
[0374] FIG. 363 shows equivalent signature generation
[0375] FIG. 364 shows a basic field definition
[0376] FIG. 365 shows an example of defining field sizes and
positions
[0377] FIG. 366 shows permissions
[0378] FIG. 367 shows a first example of permissions for a
field
[0379] FIG. 368 shows a second example of permissions for a
field
[0380] FIG. 369 shows field attributes
[0381] FIG. 370 shows an output signature generation data format
for Read
[0382] FIG. 371 shows an input signature verification data format
for Test
[0383] FIG. 372 shows an output signature generation data format
for Translate
[0384] FIG. 373 shows an input signature verification data format
for WriteAuth
[0385] FIG. 374 shows input signature data format for
ReplaceKey
[0386] FIG. 375 shows a key replacement map
[0387] FIG. 376 shows a key replacement map after K1 is
replaced
[0388] FIG. 377 shows a key replacement process
[0389] FIG. 378 shows an output signature data format for
GetProgramKey
[0390] FIG. 379 shows transfer and rollback process
[0391] FIG. 380 shows an upgrade flow
[0392] FIG. 381 shows authorised ink refill paths in the printing
system
[0393] FIG. 382 shows an input signature verification data format
for XferAmount
[0394] FIG. 383 shows a transfer and rollback process
[0395] FIG. 384 shows an upgrade flow
[0396] FIG. 385 shows authorised upgrade paths in the printing
system
[0397] FIG. 386 shows a direct signature validation sequence
[0398] FIG. 387 shows signature validation using translation
[0399] FIG. 388 shows setup of preauth field attributes
[0400] FIG. 389 shows a high level block diagram of QA Chip
[0401] FIG. 390 shows an analogue unit
[0402] FIG. 391 shows a serial bus protocol for trimming
[0403] FIG. 392 shows a block diagram of a trim unit
[0404] FIG. 393 shows a block diagram of a CPU of the QA chip
[0405] FIG. 394 shows block diagram of an MIU
[0406] FIG. 395 shows a block diagram of memory components
[0407] FIG. 396 shows a first byte sent to an IOU
[0408] FIG. 397 shows a block diagram of the IOU
[0409] FIG. 398 shows a relationship between external SDa and SCIk
and generation of internal signals
[0410] FIG. 399 shows block diagram of ALU
[0411] FIG. 400 shows a block diagram of DataSel
[0412] FIG. 401 shows a block diagram of ROR
[0413] FIG. 402 shows a block diagram of the ALU's IO block
[0414] FIG. 403 shows a block diagram of PCU
[0415] FIG. 404 shows a block diagram of an Address Generator
Unit
[0416] FIG. 405 shows a block diagram for a Counter Unit
[0417] FIG. 406 shows a block diagram of PMU
[0418] FIG. 407 shows a state machine for PMU
[0419] FIG. 408 shows a block diagram of MRU
[0420] FIG. 409 shows simplified MAU state machine
[0421] FIG. 410 shows power-on reset behaviour
[0422] FIG. 411 shows a ring oscillator block diagram
[0423] FIG. 412 shows a system clock duty cycle
DETAILED DESCRIPTION
1 Print System Overview
1.1 Printing Considerations
[0424] 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.
[0425] 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).
[0426] 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.
[0427] 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.
[0428] 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).
[0429] A Netpage printer, for example, may use a contone resolution
of 267 ppi (i.e. 1600 dpi 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.
1.2 Document Data Flow
[0430] 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 cannot 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.
[0431] This decoupling also allows the RIP(s) to run ahead of the
printer when rasterizing simple pages, buying time to rasterize
more complex pages.
[0432] 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.
[0433] FIG. 2 shows the flow of a document from computer system to
printed page.
[0434] 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.
[0435] 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.
[0436] 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--i.e. since it introduces hard-to-compress
disorder.
[0437] 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.
[0438] 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.
[0439] 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.
[0440] 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.
[0441] The document data flow is: [0442] The RIP software
rasterizes each page description and compress the rasterized page
image. [0443] The infrared layer of the printed page optionally
contains encoded Netpage tags at a programmable density. [0444] The
compressed page image is transferred to the SoPEC device via the
USB normally on a band by band basis. [0445] The print engine takes
the compressed page image and starts the page expansion. [0446] The
first stage page expansion consists of 3 operations performed in
parallel [0447] expansion of the JPEG-compressed contone layer
[0448] expansion of the SMG4 fax compressed bi-level layer [0449]
encoding and rendering of the bi-level tag data. [0450] The second
stage dithers the contone layer using a programmable dither matrix,
producing up to four bi-level layers at full-resolution. [0451] 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. [0452] A
fixative layer is also generated as required. [0453] The last stage
formats and prints the bi-level data through the bi-lithic
printhead via the printhead interface.
[0454] 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.
[0455] 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.
[0456] 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.
1.2.1 Page Considerations Due to SoPEC
[0457] 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 the following table 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.
TABLE-US-00001 Size Page Content Description Calculation (MByte)
Best Case picture Image, 8.26 .times. 11.7 .times. 267 .times. 1.97
267 ppi with 3 colors, 267 .times. 3 @ 10:1 A4 size Full page text,
800 dpi 8.26 .times. 11.7 .times. 800 .times. 0.74 A4 size 800 @
10:1 Mixed Graphics and Text 6 .times. 4 .times. 267 .times. 267
.times. 1.55 Image of 6 inches .times. 4 3 @ 5:1 inches @ 267 ppi
and 800 .times. 800 .times. 73 @ 10:1 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
[0458] 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.
[0459] 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.
1.3 Page Format and Printflow
[0460] 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. 9 shows the high level data structure of a
number of pages with different numbers of bands in the page.
[0461] 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.sup.1, the
band header specifies which planes are included with the band. FIG.
10 gives a high-level breakdown of the contents of a page band.
.sup.1Although a band must contain at least one plane
[0462] A single SoPEC has maximum rendering restrictions as
follows: [0463] 1 bi-level plane [0464] 1 contone interleaved plane
set containing a maximum of 4 contone planes [0465] 1 tag data
plane [0466] a bi-lithic printhead with a maximum of 2 printhead
ICs
[0467] The requirement for single-sided A4 single SoPEC printing is
[0468] 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. [0469] average bi-level compression ratio of 10:1,
with a local minimum compression ratio of 1:1 for a single
line.
[0470] 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.
[0471] 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.
[0472] 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. 11 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.
[0473] 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.sup.2, the memory can
be allocated in any way. .sup.2Contiguous allocation also includes
wrapping around in SoPEC's band store memory.
1.4 SoPEC ASIC
[0474] 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.
[0475] A single SoPEC can control 2 bi-lithic printheads and up to
6 color channels at 10,000 lines/sec.sup.3, 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: .sup.310,000 lines per second equates to 30 A4/Letter
pages per minute at 1600 dpi [0476] CMY, for regular color
printing. [0477] K, for black text, line graphics and gray-scale
printing. [0478] IR (infrared), for Netpage-enabled applications.
[0479] 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.
[0480] 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.
[0481] 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.
[0482] 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.
[0483] 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.
1.4.1 Printing Rates
[0484] 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: [0485] 300 mm.times.63 (dot/mm)/2
sec=105.8 .mu.seconds per line, with no inter-sheet gap. [0486] 340
mm.times.63 (dot/mm)/2 sec=93.3 .mu.seconds per line, with a 4 cm
inter-sheet gap.
[0487] 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.
[0488] 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.
1.4.2 9.3 SoPEC Block Description
[0489] Looking at FIG. 13, the various units are described here in
summary form:
TABLE-US-00002 Unit Subsystem Acronym Unit Name Description DRAM
DIU DRAM interface unit 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 Embedded DRAM 20 Mbits of embedded DRAM, CPU CPU
Central Processing CPU for system configuration and control Unit
MMU Memory Management Limits access to certain memory address areas
Unit in CPU user mode RDU Real-time Debug Unit Facilitates the
observation of the contents of most of the CPU addressable
registers in SoPEC in addition to some pseudo-registers in
realtime. TIM General Timer Contains watchdog and general system
timers LSS Low Speed Serial Low level controller for interfacing
with the QA Interfaces chips GPIO General Purpose IOs General IO
controller, with built-in Motor control unit, LED pulse units and
de-glitch circuitry ROM Boot ROM 16 KBytes of System Boot ROM code
ICU Interrupt Controller General Purpose interrupt controller with
Unit configurable priority, and masking. CPR Clock, Power and
Central Unit for controlling and generating the Reset block system
clocks and resets and powerdown mechanisms PSS Power Save Storage
Storage retained while system is powered down USB Universal Serial
Bus USB device controller for interfacing with the Device host USB.
ISI Inter-SoPEC Interface ISI controller for data and control
communication with other SoPEC's in a multi- SoPEC system SCB
Serial Communication Contains both the USB and ISI blocks. Block
Print Engine PCU PEP controller Provides external CPU with the
means to read Pipeline and write PEP Unit registers, and read and
(PEP) write DRAM in single 32-bit chunks. CDU Contone decoder unit
Expands JPEG compressed contone layer and writes decompressed
contone to DRAM CFU Contone FIFO Unit Provides line buffering
between CDU and HCU LBD Lossless Bi-level Expands compressed
bi-level layer. Decoder SFU Spot FIFO Unit Provides line buffering
between LBD and HCU TE Tag encoder Encodes tag data into line of
tag dots. TFU Tag FIFO Unit Provides tag data storage between TE
and HCU HCU Halftoner compositor Dithers contone layer and
composites the bi- unit level spot 0 and position tag dots. DNC
Dead Nozzle Compensates for dead nozzles by color Compensator
redundancy and error diffusing dead nozzle data into surrounding
dots. DWU Dotline Writer Unit Writes out the 6 channels of dot data
for a given printline to the line store DRAM LLU Line Loader Unit
Reads the expanded page image from line store, formatting the data
appropriately for the bi-lithic printhead. PHI PrintHead Interface
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.
1.5 General Purpose IO (GPIO)
1.5.1 13.1 Overview
[0490] The General Purpose IO block (GPIO) is responsible for
control and interfacing of GPIO pins to the rest of the SoPEC
system. It provides easily programmable control logic to simplify
control of GPIO functions. In all there are 32 GPIO pins of which
any pin can assume any output or input function. Possible output
functions are [0491] 4 Stepper Motor control Outputs [0492] 12
Brushless DC Motor Control Output (total of 2 different controllers
each with 6 outputs) [0493] 4 General purpose high drive pulsed
outputs capable of driving LEDs. [0494] 4 Open drain IOs used for
LSS interfaces [0495] 4 Normal drive low impedance IOs used for the
ISI interface in Multi-SoPEC mode
[0496] Each of the pins can be configured in either input or output
mode, each pin is independently controlled. A programmable
de-glitching circuit exists for a fixed number of input pins. Each
input is a schmidt trigger to increase noise immunity should the
input be used without the de-glitch circuit.
1.6 ROM Block
1.6.1 Overview
[0497] The ROM block interfaces to the CPU bus and contains the
SoPEC boot code. The ROM block consists of the CPU bus interface,
the ROM macro and the ChipID macro. The current ROM size is 16
KBytes implemented as a 4096.times.32 macro. Access to the ROM is
not cached because the CPU enjoys fast (no more than one cycle
slower than a cache access), unarbitrated access to the ROM.
[0498] Each SoPEC device is required to have a unique ChipID which
is set by blowing fuses at manufacture. IBM's 300 mm ECID macro and
a custom 112-bit ECID macro are used to implement the ChipID
offering 224-bits of laser fuses. The exact number of fuse bits to
be used for the ChipID will be determined later but all bits are
made available to the CPU. The ECID macros allows all 224 bits to
be read out in parallel and the ROM block will make all 224 bits
available in the FuseChipID[N] registers which are readable by the
CPU in supervisor mode only.
1.7 Power Safe Storage (PSS) Block
1.7.1 Overview
[0499] The PSS block provides 128 bytes of storage space that will
maintain its state when the rest of the SoPEC device is in sleep
mode. The PSS is expected to be used primarily for the storage of
decrypted signatures associated with downloaded programmed code but
it can also be used to store any information that needs to survive
sleep mode (e.g. configuration details). Note that the signature
digest only needs to be stored in the PSS before entering sleep
mode and the PSS can be used for temporary storage of any data at
all other times.
[0500] Prior to entering sleep mode the CPU should store all of the
information it will need on exiting sleep mode in the PSS. On
emerging from sleep mode the boot code in ROM will read the
ResetSrc register in the CPR block to determine which reset source
caused the wakeup. The reset source information indicates whether
or not the PSS contains valid stored data, and the PSS data
determines the type of boot sequence to execute. If for any reason
a full power-on boot sequence should be performed (e.g. the printer
driver has been updated) then this is simply achieved by initiating
a full software reset.
[0501] Note that a reset or a powerdown (powerdown is implemented
by clock gating) of the PSS block will not clear the contents of
the 128 bytes of storage. If clearing of the PSS storage is
required, then the CPU must write to each location
individually.
1.8 Low Speed Serial Interface (LSS)
1.8.1 19.1 Overview
[0502] The Low Speed Serial Interface (LSS) provides a mechanism
for the internal SoPEC CPU to communicate with external QA chips
via two independent LSS buses. The LSS communicates through the
GPIO block to the QA chips. This allows the QA chip pins to be
reused in multi-SoPEC environments. The LSS Master system-level
interface is illustrated in FIG. 75. Note that multiple QA chips
are allowed on each LSS bus.
1.9 PEP Controller Unit (PCU)
1.9.1 Overview
[0503] The PCU has three functions: [0504] The first is to act as a
bus bridge between the CPU-bus and the PCU-bus for reading and
writing PEP configuration registers. [0505] The second is to
support page banding by allowing the PEP blocks to be reprogrammed
between bands by retrieving commands from DRAM instead of being
programmed directly by the CPU. [0506] The third is to send
register debug information to the RDU, within the CPU subsystem,
when the PCU is in Debug Mode.
1.10 Contone Decoder Unit (CDU)
1.10.1 Overview
[0507] The Contone Decoder Unit (CDU) is responsible for performing
the optional decompression of the contone data layer.
[0508] 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.
[0509] 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.
[0510] 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.
1.11 Contone FIFO Unit (CFU)
1.11.1 Overview
[0511] The Contone FIFO Unit (CFU) is responsible for reading the
decompressed contone data layer from the circular buffer in DRAM,
performing optional color conversion from YCrCb to RGB followed by
optional color inversion in up to 4 color planes, and then feeding
the data on to the HCU. Scaling of data is performed in the
horizontal and vertical directions by the CFU so that the output to
the HCU matches the printer resolution. Non-integer scaling is
supported in both the horizontal and vertical directions.
Typically, the scale factor will be the same in both directions but
may be programmed to be different.
1.12 Lossless Bi-level Decoder (LBD)
1.12.1 Overview
[0512] The Lossless Bi-level Decoder (LBD) is responsible for
decompressing a single plane of bi-level data. In SoPEC bi-level
data is limited to a single spot color (typically black for text
and line graphics).
[0513] The input to the LBD is a single plane of bi-level data,
read as a bitstream from DRAM. The LBD is programmed with the start
address of the compressed data, the length of the output
(decompressed) line, and the number of lines to decompress.
Although the requirement for SoPEC is to be able to print text at
10:1 compression, the LBD can cope with any compression ratio if
the requested DRAM access is available. A pass-through mode is
provided for 1:1 compression. 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.
[0514] The output of the LBD is a single plane of decompressed
bi-level data. The decompressed bi-level data is output to the SFU
(Spot FIFO Unit), and in turn becomes an input to the HCU
(Halftoner/Compositor unit) for the next stage in the printing
pipeline. The LBD also outputs a lbd_finishedband control flag that
is used by the PCU and is available as an interrupt to the CPU.
1.13 Halftoner Compositor Unit (HCU)
1.13.1 Overview
[0515] 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).
1.13.2 Data flow
[0516] FIG. 230 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.
[0517] 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).
[0518] 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.
1.13.3 DRAM storage requirements
[0519] 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.
[0520] The following give the storage and bandwidths requirements
for some of the possible configurations of the dither matrix.
[0521] 4 Kbyte DRAM storage required for one 64.times.64
(preferred) byte dither matrix [0522] 6.25 Kbyte DRAM storage
required for one 80.times.80 byte dither matrix [0523] 16 Kbyte
DRAM storage required for four 64.times.64 byte dither matrices
[0524] 64 Kbyte DRAM storage required for one 256.times.256 byte
dither matrix
[0525] 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).
1.13.4 Implementation
1.13.4.1 Control Unit
[0526] 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.
232.
[0527] 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.
[0528] 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.
[0529] 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.
1.13.4.1.1 Determine Advdot
[0530] 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).
[0531] 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 194. 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_page 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.
[0532] 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.
233.
[0533] 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.
1.13.4.1.2 Position Unit 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.
[0534] 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.
1.13.4.1.3 Margin Unit
[0535] 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. 234). This
unit is instantiated for both the contone/spot margin unit and the
tag margin unit.
[0536] The margin unit takes the current dot and line position, and
returns three flags. [0537] the first, in_page is 1 if the current
dot is within the page, and 0 if it is outside the page. [0538] 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. [0539] 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.
[0540] A block diagram of the margin unit is shown in FIG. 235.
1.13.4.1.4 Dither Matrix Table Interface
[0541] 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.
[0542] 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. 236 shows a block
diagram of the dither matrix table interface.
1.13.4.1.5 Dither Data Structure in DRAM
[0543] The dither matrix is stored in DRAM in 256-bit words,
transferred to the HCU in 64-bit words and consumed by the HCU in
bytes. Table 195 shows the 64-bit words mapping to 256-bit word
addresses, and Table 196 shows the 8-bits dither value mapping in
the 64-bits word.
[0544] 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.
1.13.4.1.5.1 Dither Matrix Buffer
[0545] The state machine loads dither matrix table data a line at a
time from DRAM and stores it in a buffer. A single line of the
dither matrix is either 256 or 128 8-bit entries, depending on the
programmable bit DoubleLineBuf. If this bit is enabled, a
double-buffer mechanism is employed such that while one buffer is
read from for the current line's dither matrix data (8 bits
representing a single dither matrix entry), the other buffer is
being written to with the next line's dither matrix data (64-bits
at a time). Alternatively, the single buffer scheme can be used,
where the data must be loaded at the end of the line, thus
incurring a delay.
[0546] The single/double buffer is implemented using a 256 byte
3-port register array, two reads, one write port, with the reads
clocked at double the system clock rate (320 MHz) allowing 4 reads
per clock cycle.
[0547] The dither matrix buffer unit also provides the mechanism
for keeping track of the current read and write buffers, and
providing the mechanism such that a buffer cannot be read from
until it has been written to. In this case, each buffer is a line
of the dither matrix, i.e. 256 or 128 bytes.
[0548] The dither matrix buffer maintains a read and write pointer
for the dither matrix. The output value dm_avail is derived by
comparing the read and write pointers to determine when the dither
matrix is not empty. The write pointer wr_adr is incremented each
time a 64-bit word is written to the dither matrix buffer and the
read pointer rd_ptr is incremented each time dm_advline is
received. If double_line_buf is 0 the rd_ptr will increment by 2,
otherwise it will increment by 1. If the dither matrix buffer is
full then no further writes will be allowed (buff_full=1), or if
the buffer is empty no further buffer reads are allowed
(buff_emp=1).
[0549] The read addresses are byte aligned and are generated by the
read address generator. A single dither matrix entry is represented
by 8 bits and an entry is read for each of the four contone planes
in parallel. If double buffer is used (double_line_buf=1) the read
address is derived from 7-bit address from the read address
generator and 1-bit from the read pointer. If double_line_buf=0
then the read address is the full 8-bits from the read address
generator.
1.13.4.1.5.2 Read Address Generator
[0550] For each contone plane there is a initial, lower and upper
index to be used when reading dither cell values from the dither
matrix double buffer. The read address for each plane is used to
select a byte from the current 256-byte read buffer. When Go gets
set (0 to 1 transition), or at the end of a line, the read
addresses are set to their corresponding initial index. Otherwise,
the read address generator relies on advdot to advance the
addresses within the inclusive range specified the lower and upper
indices.
1.13.4.1.5.3 State Machine
[0551] The dither matrix is read from DRAM in single 256-bit
accesses, receiving the data from the DIU over 4 clock cycles
(64-bits per cycle). Read accesses to DRAM are implemented by means
of the state machine described in FIG. 238.
[0552] All counters and flags should be cleared after reset or when
Go transitions from 0 to 1. While the Go bit is 1, the state
machine relies on the dm_read_enable bit to tell it whether to
attempt to read dither matrix data from DRAM. When dm_read_enable
is clear, the state machine does nothing and remains in the idle
state. When dm_read_enable is set, the state machine continues to
load dither matrix data, 256-bits at a time (received over 4 clock
cycles, 64 bits per cycle), while there is space available in the
dither matrix buffer, (buff_full !=1).
[0553] The read address and line_start_adr are initially set to
start_dm_adr. The read address gets incremented after each read
access. 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. A count is kept of the accesses to
DRAM. When a read access completes and access_count equals 3 or 7,
a line of dither matrix has just been loaded from and the read
address is updated to line_start_adr plus line_increment so it
points to the start of the next line of dither matrix.
(line_start_adr is also updated to this value). If the read address
equals end_dm_adr then the next read address will be start_dm_adr,
thus the read address wraps to point to the start of the area in
DRAM where the dither matrix is stored.
[0554] The write address for the dither matrix buffer is
implemented by means of a modulo-32 counter that is initially set
to 0 and incremented when diu_hcu_rvalid is asserted.
1.13.4.2 Contone Dotgen Unit
[0555] 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.
[0556] The block diagram for the contone dotgen unit is shown in
FIG. 239.
[0557] 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.
[0558] 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).
[0559] Note that constant use is dependant on the in_target_page
signal only, if in_target_page 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.
1.13.4.3 Spot Dotgen Unit
[0560] 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.
[0561] 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.
1.13.4.4 Tag Dotgen Unit
[0562] This unit is very similar to the spot dotgen unit in that it
deals with bi-level data, in this case from the TE via the TFU. The
tag layer is only defined within the tag margin area. As a result,
if input flag in_tag_target_page is 0, then a constant dot value,
tp_constant (typically this would be 0), is used for the output
dot. The tagplane dotgen unit also produces a tp_avail flag which
specifies whether or not tag dots are currently available for the
tagplane, and the output hcu_tfu_advdot to request the TFU to
provide the next bi-level data value.
[0563] The hcu_tfu_advdot generation is similar to the SFU and CFU,
except it depends only on in_target_page and advdot. It does not
take into account the avail mask when inside the target page.
1.13.4.5 Dot Reorg Unit
[0564] 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.
[0565] 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.
[0566] 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).
[0567] 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.
[0568] 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.
[0569] 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.
[0570] 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. 240.
1.13.4.6 Output Buffer
[0571] 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.
[0572] 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.
[0573] 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.
[0574] 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.
1.13.4.6.1 HCU to DNC Interface
[0575] FIG. 241 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.
1.13.4.7 Feeder to HCU interfaces
[0576] FIG. 242 shows the feeder unit to HCU interface timing
diagram, and FIG. 243 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.
1.14 Dead Nozzle Compensator (DNC)
1.14.1 Overview
[0577] 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. 244.
[0578] The DNC compensates for a dead nozzles by performing the
following operations: [0579] Dead nozzle removal, i.e. turn the
nozzle off [0580] Ink replacement by direct substitution i.e.
K->K [0581] Ink replacement by indirect substitution i.e.
K->CMY [0582] Error diffusion to adjacent nozzles [0583]
Fixative corrections
[0584] 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.
1.14.2 Dead Nozzle Identification
[0585] 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.4. 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.
245. 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 do mask of all
zeros. These null dead nozzle identifiers should also be used so
that: .sup.4for 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). [0586] the dead nozzle table is a multiple of 16
entries (so that it is aligned to the 256-bit DRAM locations)
[0587] 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.
[0588] 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.
1.14.3 DRAM Storage and Bandwidth Requirement
[0589] 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.
1.14.4 Nozzle Compensation
[0590] The 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.
1.14.4.1 Dead Nozzle Removal
[0591] 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 do
mask with the dot value.
1.14.4.2 Ink Replacement
[0592] 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.
[0593] 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. See Figure n page565 on page 18 for
implementation details.
[0594] 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.
[0595] 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.
1.14.4.3 Error Diffusion
[0596] 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.
[0597] 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.
[0598] 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.
246.
[0599] 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.
[0600] 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.
[0601] 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.
[0602] Thus, as a rule, a 1 in dot B cannot be diffused into dot A
if [0603] a 1 is already present in dot A, [0604] dot A is defined
as dead, [0605] or dot A is the last dot in a line.
[0606] Similarly, a 1 in dot B cannot be diffused into dot C if
[0607] a 1 is already present in dot C, [0608] dot C is defined as
dead, [0609] or dot C is the first dot in a line.
[0610] 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.
[0611] 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: [0612] 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). [0613] If dot can be
placed into only one of A and C, then the 1 from B is placed into
that position. [0614] If dot cannot be placed into either one of A
or C, then the DNC cannot place the dot in either position.
1.14.4.4 Fixative Correction
[0615] 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.
[0616] 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.
[0617] 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
1.14.5 Implementation
[0618] A block diagram of the DNC is shown in FIG. 247.
1.14.5.1 Ink Replacement Unit
[0619] FIG. 248 shows a sub-block diagram for the ink replacement
unit.
1.14.5.1.1 Control Unit
[0620] 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. 249.
[0621] 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.
[0622] 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: [0623] 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. [0624] If rd_count equals 3 and
dn_table_radr does not equal dn_table_end_adr, then dn_table_radr
is incremented by 1.
[0625] 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.
[0626] 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.
[0627] 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.
1.14.5.1.2 Dead Nozzle FIFO
[0628] 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).
[0629] 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.).
1.14.5.1.3 GenMask Unit
[0630] 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.
[0631] 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.
[0632] 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.
[0633] 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.
1.14.5.1.4 Replace Unit
[0634] Dead nozzle removal and ink replacement are implemented by
the combinatorial logic shown in FIG. 250. Dead nozzle removal is
performed by bit-wise ANDing of the inverse of the dn_mask with the
dot value.
[0635] 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.
[0636] 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.
1.14.5.2 Error Diffusion Unit
[0637] FIG. 251 shows a sub-block diagram for the error diffusion
unit.
1.14.5.2.1 Random Bit Generator
[0638] 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. 252.
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.
1.14.5.2.2 Advance Dot Unit
[0639] 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.
[0640] 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.
1.14.5.2.3 Diffuse Unit
[0641] The diffuse unit contains the combinatorial logic to
implement the truth table from 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.
[0642] 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.
[0643] 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.
1.14.5.3 Fixative Correction Unit
[0644] The fixative correction unit consists of combinatorial logic
to implement fixative correction as set forth in the following
truth table. 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.
TABLE-US-00003 Fixative Fixative Present required Action Output 1 1
Output dot as is. dnc_dwu_data = edu_data 1 0 Clear fixative plane.
dnc_dwu_data = (edu_data) & ~(FixativeMask1 | FixativeMask2) 0
1 Attempt to add fixative. if (FixativeMask1 & DnMask) != 0
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 FixativePresent = ((FixativeMask1 |
FixativeMask2) & edu_data) != 0 FixativeRequired =
(FixativeRequiredMask & edu_data) != 0
[0645] It then looks up the truth table to see what action, if any,
needs to be taken.
[0646] 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.
1.15 Dotline Writer Unit (DWU)
1.15.1 Overview
[0647] 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.
1.16 Line Loader Unit (LLU)
1.16.1 Overview
[0648] 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. 267
shows a high level data flow diagram of the LLU in context.
1.17 PrintHead Interface (PHI)
1.17.1 Overview
[0649] 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.
[0650] 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. See Bi-lithic Printhead Reference document
for a complete description of printhead types.
[0651] 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.
[0652] 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.
[0653] 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: [0654] determine printhead temperature
[0655] test for and determine dead nozzles for each printhead IC
[0656] initialize each printhead IC [0657] pre-heat each printhead
IC
[0658] FIG. 277 shows a high level data flow diagram of the PHI in
context.
* * * * *