Printer Incorporating Multiple Synchronizing Printer Controllers

TECHNICAL FIELD

The present invention relates to a printer comprising one or more printhead modules and a printer controller for supplying the printhead modules with data to be printed.

The invention has primarily been developed in the form of a pagewidth inkjet printer in which considerable data processing and ordering is required of the printer controller, and will be described with reference to this example. However, it will be appreciated that the invention is not limited to any particular type of printing technology, and may be used in, for example, non-pagewidth and non-inkjet printing applications.

CO-PENDING APPLICATIONS

Various methods, systems and apparatus relating to the present invention are disclosed in the following co-pending applications filed by the applicant or assignee of the present invention with the present application:

7,427,117
7,448,707
7,281,330
10/854,503
7,328,956

7,374,266
7,188,928
7,093,989
7,377,609
7,600,843

10/854,498
10/854,511
7,390,071
10/854,525
10/854,526

7,549,715
7,252,353
7,607,757
7,267,417
10/854,505

7,517,036
7,275,805
7,314,261
7,549,718
7,281,777

7,290,852
7,484,831
10/854,523
10/854,527
10/854,501

10/854,520
7,631,190
7,557,941
10/854,518
10/854,499

7,243,193
7,266,661

The disclosures of these co-pending applications are incorporated herein by cross-reference.

CROSS-REFERENCES

7,249,108
6,566,858
6,331,946
6,246,970
6,442,525

7,346,586
7,685,423
6,374,354
7,246,098
6,816,968

6,757,832
6,334,190
6,745,331
7,249,109
7,509,292

7,685,424
7,416,280
7,252,366
7,488,051
7,360,865

6,947,173
10/727,162
7,377,608
7,399,043
7,121,639

7,165,824
7,152,942
10/727,157
7,181,572
7,096,137

7,302,592
7,278,034
7,188,282
7,592,829
10/727,180

10/727,179
10/727,192
10/727,274
10/727,164
7,523,111

7,573,301
7,660,998
10/754,536
10/754,938
10/727,160

6,795,215
6,859,289
6,977,751
6,398,332
6,394,573

6,622,923
6,747,760
6,921,144
7,454,617
7,194,629

10/791,792
7,182,267
7,025,279
6,857,571
6,817,539

6,830,198
6,992,791
7,038,809
6,980,323
7,148,992

7,139,091

BACKGROUND

Printer controllers face difficulties when they have to send print data to two or more printhead modules in a printhead, each of the modules having one or more rows of print nozzles for outputting ink. In one embodiment favored by the applicant, data for each row is shifted into a shift register associated with that row.

The applicant has discovered that some manufacturing advantages arise when printhead modules of different lengths are used within a product range. For example, a particular width of printhead for a pagewidth printer can be achieved with various different combinations of printhead module. So, a 10 inch printhead can be formed from two 5 inch printhead modules, a 6 and a 4 inch module, or a 7 and a 3 inch module.

Whilst useful in some ways, printhead modules of different lengths raise some other issues. One of these is that when one of the modules is longer, it must be loaded with more data than the other module in a given load period.

One way of dealing with the problem is to use a printer controller with sufficient processing power and data delivery capabilities that the data imbalance is not problematic. Alternatively, in some cases it may be feasible to add one or more additional printer controllers to help deal with the high data rates involved. However, if the data rates for the printer controller providing data to the longer printhead module are already relatively close to that printer controller's capabilities, it may be not be commercially feasible for either of these solutions to be implemented.

It would be useful to provide a printhead module that addresses at least some of the disadvantages of known printhead modules.

SUMMARY

According to one aspect of the present disclosure, a printer includes a printhead having first and second elongate printhead modules; and first and second printer controllers receiving print data and processing the print data to output dot data to the printhead, the first printer controller outputting dot data to the first printhead module and the second printer controller outputting dot data to the second printhead module. The first elongate printhead module is informationally isolated from the second elongate printhead module, whereby no dot data passes therebetween. The first printer controller and the second printer controller communicate therebetween a synchronization signal to effect synchronization therebetween.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1. Example State machine notation

FIG. 2. Single SoPEC A4 Simplex system

FIG. 3. Dual SoPEC A4 Simplex system

FIG. 4. Dual SoPEC A4 Duplex system

FIG. 5. Dual SoPEC A3 simplex system

FIG. 6. Quad SoPEC A3 duplex system

FIG. 7. SoPEC A4 Simplex system with extra SoPEC used as DRAM storage

FIG. 8. SoPEC A4 Simplex system with network connection to Host PC

FIG. 9. Document data flow

FIG. 10. Pages containing different numbers of bands

FIG. 11. Contents of a page band

FIG. 12. Page data path from host to SoPEC

FIG. 13. Page structure

FIG. 14. SoPEC System Top Level partition

FIG. 15. Proposed SoPEC CPU memory map (not to scale)

FIG. 16. Possible USB Topologies for Multi-SoPEC systems

FIG. 17. CPU block diagram

FIG. 18. CPU bus transactions

FIG. 19. State machine for a CPU subsystem slave

FIG. 20. Proposed SoPEC CPU memory map (not to scale)

FIG. 21. MMU Sub-block partition, external signal view

FIG. 22. MMU Sub-block partition, internal signal view

FIG. 23. DRAM Write buffer

FIG. 24. DIU waveforms for multiple transactions

FIG. 25. SoPEC LEON CPU core

FIG. 26. Cache Data RAM wrapper

FIG. 27. Realtime Debug Unit block diagram

FIG. 28. Interrupt acknowledge cycles for a single and pending interrupts

FIG. 29. UHU Dataflow

FIG. 30. UHU Basic Block Diagram

FIG. 31. ehci_ohci Basic Block Diagram.

FIG. 32. uhu_ctl

FIG. 33. uhu_dma

FIG. 34. EHCI DIU Buffer Partition

FIG. 35. UDU Sub-block Partition

FIG. 36. Local endpoint packet buffer partitioning

FIG. 37. Circular buffer operation

FIG. 38. Overview of Control Transfer State Machine

FIG. 39. Writing a Setup packet at the start of a Control-In transfer

FIG. 40. Reading Control-In data

FIG. 41. Status stage of Control-In transfer

FIG. 42. Writing Control-Out data

FIG. 43. Reading Status In data during a Control-Out transfer

FIG. 44. Reading bulk/interrupt IN data

FIG. 45. A bulk OUT transfer

FIG. 46. VCI slave port bus adapter

FIG. 47. Duty Cycle Select

FIG. 48. Low Pass filter structure

FIG. 49. GPIO partition

FIG. 50. GPIO Partition (continued)

FIG. 51. LEON UART block diagram

FIG. 52. Input de-glitch RTL diagram

FIG. 53. Motor control RTL diagram

FIG. 54. BLDC controllers RTL diagram

FIG. 55. Period Measure RTL diagram

FIG. 56. Frequency Modifier sub-block partition

FIG. 57. Fixed point bit allocation

FIG. 58. Frequency Modifier structure

FIG. 59. Line sync generator diagram

FIG. 60. HSI timing diagram

FIG. 61. Centronic interface timing diagram

FIG. 62. Parallel Port EPP read and write transfers

FIG. 63. ECP forward Data and command cycles

FIG. 64. ECP Reverse Data and command cycles

FIG. 65. 68K example read and write access

FIG. 66. Non burst, non pipelined read and write accesses with wait states

FIG. 67. Generic Flash Read and Write operation

FIG. 68. Serial flash example 1 byte read and write protocol

FIG. 69. MMI sub-block partition

FIG. 70. MMI Engine sub-block diagram

FIG. 71. Instruction field bit allocation

FIG. 72. Circular buffer operation

FIG. 73. ICU partition

FIG. 74. Interrupt clear state diagram

FIG. 75. Timers sub-block partition diagram

FIG. 76. Watchdog timer RTL diagram

FIG. 77. Generic timer RTL diagram

FIG. 78. Pulse generator RTL diagram

FIG. 79. SoPEC clock relationship

FIG. 80. CPR block partition

FIG. 81. Reset Macro block structure

FIG. 82. Reset control logic state machine

FIG. 83. PLL and Clock divider logic

FIG. 84. PLL control state machine diagram

FIG. 85. Clock gate logic diagram

FIG. 86. SoPEC clock distribution diagram

FIG. 87. Sub-block partition of the ROM block

FIG. 88. LSS master system-level interface

FIG. 89. START and STOP conditions

FIG. 90. LSS transfer of 2 data bytes

FIG. 91. Example of LSS write to a QA Chip

FIG. 92. Example of LSS read from QA Chip

FIG. 93. LSS block diagram

FIG. 94. Example LSS multi-command transaction

FIG. 95. Start and stop generation based on previous bus state

FIG. 96. S master state machine

FIG. 97. LSS Master timing

FIG. 98. SoPEC System Top Level partition

FIG. 99. Shared read bus with 3 cycle random DRAM read accesses

FIG. 100. Interleaving CPU and non-CPU read accesses

FIG. 101. Interleaving read and write accesses with 3 cycle random DRAM accesses

FIG. 102. Interleaving write accesses with 3 cycle random DRAM accesses

FIG. 103. Read protocol for a SoPEC Unit making a single 256-bit access

FIG. 104. Read protocol for a CPU making a single 256-bit access

FIG. 105. Write Protocol shown for a SoPEC Unit making a single 256-bit access

FIG. 106. Protocol for a posted, masked, 128-bit write by the CPU.

FIG. 107. Write Protocol shown for CDU making four contiguous 64-bit accesses

FIG. 108. Timeslot based arbitration

FIG. 109. Timeslot based arbitration with separate pointers

FIG. 110. Example (a), separate read and write arbitration

FIG. 111. Example (b), separate read and write arbitration

FIG. 112. Example (c), separate read and write arbitration

FIG. 113. DIU Partition

FIG. 114. DIU Partition

FIG. 115. Multiplexing and address translation logic for two memory instances

FIG. 116. Timing of dau_dcu_valid, dcu_dau_adv and dcu_dau_wadv

FIG. 117. DCU state machine

FIG. 118. Random read timing

FIG. 119. Random write timing

FIG. 120. Refresh timing

FIG. 121. Page mode write timing

FIG. 122. Timing of non-CPU DIU read access

FIG. 123. Timing of CPU DIU read access

FIG. 124. CPU DIU read access

FIG. 125. Timing of CPU DIU write access

FIG. 126. Timing of a non-CDU/non-CPU DIU write access

FIG. 127. Timing of CDU DIU write access

FIG. 128. Command multiplexor sub-block partition

FIG. 129. Command Multiplexor timing at DIU requestors interface

FIG. 130. Generation of re_arbitrate and re_arbitrate_wadv

FIG. 131. CPU Interface and Arbitration Logic

FIG. 132. Arbitration timing

FIG. 133. Setting RotationSync to enable a new rotation.

FIG. 134. Timeslot based arbitration

FIG. 135. Timeslot based arbitration with separate pointers

FIG. 136. CPU pre-access write lookahead pointer

FIG. 137. Arbitration hierarchy

FIG. 138. Hierarchical round-robin priority comparison

FIG. 139. Read Multiplexor partition.

FIG. 140. Read Multiplexor timing

FIG. 141. Read command queue (4 deep buffer)

FIG. 142. State-machines for shared read bus accesses

FIG. 143. Read Multiplexor timing for back to back shared read bus transfers

FIG. 144. Write multiplexor partition

FIG. 145. Block diagram of PCU

FIG. 146. PCU accesses to PEP registers

FIG. 147. Command Arbitration and execution

FIG. 148. DRAM command access state machine

FIG. 149. Outline of contone data flow with respect to CDU

FIG. 150. Block diagram of CDU

FIG. 151. State machine to read compressed contone data

FIG. 152. DRAM storage arrangement for a single line of JPEG 8×8 blocks in 4 colors

FIG. 153. State machine to write decompressed contone data

FIG. 154. Lead-in and lead-out clipping of contone data in multi-SoPEC environment

FIG. 155. Block diagram of CFU

FIG. 156. DRAM storage arrangement for a single line of JPEG blocks in 4 colors

FIG. 157. State machine to read decompressed contone data from DRAM

FIG. 158. Block diagram of color space converter

FIG. 159. High level block diagram of LBD in context

FIG. 160. Schematic outline of the LBD and the SFU

FIG. 161. Block diagram of lossless bi-level decoder

FIG. 162. Stream decoder block diagram

FIG. 163. Command controller block diagram

FIG. 164. State diagram for the Command Controller (CC) state machine

FIG. 165. Next Edge Unit block diagram

FIG. 166. Next edge unit buffer diagram

FIG. 167. Next edge unit edge detect diagram

FIG. 168. State diagram for the Next Edge Unit (NEU) state machine

FIG. 169. Line fill unit block diagram

FIG. 170. State diagram for the Line Fill Unit (LFU) state machine

FIG. 171. Bi-level DRAM buffer

FIG. 172. Interfaces between LBD/SFU/HCU

FIG. 173. SFU Sub-Block Partition

FIG. 174. LBDPrevLineFifo Sub-block

FIG. 175. Timing of signals on the LBDPrevLineFIFO interface to DIU and Address Generator

FIG. 176. Timing of signals on LBDPrevLineFIFO interface to DIU and Address Generator

FIG. 177. LBDNextLineFifo Sub-block

FIG. 178. Timing of signals on LBDNextLineFIFO interface to DIU and Address Generator

FIG. 179. LBDNextLineFIFO DIU Interface State Diagram

FIG. 180. LDB to SFU write interface

FIG. 181. LDB to SFU read interface (within a line)

FIG. 182. HCUReadLineFifo Sub-block

FIG. 183. DIU Write Interface

FIG. 184. DIU Read Interface multiplexing by select_hrfplf

FIG. 185. DIU read request arbitration logic

FIG. 186. Address Generation

FIG. 187. X scaling control unit

FIG. 188. Y scaling control unit

FIG. 189. Overview of X and Y scaling at HCU interface

FIG. 190. High level block diagram of TE in context

FIG. 191. Example QR Code developed by Denso of Japan

FIG. 192. Netpage tag structure

FIG. 193. Netpage tag with data rendered at 1600 dpi (magnified view)

FIG. 194. Example of 2×2 dots for each block of QR code

FIG. 195. Placement of tags for portrait & landscape printing

FIG. 196. General representation of tag placement

FIG. 197. Composition of SoPEC's tag format structure

FIG. 198. Simple 3×3 tag structure

FIG. 199. 3×3 tag redesigned for 21×21 area (not simple replication)

FIG. 200. TE Block Diagram

FIG. 201. TE Hierarchy

FIG. 202. Tag Encoder Top-Level FSM

FIG. 203. Logic to combine dot information and Encoded Data

FIG. 204. Generation of Lastdotintag

FIG. 205. Generation of Dot Position Valid

FIG. 206. Generation of write enable to the TFU

FIG. 207. Generation of Tag Dot Number

FIG. 208. TDI Architecture

FIG. 209. Data Flow Through the TDI

FIG. 210. Raw tag data interface block diagram

FIG. 211. RTDI State Flow Diagram

FIG. 212. Relationship between te_endoftagdata, te_startofbandstore and te_endofbandstore

FIG. 213. TDi State Flow Diagram

FIG. 214. Mapping of the tag data to codewords 0-7 for (15,5) encoding.

FIG. 215. Coding and mapping of uncoded Fixed Tag Data for (15,5) RS encoder

FIG. 216. Mapping of pre-coded Fixed Tag Data

FIG. 217. Coding and mapping of Variable Tag Data for (15,7) RS encoder

FIG. 218. Coding and mapping of uncoded Fixed Tag Data for (15,7) RS encoder

FIG. 219. Mapping of 2D decoded Variable Tag Data, DataRedun=0

FIG. 220. Simple block diagram for an m=4 Reed Solomon Encoder

FIG. 221. RS Encoder I/O diagram

FIG. 222. (15,5) & (15,7) RS Encoder block diagram

FIG. 223. (15,5) RS Encoder timing diagram

FIG. 224. (15,7) RS Encoder timing diagram

FIG. 225. Circuit for multiplying by α3

FIG. 226. Adding two field elements, (15,5) encoding.

FIG. 227. RS Encoder Implementation

FIG. 228. encoded tag data interface

FIG. 229. Breakdown of the Tag Format Structure

FIG. 230. TFSI FSM State Flow Diagram

FIG. 231. TFS Block Diagram

FIG. 232. Table A address generator

FIG. 233. Table C interface block diagram

FIG. 234. Table B interface block diagram

FIG. 235. Interfaces between TE, TFU and HCU

FIG. 236. 16-byte FIFO in TFU

FIG. 237. High level block diagram showing the HCU and its external interfaces

FIG. 238. Block diagram of the HCU

FIG. 239. Block diagram of the control unit

FIG. 240. Block diagram of determine advdot unit

FIG. 241. Page structure

FIG. 242. Block diagram of margin unit

FIG. 243. Block diagram of dither matrix table interface

FIG. 244. Example reading lines of dither matrix from DRAM

FIG. 245. State machine to read dither matrix table

FIG. 246. Contone dotgen unit

FIG. 247. Block diagram of dot reorg unit

FIG. 248. HCU to DNC interface (also used in DNC to DWU, LLU to PHI)

FIG. 249. SFU to HCU (all feeders to HCU)

FIG. 250. Representative logic of the SFU to HCU interface

FIG. 251. High level block diagram of DNC

FIG. 252. Dead nozzle table format

FIG. 253. Set of dots operated on for error diffusion

FIG. 254. Block diagram of DNC

FIG. 255. Sub-block diagram of ink replacement unit

FIG. 256. Dead nozzle table state machine

FIG. 257. Logic for dead nozzle removal and ink replacement

FIG. 258. Sub-block diagram of error diffusion unit

FIG. 259. Maximum length 32-bit LFSR used for random bit generation

FIG. 260. High level data flow diagram of DWU in context

FIG. 261. Printhead Nozzle Layout for conceptual 36 Nozzle AB single segment printhead

FIG. 262. Paper and printhead nozzles relationship (example with D₁=D₂=5)

FIG. 263. Dot line store logical representation

FIG. 264. Conceptual view of 2 adjacent printhead segments possible row alignment

FIG. 265. Conceptual view of 2 adjacent printhead segments row alignment (as seen by the LLU)

FIG. 266. Even dot order in DRAM (13312 dot wide line)

FIG. 267. Dotline FIFO data structure in DRAM (LLU specification)

FIG. 268. DWU partition

FIG. 269. Sample dot_data generation for color 0 even dot

FIG. 270. Buffer address generator sub-block

FIG. 271. DIU Interface sub-block

FIG. 272. Interface controller state diagram

FIG. 273. High level data flow diagram of LLU in context

FIG. 274. Paper and printhead nozzles relationship (example with D₁=D₂=5)

FIG. 275. Conceptual view of vertically misaligned printhead segment rows (external)

FIG. 276. Conceptual view of vertically misaligned printhead segment rows (internal)

FIG. 277. Conceptual view of color dependent vertically misaligned printhead segment rows (internal)

FIG. 278. Conceptual horizontal misalignment between segments

FIG. 279. Relative positions of dot fired (example cases)

FIG. 280. Example left and right margins

FIG. 281. Dot data generated and transmitted order

FIG. 282. Dotline FIFO data structure in DRAM (LLU specification)

FIG. 283. LLU partition

FIG. 284. DIU interface

FIG. 285. Interface controller state diagram

FIG. 286. Address generator logic

FIG. 287. Write pointer state machine

FIG. 288. PHI to linking printhead connection (Single SoPEC)

FIG. 289. PHI to linking printhead connection (2 SoPECs)

FIG. 290. CPU command word format

FIG. 291. Example data and command sequence on a print head channel

FIG. 292. PHI block partition

FIG. 293. Data generator state diagram

FIG. 294. PHI mode Controller

FIG. 295. Encoder RTL diagram

FIG. 296. 28-bit scrambler

FIG. 297. Printing with 1 SoPEC

FIG. 298. Printing with 2 SoPECs (existing hardware)

FIG. 299. Each SoPEC generates dot data and writes directly to a single printhead

FIG. 300. Each SoPEC generates dot data and writes directly to a single printhead

FIG. 301. Two SoPECs generate dots and transmit directly to the larger printhead

FIG. 302. Serial Load

FIG. 303. Parallel Load

FIG. 304. Two SoPECs generate dot data but only one transmits directly to the larger printhead

FIG. 305. Odd and Even nozzles on same shift register

FIG. 306. Odd and Even nozzles on different shift registers

FIG. 307. Interwoven shift registers

FIG. 308. Linking Printhead Concept

FIG. 309. Linking Printhead 30 ppm

FIG. 310. Linking Printhead 60 ppm

FIG. 311. Theoretical 2 tiles assembled as A-chip/A-chip—right angle join

FIG. 312. Two tiles assembled as A-chip/A-chip

FIG. 313. Magnification of color n in A-chip/A-chip

FIG. 314. A-chip/A-chip growing offset

FIG. 315. A-chip/A-chip aligned nozzles, sloped chip placement

FIG. 316. Placing multiple segments together

FIG. 317. Detail of a single segment in a multi-segment configuration

FIG. 318. Magnification of inter-slope compensation

FIG. 319. A-chip/B-chip

FIG. 320. A-chip/B-chip multi-segment printhead

FIG. 321. Two A-B-chips linked together

FIG. 322. Two A-B-chips with on-chip compensation

FIG. 323. Frequency modifier block diagram

FIG. 324. Output frequency error versus input frequency

FIG. 325. Output frequency error including K

FIG. 326. Optimised for output jitter<0.2%, F_sys=48 MHz, K=25

FIG. 327. Direct form II biquad

FIG. 328. Output response and internal nodes

FIG. 329. Butterworth filter (Fc=0.005) gain error versus input level

FIG. 330. Step response

FIG. 331. Output frequency quantisation (K=2̂25)

FIG. 332. Jitter attenuation with a 2nd order Butterworth, F_c=0.05

FIG. 333. Period measurement and NCO cumulative error

FIG. 334. Stepped input frequency and output response

FIG. 335. Block diagram overview

FIG. 336. Multiply/divide unit

FIG. 337. Power-on-reset detection behaviour

FIG. 338. Brown-out detection behaviour

FIG. 339. Adapting the IBM POR macro for brown-out detection

FIG. 340. Deglitching of power-on-reset signal

FIG. 341. Deglitching of brown-out detector signal

FIG. 342. Proposed top-level solution

FIG. 343. First Stage Image Format

FIG. 344. Second Stage Image Format

FIG. 345. Overall Logic Flow

FIG. 346. Initialisation Logic Flow

FIG. 347. Load & Verify Second Stage Image Logic Flow

FIG. 348. Load from LSS Logic Flow

FIG. 349. Load from USB Logic Flow

FIG. 350. Verify Header and Load to RAM Logic Flow

FIG. 351. Body Verification Logic Flow

FIG. 352. Run Application Logic Flow

FIG. 353. Boot ROM Memory Layout

FIG. 354. Overview of LSS buses for single SoPEC system

FIG. 355. Overview of LSS buses for single SoPEC printer

FIG. 356. Overview of LSS buses for simplest two-SoPEC printer

FIG. 357. Overview of LSS buses for alternative two-SoPEC printer

FIG. 358. SoPEC System top level partition

FIG. 359. Print construction and Nozzle position

FIG. 360. Conceptual horizontal misplacement between segments

FIG. 361. Printhead row positioning and default row firing order

FIG. 362. Firing order of fractionally misaligned segment

FIG. 363. Example of yaw in printhead IC misplacement

FIG. 364. Vertical nozzle spacing

FIG. 365. Single printhead chip plus connection to second chip

FIG. 366. Two printheads connected to form a larger printhead

FIG. 367. Colour arrangement.

FIG. 368. Nozzle Offset at Linking Ends

FIG. 369. Bonding Diagram

FIG. 370. MEMS Representation.

FIG. 371. Line Data Load and Firing, properly placed Printhead,

FIG. 372. Simple Fire order

FIG. 373. Micro positioning

FIG. 374. Measurement convention

FIG. 375. Scrambler implementation

FIG. 376. Block Diagram

FIG. 377. Netlist hierarchy

FIG. 378. Unit cell schematic

FIG. 379. Unit cell arrangement into chunks

FIG. 380. Unit Cell Signals

FIG. 381. Core data shift registers

FIG. 382. Core Profile logical connection

FIG. 383. Column SR Placement

FIG. 384. TDC block diagram

FIG. 385. TDC waveform

FIG. 386. TDC construction

FIG. 387. FPG Outputs (vposition=0)

FIG. 388. DEX block diagram

FIG. 389. Data sampler

FIG. 390. Data Eye

FIG. 391. scrambler/descrambler

FIG. 392. Aligner state machine

FIG. 393. Disparity decoder

FIG. 394. CU command state machine

FIG. 395. Example transaction

FIG. 396. clk phases

FIG. 397. Planned tool flow

FIG. 398. Equivalent signature generation

FIG. 399. An allocation of words in memory vectors

FIG. 400. Transfer and rollback process

DETAILED DESCRIPTION

Various aspects of the preferred and other embodiments will now be described.

It will be appreciated that the following description is a highly detailed exposition of the hardware and associated methods that together provide a printing system capable of relatively high resolution, high speed and low cost printing compared to prior art systems.

Much of this description is based on technical design documents, so the use of words like “must”, “should” and “will”, and all others that suggest limitations or positive attributes of the performance of a particular product, should not be interpreted as applying to the invention in general. These comments, unless clearly referring to the invention in general, should be considered as desirable or intended features in a particular design rather than a requirement of the invention. The intended scope of the invention is defined in the claims.

Also throughout this description, “printhead module” and “printhead” are used somewhat interchangeably. Technically, a “printhead” comprises one or more “printhead modules”, but occasionally the former is used to refer to the latter. It should be clear from the context which meaning should be allocated to any use of the word “printhead”.

1 Print System Overview

This document describes the SoPEC ASIC (Small office home office Print Engine Controller) suitable for use in price sensitive SoHo printer products. The SoPEC ASIC is intended to be a relatively low cost solution for linking printhead control, replacing the multichip solutions in larger more professional systems with a single chip. The increased cost competitiveness is achieved by integrating several systems such as a modified PEC1 printing pipeline, CPU control system, peripherals and memory sub-system onto one SoC ASIC, reducing component count and simplifying board design. SoPEC contains features making it suitable for multifunction or “all-in-one” devices as well as dedicated printing systems.

This section will give a general introduction to Memjet printing systems, introduce the components that make a linking printhead system, describe a number of system architectures and show how several SoPECs can be used to achieve faster, wider and/or duplex printing. The section “SoPEC ASIC” describes the SoC SoPEC ASIC, with subsections describing the CPU, DRAM and Print Engine Pipeline subsystems. Each section gives a detailed description of the blocks used and their operation within the overall print system.

1.1 Nomenclature

The following terms are used throughout this specification:

- CPU Refers to CPU core, caching system and MMU.
- Host A PC providing control and print data to a Memjet printer.
- ISCMaster In a multi-SoPEC system, the ISCMaster (Inter SoPEC Communication Master) is the SoPEC device that initiates communication with other SoPECs in the system. The ISCMaster interfaces with the host.
- ISCSlave In a multi-SoPEC system, an ISCSlave is a SoPEC device that responds to communication initiated by the ISCMaster.
- LEON Refers to the LEON CPU core.
- LineSyncMaster The LineSyncMaster device generates the line synchronisation pulse that all SoPECs in the system must synchronise their line outputs to.
- Linking Printhead Refers to a page-width printhead constructed from multiple linking printhead ICs
- Linking Printhead IC A MEMS IC. Multiple ICs link together to form a complete printhead. An A4/Letter page width printhead requires 11 printhead ICs.
- Multi-SoPEC Refers to SoPEC based print system with multiple SoPEC devices
- Netpage Refers to page printed with tags (normally in infrared ink).
- PEC1 Refers to Print Engine Controller version 1, precursor to SoPEC used to control printheads constructed from multiple angled printhead segments.
- PrintMaster The PrintMaster device is responsible for coordinating all aspects of the print operation. There may only be one PrintMaster in a system.
- QA Chip Quality Assurance Chip
- Storage SoPEC A SoPEC used as a DRAM store and which does not print.
- Tag Refers to pattern which encodes information about its position and orientation which allow it to be optically located and its data contents read.

1.2 Acronym and Abbreviations

The following acronyms and abbreviations are used in this specification:

- CFU Contone FIFO53 Unit
- CPU Central Processing Unit
- DIU DRAM Interface Unit
- DNC Dead Nozzle Compensator
- DRAM Dynamic Random Access Memory
- DWU DotLine Writer Unit
- GPIO General Purpose Input Output
- HCU Halftoner Compositor Unit
- ICU Interrupt Controller Unit
- LDB Lossless Bi-level Decoder
- LLU Line Loader Unit
- LSS Low Speed Serial interface
- MEMS Micro Electro Mechanical System
- MMI Multiple Media Interface
- MMU Memory Management Unit
- PCU SoPEC Controller Unit
- PHI PrintHead Interface
- PHY USB multi-port Physical Interface
- PSS Power Save Storage Unit
- RDU Real-time Debug Unit
- ROM Read Only Memory
- SFU Spot FIFO Unit
- SMG4 Silverbrook Modified Group 4.
- SoPEC Small office home office Print Engine Controller
- SRAM Static Random Access Memory
- TE Tag Encoder
- TFU Tag FIFO Unit
- TIM Timers Unit
- UDU USB Device Unit
- UHU USB Host Unit
- USB Universal Serial Bus

1.3 Pseudocode Notation

In general the pseudocode examples use C like statements with some exceptions. Symbol and naming convections used for pseudocode.

- // Comment=
- = Assignment
- ==, !=, <, > Operator equal, not equal, less than, greater than
- +, −, *, /, % Operator addition, subtraction, multiply, divide, modulus
- &, |, ̂, <<, >>, ˜ Bitwise AND, bitwise OR, bitwise exclusive OR, left shift, right shift, complement
- AND, OR, NOT Logical AND, Logical OR, Logical inversion
- [XX:YY] Array/vector specifier
- {a, b, c} Concatenation operation
- ++, −− Increment and decrement

1.4 Register and Signal Naming Conventions

In general register naming uses the C style conventions with capitalization to denote word delimiters. Signals use RTL style notation where underscore denote word delimiters. There is a direct translation between both conventions. For example the CmdSourceFifo register is equivalent to cmd_source_fifo signal.

1.5 State Machine Notation

State machines are described using the pseudocode notation outlined above. State machine descriptions use the convention of underline to indicate the cause of a transition from one state to another and plain text (no underline) to indicate the effect of the transition i.e. signal transitions which occur when the new state is entered. A sample state machine is shown in FIG. 1.

1.6 Print Quality Considerations

The preferred embodiment linking printhead produces 1600 dpi bi-level dots. On low-diffusion paper, each ejected drop forms a 22.5 μm diameter dot. Dots are easily produced in isolation, allowing dispersed-dot dithering to be exploited to its fullest. Since the preferred form of the linking printhead is pagewidth and operates with a constant paper velocity, color planes are printed in good registration, allowing dot-on-dot printing. Dot-on-dot printing minimizes ‘muddying’ of midtones caused by inter-color bleed.

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×16×8 bits for 257 intensity levels).

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.

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.

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).

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.7 Memjet Printer Architecture

The SoPEC device can be used in several printer configurations and architectures. In the general sense, every preferred embodiment SoPEC-based printer architecture will contain:

- One or more SoPEC devices.
- One or more linking printheads.
- Two or more LSS busses.
- Two or more QA chips.
- Connection to host, directly via USB2.0 or indirectly.
- Connections between SoPECs (when multiple SoPECs are used).

1.7.1 System Components

1.7.1.1 SoPEC Print Engine Controller

The SoPEC device contains several system on a chip (SoC) components, as well as the print engine pipeline control application specific logic.

1.7.1.2 Print Engine Pipeline (PEP) Logic

The PEP reads compressed page store data from the embedded memory, optionally decompresses the data and formats it for sending to the printhead. The print engine pipeline functionality includes expanding the page image, dithering the contone layer, compositing the black layer over the contone layer, rendering of Netpage tags, compensation for dead nozzles in the printhead, and sending the resultant image to the linking printhead.

1.7.1.3 Embedded CPU

SoPEC contains an embedded CPU for general-purpose system configuration and management. The CPU performs page and band header processing, motor control and sensor monitoring (via the GPIO) and other system control functions. The CPU can perform buffer management or report buffer status to the host. The CPU can optionally run vendor application specific code for general print control such as paper ready monitoring and LED status update.

1.7.1.4 Embedded Memory Buffer

A 2.5 Mbyte embedded memory buffer is integrated onto the SoPEC device, of which approximately 2 Mbytes are available for compressed page store data. A compressed page is divided into one or more bands, with a number of bands stored in memory. As a band of the page is consumed by the PEP for printing a new band can be downloaded. The new band may be for the current page or the next page.

Using banding it is possible to begin printing a page before the complete compressed page is downloaded, but care must be taken to ensure that data is always available for printing or a buffer underrun may occur.

A Storage SoPEC acting as a memory buffer could be used to provide guaranteed data delivery.

1.7.1.5 Embedded USB2.0 Device Controller

The embedded single-port USB2.0 device controller can be used either for interface to the host PC, or for communication with another SoPEC as an ISCSlave. It accepts compressed page data and control commands from the host PC or ISCMaster SoPEC, and transfers the data to the embedded memory for printing or downstream distribution.

1.7.1.6 Embedded USB2.0 Host Controller

The embedded three-port USB2.0 host controller enables communication with other SoPEC devices as a ISCMaster, as well as interfacing with external chips (e.g. for Ethernet connection) and external USB devices, such as digital cameras.

1.7.1.7 Embedded Device/Motor Controllers

SoPEC contains embedded controllers for a variety of printer system components such as motors, LEDs etc, which are controlled via SoPEC's GPIOs. This minimizes the need for circuits external to SoPEC to build a complete printer system.

1.7.1.8 Linking Printhead

The printhead is constructed by abutting a number of printhead ICs together. Each SoPEC can drive up to 12 printhead ICs at data rates up to 30 ppm or 6 printhead ICs at data rates up to 60 ppm. For higher data rates, or wider printheads, multiple SoPECs must be used.

1.7.1.9 LSS Interface Bus

Each SoPEC device has 2 LSS system buses for communication with QA devices for system authentication and ink usage accounting. The number of QA devices per bus and their position in the system is unrestricted with the exception that PRINTER_QA and INK_QA devices should be on separate LSS busses.

1.7.1.10 QA Devices

Each SoPEC system can have several QA devices. Normally each printing SoPEC will have an associated PRINTER_QA. Ink cartridges will contain an INK_QA chip. PRINTER_QA and INK_QA devices should be on separate LSS busses. All QA chips in the system are physically identical with flash memory contents defining PRINTER_QA from INK_QA chip.

1.7.1.11 Connections Between SoPECs

In a multi-SoPEC system, the primary communication channel is from a USB2.0 Host port on one SoPEC (the ISCMaster), to the USB2.0 Device port of each of the other SoPECs (ISCSlaves). If there are more ISCSlave SoPECs than available USB Host ports on the ISCMaster, additional connections could be via a USB Hub chip, or daisy-chained SoPEC chips. Typically one or more of SoPEC's GPIO signals would also be used to communicate specific events between multiple SoPECs.

1.7.1.12 Non-USB Host PC Communication

The communication between the host PC and the ISCMaster SoPEC may involve an external chip or subsystem, to provide a non-USB host interface, such as ethernet or WiFi. This subsystem may also contain memory to provide an additional buffered band/page store, which could provide guaranteed bandwidth data deliver to SoPEC during complex page prints.

1.7.2 Possible SoPEC Systems

Several possible SoPEC based system architectures exist. The following sections outline some possible architectures. It is possible to have extra SoPEC devices in the system used for DRAM storage. The QA chip configurations shown are indicative of the flexibility of LSS bus architecture, but not limited to those configurations.

1.7.2.1 A4 Simplex at 30 ppm with 1 SoPEC Device

In FIG. 2, a single SoPEC device is used to control a linking printhead with 11 printhead ICs. The SoPEC receives compressed data from the host through its USB device port. The compressed data is processed and transferred to the printhead. This arrangement is limited to a speed of 30 ppm. The single SoPEC also controls all printer components such as motors, LEDs, buttons etc, either directly or indirectly.

1.7.2.2 A4 Simplex at 60 ppm with 2 SoPEC Devices

In FIG. 3, two SoPECs control a single linking printhead, to provide 60 ppm A4 printing. Each SoPEC drives 5 or 6 of the printheads ICs that make up the complete printhead. SoPEC #0 is the ISCMaster, SoPEC #1 is an ISCSlave. The ISCMaster receives all the compressed page data for both SoPECs and re-distributes the compressed data for the ISCSlave over a local USB bus. There is a total of 4 MBytes of page store memory available if required. Note that, if each page has 2 MBytes of compressed data, the USB2.0 interface to the host needs to run in high speed (not full speed) mode to sustain 60 ppm printing. (In practice, many compressed pages will be much smaller than 2 MBytes). The control of printer components such as motors, LEDs, buttons etc, is shared between the 2 SoPECs in this configuration.

1.7.2.3 A4 Duplex with 2 SoPEC Devices

In FIG. 4, two SoPEC devices are used to control two printheads. Each printhead prints to opposite sides of the same page to achieve duplex printing. SoPEC #0 is the ISCMaster, SoPEC #1 is an ISCSlave. The ISCMaster receives all the compressed page data for both SoPECs and re-distributes the compressed data for the ISCSlave over a local USB bus. This configuration could print 30 double-sided pages per minute.

1.7.2.4 A3 Simplex with 2 SoPEC Devices

In FIG. 5, two SoPEC devices are used to control one A3 linking printhead, constructed from 16 printhead ICs. Each SoPEC controls 8 printhead ICs. This system operates in a similar manner to the 60 ppm A4 system in FIG. 3, although the speed is limited to 30 ppm at A3, since each SoPEC can only drive 6 printhead ICs at 60 ppm speeds. A total of 4 Mbyte of page store is available, this allows the system to use compression rates as in a single SoPEC A4 architecture, but with the increased page size of A3.

1.7.2.5 A3 Duplex with 4 SoPEC Devices

In FIG. 6 a four SoPEC system is shown. It contains 2 A3 linking printheads, one for each side of an A3 page. Each printhead contain 16 printhead ICs, each SoPEC controls 8 printhead ICs. SoPEC #0 is the ISCMaster with the other SoPECs as ISCSlaves. Note that all 3 USB Host ports on SoPEC #0 are used to communicate with the 3 ISCSlave SoPECs. In total, the system contains 8 Mbytes of compressed page store (2 Mbytes per SoPEC), so the increased page size does not degrade the system print quality, from that of an A4 simplex printer. The ISCMaster receives all the compressed page data for all SoPECs and re-distributes the compressed data over the local USB bus to the ISCSlaves. This configuration could print 30 double-sided A3 sheets per minute.

1.7.2.6 SoPEC DRAM Storage Solution: A4 Simplex with 1 Printing SoPEC and 1 Memory SoPEC

Extra SoPECs can be used for DRAM storage e.g. in FIG. 7 an A4 simplex printer can be built with a single extra SoPEC used for DRAM storage. The DRAM SoPEC can provide guaranteed bandwidth delivery of data to the printing SoPEC. SoPEC configurations can have multiple extra SoPECs used for DRAM storage.

1.7.2.7 Non-USB Connection to Host PC

FIG. 8 shows a configuration in which the connection from the host PC to the printer is an ethernet network, rather than USB. In this case, one of the USB Host ports on SoPEC interfaces to a external device that provide ethernet-to-USB bridging. Note that some networking software support in the bridging device might be required in this configuration. A Flash RAM will be required in such a system, to provide SoPEC with driver software for the Ethernet bridging function.

1.8 Document Data Flow

1.8.1 Overall Flow for PC-Based Printing

Because of the page-width nature of the linking printhead, each page must be printed at a constant speed to avoid creating visible artifacts. This means that the printing speed can't be varied to match the input data rate. Document rasterization and document printing are therefore decoupled to ensure the printhead has a constant supply of data. A page is never printed until it is fully rasterized. This can be achieved by storing a compressed version of each rasterized page image in memory.

This decoupling also allows the RIP(s) to run ahead of the printer when rasterizing simple pages, buying time to rasterize more complex pages.

Because contone color images are reproduced by stochastic dithering, but black text and line graphics are reproduced directly using dots, the compressed page image format contains a separate foreground bi-level black layer and background contone color layer. The black layer is composited over the contone layer after the contone layer is dithered (although the contone layer has an optional black component). A final layer of Netpage tags (in infrared, yellow or black ink) is optionally added to the page for printout.

FIG. 9 shows the flow of a document from computer system to printed page.

1.8.2 Multi-Layer Compression

At 267 ppi for example, an A4 page (8.26 inches 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.

At 800 dpi, an A4 page of bi-level data has a size of 7.4 MB. At 1600 dpi, a Letter page of bi-level data has a size of 29.5 MB. Coherent data such as text compresses very well. Using lossless bi-level compression algorithms such as SMG4 fax, ten-point plain text compresses with a ratio of about 50:1. Lossless bi-level compression across an average page is about 20:1 with 10:1 possible for pages which compress poorly. The requirement for SoPEC is to be able to print text at 10:1 compression. Assuming 10:1 compression gives compressed page sizes of 0.74 MB at 800 dpi, and 2.95 MB at 1600 dpi.

Once dithered, a page of CMYK contone image data consists of 116 MB of bi-level data. Using lossless bi-level compression algorithms on this data is pointless precisely because the optimal dither is stochastic—i.e. since it introduces hard-to-compress disorder.

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 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 2 mm (each tag is 126 dots 126 dots, for a total coverage of 148 tags 105 tags). 15,540 tags of 128 bits per tag gives a compressed tag page size of 0.24 MB.

The multi-layer compressed page image format therefore exploits the relative strengths of lossy JPEG contone image compression, lossless bi-level text compression, and tag encoding. The format is compact enough to be storage-efficient, and simple enough to allow straightforward real-time expansion during printing.

Since text and images normally don't overlap, the normal worst-case page image size is image only, while the normal best-case page image size is text only. The addition of worst case Netpage tags adds 0.24 MB to the page image size. The worst-case page image size is text over image plus tags. The average page size assumes a quarter of an average page contains images. Table 1 shows data sizes for a compressed A4 page for these different options.

TABLE 1

Data sizes for A4 page (8.26 inches 11.7 inches)

267 ppi
320 ppi

contone
contone

800 dpi bi-
1600 dpi bi-

level
level

Image only (contone), 10:1
2.63 MB
3.78 MB

compression

Text only (bi-level), 10:1
0.74 MB
2.95 MB

compression

Netpage tags, 1600 dpi
0.24 MB
0.24 MB

Worst case (text + image +
3.61 MB
6.67 MB

tags)

Average (text + 25% image +
1.64 MB
4.25 MB

tags)

1.8.3 Document Processing Steps

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 directly via a USB link, or via an external bridge e.g. from ethernet to USB. 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 linking printhead.

The document data flow is:

- The RIP software rasterizes each page description and compress the rasterized page image.
- The infrared layer of the printed page optionally contains encoded Netpage tags at a programmable density.
- The compressed page image is transferred to the SoPEC device via the USB (or ethernet), normally on a band by band basis.
- The print engine takes the compressed page image and starts the page expansion.
- The first stage page expansion consists of 3 operations performed in parallel
- expansion of the JPEG-compressed contone layer
- expansion of the SMG4 fax compressed bi-level layer
- encoding and rendering of the bi-level tag data.
- The second stage dithers the contone layer using a programmable dither matrix, producing up to four bi-level layers at full-resolution.
- The third 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.
- A fixative layer is also generated as required.
- The last stage formats and prints the bi-level data through the linking printhead via the printhead interface.

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 linking printhead color planes.

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.

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 edged contone images, such as 1600 dpi color text.

1.8.4 Page Size and Complexity in SoPEC

The SoPEC device typically stores a complete page of document data on chip. The amount of storage available for compressed pages is limited to 2 Mbytes, imposing a fixed maximum on compressed page size. A comparison of the compressed image sizes in Table 1 indicates that SoPEC would not be capable of printing worst case pages unless they are split into bands and printing commences before all the bands for the page have been downloaded. The page sizes in the table are shown for comparison purposes and would be considered reasonable for a professional level printing system. The SoPEC device is aimed at the consumer level and would not be required to print pages of that complexity. Target document types for the SoPEC device are shown Table 2.

TABLE 2

Page content targets for SoPEC

Size

Page Content Description
Calculation
(MByte)

Best Case picture Image, 267ppi with 3 colors, A4
8.26 × 11.7 × 267 × 267 ×
1.97

size
3 @10:1

Full page text, 800dpi A4 size
8.26 × 11.7 × 800 × 800
0.74

@ 10:1

Mixed Graphics and Text

1.55

Image of 6 inches × 4 inches @ 267 ppi and 3
6 × 4 × 267 × 267 × 3 @

colors
5:1

Remaining area text ~73 inches², 800 dpi
800 × 800 × 73 @ 10:1

Best Case Photo, 3 Colors, 6.6 MegaPixel Image
6.6 Mpixel @ 10:1
2.00

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 print quality, or
- It can 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.

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. Alternatively, a number of methods are available to provide additional local page data storage with guaranteed bandwidth to SoPEC, for example a Storage SoPEC.

1.8.5 Other Printing Sources

The preceding sections have described the document flow for printing from a host PC in which the RIP on the host PC does much of the management work for SoPEC. SoPEC also supports printing of images directly from other sources, such as a digital camera or scanner, without the intervention of a host PC.

In such cases, SoPEC receives image data (and associated metadata) into its DRAM via a USB host or other local media interface. Software running on SoPEC's CPU determines the image format (e.g. compressed or non-compressed, RGB or CMY, etc.), and optionally applies image processing algorithms such as color space conversion. The CPU then makes the data to be printed available to the PEP pipeline. SoPEC allows various PEP pipeline stages to be bypassed, for example JPEG decompression. Depending on the format of the data to be printed, PEP hardware modules interact directly with the CPU to manage DRAM buffers, to allow streaming of data from an image source (e.g. scanner) to the printhead interface without overflowing the limited on-chip DRAM.

1.9 Page Format

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. 10 shows the high level data structure of a number of pages with different numbers of bands in the page. Each compressed band contains a mandatory band header, an optional bi-level plane, optional sets of interleaved contone planes, and an optional tag data plane (for Netpage enabled applications). Since each of these planes is optional, the band header specifies which planes are included with the band. FIG. 11 gives a high-level breakdown of the contents of a page band.

A single SoPEC has maximum rendering restrictions as follows:

- 1 bi-level plane
- 1 contone interleaved plane set containing a maximum of 4 contone planes
- 1 tag data plane
- a linking printhead with a maximum of 12 printhead ICs

The requirement for single-sided A4 single SoPEC printing at 30 ppm is

- 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.
- average bi-level compression ratio of 10:1, with a local minimum compression ratio of 1:1 for a single line.

If the page contains rendering parameters that exceed these specifications, then the RIP or the Host PC must split the page into a format that can be handled by a single SoPEC.

In the general case, the SoPEC CPU must analyze the page and band headers and generate an appropriate set of register write commands to configure the units in SoPEC for that page. The various bands are passed to the destination SoPEC(s) to locations in DRAM determined by the host.

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 receives its band data via its USB device interface. Band usage information from the individual SoPECs is passed back to the host. FIG. 12 shows an example data flow for a page destined to be printed by a single SoPEC.

SoPEC has an addressing mechanism that permits circular band memory allocation, thus facilitating easy memory management. However it is not strictly necessary that all bands be stored together. As long as the appropriate registers in SoPEC are set up for each band, and a given band is contiguous, the memory can be allocated in any way.

1.9.1 Print Engine Example Page Format

Note: This example is illustrative of the types of data a compressed page format may need to contain. The actual implementation details of page formats are a matter for software design (including embedded software on the SoPEC CPU); the SoPEC hardware does not assume any particular format.

This section describes a possible format of compressed pages expected by the embedded CPU in SoPEC. The format is generated by software in the host PC and interpreted by embedded software in SoPEC. This section indicates the type of information in a page format structure, but implementations need not be limited to this format. The host PC can optionally perform the majority of the header processing.

The compressed format and the print engines are designed to allow real-time page expansion during printing, to ensure that printing is never interrupted in the middle of a page due to data underrun.

The page format described here is for a single black bi-level layer, a contone layer, and a Netpage tag layer. The black bi-level layer is defined to composite over the contone layer.

The black bi-level layer consists of a bitmap containing a 1-bit opacity for each pixel. This black layer matte has a resolution which is an integer or non-integer factor of the printer's dot resolution. The highest supported resolution is 1600 dpi, i.e. the printer's full dot resolution.

The contone layer, optionally passed in as YCrCb, consists of a 24-bit CMY or 32-bit CMYK color for each pixel. This contone image has a resolution which is an integer or non-integer factor of the printer's dot resolution. The requirement for a single SoPEC is to support 1 side per 2 seconds A4/Letter printing at a resolution of 267 ppi, i.e. one-sixth the printer's dot resolution.

Non-integer scaling can be performed on both the contone and bi-level images. Only integer scaling can be performed on the tag data.

The black bi-level layer and the contone layer are both in compressed form for efficient storage in the printer's internal memory.

1.9.1.1 Page Structure

A single SoPEC is able to print with full edge bleed for A4/Letter paper using the linking printhead. It imposes no margins and so has a printable page area which corresponds to the size of its paper. The target page size is constrained by the printable page area, less the explicit (target) left and top margins specified in the page description. These relationships are illustrated below.

1.9.1.2 Compressed Page Format

Apart from being implicitly defined in relation to the printable page area, each page description is complete and self-contained. There is no data stored separately from the page description to which the page description refers. The page description consists of a page header which describes the size and resolution of the page, followed by one or more page bands which describe the actual page content.

1.9.1.2.1 Page Header

The page header contains a signature and version which allow the CPU to identify the page header format. If the signature and/or version are missing or incompatible with the CPU, then the CPU can reject the page.

The contone flags define how many contone layers are present, which typically is used for defining whether the contone layer is CMY or CMYK. Additionally, if the color planes are CMY, they can be optionally stored as YCrCb, and further optionally color space converted from CMY directly or via RGB. Finally the contone data is specified as being either JPEG compressed or non-compressed.

The page header defines the resolution and size of the target page. The bi-level and contone layers are clipped to the target page if necessary. This happens whenever the bi-level or contone scale factors are not factors of the target page width or height.

The target left, top, right and bottom margins define the positioning of the target page within the printable page area.

The tag parameters specify whether or not Netpage tags should be produced for this page and what orientation the tags should be produced at (landscape or portrait mode). The fixed tag data is also provided.

The contone, bi-level and tag layer parameters define the page size and the scale factors.

1.9.1.2.2 Band Format

The bi-level layer parameters define the height of the black band, and the size of its compressed band data. The variable-size black data follows the page band header.

The contone layer parameters define the height of the contone band, and the size of its compressed page data. The variable-size contone data follows the black data.

The tag band data is the set of variable tag data half-lines as required by the tag encoder. The tag band data follows the contone data.

The start of each variable-size segment of band data should be aligned to a 256-bit DRAM word boundary.

The following sections describe the format of the compressed bi-level layers and the compressed contone layer.

1.9.1.2.3 Bi-Level Data Compression

The (typically 1600 dpi) black bi-level layer is losslessly compressed using Silverbrook Modified Group 4 (SMG4) compression which is a version of Group 4 Facsimile compression without Huffman and with simplified run length encodings. Typically compression ratios exceed 10:1.

Since the compression is a bitstream, the encodings are read right (least significant bit) to left (most significant bit).

Each band of bi-level data is optionally self contained. The first line of each band therefore is based on a ‘previous’ blank line or the last line of the previous band.

1.9.1.2.3.1 Group 3 and 4 Facsimile Compression

The Group 3 Facsimile compression algorithm losslessly compresses bi-level data for transmission over slow and noisy telephone lines. The bi-level data represents scanned black text and graphics on a white background, and the algorithm is tuned for this class of images (it is explicitly not tuned, for example, for halftoned bi-level images). The 1D Group 3 algorithm runlength-encodes each scanline and then Huffman-encodes the resulting runlengths. Runlengths in the range 0 to 63 are coded with terminating codes. Runlengths in the range 64 to 2623 are coded with make-up codes, each representing a multiple of 64, followed by a terminating code. Runlengths exceeding 2623 are coded with multiple make-up codes followed by a terminating code. The Huffman tables are fixed, but are separately tuned for black and white runs (except for make-up codes above 1728, which are common). When possible, the 2D Group 3 algorithm encodes a scanline as a set of short edge deltas (0, ±1, ±2, ±3) with reference to the previous scanline. The delta symbols are entropy-encoded (so that the zero delta symbol is only one bit long etc.) Edges within a 2D-encoded line which can't be delta-encoded are runlength-encoded, and are identified by a prefix. 1D- and 2D-encoded lines are marked differently. 1D-encoded lines are generated at regular intervals, whether actually required or not, to ensure that the decoder can recover from line noise with minimal image degradation. 2D Group 3 achieves compression ratios of up to 6:1.

The Group 4 Facsimile algorithm losslessly compresses bi-level data for transmission over error-free communications lines (i.e. the lines are truly error-free, or error-correction is done at a lower protocol level). The Group 4 algorithm is based on the 2D Group 3 algorithm, with the essential modification that since transmission is assumed to be error-free, 1D-encoded lines are no longer generated at regular intervals as an aid to error-recovery. Group 4 achieves compression ratios ranging from 20:1 to 60:1 for the CCITT set of test images.

The design goals and performance of the Group 4 compression algorithm qualify it as a compression algorithm for the bi-level layers. However, its Huffman tables are tuned to a lower scanning resolution (100-400 dpi), and it encodes runlengths exceeding 2623 awkwardly.

1.9.1.2.4 Contone Data Compression

The contone layer (CMYK) is either a non-compressed bytestream or is compressed to an interleaved JPEG bytestream. The JPEG bytestream is complete and self-contained. It contains all data required for decompression, including quantization and Huffman tables.

The contone data is optionally converted to YCrCb before being compressed (there is no specific advantage in color-space converting if not compressing). Additionally, the CMY contone pixels are optionally converted (on an individual basis) to RGB before color conversion using R=255−C, G=255−M, B=255−Y. Optional bitwise inversion of the K plane may also be performed. Note that this CMY to RGB conversion is not intended to be accurate for display purposes, but rather for the purposes of later converting to YCrCb. The inverse transform will be applied before printing.

1.9.1.2.4.1 JPEG Compression

The JPEG compression algorithm lossily compresses a contone image at a specified quality level. It introduces imperceptible image degradation at compression ratios below 5:1, and negligible image degradation at compression ratios below 10:1.

JPEG typically first transforms the image into a color space which separates luminance and chrominance into separate color channels. This allows the chrominance channels to be subsampled without appreciable loss because of the human visual system's relatively greater sensitivity to luminance than chrominance. After this first step, each color channel is compressed separately.

The image is divided into 8 8 pixel blocks. Each block is then transformed into the frequency domain via a discrete cosine transform (DCT). This transformation has the effect of concentrating image energy in relatively lower-frequency coefficients, which allows higher-frequency coefficients to be more crudely quantized. This quantization is the principal source of compression in JPEG. Further compression is achieved by ordering coefficients by frequency to maximize the likelihood of adjacent zero coefficients, and then runlength-encoding runs of zeroes. Finally, the runlengths and non-zero frequency coefficients are entropy coded. Decompression is the inverse process of compression.

1.9.1.2.4.2 Non-Compressed Format

If the contone data is non-compressed, it must be in a block-based format bytestream with the same pixel order as would be produced by a JPEG decoder. The bytestream therefore consists of a series of 8 8 block of the original image, starting with the top left 8 8 block, and working horizontally across the page (as it will be printed) until the top rightmost 8 8 block, then the next row of 8 8 blocks (left to right) and so on until the lower row of 8 8 blocks (left to right). Each 8 8 block consists of 64 8-bit pixels for color plane 0 (representing 8 rows of 8 pixels in the order top left to bottom right) followed by 64 8-bit pixels for color plane 1 and so on for up to a maximum of 4 color planes.

If the original image is not a multiple of 8 pixels in X or Y, padding must be present (the extra pixel data will be ignored by the setting of margins).

1.9.1.2.4.3 Compressed Format

If the contone data is compressed the first memory band contains JPEG headers (including tables) plus MCUs (minimum coded units). The ratio of space between the various color planes in the JPEG stream is 1:1:1:1. No subsampling is permitted. Banding can be completely arbitrary i.e there can be multiple JPEG images per band or 1 JPEG image divided over multiple bands. The break between bands is only memory alignment based.

1.9.1.2.4.4 Conversion of RGB to YCrCb (in RIP)

YCrCb is defined as per CCIR 601-1 except that Y, Cr and Cb are normalized to occupy all 256 levels of an 8-bit binary encoding and take account of the actual hardware implementation of the inverse transform within SoPEC.

The exact color conversion computation is as follows:

- Y*=(9805/32768)R+(19235/32768)G+(3728/32768)B
- Cr*=(16375/32768)R−(13716/32768)G−(2659/32768)B+128
- Cb*=−(5529/32768)R−(10846/32768)G+(16375/32768)B+128

Y, Cr and Cb are obtained by rounding to the nearest integer. There is no need for saturation since ranges of Y*, Cr* and Cb* after rounding are [0-255], [1-255] and [1-255] respectively. Note that full accuracy is possible with 24 bits.

2 SoPEC ASIC

2.1 Features and Architecture

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 linking printhead. The dot generation process takes account of printhead construction, dead nozzles, and allows for fixative generation.

A single SoPEC can control up to 12 linking printheads and up to 6 color channels at >10,000 lines/sec, equating to 30 pages per minute. A single SoPEC can perform full-bleed printing of A4 and Letter pages. The 6 channels of colored ink are the expected maximum in a consumer SOHO, or office Memjet printing environment:

- CMY, for regular color printing.
- K, for black text, line graphics and gray-scale printing.
- IR (infrared), for Netpage-enabled applications.
- F (fixative), to enable printing at high speed. Because the Memjet printer is capable of printing so fast, a fixative may be required on specific media types (such as calendared paper) to enable the ink to dry before the page touches a previously printed page. Otherwise the pages may bleed on each other. In low speed printing environments, and for plain and photo paper, the fixative is not be required.

SoPEC is color space agnostic. Although it can accept contone data as CMYX or RGBX, where X is an optional 4th channel (such as black), 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 only generated for fast printing applications.

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 linking printhead.

SoPEC is page-length agnostic. Successive pages are typically split into bands and downloaded into the page store as each band of information is consumed and becomes free.

SoPEC provides mechanisms 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.

2.2 Printing Rates

The required printing rate for a single SoPEC is 30 sheets per minute with an inter-sheet spacing of 4 cm. To achieve a 30 sheets per minute print rate, this requires:

- 300 mm×63 (dot/mm)/2 sec=105.8 μseconds per line, with no inter-sheet gap.
- 340 mm×63 (dot/mm)/2 sec=93.3 μseconds per line, with a 4 cm inter-sheet gap.

A printline for an A4 page consists of 13 824 nozzles across the page. At a system clock rate of 192 MHz, 13824 dots of data can be generated in 69.2 μseconds. Therefore data can be generated fast enough to meet the printing speed requirement.

Once generated, the data must be transferred to the printhead. Data is transferred to the printhead ICs using a 288 MHz clock ( 3/2 times the system clock rate). SoPEC has 6 printhead interface ports running at this clock rate. Data is 8b/10b encoded, so the throughput per port is 0.8×288=230.4 Mb/sec. For 6 color planes, the total number of dots per printhead IC is 1280×6=7680, which takes 33.3 μseconds to transfer. With 6 ports and 11 printhead ICs, 5 of the ports address 2 ICs sequentially, while one port addresses one IC and is idle otherwise. This means all data is transferred on 66.7 μseconds (plus a slight overhead). Therefore one SoPEC can transfer data to the printhead fast enough for 30 ppm printing.

2.3 SoPEC Basic Architecture

From the highest point of view the SoPEC device consists of 3 distinct subsystems

- CPU Subsystem
- DRAM Subsystem
- Print Engine Pipeline (PEP) Subsystem

See FIG. 14 for a block level diagram of SoPEC.

2.3.1 CPU Subsystem

The CPU subsystem controls and configures all aspects of the other subsystems. It provides general support for interfacing and synchronising the external printer with the internal print engine. It also controls the low speed communication to the QA chips. The CPU subsystem contains various peripherals to aid the CPU, such as GPIO (includes motor control), interrupt controller, LSS Master, MMI and general timers. The CPR block provides a mechanism for the CPU to powerdown and reset individual sections of SoPEC. The UDU and UHU provide high-speed USB2.0 interfaces to the host, other SoPEC devices, and other external devices. For security, the CPU supports user and supervisor mode operation, while the CPU subsystem contains some dedicated security components.

2.3.2 DRAM Subsystem

The DRAM subsystem accepts requests from the CPU, UHU, UDU, MMI and blocks within the PEP subsystem. The DRAM subsystem (in particular the DIU) arbitrates the various requests and determines which request should win access to the DRAM. The DIU arbitrates based on configured parameters, to allow sufficient access to DRAM for all requestors. The DIU also hides the implementation specifics of the DRAM such as page size, number of banks, refresh rates etc.

2.3.3 Print Engine Pipeline (PEP) Subsystem

The Print Engine Pipeline (PEP) subsystem accepts compressed pages from DRAM and renders them to bi-level dots for a given print line destined for a printhead interface that communicates directly with up to 12 linking printhead ICs.

The first stage of the page expansion pipeline is the CDU, LBD and TE. The CDU expands the JPEG-compressed contone (typically CMYK) layer, the LBD expands the compressed bi-level layer (typically K), and the TE encodes Netpage tags for later rendering (typically in IR, Y or K ink). The output from the first stage is a set of buffers: the CFU, SFU, and TFU. The CFU and SFU buffers are implemented in DRAM.

The second stage is the HCU, which dithers the contone layer, and composites position tags and the bi-level spot0 layer over the resulting bi-level dithered layer. A number of options exist for the way in which compositing occurs. Up to 6 channels of bi-level data are produced from this stage. Note that not all 6 channels may be present on the printhead. For example, the printhead may be CMY only, with K pushed into the CMY channels and IR ignored. Alternatively, the position tags may be printed in K or Y if IR ink is not available (or for testing purposes).

The third stage (DNC) compensates for dead nozzles in the printhead by color redundancy and error diffusing dead nozzle data into surrounding dots.

The resultant bi-level 6 channel dot-data (typically CMYK-IRF) is buffered and written out to a set of line buffers stored in DRAM via the DWU.

Finally, the dot-data is loaded back from DRAM, and passed to the printhead interface via a dot FIFO. The dot FIFO accepts data from the LLU up to 2 dots per system clock cycle, while the PHI removes data from the FIFO and sends it to the printhead at a maximum rate of 1.5 dots per system clock cycle.

2.4 Buffer Management in SoPEC

SoPEC has a requirement to print 1 side every 2 seconds i.e. 30 sides per minute.

2.4.1 Page Buffering

Approximately 2 Mbytes of DRAM are reserved for compressed page buffering in SoPEC. If a page is compressed to fit within 2 Mbyte then a complete page can be transferred to DRAM before printing. USB2.0 in high speed mode allows the transfer of 2 Mbyte in less than 40 ms, so data transfer from the host is not a significant factor in print time in this case.

For a host PC running in USB1.1 compatible full speed mode, the transfer time for 2 Mbyte approaches 2 seconds, so the cycle time for full page buffering approaches 4 seconds.

2.4.2 Band Buffering

The SoPEC page-expansion blocks support the notion of page banding. The page can be divided into bands and another band can be sent down to SoPEC while the current band is being printed.

Therefore printing can start once at least one band has been downloaded.

The band size granularity should be carefully chosen to allow efficient use of the USB bandwidth and DRAM buffer space. It should be small enough to allow seamless 30 sides per minute printing but not so small as to introduce excessive CPU overhead in orchestrating the data transfer and parsing the band headers. Band-finish interrupts have been provided to notify the CPU of free buffer space. It is likely that the host PC will supervise the band transfer and buffer management instead of the SoPEC CPU.

If SoPEC starts printing before the complete page has been transferred to memory there is a risk of a buffer underrun occurring if subsequent bands are not transferred to SoPEC in time e.g. due to insufficient USB bandwidth caused by another USB peripheral consuming USB bandwidth. A buffer underrun occurs if a line synchronisation pulse is received before a line of data has been transferred to the printhead and causes the print job to fail at that line. If there is no risk of buffer underrun then printing can safely start once at least one band has been downloaded.

If there is a risk of a buffer underrun occurring due to an interruption of compressed page data transfer, then the safest approach is to only start printing once all of the bands have been loaded for a complete page. This means that some latency (dependent on USB speed) will be incurred before printing the first page. Bands for subsequent pages can be downloaded during the printing of the first page as band memory is freed up, so the transfer latency is not incurred for these pages.

A Storage SoPEC, or other memory local to the printer but external to SoPEC, could be added to the system, to provide guaranteed bandwidth data delivery.

The most efficient page banding strategy is likely to be determined on a per page/print job basis and so SoPEC will support the use of bands of any size.

2.4.3 USB Operation in Multi-SoPEC Systems

In a system containing more than one SoPECs, the high bandwidth communication path between SoPECs is via USB. Typically, one SoPEC, the ISCMaster, has a USB connection to the host PC, and is responsible for receiving and distributing page data for itself and all other SoPECs in the system. The ISCMaster acts as a USB Device on the host PC's USB bus, and as the USB Host on a USB bus local to the printer.

Any local USB bus in the printer is logically separate from the host PC's USB bus; a SoPEC device does not act as a USB Hub. Therefore the host PC sees the entire printer system as a single USB function.

The SoPEC UHU supports three ports on the printer's USB bus, allowing the direct connection of up to three additional SoPEC devices (or other USB devices). If more than three USB devices need to be connected, two options are available:

- Expand the number of ports on the printer USB bus using a USB Hub chip.
- Create one or more additional printer USB busses, using the UHU ports on other SoPEC devices

FIG. 16 shows these options.

Since the UDU and UHU for a single SoPEC are on logically different USB busses, data flow between them is via the on-chip DRAM, under the control of the SoPEC CPU. There is no direct communication, either at control or data level, between the UDU and the UHU. For example, when the host PC sends compressed page data to a multi-SoPEC system, all the data for all SoPECs must pass via the DRAM on the ISCMaster SoPEC. Any control or status messages between the host and any SoPEC will also pass via the ISCMaster's DRAM.

Further, while the UDU on SoPEC supports multiple USB interfaces and endpoints within a single USB device function, it typically does not have a mechanism to identify at the USB level which SoPEC is the ultimate destination of a particular USB data or control transfer. Therefore software on the CPU needs to redirect data on a transfer-by-transfer basis, either by parsing a header embedded in the USB data, or based on previously communicated control information from the host PC. The software overhead involved in this management adds to the overall latency of compressed page download for a multi-SoPEC system.

The UDU and UHU contain highly configurable DMA controllers that allow the CPU to direct USB data to and from DRAM buffers in a flexible way, and to monitor the DMA for a variety of conditions. This means that the CPU can manage the DRAM buffers between the UDU and the UHU without ever needing to physically move or copy packet data in the DRAM.

3 Bi-Lithic Printheads

This section describes the bi-lithic printhead (as distinct from the linking printhead) from the point of view of printing 30 ppm from a SoPEC ASIC, as well as architectures that solve the 60 ppm printing requirement using the bi-lithic printhead model.

3.1 30 ppm Printheads

To print at 30 ppm, the printheads must print a single page within 2 seconds. This would include the time taken to print the page itself plus any inter-page gap (so that the 30 ppm target could be met). The required printing rate assumes an inter-sheet spacing of 4 cm.

A baseline SoPEC system connecting to two printhead segments is shown in FIG. 297. The two segments (A and B) combine to form a printhead of typical width 13,824 nozzles per color.

We assume decoupling of data generation, transmission to the printhead, and firing.

3.1.1 Data Generation

A single SoPEC produces the data for both printheads for the entire page. Therefore it has the entire line time in which to generate the dot data.

3.1.2 Letter Pages

A Letter page is 11 inches high. Assuming 1600 dpi and a 4 cm inter-page gap, there are 20,120 lines. This is a line rate of 10.06 KHz (a line time of 99.4 us).

The printhead is 14,080 dots wide. To calculate these dots within the line time, SoPEC requires a 140.8 MHz dot generation rate. Since SoPEC is run at 160 MHz and generates 1 dot per cycle, it is able to meet the Letter page requirement and cope with a small amount of stalling during the dot generation process.

3.1.3 A4 Pages

An A4 page is 297 mm high. Assuming 62.5 dots/mm and a 4 cm inter-page gap, there are 21,063 lines. This is a line rate of 10.54 KHz (a line time of 94.8 us).

The printhead is 14,080 dots wide. To calculate these dots within the line time, SoPEC requires a 148.5 MHz dot generation rate. Since SoPEC is run at 160 MHz and generates 1 dot per cycle, it is able to meet the A4 page requirement and cope with minimal stalling.

3.1.4 Transmitting the Dot Data to the Printhead

Assuming an n-color printhead, SoPEC must transmit 14,080 dots n-bits within the line time. i.e. n the data generation rate=n-bits 14,080 dots 10.54 KHz. Thus a 6-color printhead requires 874.2 Mb/sec.

The transmission time is further constrained by the fact that no data must be transmitted to the printhead segments during a window around the linesync pulse. Assuming a 1% overhead for linesync overhead (being very conservative), the required transmission bandwidth for 6 colors is 883 Mb/sec.

However, the data is transferred to both segments simultaneously. This means the longest time to transfer data for a line is determined by the time to transfer print data to the longest print segment. There are 9744 nozzles per color across a type 7 printhead. We therefore must be capable of transmitting 6-bits 9744 dots at the line rate i.e. 6-bits 9744 10.54 KHz=616.2 Mb/sec. Again, assuming a 1% overhead for linesync overhead, the required transmission bandwidth to each printhead is 622.4 Mb/sec.

The connections from SoPEC to each segment consist of 2 1-bit data lines that operate at 320 MHz each. This gives a total of 640 Mb/sec.

Therefore the dot data can be transmitted at the appropriate rate to the printhead to meet the 30 ppm requirement.

3.2 Hardware Specification

3.2.1 Dot Generation Hardware

SoPEC has a dot generation pipeline that generates 1 6-color dot per cycle.

The LBD and TE are imported blocks from PEC1, with only marginal changes, and these are therefore capable of nominally generating 2 dots per cycle. However the rest of the pipeline is only capable of generating 1 dot per cycle.

3.2.2 Dot Transmission Hardware

SoPEC is capable of transmitting data to 2 printheads simultaneously. Connections are 2 data plus 1 clock, each sent as an LVDS 2-wire pair. Each LVDS wire-pair is run at 320 MHz.

SoPEC is in a 100-pin QFP, with 12 of those wires dedicated to the transmission of print data (6 wires per printhead segment). Additional wires connect SoPEC to the printhead, but they are not considered for the purpose of this discussion.

3.2.3 Within the Printhead

The dot data is accepted by the printhead at 2-bits per cycle at 320 MHz. 6 bits are available after 3 cycles at 320 MHz, and these 6-bits are then clocked into the shift registers within the printhead at a rate of 106 MHz.

Thus the data movement within the printhead shift registers is able to keep up with the rate at which data arrives in the printhead.

3.3 3.60 ppm Printheads

This chapter describes the issues introduced by printing at 60 ppm, with the cases of 4, 5, and 6 colors in the printhead. The arrangement is shown in FIG. 298.

3.3.1 Data Generation

A 60 ppm printer is 1 page per second. i.e

- A4=21,063 lines. This is a line rate of 21.06 KHz (a line time of 47.4 us)
- Letter=20,120 lines. This is a line rate of 20.12 KHz (a line time of 49.7 us)

If each SoPEC is responsible for generating the data for its specific printhead, then the worst case for dot generation is the largest printhead.

Since the preferred embodiment of SoPEC is run at 160 MHz, it is only able to meet the dot requirement rate for the 5:5 printhead, and not the 6:4 or 7:3 printheads.

3.3.2 Transmitting the Dot Data to the Printhead

Each SoPEC must transmit a printhead's worth of bits per color to the printhead per line.

The transmission time is further constrained by the fact that no data must be transmitted to the printhead segments during a window around the linesync pulse. Assuming that the line sync overhead is constant regardless of print speed, then a 1% overhead at 30 ppm translates into a 2% overhead at 60 ppm.

Since we have 2 lines to the printhead operating at 320 MHz each, the total bandwidth available is 640 Mb/sec. The existing connection to the printhead will only deliver data to a 4-color 5:5 arrangement printhead fast enough for 60 ppm. The connection speed in the preferred embodiment is not fast enough to support any other printhead or color configuration.

3.3.3 Within the Printhead

The dot data is currently accepted by the printhead at 2-bits per cycle at 320 MHz. Although the connection rate is only fast enough for 4 color 5:5 printing, the data must still be moved around in the shift registers once received.

The 5:5 printer 4-color dot data is accepted by the printhead at 2-bits per cycle at 320 MHz. 4 bits are available after 2 cycles at 320 MHz, and these 4-bits would then need to be clocked into the shift registers within the printhead at a rate of 160 MHz.

Since the 6:4 and 7:3 printhead configuration schemes require additional bandwidth etc., the printhead needs some change to support these additional forms of 60 ppm printing.

3.3.4 Examples of 60 ppm Architectures

Given the problems described above, the following issues have been addressed for 60 ppm printing based on the earlier SoPEC architecture:

- rate of data generation
- transmission to the printhead
- shift register setup within the printhead.

Assuming the current bi-lithic printhead, there are 3 basic classes of solutions to allow 60 ppm:

- a) Each SoPEC generates dot data and transmits that data to a single printhead connection, as shown in FIG. 299.
- b) One SoPEC generates data and transmits to the smaller printhead, but both SoPECs generate and transmit directly to the larger printhead, as shown in FIG. 300.
- c) Same as (b) except that SoPEC A only transmits to printhead B via SoPEC B (i.e. instead of directly), as shown in FIG. 301.

3.3.4.1 Class A: Each SoPEC Writes to a Printhead

This solution class is where each SoPEC generates dot data and transmits that data to a single printhead connection, as shown in FIG. 299. The existing SoPEC architecture is targeted at this class of solution.

Two methods of implementing a 60 ppm solution of this class are examined in the following sections.

3.3.4.1.1 Basic Speed Improvement

To achieve 60 ppm using the same basic architecture as currently implemented, the following needs to occur:

- Increase effective dot generation rate to 206 MHz (see Table 2)
- Increase bandwidth to printhead to 1256 Mb/sec (see Table 3)
- Increase bandwidth of printhead shift registers to match transmission bandwidth

It should be noted that even when all these speed improvements are implemented, one SoPEC will still be producing 40% more dots than it would be under a 5:5 scheme. i.e. this class of solution is not load balanced.

3.3.4.1.2 Connect Printheads Together to Appear Logically as a 5:5

In this scenario, each SoPEC generates data as if for a 5:5 printhead, and the printhead, even though it is physically a 5:5, 6:4 or 7:3 printhead, maintains a logical appearance of a 5:5 printhead.

There are a number of means of accomplishing this logical appearance, but they all rely on the two printheads being connected in some way, as shown in FIG. 300.

In this embodiment, the dot generation rate no longer needs to be addressed as only the 5:5 dot generation rate is required, and the current speed of 160 MHz is sufficient.

3.3.4.2 Class B: Two SoPECs Write Directly to a Single Printhead

This solution class is where one SoPEC generates data and transmits to the smaller printhead, but both SoPECs generate and transmit directly to the larger printhead, as shown in FIG. 301. i.e. SoPEC A transmits to printheads A and B, while SoPEC B transmits only to printhead B. The intention is to allow each SoPEC to generate the dot data for a type 5 printhead, and thereby to balance the dot generation load.

Since the connections between SoPEC and printhead are point-to-point, it requires a doubling of printhead connections on the larger printhead (one connection set goes to SoPEC A and the other goes to SoPEC B).

The two methods of implementing a 60 ppm solution of this class depend on the internals of the printhead, and are examined in the following sections.

3.3.4.2.1 Serial Load

This is the scenario when the two connections on the printhead are connected to the same shift register. Thus the shift register can be driven by either SoPEC, as shown in FIG. 302.

The 2 SoPECs take turns (under synchronisation) in transmitting on their individual lines as follows:

- SoPEC B transmits even (or odd) data for 5 segments
- SoPEC A transmits data for 5-printhead A segments even and odd
- SoPEC B transmits the odd (or even) data for 5 segments.

Meanwhile SoPEC A is transmitting the data for printhead A, which will be length 3, 4, or 5.

Note that SoPEC A is transmitting as if to a printhead combination of N:5-N, which means that the dot generation pathway (other than synchronization) is already as defined.

Although the dot generation problem is resolved by this scenario (each SoPEC generates data for half the page width and therefore it is load balanced), the transmission speed for each connection must be sufficient to deliver to a type 7 printhead i.e. 1256 Mb/sec (see Table 3). In addition, the bandwidth of the printhead shift registers must be altered to match the transmission bandwidth.

3.3.4.2.2 Parallel Load

This is the scenario when the two connections on the printhead are connected to different shift registers, as shown in FIG. 303. Thus the two SoPECs can write to the printhead in parallel.

Note that SoPEC A is transmitting as if to a printhead combination of N:5-N, which means that the dot generation pathway is already as defined.

The dot generation problem is resolved by this scenario since each SoPEC generates data for half the page width and therefore it is load balanced.

Since the connections operate in parallel, the transmission speed required is that required to address 5:5 printing, i.e. 891 Mb/sec. In addition, the bandwidth of the printhead shift registers must be altered to match the transmission bandwidth.

3.3.4.3 Class C: Two SoPECs Write to a Single Printhead, One Indirectly

This solution class is the same as that of Class B, except that SoPEC A only transmits to printhead B via SoPEC B (i.e. instead of directly), as shown in FIG. 304 i.e. SoPEC A transmits directly to printhead A and indirectly to printhead B via SoPEC B, while SoPEC B transmits only to printhead B.

This class of architecture has the attraction that a printhead is driven by a single SoPEC, which minimizes the number of pins on a printhead. However it requires receiver connections on SoPEC B. It becomes particularly practical (costwise) if those receivers are currently unused (i.e. they would have been used for transmitting to the second printhead in a single SoPEC system). Of course this assumes that the pins are not being used to achieve the higher bandwidth.

Since there is only a single connection on the printhead, the serial load scenario described above under the heading of “Serial Load” would be the mechanism for transfer of data, with the only difference that the connections to the printhead are via SoPEC B.

Although the dot generation problem is resolved by this scenario (each SoPEC generates data for half the page width and therefore it is load balanced), the transmission speed for each connection must be sufficient to deliver to a type 7 printhead i.e. 1256 Mb/sec. In addition, the bandwidth of the printhead shift registers must be altered to match the transmission bandwidth.

If SoPEC B provides at least a line buffer for the data received from SoPEC A, then the transmission between SoPEC A and printhead A is decoupled, and although the bandwidth from SoPEC B to printhead B must be 1256 Mb/sec, the bandwidth between the two SoPECs can be lower i.e. enough to transmit 2 segments worth of data (359 Mb/sec).

3.3.4.4 4.4 Additional Comments on Architectures a, b, and c

Architecture A has the problem that no matter what the increase in speed, the solution is not load balanced, leaving architecture B or C the more preferred solution where load-balancing between SoPEC chips is desirable or necessary. The main advantage of an architecture A style solution is that it reduces the number of connections on the printhead.

All architectures require the increase in bandwidth to the printhead, and a change to the internal shift register structure of the printhead.

3.3.4.5 4.5 Other Architectures

Other architectures can be used where different printhead modules are used. For example, in one embodiment, the dot data is provided from a single printed controller (SoPEC) via multiple serial links to a printhead. Preferably, the links in this embodiment each carry dot data for more than one channel (color, etc) of the printhead. For example, one link can carry CMY dot data from the printer controller and the other channel can carry K, IR and fixative channels.

3.4 Methods of Solution

3.4.1 Increasing Dot Generation Rate

3.4.1.1 Clock Speed Increase

The clock frequency of SoPEC could be increased from 160 MHz, e.g. to 176 or 192 MHz. 192 MHz is convenient because it allows the simple generation of a 48 MHz clock as required for the USB cores.

Under architecture A, a 176 MHz clock speed would be sufficient to generate dot data for 5:5 and 6:4 printheads (see Table 2), but would not be sufficient to generate data for a 7:3 printhead.

With architectures B and C, any clock speed increase can be applied to increasing the inter-page gap, or the ability to cope with local stalling.

The cost of increasing the dot generation speed is:

- a slight increase in area within SoPEC
- an increase in time to achieve timing closure in SoPEC
- the possibility of the JPEG core being reduced to half speed if it can't be run at the target frequency (current speed rating on CU11 is 185 MHz)
- the possibility of the LEON core being reduced in speed if it can't be run at the target frequency
- an increase in power consumption thereby requiring a different (more expensive) package.

All of these factors are exacerbated by the proportion of speed increase. A 10% speed increase is within the JPEG core tolerance.

3.4.1.2 Load Sharing

Since a single SoPEC is incapable of generating the data required for a type 6 or type 7 printhead, yet is capable of generating the data for a type 5 printhead, it is possible to share the generation load by having each SoPEC generate the data for half the total printhead width.

Architectures B and C are specifically designed to load share dot generation.

The problem introduced by load sharing is that the data from both SoPEC A and SoPEC B must be transmitted to the larger printhead.

3.4.2 Increasing Transmission Bandwidth

3.4.2.1 Bandwidth Increase with No Change in Connections for SoPEC

At present there are 2 sets of connections from SoPEC to the printheads. Each set consists of 2 data plus a clock, running at twice the nominal SoPEC clock frequency i.e. 160 MHz gives 320 Mb/sec per channel.

If one of the clocks can be re-used as a data connection, it is possible to have up to 5 channels going to the printhead, as shown in Table 220.

TABLE 220

Increasing # of Channels

SoPEC clock speed
1
2
3
4
5

160 MHz
320 Mb/sec
640 Mb/sec
960 Mb/sec
1280 Mb/sec
1600 Mb/sec

176 MHz
352 Mb/sec
704 Mb/sec
1056 Mb/sec
1408 Mb/sec
1760 Mb/sec

192 MHz
384 Mb/sec
768 Mb/sec
1152 Mb/sec
1536 Mb/sec
1920 Mb/sec

For all clock speeds of SoPEC from 160 MHz to 192 MHz:

- Architecture A requires 4 channels on SoPEC and 4 on the printhead
- Architecture B serial requires 4 channels on SoPEC and 8 on the printhead
- Architecture B parallel requires 3 channels on SoPEC and 6 on the printhead.
- Architecture C requires 8 channels. Since SoPEC only has 5, this scenario would only be possible by allocating more pins to transmission.

3.4.2.2 Bandwidth Increase with Clock Forwarding Scheme

Assuming we keep our clock forwarding scheme, our I/O could run at 450 MHz, with resultant bandwidths as shown in Table 221.

TABLE 221

Increasing # of Channels at 450 MHz

Basic

xmit

rate
1
2
3
4
5

450
450 Mb/sec
900 Mb/sec
1350 Mb/sec
1800 Mb/sec
2250

MHz

Mb/sec

The following would then be true:

- Architecture A requires 3 channels on SoPEC and 3 on the printhead
- Architecture B serial requires 3 channels on SoPEC, and 6 on the printhead
- Architecture B parallel requires 2 channels on SoPEC, and 4 on the printhead.
- Architecture C requires 6 channels and 6 on the printhead. Since SoPEC only has 5 (4+ reuse of clock as data), this scenario would only be possible by allocating more pins to transmission.

3.4.2.3 Bandwidth Increase with Encoded Clock Scheme

Assuming our own flavour of SerDes, 600 Mb/sec might be possible. To accomplish 600 Mb/sec, SerDes would be required on the printhead (extra PLL plus approx 1 mm²of logic). The fastest possible SerDes on 0.35 micron CMOS is in the order of 0.75 Gbit/sec, which gives an effective data rate per channel of 600 Mb/sec.

The resultant bandwidths as shown in Table 222.

TABLE 222

Increasing # of Channels at 600 MHz

Basic

xmit

rate
1
2
3
4
5

600
600 Mb/sec
1200 Mb/sec
1800 Mb/sec
2400 Mb/sec
3200

MHz

Mb/sec

The following would then be true:

- Architecture A requires 2 channels and 2 on the printhead
- Architecture B serial could possibly get away with 2 channels on SoPEC (1200 vs 1256), and 4 on the printhead
- Architecture B parallel requires 2 channels on SoPEC, and 4 on the printhead.
- Architecture C requires 4 channels and 4 on the printhead.

Going faster with SerDes with IBM-specific macros does not give any benefits because:

- the printhead is limited due to 0.35 micron process
- there is a significant cost for the SerDes core plus a royalty per chip
- it would require a change of package to flip-chip style, more than doubling the cost of SoPEC
- there are physical constraints on the connection between SoPEC and the printhead cartridge, esp in the 3R printer application.

3.4.3 Bandwidth within the Printhead

3.4.3.1 Shift Registers that Shift in 1 Direction

Instead of having the odd and even nozzles connected by a single shift register, as is currently done and shown in FIG. 305, it is possible to place the even and odd nozzles on separate shift registers, as shown in FIG. 306.

By having the odd and even nozzles on different shift registers, the 6-bits of data is still received at the high rate (e.g. 320 MHz), but the shift register rate is halved, since each shift register is written to half as frequently. Thus it is possible to collect 12 bits (an odd and even dot), then shift them into the 12 shift registers (6 even, 6 odd) at 80 MHz (or whatever appropriate).

The effect is that data for even and odd dots has the same sense (i.e. always increasing or decreasing depending on the orientation of the printhead to the paper movement). However for the two printhead segments (and therefore the 2 SoPECs), the sense would be opposite (i.e. the data is always shifting towards the join point at the centre of the printhead).

As long as each SoPEC is responsible for writing to a single printhead segment (in a 5:5 printer this will be the case), then no change is required to SoPEC's DWU or PHI given the shift register arrangement in FIG. 306. The LLU needs to change to allow reading of odd and even data in an interleaved fashion (in the preferred form, all evens are read before all odds or vice versa). Additionally, the LLU would need to be changed be to permit the data rate required for data transmission.

However testing the integrity of the shift registers is of concern since there is no path back.

3.4.3.2 Interwoven Shift Registers

Instead of having odd and even dots on separate shift registers, it is possible to interweave the shift registers to keep the same sense of data transmission (e.g. from within the LLU), but keep the CMOS testing and lower speed shift-registers. Thus it is possible to collect 12 bits (representing two dots), then shift them into the 12 shift registers at 80 MHz (or as appropriate). The arrangement is shown FIG. 307.

The interweaving requires more wiring that the solution described in previous section, however it has the following advantages:

- The DWU is unchanged.
- The LLU stays the same in so far as the even dots are generated first, then the odd dots (or vice versa). The LLU still needs the bandwidth change for transmission.
- A shift register test path is enabled.
- The relative dot generation and bandwidth required is lower for A4 printing due to only half of the off-page dots needing to be sent.

3.5 60 ppm BI-LITHIC Summary

60 ppm printing using bi-lithic printheads is risky due to increased CPU requirements, increased numbers of pins, and the high data rates at which the transmission occurs. It also relies on stitching working correctly on the printheads to allow the creation of long printheads over several reticles.

Therefore an alternative to 60 ppm printing via bi-lithic printheads should be found.

4 Linking Printheads

4.1 Basic Concepts

The basic idea of the linking printhead is that we create a printhead from tiles each of which can be fully formed within the reticle. The printheads are linked together as shown in FIG. 308 to form the page-width printhead. For example, an A4/Letter page is assembled from 11 tiles.

The printhead is assembled by linking or butting up tiles next to each other. The physical process used for linking means that wide-format printheads are not readily fabricated (unlike the 21 mm tile). However printers up to around A3 portrait width (12 inches) are expected to be possible.

The nozzles within a single segment are grouped physically to reduce ink supply complexity and wiring complexity. They are also grouped logically to minimize power consumption and to enable a variety of printing speeds, thereby allowing speed/power consumption trade-offs to be made in different product configurations.

Each printhead segment contains a constant number of nozzles per color (currently 1280), divided into half (640) even dots and half (640) odd dots. If all of the nozzles for a single color were fired at simultaneously, the even and odd dots would be printed on different dot-rows of the page such that the spatial difference between any even/odd dot-pair is an exact number of dot lines. In addition, the distance between a dot from one color and the corresponding dot from the next color is also an exact number of dot lines.

The exact distance between even and odd nozzle rows, and between colors will vary between embodiments, so it is preferred that these relationships be programmable with respect to SoPEC.

4.1.1 Building a 30 ppm Printer with SoPEC

When 11 segments are joined together to create a 30 ppm printhead, a single SoPEC will connect to them as shown in FIG. 309 below.

Notice that each phDataOutn lvds pair goes to two adjacent printhead segments, and that each phClkn signal goes to 5 or 6 printhead segments. Each phRstn signal goes to alternate printhead segments.

4.1.2 Assigning Ids to the Printheads for Further Communication

SoPEC drives phRst0 and phRst1 to put all the segments into reset.

SoPEC then lets phRst1 come out of reset, which means that all the segment 1, 3, 5, 7, and 9 are now alive and are capable of receiving commands.

SoPEC can then communicate with segment 1 by sending commands down phDataOut0, and program the segment 1 to be id 1. It can communicate with segment 3 by sending commands down phDataOut1, and program segment 3 to be id 1. This process is repeated until all segments 1, 3, 5, 7, and 9 are assigned ids of 1. The id only needs to be unique per segment addressed by a given phDataOutn line.

SoPEC can then let phRst0 come out of reset, which means that segments 0, 2, 4, 6, 8, and 10 are all alive and are capable of receiving commands. The default id after reset is 0, so now each of the segments is capable of receiving commands along the same pDataOutn line.

4.1.3 Sending Commands to the Printhead

SoPEC needs to be able to send commands to individual printheads, and it does so by writing to particular registers at particular addresses.

The exact relationship between id and register address etc. is yet to be determined, but at the very least it will involve the CPU being capable of telling the PHI to send a command byte sequence down a particular phDataOutn line.

One possibility is that one register contains the id (possibly 2 bits of id). Further, a command may consist of:

- register write
- register address
- data

A 10-bit wide fifo can be used for commands in the PHI.

4.1.4 Building a 60 ppm Printer with 2 SoPECs

When 11 segments are joined together to create a 60 ppm printhead, the 2 SoPECs will connect to them as shown in FIG. 310 below.

In the 60 ppm case only phClk0 and phRst0 are used (phClk1 and phRst1 are not required). However note that lineSync is required instead. It is possible therefore to reuse phRst1 as a lineSync signal for multi-SoPEC synchronisation. It is not possible to reuse the pins from phClk1 as they are lvds. It should be possible to disable the lvds pads of phClk1 on both SoPECs and phDataOut5 on SoPEC B and therefore save a small amount of power.

4.2 Segment Options

This section details various classes of printhead that can be used. With the exception of the PEC1 style slope printhead, SoPEC is designed to be capable of working with each of these printhead types at full 60 ppm printing speed.

4.2.1 A-chip/A-chip

This printhead style consists of identical printhead tiles (type A) assembled in such a way that rows of nozzles between 2 adjacent chips have no vertical misalignment.

The most ideal format for this kind of printhead from a data delivery point of view is a rectangular join between two adjacent printheads, as shown in FIG. 311. However due to the requirement for dots to be overlapping, a rectangular join results in a it results in a vertical stripe of white down the join section since no nozzle can be in this join region. A white stripe is not acceptable, and therefore this join type is not acceptable.

FIG. 312 shows a sloping join similar to that described for the bi-lithic printhead chip, and FIG. 313 is a zoom in of a single color component, illustrating the way in which there is no visible join from a printing point of view (i.e. the problem seen in FIG. 311 has been solved).

4.2.2 A-chip/A-chip Growing Offset

The A-chip/A-chip setup described previously requires perfect vertical alignment. Due to a variety of factors (including ink sealing) it may not be possible to have perfect vertical alignment. To create more space between the nozzles, A-chips can be joined with a growing vertical offset, as shown in FIG. 314.

The growing offset comes from the vertical offset between two adjacent tiles. This offset increases with each join. For example, if the offset were 7 lines per join, then an 11 segment printhead would have a total of 10 joins, and 70 lines.

To supply print data to the printhead for a growing offset arrangement, the print data for the relevant lines must be present. A simplistic solution of simply holding the entire line of data for each additional line required leads to increased line store requirements. For example, an 11 segment×1280-dot printhead requires an additional 11×1280-dots×6-colors per line i.e. 10.3125 Kbytes per line. 70 lines requires 722 Kbytes of additional storage. Considering SoPEC contains only 2.5 MB total storage, an additional 722 Kbytes just for the offset component is not desirable. Smarter solutions require storage of smaller parts of the line, but the net effect is the same: increased storage requirements to cope with the growing vertical offset.

4.2.3 A-chip/A-chip Aligned Nozzles, Sloped Chip Placement

The problem of a growing offset is that a number of additional lines of storage need to be kept, and this number increases proportional to the number of joins i.e. the longer the printhead the more lines of storage are required.

However, we can place each chip on a mild slope to achieve a constant number of printlines regardless of the number of joins. The arrangement is similar to that used in PEC1, where the printheads are sloping. The difference here is that each printhead is only mildly sloping, for example so that the total number of lines gained over the length of the printhead is 7. The next printhead can then be placed offset from the first, but this offset would be from the same base. i.e. a printhead line of nozzles starts addressing line n, but moves to different lines such that by the end of the line of nozzles, the dots are 7 dotlines distant from the startline. This means that the 7-line offset required by a growing-offset printhead can be accommodated.

The arrangement is shown in FIG. 315.

If the offset were 7 rows, then a total of 72.2 KBytes are required to hold the extra rows, which is a considerable saving over the 722 Kbytes required by the “A-chip/A-chip growing offset” solution.

Note also, that in this example, the printhead segments are vertically aligned (as in PEC1).

It may be that the slope can only be a particular amount, and that growing offset compensates for additional differences—i.e. the segments could in theory be misaligned vertically. In general SoPEC must be able to cope with vertically misaligned printhead segments.

The question then arises as to how much slope must be compensated for at 60 ppm speed. Basically—as much as can comfortably handled without too much logic. However, amounts like 1 in 256 (i.e. 1 in 128 with respect to a half color), or 1 in 128 (i.e. 1 in 64 with respect to a half color) must be possible. Greater slopes and weirder slopes (e.g. 1 in 129 with respect to a half color) must be possible, but with a sacrifice of speed i.e. SoPEC must be capable even if it is a slower print.

Note also that the nozzles are aligned, but the chip is placed sloped. This means that when horizontal lines are attempted to be printed and if all nozzles were fired at once, the effect would be lots of sloped lines. However, if the nozzles are fired in the correct order relative to the paper movement, the result is a straight line for n dots, then another straight line for n dots 1 line up.

4.2.4 PEC1 Style Slope

This is the physical arrangement used by printhead segments addressed by PEC1. Note that SoPEC is not expected to work at 60 ppm speed with printheads connected in this way. However it is expected to work and is shown here for completeness, and if tests should prove that there is no working alternative to the 21 mm tile, then SoPEC will require significant reworking to accommodate this arrangement at 60 ppm.

In this scheme, the segments are joined together by being placed on an angle such that the segments fit under each other, as shown in FIG. 316. The exact angle will depend on the width of the Memjet segment and the amount of overlap desired, but the vertical height is expected to be in the order of 1 mm, which equates to 64 dot lines at 1600 dpi.

FIG. 317 shows more detail of a single segment in a multi-segment configuration, considering only a single row of nozzles for a single color plane. Each of the segments can be considered to produce dots for multiple sets of lines. The leftmost d nozzles (d depends on the angle that the segment is placed at) produce dots for line n, the next d nozzles produce dots for line n−1, and so on.

4.2.5 A-chip/A-chip with Inter-Line Slope Compensation

This is effectively the same as described above under the heading of “A-chip/A-chip aligned nozzles, sloped chip placement” except that the nozzles are physically arranged inside the printhead to compensate for the nozzle firing order given the desire to spread the power across the printhead. This means that one nozzle and its neighbor can be vertically separated on the printhead by 1 printline. i.e. the nozzles don't line up across the printhead. This means a jagged effect on printed “horizontal lines” is avoided, while achieving the goal of averaging the power.

The arrangement of printheads is the same as that shown in FIG. 315. However the actual nozzles are slightly differently arranged, as illustrated via magnification in FIG. 318.

4.2.6 A-chip/B-chip

Another possibility is to have two kinds of printing chips: an A-type and a B-type. The two types of chips have different shapes, but can be joined together to form long printheads. A parallelogram is formed when the A-type and B-type are joined.

The two types are joined together as shown in FIG. 319.

Note that this is not a growing offset. The segments of a multiple-segment printhead have alternating fixed vertical offset from a common point, as shown in FIG. 320.

If the vertical offset from a type-A to a type-B printhead were n lines, the entire printhead regardless of length would have a total of n lines additionally required in the line store. This is certainly a better proposition than a growing offset).

However there are many issues associated with an A-chip/B-chip printhead. Firstly, there are two different chips i.e. an A-chip, and a B-chip. This means 2 masks, 2 developments, verification, and different handling, sources etc. It also means that the shape of the joins are different for each printhead segment, and this can also imply different numbers of nozzles in each printhead. Generally this is not a good option.

4.2.7 A-B Chip with SoPEC Compensation

The general linking concept illustrated in the A-chip/B-chip arrangement can be incorporated into a single printhead chip that contains the A-B join within the single chip type.

This kind of joining mechanism is referred to as the A-B chip since it is a single chip with A and B characteristics. The two types are joined together as shown in FIG. 321.

This has the advantage of the single chip for manipulation purposes.

Note that as with the A-chip/B-chip arrangement, SoPEC must compensate for the vertical misalignment within the printhead. The amount of misalignment is the amount of additional line storage required.

Note that this kind of printhead can effectively be considered similar to the mildly sloping printhead described under the heading of “A-chip/A-chip aligned nozzles, sloped chip placement” except that the step at the discontinuity is likely to be many lines vertically (on the order of 7 or so) rather than the 1 line that a gentle slope would generate.

4.2.8 A-B Chip with Printhead Compensation

This kind of printhead is where we push the A-B chip discontinuity as far along the printhead segment as possible—right to the edge. This maximises the A part of the chip, and minimizes the B part of the chip. If the B part is small enough, then the compensation for vertical misalignment can be incorporated on the printhead, and therefore the printhead appears to SoPEC as if it was a single typeA chip. This only makes sense if the B part is minimized since printhead real-estate is more expensive at 0.35 microns rather than on SoPEC at 0.18 microns.

The arrangement is shown in FIG. 322.

Note that since the compensation is accomplished on the printhead, the direction of paper movement is fixed with respect to the printhead. This is because the printhead is keeping a history of the data to apply at a later time and is only required to keep the small amount of data from the B part of the printhead rather than the A part.

4.2.9 Various Combinations of the Above

Within reason, some of the various linking methods can be combined. For example, we may have a mild slope of 5 over the printhead, plus an on-chip compensation for a further 2 lines for a total of 7 lines between type A chips. The mild slope of 5 allows for a 1 in 128 per half color (a reasonable bandwidth increase), and the remaining 2 lines are compensated for in the printheads so do not impact bandwidth at all.

However we can assume that some combinations make less sense. For example, we do not expect to see an A-B chip with a mild slope.

4.2.10 Redundancy

SoPEC also caters for printheads and printhead modules that have redundant nozzle rows. The idea is that for one print line, we fire from nozzles in row x, in the next print line we fire from the nozzles in row y, and the next print line we fire from row x again etc. Thus, if there are any defective nozzles in a given row, the visual effect is halved since we only print every second line from that row of nozzles. This kind of redundancy requires SoPEC to generate data for different physical lines instead of consecutive lines, and also requires additional dot line storage to cater for the redundant rows of nozzles.

Redundancy can be present on a per-color basis. For example, K may have redundant nozzles, but C, M, and Y have no redundancy.

In the preferred form, we are concerned with redundant row pairs, i.e. rows 0+1 always print odd and even dots of the same colour, so redundancy would require say rows 0+1 to alternate with rows 2+3.

To enable alternating between two redundant rows (for example), two additional registers REDUNDANT_ROWS_0[7:0] and REDUNDANT_ROWS_1[7:0] are provided at addresses 8 and 9. These are protected registers, defaulting to 0x00. Each register contains the following fields:

- Bits [2:0]—RowPairA (000 means rows 0+1, 001 means rows 2+3 etc)
- Bits [5:3]—RowPairB (000 means rows 0+1, 001 means rows 2+3 etc)
- Bit [6]—toggleAB (0 means loadA/fireB, 1 means loadB/fireA)
- Bit [7]—valid (0 means ignore the register).

The toggle bit changes state on every FIRE command; SoPEC needs to clear this bit at the start of a page.

The operation for redundant row printing would use similar mechanism to those used when printing less than 5 colours:

- with toggleAB=0, the RowPairA rows would be loaded in the DATA_NEXT sequence, but the RowPairB rows would be skipped. The TDC FIFO would insert dummy data for the RowPairB rows. The RowPairA rows would not be fired, while the RowPairB rows would be fired.
- with toggleAB=1, the RowPairB rows would be loaded in the DATA_NEXT sequence, but the RowPairA rows would be skipped. The TDC FIFO would insert dummy data for the RowPairA rows. The RowPairB rows would not be fired, while the RowPairA rows would be fired.

In other embodiments, one or more redundant rows can also be used to implement per-nozzle replacement in the case of one or more dead nozzles. In this case, the nozzles in the redundant row only print dots for positions where a nozzle in the main row is defective. This may mean that only a relatively small numbers of nozzles in the redundant row ever print, but this setup has the advantage that two failed printhead modules (ie, printhead modules with one or more defective nozzles) can be used, perhaps mounted alongside each other on the one printhead, to provide gap-free printing. Of course, if this is to work correctly, it is important to select printhead modules that have different defective nozzles, so that the operative nozzles in each printhead module can compensate for the dead nozzle or nozzles in the other.

Whilst probably of questionable commercial usefullness, it is also possible to have more than one additional row for redundancy per color. It is also possible that only some rows have redundant equivalents. For example, black might have a redundant row due to its high visibility on white paper, whereas yellow might be a less likely candidate since a defective yellow nozzle is much less likely to produce a visually objectionable result. as defined in previous tables.

5 Single SoPEC System

SoPEC has hardware support for running many LSS buses (more than 50 if desired), including two LSS buses simultaneously at any given time.

Each SoPEC application must be at least compatible with a single LSS bus that is used during the boot procedure. This is because two specific pins are activated automatically as LSS bus 0 by SoPEC's boot ROM. Additionally, if application software is not found on LSS bus 0 as determined by those first two pins, another two pins (on the opposite side of the package) are then activated to be used as LSS bus 0.

When SoPEC powers up or is reset (for example due to a watchdog reset), the boot ROM attempts to load the application software. The boot ROM first resets all LSS devices attached to LSS bus 0, then attempts to load the software from a serial ROM attached to that bus. If none is found, the boot ROM tries a different pair of pins as LSS bus 0, and attempts to load the application software from a serial ROM attached to that bus. If the application software is still not found, the boot ROM attempts to load the software from SoPEC's USB device port.

Therefore, if the SoPEC application must be capable of operating standalone or must boot from an interface other than USB, the application PCB requires a serial flash to provide startup program code. This also provides a means of replacing faulty USB-boot code in the SoPEC ROM.

FIG. 354 shows the minimum set of LSS components in a single SoPEC system, regardless of application.

5.1 PCB

5.1.1 Serial Flash A, B and C

If the startup program code can be held within 7.5 KBytes, then the Serial Flash will be a 4320-based serial flash (Serial Flash B). Otherwise a more substantial flash memory (Serial Flash C) will be required. Alternatively, Serial Flash B may simply contain instructions on how to load data from some other kind of flash, e.g. connected to the MMI.

If Serial Flash C is accessed via a signalling means that is not known by the SoPEC boot ROM, then Serial Flash B will be required to load the flash access mechanism for booting from Serial Flash C.

On certain applications it may also be convenient to provide a connector on the PCB to allow the connection of a special Serial Flash A that contains special boot code for diagnostics and hardware debug purposes (or at least the program code to load the diagnostics program via some mechanism such as USB and thereby bypass Serial Flash B and/or C).

The setup as described implies that the SoPEC boot ROM looks for serial flash in a specific order, namely A, B, C. The search order of LSS addresses for flash devices is therefore fixed at:

TABLE 236

Search order for LSS devices by SoPEC boot ROM

Search
LSS
Expected device

order
address
at adr
Comments

1
0101_100
Serial Flash A
4320 based serial flash.

Requires changing LSS address

from default 4320 serial

flash address.

2
1111_010
Serial Flash B
4320 based serial flash.

Matches default address for

4320 serial flash.

3
1010_000
Serial Flash C
3rd party (commercial),

higher capacity serial

flash.

If no serial flash device is found at these addresses, the boot rom in SoPEC will attempt to boot from USB. Therefore the presence of any of these LSS devices is optional depending on the application. In the same way, if startup program code can be loaded from a serial flash on LSS bus 0, then the boot rom will not attempt to access the USB device port unless the startup program code (loaded from the serial flash) instructs SoPEC to do so.

5.2 3 Single SoPEC Printer

FIG. 355 shows the components in a single SoPEC printing system from an LSS perspective. The primary components are Cradle, Ink Cartridge, and Refill Cartridge, and each of these may contain several LSS devices.

5.2.1 Cradle

5.2.1.1 SoPEC

The SoPEC ASIC is the bus-master of two LSS buses: bus 0 and bus 1. By convention, bus 0 is used to connect to chips on the cradle or that plug directly into the cradle, and bus 1 is used to connect to ink-related components such as the ink cartridge and refill cartridge.

5.2.1.2 Serial Flash A, B and C

These are the serial flashes required for booting.

In lowest-cost printing applications the printer will boot from USB, and therefore none of these flash memories will be present. In more expensive systems, various combinations of flash memories will be required, specifically for standalone operation or for ethernet connectivity etc.

6 Two-SoPEC Printer

This discussion describes a two-SoPEC printer where both SoPECs are printing—i.e. ink information is required by both SoPECs.

6.1 Simplest Setup

FIG. 356 shows the simplest setup.

In this system, SoPEC1 is the ISC (Inter-SoPEC-Communication) Master and SoPEC2 is an ISC slave. SoPEC1 can boot from Serial Flash A, B, C, or from USB as in the single SoPEC case. SoPEC2 can boot via USB, thus getting its boot code from SoPEC1.

Although the Additional block is shown in FIG. 356, additional LSS devices are unlikely to contain GPIOs as the printer system has a total of 128 GPIO pins due to there being 2 SoPECs (with GPIO 64 pins each). However a temperature sensor is just as likely as in the single SoPEC system.

In this system, SoPEC1 is the only SoPEC that talks on the LSS. SoPEC2 does not directly request any LSS services from SoPEC1. This means that SoPEC2 must transmit its ink usage to SoPEC1, and must request printer parameters from SoPEC1. Since USB is not intrinsically secure, a means of providing secure communications between the two SoPECs is required.

In this option, the PrinterQA contains the SoPEC_id_keys for both SoPEC1 and SoPEC2. The PrinterQA also contains the following keys:

- printer_feature_access_key to enable SoPEC software to securely read printer features from PrinterQA or UpgradeQA. This key has no write permissions to the printer features.
- vc_access_key to enable SoPEC software to securely read virtual consumables such as ink volumes and details from InkCartridgeQA and RefillQA. This key has write permissions in the InkCartridge for preauthorisation of ink usage, and has decrement-only permissions on the consumables themselves, and read-only permissions on consumable attribute data.

The startup process involves transferring the printer_feature_access_key to all SoPECs so that it can be used as the InterSoPECKey i.e. a secure key for communication between SoPECs. The startup process is as follows:

- SoPEC1 requests the PrinterQA to transport the printer_feature_access_key from the PrinterQA to SoPEC1 via SoPEC1_id_key as the transport key.
- SoPEC2 requests the InterSoPECKey from SoPEC1. Since SoPEC1 does not know SoPEC2_id_key, SoPEC1 cannot directly send printer_feature_access_key to SoPEC2. However SoPEC1 requests the PrinterQA to transport the printer_feature_access_key from the PrinterQA to SoPEC2 via SoPEC2_id_key as the transport key. Within SoPEC2, the received key is only known as the InterSoPECKey.

SoPEC1 and SoPEC2 can now communicate securely via the printer_feature_access_key.

In addition, SoPEC1 requests the PrinterQA to transport the vc_access_key from the PrinterQA to SoPEC1 via SoPEC1_id_key as the transport key.

During printing, only SoPEC1 communicates with the external QA Chips:

- SoPEC1 performs all the LSS transactions with PrinterQA to obtain printer features.
- SoPEC1 securely transmits printer feature information to SoPEC2 (e.g. print speed, motor limitations etc.) using InterSoPECKey.
- SoPEC2 securely transmits ink usage information (from a print) to SoPEC1 using InterSoPECKey.
- SoPEC1 combines the ink usage from SoPEC1 and SoPEC2.
- SoPEC1 updates ink amounts in the InkCartridgeQA via the LSS (and vc_access_key)

If a single PrinterQA cannot hold the SoPEC_id_keys for both SoPEC1 and SoPEC2, a second PrinterQA can be added, connected directly to SoPEC1.

6.2 Recommended LSS Addresses

LSS Addressing would be as described above under the heading of “Recommended LSS addresses” with the exception that GPIO devices are unlikely due to there being 2 SoPECs with 64 GPIO pins each.

6.3 Alternative Setup

FIG. 357 shows an alternative setup. The primary difference in setup between FIG. 357 and FIG. 356 is that SoPEC1 is the boot master (and can thus boot from Serial Flash A, B, C, or USB), while SoPEC2 is the LSS master for QA-related activities.

By creating two bus 0s, the effective Hamming distance between devices on each bus is increased, and can be further increased by reassigning ids if desired.

The same principles of secure access to the PrinterQA and ink-related QA Chips as described above are required.

7 N-SoPEC Printer

At startup, SoPEC1 obtains the access keys from PrinterQA, as well providing a service to the various SoPECs for them to obtain the InterSoPECKey. SoPEC1 performs this service by calling functions on PrinterQA. All SoPECs can now communicate securely via the InterSoPECKey.

The number of PrinterQAs required in a cradle is determined by the total number of keys that can be stored in each.

7.1 Multiple Ink Devices

In certain non-soho applications, it may be desirable to have multiple physical QA devices for ink supply. For example, if ink reservoirs are installed separately, it would be useful to have a single InkQA device for each ink reservoir. In such a setup it may also be possible that multiple ink refills are occurring simultaneously.

It is the responsibility of the system designer to allocate LSS buses and LSS ids to the various devices for the purposes of the specific system. This section gives comment on the two extreme setups for the purposes of illustration.

At one extreme, each ink device has its own LSS bus. In a similar setup, each InkQA and its corresponding RefillQA could have its own LSS bus. The ids for RefillQA and InkQAs could be arbitrarily chosen to ensure the Hamming distance between them was maximised. The programming of ids can readily be accomplished at the fill/refill factory.

At the other extreme, all InkQAs and RefillQAs are on the same bus. In this case, the following ids are recommended to give a Hamming distance of 3, especially if serial flash is also required on the same bus:

TABLE 239

Recommended LSS addresses when multiple ink devices

share the same bus

Expected

LSS
device at

address
adr
Comments

0000_010
InkQA1
4320-based BaseQA. Matches default address

[3].

0011_001
InkQA2
Requires changing LSS address from default

BaseQA [3].

0011_110
InkQA3
Requires changing LSS address from default

BaseQA [3].

0101_011
InkQA4
Requires changing LSS address from default

BaseQA [3].

1100_001
InkQA5
Requires changing LSS address from default

BaseQA [3].

1100_110
InkQA6
Requires changing LSS address from default

BaseQA [3].

0000_101
RefillQA1
4320-based Base + XferQA. Matches default

address [3].

1010_011
RefillQA2
Requires changing LSS address from default

Base + XferQA [3].

1010_110
RefillQA3
Requires changing LSS address from default

Base + XferQA [3].

1001_000
RefillQA4
Requires changing LSS address from default

Base + XferQA [3].

1001_111
RefillQA5
Requires changing LSS address from default

Base + XferQA [3].

0110_000
RefillQA6
Requires changing LSS address from default

Base + XferQA [3].

8 Bandwidth and Latency Requirements

8.1 Bits-Per-Cycle Analysis

A single SoPEC is required to produce data from the DNC at a rate of 1 bit/cycle. Many of the upstream blocks read or write data at approximately this rate or a multiple of this rate. In analysing bandwidth requirements it is convenient to construct the timeslot programming as a nominally 256-cycle rotation, such that 1 bit/cycle is equivalent to one 256-bit read or write per rotation, and one slot is allocated for each bit/cycle required.

8.2 Compensation for Latency

A non-CPU DIU requester faces a minimum gap between the acknowledgment by the DIU of a current request and the issuing of the next. This is due to the state machine to clock the 4 cycles of data, some cycles of latency of registering requests and the DRAM access time. For read requesters this is around 10 cycles in total (less for the LLU) and for writes around 9 cycles.

Most requesters are at least double-buffered internally. For example a one-slot-per-rotation read requester that consumes 256 bits of internal data in 256 cycles takes from the time a request is issued (for the empty buffer) to the time the block is out of data (and therefore stalled) 256 cycles. It takes 10 cycles of latency for the block to be able to use the data, so the request must be serviced in 256-10 cycles if a stall is to be avoided. If the rotation time was fixed at 256 cycles the block will (after startup) be re-requesting around 10 cycles after acknowledgment of the previous request, so will always be requesting in time to use its allocated slot and therefore take up all the bandwidth. The LBD operating at 1:1 compression is an example of this, as are each of the separate SFU request channels. However the total time for a rotation is not fixed at 256 cycles. The time taken for a particular rotation depends on a number of factors, including

- the number of cpu pre-accesses that occur, and whether they are pre-accesses or main slots
- the number of 4-cycle accesses (consecutive non-CPU reads)
- the number of CDU(W) accesses
- the number of forced refreshes

These factors can vary during operation, for example if a burst of CPU or USB activity occurs. This means that rotations can vary from well under 256 cycles to close to 256 cycles. This means that the alignment of the requests with the allocated slots is not guaranteed, and a requester can miss its slot by a clock cycle. In this case the servicing time or latency is the length of the whole rotation. To ensure that such a block cannot stall, the rotation is shortened by 10 cycles. For multiple-slot requesters, the latency analysis would suggest that this 10 cycles be subtracted for each access. In practice for each of these blocks it can be argued that this is not necessary.

8.3 Computation of CPU Access Ratios

The nominal timeslot rotation is 256 cycles. A 64-slot rotation with all 4-cycle accesses and no CPU pre-accesses will take 256 cycles. For a shorter rotation, CPU pre-accesses can use the unused bandwidth, taking each slot from 3 or 4 cycles to 6 cycles. The worst-case analysis that follows assumes all non-pre-accessed slots are 4 cycles. A pre-accessed slot takes 6 cycles total whether on a read or a write slot, so the 4-cycle assumption makes a difference only for the non-pre-accessed slots.

Say that the allocation gives C slots to CPU(W) accesses, and N slots overall. Timeslot rotation is nominally 256 cycles.

Subtract L=10 cycles for latency allowance as described in the previous section. An increase in this value will speed up the rotation.

Subtract C*6 cycles as a CPU(W) access takes 6 cycles longer than other non-CPU write accesses.

Add R extra slots to N to allow for forced refresh accesses, which occur every 119 cycles, so up to 3 per rotation. These can be pre-accessed so are counted with the main slots in this calculation.

Each pre-accessed slot will take 2 cycles longer than the 4 cycles per slot allowed, making the total 6 cycles. Call the number of pre-accessed slots P.

Time allowed for rotation=256−L

Time taken by slots=C*6+(N+R)*4+P*2

256−L=C*6+(N+R)*4+P*2

P=(256−L−(C*6)−(N+R)*4)/2

Percentage of slots that can be pre-accessed=P/(N+R).

In the average case where not all non-pre-accessed slots are 4 cycles, a slightly greater allocation of CPU pre-accesses is possible, but the guarantees of the rotation time will not necessarily hold.

In choosing the numerator and denominator for the pre-access ratio it is advisable to choose as low a denominator as possible to reduce clumping in the CPU requests relative to the main rotation. For example, a ratio of 4/12 will allow up to 12 CPU pre-accesses to 20 slots in the worst-case, whereas a ratio of 1/3 would allow only 8. Excessive clumping may increase the maximum servicing time of a requester, leading to stalling if the timing is tight.

8.4 Servicing of High Bandwidth Requesters

Most of the high bandwidth requesters in SoPEC have sufficient buffering to average out significant stalls, as long as the bandwidth is supplied over a the rotation. The DWU, LLU and CFU need many slots allocated but these do not need to be evenly distributed. For the DWU the slots must have a gap of at least 2 slots, and the CFU a gap of at least 3 slots to allow for the data to be transferred and the block to re-request. The LLU's state machine can re-request as soon as the first request is acknowledged so can be allocated every second slot.

The CDU read and write require 4 slots each in the contone scale factor (SF)=4 case, where 1.5 buffering is used to the CFU, such that the CDU must work in half the time the CFU does. Latency effects could mean that the CDU was not guaranteed unstalled service, however the fast processing rate of the CDU JPEG engine (8 bits/cycle) means that this is not a problem. The JPEG engine may process slower than this for very low rates of compression, so extra slots for the CDU or more allowance for latency may need to be made. An even distribution of CDU(R) and CDU(W) slots will minimise stalling.

8.5 Servicing of Very Low Bandwidth Requesters Via Round-Robin

Read requesters with a very low bandwidth requirement, for example the TFS and the HCU, can be allocated bandwidth indirectly. Many of the multiple-slot requesters will not use all of their allocation all the time as they are allocated slots for their peak requirements not average requirements. As described above, all unused read slots are reallocated through a two-level round robin scheme. Low-bandwidth requesters without their own slot such as the HCU and TFS should be put in the top level (Level 1). The PCU should also be in the top level as it requests infrequently but may require several accesses in a short period of time. The Refresh requester is always requesting so will lock out any requesters in the lower level if it is in Level 1. The DNC allocation of 3 slots may be replaced with a smaller allocation and a Level 1 round-robin entry if the clumping of DNC table entries is expected to be low.

8.6 Timeslot Register Programming Using Spreadsheet

A spreadsheet can be constructed to make the process of slot allocation easier. The main tasks of the spreadsheet are to count the allocated slots and to assist with allocating the slots such that the multi-slot requesters are well distributed.

In the same directory as this document the spreadsheet ‘programming_macro.xls’ can be found. This requires the Analysis Toolpak installed which is an option on the standard installation of Excel. The Analysis Toolpak has the HEX2DEC and DEC2HEX functions that are used to create hex register writes ready to cut and paste into a file.

To use, in column C, rows 20-38 enter the number of slots to allocate to each requester. In column J, from row 20 onwards, enter the name of a requester in each slot. These are tallied up in column E. Column K will display ‘WRITE’ if consecutive write slots are programmed Columns V and W create a list register writes in hex. The area near slot A90 computes a worst-case CPU access ratio, as described in an earlier section of this document.

The remainder of the spreadsheet assists in creating evenly spread requesters by computing the deviation of the slot allocated from an even distribution of that requester. Column L estimates the usual cycle time of the rotation, taking into account the expected write slots and the CDU writes. The columns to the right of this compute approximately the evenness of the slot distribution for multi-slot requesters, showing a + value in cycles for a slot that is late and a − value in cycles for a slot that is early. Note that requesters such as the LLU and DWU do not require a perfect allocation and the slot spread information is provided as a guide not a rule. The early/late indications will update if the intervening slots change, for example if the location of the CDU(W) slots changes.

9 Printhead Misplacement Types

9.1 Printhead Construction

A linking printhead is constructed from linking printhead ICs, placed on a substrate containing ink supply holes. An A4 pagewidth printer used 11 linking printhead ICs. Each printhead is placed on the substrate with reference to positioning fidicuals on the substrate. FIG. 359 shows the arrangement of the printhead ICs (also known as segments) on a printhead. The join between two ICs is shown in detail. The left-most nozzles on each row are dropped by 10 line-pitches, to allow continuous printing across the join. FIG. 359 also introduces some naming and co-ordinate conventions used throughout this document. FIG. 359 shows the anticipated first generation linking printhead nozzle arrangements, with 10 nozzle rows supporting five colours. The SoPEC compensation mechanisms are general enough to cover other nozzle arrangements.

9.2 Misplacement Types

Printheads ICs may be misplaced relative to their ideal position. This misplacement may include any combination of:

- x offset
- y offset
- yaw (rotation around z)
- pitch (rotation around y)
- roll (rotation around z)

In some cases, the best visual results are achieved by considering relative misplacement between adjacent ICs, rather than absolute misplacement from the substrate. There are some practical limits to misplacement, in that a gross misplacement will stop the ink from flowing through the substrate to the ink channels on the chip.

Correcting for misplacement obviously requires the misplacement to be measured. In general this may be achieved directly by inspection of the printhead after assembly, or indirectly by scanning or examining a printed test pattern.

9.3 Misplacement Compensation

9.3.1 X Offset

SoPEC can compensate for misplacement of linking chips in the X-direction, but only snapped to the nearest dot. That is, a misplacement error of less than 0.5 dot-pitches or 7.9375 microns is not compensated for, a misplacement more that 0.5 dot-pitches but less than 1.5 dot-pitches is treated as a misplacement of 1 dot-pitch, etc.

Uncompensated X misplacement can result in three effects:

- printed dots shifted from their correct position for the entire misplaced segment
- missing dots in the overlap region between segments.
- duplicated dots in the overlap region between segments.

SoPEC can correct for each of these three effects.

9.3.1.1 Correction for Overall Position in X

In preparing line data to be printed, SoPEC buffers in memory the dot data for a number of lines of the image to be printed. Compensation for misplacement generally involves changing the pattern in which this dot data is passed to the printhead ICs.

SoPEC uses separate buffers for the even and odd dots of each colour on each line, since they are printed by different printhead rows. So SoPEC's view of a line at this stage is as (up to) 12 rows of dots, rather than (up to) 6 colours. Nominally, the even dots for a line are printed by the lower of the two rows for that colour on the printhead, and the odd dots are printed by the upper row (see FIG. 359). For the current linking printhead IC, there are 640 nozzles in row. Each row buffer for the full printhead would contain 640×11 dots per line to be printed, plus some padding if required.

In preparing the image, SoPEC can be programmed in the DWU module to precompensate for the fact that each row on the printhead IC is shifted left with respect to the row above. In this way the leftmost dot printed by each row for a colour is the same offset from the start of a row buffer. In fact the programming can support arbitrary shapes for the printhead IC.

SoPEC has independent registers in the LLU module for each segment that determine which dot of the prepared image is sent to the left-most nozzle of that segment. Up to 12 segments are supported. With no misplacement, SoPEC could be programmed to pass dots 0 to 639 in a row to segment 0, dots 640 to 1279 in a row to segment 1, etc.

If segment 1 was misplaced by 2 dot-pitches to the right, SoPEC could be adjusted to pass to dots 641 to 1280 of each row to segment 1 (remembering that each row of data consists entirely of either odd dots or even dots from a line, and that dot 1 on a row is printed two dot positions away from dot 0). This means the dots are printed in the correct position overall. This adjustment is based on the absolute placement of each printhead IC. Dot 640 is not printed at all, since there is no nozzle in that position on the printhead.

A misplacement of an odd number of dot-pitches is more problematic, because it means that the odd dots from the line now need to be printed by the lower row of a colour pair, and the even dots by the upper row of a colour pair on the printhead segment. Further, swapping the odd and even buffers interferes with the precompensation. This results in the position of the first dot to be sent to a segment being different for odd and even rows of the segment. SoPEC addresses this by having independent registers in the LLU to specify the first dot for the odd and even rows of each segment, i.e. 2×12 registers. A further register bit determines whether dot data for odd and even rows should be swapped on a segment by segment basis.

9.3.1.2 Correcting for Duplicate and Missing Dots

FIG. 360 shows the detailed alignment of dots at the join between two printhead ICs, for various cases of misplacement, for a single colour.

The effects at the join depend on the relative misplacement of the two segments. In the ideal case with no misplacement, the last 3 nozzles of upper row of the segment N interleave with the first three nozzles of the lower row of segment N+1, giving a single nozzle (and so a single printed dot) at each dot-pitch.

When segment N+1 is misplaced to the right relative to segment N (a positive relative offset in X), there are some dot positions without a nozzle, i.e. missing dots. For positive offsets of an odd number of dot-pitches, there may also be some dot positions with two nozzles, i.e. duplicated dots. Negative relative offsets in X of segment N+1 with respect to segment N are less likely, since they would usually result in a collision of the printhead ICs, however they are possible in combination with an offset in Y. A negative offset will always cause duplicated dots, and will cause missing dots in some cases. Note that the placement and tolerances can be deliberately skewed to the right in the manufacturing step to avoid negative offsets.

Where two nozzles occupy the same dot position, the corrections described above will result in SoPEC reading the same dot data from the row buffer for both nozzles. To avoid printing this data twice SoPEC has two registers per segment in the LLU that specify a number (up to 3) of dots to suppress at the start of each row, one register applying to even dot rows, one to odd dot rows.

SoPEC compensates for missing dots by add the missing nozzle position to its dead nozzle map. This tells the dead nozzle compensation logic in the DNC module to distribute the data from that position into the surrounding nozzles, before preparing the row buffers to be printed.

9.3.2 Y Offset

SoPEC can compensate for misplacement of printhead ICs in the Y-direction, but only snapped to the nearest 0.1 of a line. Assuming a line-pitch of 15.875 microns, if an IC is misplaced in Y by 0 microns, SoPEC can print perfectly in Y. If an IC is misplaced by 1.5875 microns in Y, then we can print perfectly. If an IC is misplaced in Y by 3.175 microns, we can print perfectly. But if an IC is misplaced by 3 microns, this is recorded as a misplacement of 3.175 microns (snapping to the nearest 0.1 of a line), and resulting in a Y error of 0.175 microns (most likely an imperceptible error).

Uncompensated Y misplacement results in all the dots for the misplaced segment being printed in the wrong position on the page.

SoPEC's compensation for Y misplacement uses two mechanism, one to address whole line-pitch misplacement, and another to address fractional line-pitch misplacement. These mechanisms can be applied together, to compensate for arbitrary misplacements to the nearest 0.1 of a line.

9.3.2.1 Compensating for Whole Line-Pitch Misplacement

The section above under the heading of “X Offset” described the buffers used to hold dot data to be printed for each row. These buffers contain dot data for multiple lines of the image to be printed. Due to the physical separation of nozzle rows on a printhead IC, at any time different rows are printing data from different lines of the image.

For a printhead on which all ICs are ideally placed, row 0 of each segment is printing data from the line N of the image, row 1 of each segment is printing data from row N-M of the image etc. where N is the separation of rows 0 and 1 on the printhead. Separate SoPEC registers in the LLU for each row specify the designed row separations on the printhead, so that SoPEC keeps track of the “current” image line being printed by each row.

If one segment is misplaced by one whole line-pitch, SoPEC can compensate by adjusting the line of the image being sent to each row of that segment. This is achieved by adding an extra offset on the row buffer address used for that segment, for each row buffer. This offset causes SoPEC to provide the dot data to each row of that segment from one line further ahead in the image than the dot data provided to the same row on the other segments. For example, when the correctly placed segments are printing line N of an image with row 0, line N−M of the image with row 1, etc, then the misplaced segment is printing line N+1 of the image with row 0, line N−M+1 of the image with row 1, etc.

SoPEC has one register per segment to specify this whole line-pitch offset. The offset can be multiple line-pitches, compensating for multiple lines of misplacement. Note that the offset can only be in the forward direction, corresponding to a negative Y offset. This means the initial setup of SoPEC must be based on the highest (most positive) Y-axis segment placement, and the offsets for other segments calculated from this baseline. Compensating for Y displacement requires extra lines of dot data buffering in SoPEC, equal to the maximum relative Y offset (in line-pitches) between any two segments on the printhead. For each misplaced segment, each line of misplacement requires approximately 640×10 or 6400 extra bits of memory.

9.3.2.2 Compensation for Fractional Line Pitch Misplacement

Compensation for fractional line-pitch displacement of a segment is achieved by a combination of SoPEC and printhead IC fire logic.

The nozzle rows in the printhead are positioned by design with vertical spacings in line-pitches that have a integer and fractional component. The fractional components are expressed relative to row zero, and are always some multiple of 0.1 of a line-pitch. The rows are fired sequentially in a given order, and the fractional component of the row spacing matches the distance the paper will move between one row firing and the next. FIG. 361 shows the row position and firing order on the current implementation of the printhead IC. Looking at the first two rows, the paper moves by 0.5 of a line-pitch between the row 0 (fired first) and row 1 (fired sixth). is supplied with dot data from a line 3 lines before the data supplied to row 0. This data ends up on the paper exactly 3 line-pitches apart, as required.

If one printhead IC is vertically misplaced by a non-integer number of line-pitches, row 0 of that segment no longer aligns to row 0 of other segments. However, to the nearest 0.1 of a line, there is one row on the misplaced segment that is an integer number of line-pitches away from row 0 of the ideally placed segments. If this row is fired at the same time as row 0 of the other segments, and it is supplied with dot data from the correct line, then its dots will line up with the dots from row 0 of the other segments, to within a 0.1 of a line-pitch. Subsequent rows on the misplaced printhead can then be fired in their usual order, wrapping back to row 0 after row 9. This firing order results in each row firing at the same time as the rows on the other printheads closest to an integer number of line-pitches away.

FIG. 362 shows an example, in which the misplaced segment is offset by 0.3 of a line-pitch. In this case, row 5 of the misplaced segment is exactly 24.0 line-pitches from row 0 of the ideal segment. Therefore row 5 is fired first on the misplaced segment, followed by row 7, 9, 0 etc. as shown. Each row is fired at the same time as the a row on the ideal segment that is an integer number of lines away. This selection of the start row of the firing sequence is controlled by a register in each printhead IC.

SoPEC's role in the compensation for fractional line-pitch misplacement is to supply the correct dot data for each row. Looking at FIG. 362, we can see that to print correct, row 5 on the misplaced printhead needs dot data from a line 24 lines earlier in the image than the data supplied to row 0. On the ideal printhead, row 5 needs dot data from a line 23 lines earlier in the image than the data supplied to row 0. In general, when a non-default start row is used for a segment, some rows for that segment need their data to be offset by one line, relative to the data they would receive for a default start row. SoPEC has a register in LLU for each row of each segment, that specifies whether to apply a one line offset when fetching data for that row of that segment.

9.3.3 Roll (Rotation Around X)

This kind of erroneous rotational displacement means that all the nozzles will end up pointing further up the page in Y or further down the page in Y. The effect is the same as a Y misplacement, except there is a different Y effect for each media thickness (since the amount of misplacement depends on the distance the ink has to travel).

In some cases, it may be that the media thickness makes no effective visual difference to the outcome, and this form of misplacement can simply be incorporated into the Y misplacement compensation. If the media thickness does make a difference which can be characterised, then the Y misplacement programming can be adjusted for each print, based on the media thickness.

It will be appreciated that correction for roll is particularly of interest where more than one printhead module is used to form a printhead, since it is the discontinuities between strips printed by adjacent modules that are most objectionable in this context.

9.3.4 Pitch (Rotation Around Y)

In this rotation, one end of the IC is further into the substrate than the other end. This means that the printing on the page will be dots further apart at the end that is further away from the media (i.e. less optical density), and dots will be closer together at the end that is closest to the media (more optical density) with a linear fade of the effect from one extreme to the other. Whether this produces any kind of visual artifact is unknown, but it is not compensated for in SoPEC.

9.3.5 Yaw (Rotation Around Z)

This kind of erroneous rotational displacement means that the nozzles at one end of a IC will print further down the page in Y than the other end of the IC. There may also be a slight increase in optical density depending on the rotation amount.

SoPEC can compensate for this by providing first order continuity, although not second order continuity in the preferred embodiment. First order continuity (in which the Y position of adjacent line ends is matched) is achieved using the Y offset compensation mechanism, but considering relative rather than absolute misplacement. Second order continuity (in which the slope of the lines in adjacent print modules is at least partially equalised) can be effected by applying a Y offset compensation on a per pixel basis. Whilst one skilled in the art will have little difficulty deriving the timing difference that enables such compensation, SoPEC does not compensate for it and so it is not described here in detail.

FIG. 363 shows an example where printhead IC number 4 is be placed with yaw, is shown in FIG. 363, while all other ICs on the printhead are perfectly placed. The effect of yaw is that the left end of segment 4 of the printhead has an apparent Y offset of −1 line-pitch relative to segment 3, while the right end of segment 4 has an apparent Y offset of 1 line-pitch relative to segment 5.

To provide first-order continuity in this example, the registers on SoPEC would be programmed such that segments 0 to 3 have a Y offset of 0, segment 4 has a Y offset of −1, and segments 5 and above have Y offset of −2. Note that the Y offsets accumulate in this example—even though segment 5 is perfect aligned to segment 3, they have different Y offsets programmed.

It will be appreciated that some compensation is better than none, and it is not necessary in all cases to perfectly correct for roll and/or yaw. Partial compensation may be adequate depending upon the particular application. As with roll, yaw correction is particularly applicable to multi-module printheads, but can also be applied in single module printheads.

10 Printhead

10.1 Number of Colors

The printhead will be designed for 5 colors. At present the intended use is:

- cyan
- magenta
- yellow
- black
- infra-red

However the design methodology must be capable of targeting a number other than 5 should the actual number of colors change. If it does change, it would be to 6 (with fixative being added) or to 4 (with infra-red being dropped).

The printhead chip does not assume any particular ordering of the 5 colour channels.

10.2 Number of Nozzles

The printhead will contain 1280 nozzles of each color—640 nozzles on one row firing even dots, and 640 nozzles on another row firing odd dots. This means 11 linking printheads are required to assemble an A4/Letter printhead.

However the design methodology must be capable of targeting a number other than 1280 should the actual number of nozzles per color change. Any different length may need to be a multiple of 32 or 64 to allow for ink channel routing.

10.3 Nozzle Spacing

The printhead will target true 1600 dpi printing. This means ink drops must land on the page separated by a distance of 15.875 microns.

The 15.875 micron inter-dot distance coupled with mems requirements mean that the horizontal distance between two adjacent nozzles on a single row (e.g. firing even dots) will be 31.75 microns.

All 640 dots in an odd or even colour row are exactly aligned vertically. Rows are fired sequentially, so a complete row is fired in small fraction (nominally one tenth) of a line time, with individual nozzle firing distributed within this row time. As a result dots can end up on the paper with a vertical misplacement of up to one tenth of the dot pitch. This is considered acceptable.

The vertical distance between rows is adjusted based on the row firing order. Firing can start with any row, and then follows a fixed rotation. FIG. 364 shows the default row firing order from 1 to 10, starting at the top even row. Rows are separated by an exact number of dot lines, plus a fraction of a dot line corresponding to the distance the paper will move between row firing times. This allows exact dot-on-dot printing for each colour. The starting row can be varied to correct for vertical misalignment between chips, to the nearest 0.1 pixels. SoPEC appropriate delays each row's data to allow for the spacing and firing order

An additional constraint is that the odd and even rows for given colour must be placed close enough together to allow them to share an ink channel. This results in the vertical spacing shown in FIG. 364, where L represents one dot pitch.

10.4 Linking the Chips

Multiple identical printhead chips must be capable of being linked together to form an effectively horizontal assembled printhead.

Although there are several possible internal arrangements, construction and assembly tolerance issues have made an internal arrangement of a dropped triangle (ie a set of rows) of nozzles within a series of rows of nozzles, as shown in FIG. 365. These printheads can be linked together as shown in FIG. 366.

Compensation for the triangle is preferably performed in the printhead, but if the storage requirements are too large, the triangle compensation can occur in SoPEC. However, if the compensation is performed in SoPEC, it is required in the present embodiment that there be an even number of nozzles on each side of the triangle.

It will be appreciated that the triangle disposed adjacent one end of the chip provides the minimum on-printhead storage requirements. However, where storage requirements are less critical, other shapes can be used. For example, the dropped rows can take the form of a trapezoid.

The join between adjacent heads has a 45° angle to the upper and lower chip edges. The joining edge will not be straight, but will have a sawtooth or similar profile. The nominal spacing between tiles is 10 microns (measured perpendicular to the edge). SoPEC can be used to compensate for both horizontal and vertical misalignments of the print heads, at some cost to memory and/or print quality.

Note also that paper movement is fixed for this particular design.

10.5 Print Rate

A print rate of 60 A4/Letter pages per minute is possible. The printhead will assume the following:

- page length=297 mm (A4 is longest page length)
- an inter-page gap of 60 mm or less (current best estimate is more like 15+/−5 mm

This implies a line rate of 22,500 lines per second. Note that if the page gap is not to be considered in page rate calculations, then a 20 KHz line rate is sufficient.

Assuming the page gap is required, the printhead must be capable of receiving the data for an entire line during the line time. i.e. 5 colors 1280 dots 22,500 lines=144 MHz or better (173 MHz for 6 colours).

10.6 Pins

An overall requirement is to minimize the number of pins. Pin count is driven primarily by the number of supply and ground pins for Vpos. There is a lower limit for this number based on average current and electromigration rules. There is also a significant routing area impact from using fewer supply pads.

In summary a 200 nJ ejection energy implies roughly 12.5 W average consumption for 100% ink coverage, or 2.5 W per chip from a 5V supply. This would mandate a minimum of 20 Vpos/Gnd pairs. However increasing this to around 40 pairs might save approximately 100 microns from the chip height, due to easier routing.

At this stage the print head is assuming 40 Vpos/Gnd pairs, plus 11 Vdd (3.3V) pins, plus 6 signal pins, for a total of 97 pins per chip.

10.7 Ink Supply Hole

At the CMOS level, the ink supply hole for each nozzle is defined by a metal seal ring in the shape of rectangle (with square corners), measuring 11 microns horizontally by 26 microns vertically. The centre of each ink supply hole is directly under the centre of the MEMs nozzle, i.e. the ink supply hole horizontal and vertical spacing is same as corresponding nozzle spacing.

10.8 Physical Overview

The SRM043 is a CMOS and MEMS integrated chip. The MEMS structures/nozzles can eject ink which has passed through the substrate of the CMOS via small etched holes.

The SRM043 has nozzles arranged to create a accurately placed 1600 dots per inch printout. The SRM043 has 5 colours, 1280 nozzles per colour.

The SRM043 is designed to link to a similar SRM043 with perfect alignment so the printed image has no artifacts across the join between the two chips.

SRM043 contains 10 rows of nozzles, arranged as upper and lower row pairs of 5 different inks. The paired rows share a common ink channel at the back of the die. The nozzles in one of the paired rows are horizontally spaced 2 dot pitches apart, and are offset relative to each other.

10.8.1 Colour Arrangement 1600 dpi has a dot pitch of DP=15.875 p.m. The MEMS print nozzle unit cell is 2DP wide by 5 DP high (31.75 μm×79.375 μm). To achieve 1600 dpi per colour, 2 horizontal rows of (1280/2) nozzles are placed with a horizontal offset of 5 DP (2.5 cells). Vertical offset is 3.5 DP between the two rows of the same colour and 10.1DP between rows of different colour. This slope continues between colours and results in a print area which is a trapezoid as shown in FIG. 367.

Within a row, the nozzles are perfectly aligned vertically.

10.8.2 Linking Nozzle Arrangement

For ink sealing reasons a large area of silicon beyond the end nozzles in each row is required on the base of the die, near where the chip links to the next chip. To do this the first 4*Row#+4−2*(Row# mod 2) nozzles from each row are vertical shifted down DP. Data for the nozzles in the triangle must be delayed by 10 line times to match the triangle vertical offset. The appropriate number of data bits at the start of each row are put into a FIFO. Data from the FIFO's output is used instead. The rest of the data for the row bypasses the FIFO.

10.9 Fire Cycle

10.9.1 Nozzle Firing Order

A fire cycle sequences through all of the nozzles on the chip, firing all of those with a 1 in their dot-latch. The sequence is one row at a time, each row taking 10% of the total fire cycle. Within a row, a programmable value called the column Span is used to control the firing. Each <span>'th nozzle in the row is fired simultaneously, then their immediate left neighbours, repeating <span> times until all nozzles in that row have fired. This is then repeated for each subsequent row, according the row firing order described in the next section. Hence the maximum number of nozzles firing at any one time is 640 divided by <span>.

10.9.2 Row Firing Order and Dot Placement, Default Case

In the default case, row 0 of the chip is fired first, according to the span pattern. These nozzles will all fired in the first 10% of the line time. Next all nozzles in row 2 will fire in the same pattern, similarly then rows 4, 6 then 8. Immediately following, half way through the line time, row 1 will start firing, followed by rows 3, 5, 7 then 9.

FIG. 372 shows this for the case of Span=2.

The 1/10 line time together with the 10.1DP vertical colour pitch appear on paper as a 10 DP line separation. The odd and even same-colour rows physically spaced 3.5 DP apart vertically fired half a line time apart results on paper as a 3 DP separation.

10.9.3 Dot Placement, General Case

A modification of the firing order shown in FIG. 372 can be used to assist in the event of vertical misalignment of the printhead when physically mounted into a cartridge. This is termed micro positioning in this document.

FIG. 373 shows in general how the fire pattern is modified to compensate for mounting misalignment of one printhead with respect to its linking partner. The base construction of the printhead separates the row pairs by slightly more than an integer times the dot Pitch to allow for distributing the fire pattern over the line period. This architecture can be exploited to allow micro positioning.

This scheme can compensate for printhead placement errors to 1/10 dot pitch accuracy, for arbitrary printhead vertical misalignment.

The VPOSITION register holds the row number to fire first. The printhead performs sub-line placement, the correct line must be loaded by SoPEC.

10.10 Fire Timing Parameters

10.10.1 Profiles and Fireperiod

The width of the pulse that turns a heater on to eject an ink drop is called the profile. The profile is a function of the MEMs characteristics and the ink characteristics. Different profiles might be used for different colours.

Optimal dot placement requires each line to take 10% of the line time. to fire. So, while a row for a colour with a shorter profile could in theory be fired faster than a colour with a longer profile, this is not desirable for dot placement.

To address this, the fire command includes a parameter called the fireperiod. This is the time allocated to fire a single nozzle, irrespective of its profile. For best dot placement, the fireperiod should be chosen to be greater than the longest profile. If a profile is programmed to be longer than a fireperiod, then that nozzle pulse will be extended to match the profile. This extends the line time, it does not affect subsequent profiles. This will degrade dot placement accuracy on paper.

The fireperiod and profiles are measured in wclks. A wclk is a programmable number of 288 Mhz clock periods. The value written to fireperiod and profile registers should be one less than the desired delay in wclks. These registers are all 8 bits wide, so periods from 1 to 256 wclks can be achieved. The Wclk prescaler should be programmed such that the longest profile is between 128 and 255 wclks long. This gives best line time resolution.

10.10.2 Choosing Values for Span and Fireperiod

The ideal value for column span and fireperiod can be chosen based on the maximum profile and the linetime. The linetime is fixed by the desired printing speed, while the maximum profile depends on ink and MEMs characteristics as described previously.

To ensure than all nozzles are fired within a line time, the following relationship must be obeyed:

# rows*columnspan*fireperiod<linetime

To reduce the peak Vpos current, the column span should be programmed to be the largest value that obeys the above relationship. This means making fireperiod as small as possible, consistent with the requirement that fireperiod be longer than the maximum profile, for optimal dot placement.

As an example, with a 1 uS maximum profile width, 10 rows, and 44 us desired row time a span of 4 yields 4*10*1=40 uS minimum time. A span of 5 would require 50 uS which is too long.

Having chosen the column span, the fireperiod should be adjusted upward from its minimum so that nozzle firing occupies all of the available linetime. In the above example, fireperiod would be set to 44 us/(4*10)=1.1 uS. This will produce a 10% gap between individual profiles, but ensures that dots are accurately placed on the page. Using a fireperiod longer or shorter than the scaled line time will result in inaccurately placed ink dots.

10.10.3 Adjusting Fireperiod

The fireperiod to be used is updated as a parameter to every FIRE command. This is to allow for variation in the linetime, due to changes in paper speed. This is important because a correctly calculated fireperiod is essential for optimal dot placement.

10.10.4 Error Conditions

If a FIRE command is received before a fire cycle is complete, the error bit NO_EARLY_ERR is set and the next fire cycle is started immediately. The final column(s) of the previous cycle will not have been fully fired. This can only occur if the new FIRE command is given early than expected, based on the previous fireperiod.

10.10.5 Profile Pulse Limitation

The profile pulse can only be a rectangular pulse. The only controls available are pulse width and how often the nozzle is fired.

10.11 Nozzle Unclogging

A nozzle can be fired rapidly if required by making the column span 1. Control of the data in the whole array is essential to select which nozzle[s] are fired.

Using this technique, a nozzle can be fired for 1/10 of the line period. Data in the row shift registers must be used to control which nozzles are unclogged, and to manage chip peak currents.

It is possible to fire individual nozzles even more rapidly by reducing the profile periods on colours not being cleared, and using a short fireperiod.

11 Implementation Technologies

11.1 Process

The Memjet printhead chip is fabricated with TSMC using a 0.35 micron 3V/5V process. The chip is singulated by etching as an extension of the processing for the ink channels and connecting the nozzle front etch to the back etch. MEMS structures are not covered in this document.

12 Temperature Sensing

12.1 Basic Printhead Structure and Operation

A Memjet printhead chip consists of an array of MEMs ejection devices (typically heaters), each with associated drive logic implemented in CMOS. Together the ejection device and the drive logic comprise a “unit cell”. Global control logic accepts data for a line to be printed in the form of a stream of fire bits, one bit per device. The fire bits are shifted into the array via a shift register. When each unit cell has the correct fire data bit, the control logic initiates a firing sequence, in which each ejection device is fired if its corresponding fire bit is a 1, and not fired if its corresponding fire bit is a 0.

12.2 Temperature Effects

Ejection devices can suffer damage over time, due to

- latent manufacturing defects
- temporary environment conditions (such as depriming or temporary blockage)
- permanent environment conditions (permanent blockage)

Generally the damage is associated with the device getting excessively hot.

As the devices rely on self-cooling to operate correctly, there is a vicious cycle: a hot device is likely to malfunction (e.g. to deprime, or fail to eject a drop when fired), and a malfunctioning device is likely to become hot. Also, a malfunctioning device can generate heat that flows to adjacent (good) devices, causing them to overheat and malfunction. Damaged or malfunctioning ejection devices (heaters) generally also exhibit a variation in the resistivity of the heater material.

Continued operation of a device at excess temperature can cause permanent damage, including permanent total failure.

Therefore it is useful to detect temperature, and/or conditions that may lead to excess temperature, and use this information to temporarily or permanently suppress the firing operation of a device or devices. Temporarily suppressing firing is intended to allow a device to cool, and/or another adverse condition such as depriming to clear, so that the device can subsequently resume correct firing. Permanently suppressing firing stops a damaged device from generating heat that affects adjacent devices.

12.3 Options for Sensing

The basis of the temperature (or other) detection is the variation of a measurable parameter with respect to a threshold. This provides a binary measurement result per sensor—a negative result indicates a safe condition for firing, a positive result indicates that the temperature has exceeded a first threshold which is a potentially dangerous condition for firing. The threshold can be made variable via the control logic, to allow calibration.

A direct thermal sensor would include a sensing device with a known temperature variation co-efficient; there are many well-known techniques in this area. Alternatively we can detect a change in the ejection device parameters (e.g. resistivity) directly, without it necessarily being attributable to temperature.

Temperature sensing is possible using either a MEMs sensing device as part of the MEMs heater structure, or a CMOS sensing device included in the drive logic adjacent to the MEMs heater.

Depending on requirements, a sensing device can be provided for every unit cell, or a sensing device per group (2, 4, 8 etc.) of cells. This depends on the size and complexity of the sensing device, the accuracy of the sensing device, and on the thermal characteristics of the printhead structure.

12.4 Using the Sensing Results

As mentioned, the sensing devices give a positive or negative result per cell or group of cells. There are a number of ways to use this data to suppress firing.

In the simplest case, firing is suppressed directly in the unit cell driving logic, based on the most recent sensing result for that cell, by overriding the firing data provided by external controller.

Alternatively, the sensing result can be passed out of the unit cell array to the control logic on the printhead chip, which can then suppress firing by modifying the firing data shifted into the cell for subsequent lines. One method of passing the results out of the array would be to load it each cell's sensing result into the existing shift register, and shift the sensor results out as new firing data is being shifted in. Alternatively a dedicated circuit can be used to pass the results out.

The control logic could use the raw sensing results alone to make the decision to suppress firing. Alternatively, it could combine these results with other data, for example:

- allow a programmable override, i.e. ignore the sensor results, either for a region or the whole chip
- process groups of sensing results to make decisions on which cells should not be fired
- use and algorithm based on cumulative sensor results over time.

In addition to operations on the printhead, sensing results (raw or processed/summarised) can be fed back to SoPEC (or other high level device controlling the printhead), for example to update the dead nozzle map, or change printhead parameters.

One way of doing this is to use the shift register used to shift in the dot data. For example, the clock signal that causes the values in the shift register to be output to the buffer can also trigger the shift registers to load the thermal values relating to the various nozzles. These thermal values are shifter out of the shift register as new dot data is shifted in.

The thermal signals can be stored in memory and use to effect modifications to operation of one or more nozzles where thermal problems are identified. However, it is also possible to provide the output of the shift register to the input of an AND gate. The other input to the AND gate is the dot data to be clocked in. At any particular time, the dot data at the input to the AND gate corresponds with the thermal data for the nozzle for which the dot data is destined. In this way, the dot data is only loaded, and the nozzle enabled, if the thermal data indicates that there is no thermal problem with the nozzle. A second AND gate can be provided as a global enable/disable mechanism. The second AND gate accepts an enable signal and the output of the shift register as inputs, and outputs its result to the input of the first AND gate. In this embodiment, the other input to the AND gate is the current dot data.

Depending upon the implementation, the nozzle or nozzles can be reactivated once the temperature falls to or below the first threshold. However, it may also be desirable to allow some hysteresis by setting a second threshold lower than first and only enabling the nozzle or nozzles once the second threshold is reached.

12.5 Additional Alternative Embodiments

12.5.1 Printing Fewer than the Full Number of Channels Available on the Printhead

It is possible to use SoPEC to send dot data to a printhead that is using less than its full complement of rows. For example, it is possible that the fixative, IR and black channels will be omitted in a low end, low cost printer. Rather than design a new printhead having only three channels, it is possible to select which channels are active in a printhead with a larger number of channels (such as the presently preferred channel version). It may be desirable to use a printhead which has one or more defective nozzles in up to three rows as a printhead (or printhead module) in a three color printer.

It would be disadvantageous to have to load empty data into each empty channel, so it is preferable to allow one or more rows to be disabled in the printhead.

The printhead already has a register that allows each row to be individually enabled or disabled (register ENABLE at address 0). Currently all this does is suppress firing for a non-enabled row.

To avoid SoPEC needing to send blank data for the unused rows, the functionality of these bits is extended to:

- 1. skip over disabled rows when DATA_NEXT register is written;
- 2. force dummy bits into the TDC FIFO for a disabled rows, corresponding to the number of nozzles in the dropped triangle section for that row. These dummy bits are written immediately following the first row write to the fifo following a fire command.

Using this arrangement, it is possible to operate a 6 color printhead as a 1 to 6 color printhead, depending upon which mode is set. The mode can be set by the printer controller (SoPEC); once set, SoPEC need only send dot data for the active channels of the printhead.

	Number	Date	Country
Parent	10854509	May 2004	US
Child	12758715		US

Printer Incorporating Multiple Synchronizing Printer Controllers

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

US Classifications

International Classifications

Abstract

Description

Claims

CROSS REFERENCE TO RELATED APPLICATION

Continuations (1)