System for applying a tag to a frame based on certain characteristics of the frame and transferring the frame as a function of the tag

[0002] 1. Technical Field

[0003] The present invention relates generally to data storage devices, and more specifically to methods and arrangements that can be employed to significantly reduce the processing requirements associated with the transfer of data from the storage device to an external device.

[0004] 2. Background Art

[0005] An optical disc, such as, for example, a compact disc (CD) or digital versatile disc (DVD), is a nonmagnetic data storage medium on which relatively large amounts of digital information is stored by using a laser beam to burn microscopic indentations into a surface of the medium. The stored data is read using a lower-power laser to sense the presence or absence of the indentations.

[0006] There are many different types of optical disc systems (i.e., optical discs formats and devices) available today. One of the most common optical disc systems used in contemporary personal computers (PCs) is the compact disc read-only memory (CD-ROM). CD-ROM provides a read only optical storage medium onto which data is stored only once and then read many times using a CD-ROM drive. A CD-ROM disc can contain a mixed stream of digital image, audio, video, and/or text data Additional capacity is provided by a digital versatile disc read-only-memory (DVD-ROM). In the future, DVD-ROM will also be faster. Other advanced optical disc systems allow users to also write data to the optical disc. By way of example, a compact disc recordable (CD-R) system allows the user to write-once to each section of the optical disc, while a compact disc rewritable (CD-RW) allows the user to write to each section of the optical disc many times. Other notable optical disc systems include a compact disc magneto optical (CD-MO) disc, which is also rewritable.

[0007] Reading data from these exemplary optical disc systems typically begins with the PC's processor or host processor requesting that a block of data be scanned from the optical disc and transferred over a peripheral bus to the host processor or a primary memory. A block of data typically includes a plurality of smaller blocks or frames of data. These frames of data are typically pre-processed and logically gathered into groups within the optical disc drive, and then forwarded to the host processor over the peripheral bus. By way of example, an exemplary 16X CD-ROM drive for use with a PC typically includes a digital signal processing arrangement that pre-processes the retrieved data, and a buffer management arrangement that stores frames of data, which are typically between about 2 to about 3 kilobytes long, in a 128-kilobyte dynamic random access memory (DRAM) prior to transferring a group of frames to the host processor in a single burst.

[0008] One of the problems facing optical disc drive designers is that there can be different types of frames of data, depending upon the type/format of the optical disc, and, in certain situations, not all of these frames need to be transferred to the host processor.

[0009] For example, CD-ROM discs typically include data frames associated with certain “lead-in” and “lead-out” areas. These “lead area frames” contain a table of contents (TOC) descriptor that is used within the optical disc drive to properly locate and read the tracks recorded on the optical disc and to stay within permitted boundaries on the disc. In a further example, CD-R, CD-RW and other like recordable optical discs, typically employ a plurality of “link area frames”, which are recorded between subsequently written blocks of data. These link area frames are also used within the optical disc drive to properly locate and read the blocks of data recorded on the track.

[0010] Consequently, it is preferred that the optical disc drive include the capability to determine which frames, within a block of data, are to be transferred to the host processor and which frames can be skipped or otherwise ignored and not transferred to the host processor. The task of determining which frames should be transferred to the host processor is typically conducted within a buffer manager arrangement, which can be configured to further process or otherwise examine each of the frames of data, for example, using a firmware-based processor that is responsive to a real-time firmware program. This frame-by-frame examination process tends to be burdensome on the buffer management arrangement, and at times other processing resources. Additionally, new generations of optical disc drives can introduce changes to the existing optical disc formats, or increase the speed at which an optical disc is read. As such, the processing capability of a conventional firmware-based processor may not be able to support the necessary processing demands and time constraints required in the future.

[0011] With this in mind, and considering that it is usually desirable for an optical disc drive to be compatible with the different optical disc formats/types, there is a need for methods and arrangements that effectively reduce the processing burden in an optical disc drive, and streamlines the transfer of frames from the optical disc drive to the host processor.

[0012] The methods and arrangements in accordance with the present invention significantly reduce the processing burden in a data storage device by streamlining the transfer of frames of data from the storage device to an external device by taking into account certain known and/or determinable characteristics about the data recorded on the storage medium, and selectively applying tag data to each frame of data. The tag data is then used to determine the disposition of each frame of data, for example, what actions, if any, are required to process the frame of data within the storage device. This “tagging” scheme, which can be significantly embodied in digital logic, tends to reduce the processing overhead for a significant portion of the frames of data. Therefore, the latency associated with the storage device is reduced, as well.

[0013] In accordance with certain aspects of the present invention, the various embodiments of the present invention can be used for a variety of data storage devices including optical disc drives, magnetic drives/tapes, and similar data storage devices.

[0014] With this in mind, the above stated needs and others are met by a decoder for use in transferring data from a data storage medium to an external device, in accordance with certain embodiments of the present invention. The data storage medium typically has at least one data track recorded on it. Within each of the data tracks, there is a plurality of smaller blocks or frames of data. The decoder includes an input arrangement, a frame managing arrangement and an output arrangement. The input arrangement is configured to receive at least one frame of data. The input arrangement is capable of determining certain characteristics about the frame of data and applying a tag data to the frame of data, based on at least one of these characteristics. Having “tagged” the frame of data, the input arrangement provides the tagged frame of data to the frame managing arrangement. The frame managing arrangement receives the tagged frame of data, stores the tagged frame of data, and subsequently provides the tagged frame of data to the output arrangement. The output arrangement receives the tagged frame of data and provides the tagged frame of data to an external device based on the tag data associated with the tagged frame of data.

[0015] In accordance with certain other embodiments of the present invention, the tag data is one of four types. The first type is a “send” tag, which essentially means that the associated tagged frame of data can be transferred to the external device, such as, for example, a host processor. The next type of tag data is a “skip” tag. When a frame of data is associated with a skip tag, then the tagged frame of data is essentially skipped over and is not transferred to the external device. If a “pause” tag, the third type of tag data, is associated with a frame of data, then the tagged frame of data requires further processing to determine if the tag data should be changed to a send tag, a skip tag, or a “stop” tag. The “stop” tag is the fourth type of tag data. When a tagged frame of data is associated with a stop tag then there is an error condition that will require additional processing.

[0016] By way of further example, in accordance with still further embodiments of the present invention, a send tag is applied to a frame of data when the characteristic identifies that the frame of data is either 1) a main area frame from a once-written track, 2) a main area frame from a fixed-length packet-written track, 3) a main area frame from a variable-length packet-written track, or 4) a valid link area frame from a variable-length packet-written track. Similarly, a skip tag is applied to a frame of data when the characteristic identifies that the frame of data is a link area frame from a fixed-length packet-written track, and a pause tag is applied to a frame of data when the characteristic identifies that the frame of data is a link area frame from a variable-length packet-written track. Stop tags are applied to frames of data when the characteristic identifies that the frame of data is not a valid frame of data. For example, if the frame of data is within an illegal address range, then a stop tag is applied. Further, if the frame of data can be read or has sync problems or data errors, but does not match the above characteristics, then a pause tag is applied to the frame of data.

[0017] The above stated needs and others are further met by a storage device for use in a computer system, in accordance with certain embodiments of the present invention. The storage device includes a servo assembly, a storage medium, a read assembly, a data engine, an input arrangement, a frame managing arrangement, and an output arrangement. The storage medium, such as, for example, an optical disc, magnetic disk, or combination thereof, is mounted on the servo assembly and the read assembly is used to read at least a portion of a track of data from the storage medium and output a read signal. The data engine receives the read signal and outputs at least one frame of data based on at least a portion of the read signal. The frame of data is then supplied to the input arrangement, which determines certain characteristics about the frame of data, applies tag data to the frame of data, and outputs a tagged frame of data to the frame managing arrangement, where it is stored and subsequently output to the output arrangement. The output arrangement then provides the tagged frame of data to an external device, based on the tag data within the tagged frame of data.

[0018] In accordance with yet another embodiment of the present invention, a method is provided for use in transferring data from a data storage medium to an external device. The method includes the steps of reading at least one frame of data from a data storage medium, determining certain characteristics about the frame of data, applying a tag data to the frame of data based on at least one characteristic about the frame of data, and providing the tagged frame of data to an external device, based on the tag data within the tagged frame of data. In accordance with certain embodiments of the present invention, the step of applying the tag data to the frame of data further comprises selecting either a send tag, a skip tag, a pause tag, or a stop tag depending upon the characteristic of the frame of data. The tagging of a frame of data can be logical and/or physical. By way of example, in accordance with certain embodiments of the present invention, the step of applying the tag data to the frame of data includes physically modifying data (e.g., adding a specific sequence of binary bits/bytes of data) within a tag area of the buffered frame of data to create the tag data.

[0019] Additional aspects, advantages and novel features of the invention will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following or may be learned by practice of the invention. The advantages of the invention may be realized and attained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

[0020] Reference is made to the attached drawings, wherein elements having the same reference numeral designations represent like elements throughout and wherein:

[0021] FIG. 1 is a block diagram depicting a conventional computer system having a storage device that is arranged to selectively transfer a block of data containing a plurality of data frames to a host processor over a bus or a similar network-based connection.

[0022] FIG. 2 is a block diagram depicting a storage medium on which at least one block of data is recorded, and a storage device, as in FIG. 1, that is arranged to read the block of data from the storage medium; the exemplary storage device having a read/write assembly, a servo assembly, a controller, a data engine, a block decoder, a drive memory and a bus interface.

[0023] FIG. 3 is a block diagram depicting a block decoder, as in FIG. 2, that is arranged to facilitate the transfer of selected portions of the block of data from the storage device to the host processor; the exemplary block decoder having a data engine interface, error corrector, buffer manager, host interface, and controller interface.

[0024] FIG. 4 is a graphical depiction of a conventional buffer management process for use in a block decoder, for example, as in FIG. 2, to facilitate the transfer of selected frames of the block of data from the storage device to the host processor; wherein the exemplary block decoder is capable of logically, physically, or otherwise managing a plurality of queues or stacks of received and stored data frames, of which at least a portion are subsequently transferred to the host processor.

[0025] FIG. 5 is a graphical depiction of exemplary formatted data as recorded on a storage medium, as in FIG. 2, such as, for example, an optical storage disc; the formatted data includes a lead-in area having a table of contents (TOC) section, at least one track having a plurality of frames of data (i.e., smaller portions of data) therein, and a lead-out area.

[0026] FIG. 6 is a graphical depiction of a portion of a track, as in FIG. 5, that is written in multiple discrete packets that are either of a fixed-length or a variable-length and separated by a plurality of linking blocks.

[0027] FIG. 7 is a graphical depiction of different areas, such as a main data area and a spare (unused) area, included in an exemplary frame of data, as in FIG. 5, that is stored in a drive memory.

[0028] FIG. 8 is a graphical depiction of different data fields found in an exemplary formatted main data area, as in FIG. 7.

[0029] FIGS. 9 and 10 are flow diagrams depicting processes for use in a modified storage device, the processes being configured to apply an opcode tag to a frame of data based on certain criteria and to further process the frame of data based on the opcode tag, in accordance with certain embodiments of the present invention.

[0030] FIG. 11 is a graphical depiction of a tagged frame of data having an opcode tag, in accordance with certain embodiments of the present invention.

[0031] FIG. 1 is a block diagram depicting a portion of a conventional computer system 10, such as a PC, having a host processor 12, primary memory 14, bus 16, and a storage device 18. Host processor 12 is typically configured to read data from, and/or write data to, both primary memory 14 and storage device 18. Data that is read from storage device 18 is typically recorded into primary memory 14 before being processed by processor 12. Similarly, in certain configurations, data is read from primary memory 14 by host processor 12 and provided, over bus 16, to storage device 18, where it is written to a storage medium. Bus 16 is typically a peripheral bus, such as, for example, a Small Computer System Interface (SCSI), Advanced Technology Attachment Packet Interface (ATAPI), IEEE 1394 serial bus, or similar formatted bus.

[0032] For purposes of simplicity, the remainder of this text focuses on a read operation, in which the host processor 12 has requested that a block of data be read from storage device 18 and provided to host processor 12 and/or primary memory 14, via bus 16.

[0033] FIG. 2 is a block diagram depicting the major subsystems in an exemplary storage device 18, as is shown in FIG. 1. Storage device 18 includes a storage medium 22, such as, for example, a CD or DVD. Storage medium 22 is typically removable from storage device 18. When properly inserted into storage device 18, storage medium 22 will be supported within storage device 18 and rotatably moved by a servo assembly 24. Servo assembly 24 typically includes a spindle motor and mounting arrangement (neither of which are shown). Servo assembly 24 is connected to a drive controller 26. Drive controller 26 is typically a microprocessor that is configured to control the various subsystems in storage device 18 and communicate with host processor 12, through bus 16, in accord with one or more software programs.

[0034] Data is read from (or written to), storage medium 22 by a read/write assembly 28. For a read operation, read/write assembly 28 includes a laser diode and a laser pick-up circuit (neither of which are shown). Read/write assembly 28 is selectively positioned over storage medium 22 by servo assembly 24 during a read (or write) operation, under the control of controller 26. Data is usually stored on storage medium 22 along a continuous spiral track having a constant pit (e.g., data bit) size. Therefore, the information content is greater per revolution on the outside than on the inside of the storage medium.

[0035] Read/write assembly 28 is movable relative to storage medium 22 so that it can be positioned over a particular track and follow the track as the storage medium is rotated to read the desired data.

[0036] An analog signal is output by the read/write assembly 28 and provided to a data engine 30, such as, for example a digital signal processor (DSP). Data engine 30 converts the analog signal to a digital data stream, for example, using conventional analog-to-digital conversion techniques. Depending upon the type of storage device, data engine 30 can also be configured to descramble, correct, extract, exclude, and/or otherwise modify certain data in the data stream. For example, in certain CD-ROM drives, data engine 30 employs conventional demodulation techniques (e.g., data slicing) and cross interleaved Reed Solomon code (CIRC) correction techniques to extract main data (MD) and subcode data from the analog signal. The data on a conventional CD-ROM is separated into frames of data having about 2352 bytes of MD and 96 bytes of subcode data each. The subcode data format actually includes 98 bytes, however, two of the bytes or slots are left blank to detect the start of the subcode frame. The remaining 96 slots contain one byte of subcode data each. As shown, data engine 30 is also connected to and responsive to device controller 26.

[0037] The resulting digital data from data engine 30 is provided to a block decoder 32. Block decoder 32 is configured to facilitate the transfer of the digital data to the host processor 12, via a bus interface 35 and bus 16. During a read operation, block decoder 32 gathers and stores the frames of data in a drive memory 34. Block decoder 32 then transfers a group of frames (e.g., about 4-8 frames) from drive memory 34 to host processor 12 in a single burst transfer, via bus interface 35 and bus 16. Block decoder 32 is described in more detail below. Block decoder 32 is connected to and responsive to device controller 26.

[0038] Drive memory 34 is typically a conventional DRAM chip that is connected to, but otherwise separate from, block decoder 32. The size and operational parameters of drive memory 34 vary, depending upon the operating speed of storage device 18, the operation and latency of block decoder 32, and the operation and latency of host processor 12. It is common for a CD-ROM to have the capability to store at least about 50 frames of data in drive memory 34, when the block decoder transfers groups of frames in a burst. By way of example, drive memory 34 usually needs to be about 128-kilobytes for a 16X CD-ROM, and about 256-kilobytes for a 32X CD-ROM.

[0039] Storage device 18 further includes a bus interface 35 that provides the connectivity to bus 16. Bus interface 35 is a conventional interface circuit that is specifically designed for the particular format of bus 16. Thus, for example, in certain configurations bus interface 35 can be a SCSI, ATAPI, 1394, or other like bus interface. Bus interface 35 is further connected to, and responsive to, drive controller 26.

[0040] FIG. 3 is a block diagram depicting an exemplary block decoder 32, as in FIG. 2. Block decoder 32 includes data engine interface logic 36, error correction logic 37, a buffer manager 38, host interface logic 40, and controller interface logic 42. Data engine interface logic 36 is configured to exchange data with data engine 30, and is responsive to commands from error correction logic 37, and drive controller 26, via controller interface logic 42. Host interface logic 40 is configured to exchange data with bus interface 35, and is responsive to commands from buffer manager 38, and drive controller 26 via controller interface logic 42. Similarly, controller interface logic 42 is configured to facilitate the exchange of control information between drive controller 26 and error correction logic 37, buffer manager 38, data engine interface logic 36 and host interface logic 40.

[0041] As the name implies, error correction logic 37 is provided to correct errors in the digital data received from data engine 30, via data engine interface logic 36. This typically includes employing conventional data correction techniques to evaluate certain data within each frame, identify particular types of errors, and, when applicable, correct the detected errors, for example, by automatically changing corrupted or otherwise incorrect data within the frame or requesting further assistance from controller 26, through controller interface 42.

[0042] In support of a read operation, buffer manager 38 receives frames of data from error correction logic 37 and selectively stores the frames of data in drive memory 34. Buffer manager 38 is further arranged to supply certain frames to host interface logic 40 for transfer to host processor 12. As described in detail below, when necessary, buffer manager 38, which is operatively coupled to controller 26 via controller interface 42, interrupts or otherwise requests further assistance from controller 26.

[0043] FIG. 4 is a graphical depiction of a conventional buffer management process 50 that is embodied or otherwise employed in one or more of the functions/circuits of block decoder 32, for example, as shown in FIG. 3. Buffer management process 50 facilitates the transfer of selected frames of data to the host processor 12.

[0044] Buffer management process 50 is capable of logically, physically, or otherwise managing a plurality of queues (e.g., 54, 58, 60, and 62) of stored frames of data, such as, stored frame 52, which can be stored in drive memory 34. For example, one of these queues, namely transmit queue 60, includes frames of data that will eventually be transferred to host processor 12. Arrows are shown in FIG. 4 to graphically illustrate that buffer management process 50 logically, physically, or otherwise organizes or “places” frames in certain queues.

[0045] When a new frame of data arrives, buffer management process 50 places the new data in a new frame 58 from empty queue 62 to haystack queue 54. After a pre-determined threshold number of frames have been placed in haystack queue 54, buffer management process 50 causes controller 26 to be interrupted. When this occurs, controller 26 evaluates each frame 52 in haystack queue 54 and determines what to do next. If controller 26 determines that frame 52 can be transferred to host processor 12, then buffer management process 50 places frame 52 into data queue 58, until such time as frame 52 is requested by host processor 12. When a frame or frames within data queue 58 are requested by host processor 12, buffer management process 50 places the requested frame(s) in transmit queue 60. Once in transmit queue 60, the frames are then transferred to host processor 12, for example, by host interface logic 40. Following the transfer of a frame 52 out of transmit queue 60, buffer management process 50 places frame 52 in an empty queue 62, which essentially frees up the associated memory resources for use in storing a subsequently arriving new frame 56.

[0046] If the evaluation by controller 26 for a given frame 52 determines that the frame 52 is not to be transferred to host processor 12, then the frame 52 is placed in empty queue 62. In this manner, buffer management process 50 is able to sort through the frames of data to determine whether it is proper to forward a particular frame to host processor 12.

[0047] In conventional CD-ROM drives, there are several frames of data that are not intended to be transferred to host processor 12, even if somehow requested. These include, but are not limited to, frames that are read from a lead-in area or a lead-out area of the CD-ROM.

[0048] FIG. 5 graphically depicts data 70 that is recorded on a CD-ROM. As shown, data 70 essentially includes a lead-in area 72, followed by between one and ninety-nine tracks 74, and then a lead-out area 76. Within lead-in area 72 there is a table of contents (TOC) section 73, which includes information pertaining to various parameters associated with tracks 74, such as, for example, the start and stop boundaries for each track. Similarly, within each track, for example, track 74a, there is a specific track descriptor 75 that contains additional information about track 74a. Track descriptor 75 is typically contained within the first 150 frames in the track. Lead-out area 76 is recorded at the end of data 70 and typically includes information that can be used by controller 26, for example, to recover and reposition read/write assembly 28 using servo assembly 24 if the scanning of the CD-ROM during a read operation erroneously passes beyond tracks 74.

[0049] With certain notable exceptions, the frames recorded in lead-in area 72, track descriptor 75, and lead-out area 76 are not typically transferred to host processor 12. Indeed, such a request and/or transfer is usually considered an error condition.

[0050] The track descriptor block is used by controller 26 to discover information about the track. For example, controller 26 can use the track descriptor block to determine if the track is a packet-written track, and if so, whether the packets within the track are of a fixed-length or of a variable-length, and if of a fixed-length, what the fixed-length is. As is known in the art, in packet-written tracks, data is recorded to the optical disc in a plurality of packets that are either of a fixed-length or of a variable-length to form one track.

[0051] A portion of an exemplary packet-written track 80 is graphically depicted in FIG. 6 to illustrate how two packets are linked together within track 80. As shown, packet-written track 80 has a first data area 82 containing a plurality of frames 88 associated with a first packet, and a second data area 86 containing a plurality of frames 89 associated with a second packet. A linking area 84 is located between first data area 82 and second data area 86. Linking area 84 includes a plurality of run-out blocks 90, which are recorded during an initial write operation immediately following frames 88. During a subsequent write operation, several run-in blocks 94 are recorded prior to recording frames 89. Run-out blocks 90 and run-in blocks 94 essentially identify that a transition from one packet to the next packet is taking place, thereby providing the necessary information for storage device 18 to synchronize with the subsequently written packet data.

[0052] Between run-out blocks 90 and run-in block 94, there is a link block 92, which can include data recorded during both the initial write operation and the subsequent write operation. Thus, for example, link block 92 can include superimposed bits of data, some from the initial write operation and some from the subsequent write operation.

[0053] For fixed-length packets, the frames within run-out blocks 90, link block 92, and run-in blocks 94 are not usually transferred to host processor 12. However, for variable-length packets, the frames within run-out blocks 90, link block 92, and run-in blocks 94 can be transferred to host processor 12. Thus, storage device 18 needs to have the additional capability to distinguish between fixed-length and variable-length packet-written tracks. As discussed below, the information needed to make decisions, such as these, is typically provided in the data recorded on storage medium 22 (e.g., in the track decriptor, TOC, etc.).

[0054] The complexity of buffer management process 50 is, therefore, increased to support reading packet-written tracks. This complexity can increase the latency associated with storage device 18. For example, the latency tends to increase when host processor 12 requests the transfer of a block of data that includes multiple frames, a portion of which are from linking area 84. If host processor 12 does not request the frames associated with linking area 84, then buffer management process 50 needs to move unwanted frames from transmit queue 60 to empty queue 62. This additional parsing of frames typically requires that controller 26 be interrupted, and results in multiple transfers, rather than a single transfer of the frames. Both of these side-effects tend to increase the latency of storage device 18.

[0055] Thus, there is a need for improved methods and arrangements that effectively reduce processing burden associated with the determining which frames are to be transfered to host processor 12.

[0056] As described below, improved methods and arrangements are provided, in accordance with certain embodiments of the present invention, for streamlining the various decisions that need to be made in storage device 18. In accordance with certain aspects of the present invention, an improved block decoder includes additional functionality, for example, embodied in digital logic, that identifies certain attributes about each new frame 56 and marks or otherwise identifies each new frame 56 in a manner that later reduces the need to interrupt controller 26 and/or break up a transfer of frames into multiple transfers. Thus, the decision to move a frame 52 from haystack queue 54 to data queue 58 can be simplified, and/or the decision to transfer a frame associated with a link area 84 from transmit queue 60 to empty queue 62 can be simplified.

[0057] With this in mind, in addition to the TOC 73 and track descriptor 75 (described above), additional information about the data recorded on storage medium 22 is available within each valid frame, regardless of the type of frame. FIG. 7 is a graphical depiction of an exemplary conventional frame 88athat is about 2.5 kilobytes long. As shown, frame 88aincludes a main data area 100 where user data is recorded, a subcode area 102 and a formatted-Q area 104, and a spare (unused) area 106.

[0058] FIG. 8 is a graphical depiction of the various data fields found in the data from data engine 30. Block decoder 32 uses a synchronization data field (SYNC) 110, a minute-second-frame (MSF) address 112, and a mode byte (MODE) 114 to align the frames of data, find the address information and mode of the track. This information is transferred to main data area 100′. An error detection code (e.g., CRC) 118 and an error correction code (ECC) 122 (e.g., containing a C3 code) are used by error corrector 37 to check the integrity of the main data (MD) 116 (i.e., user data). As depicted in FIG. 7, there is also an additional data stream containing subcode data, which is stored in areas 102 and 104. By way of example, for a conventional Mode 1 formatted header, these fields include a 12-byte SYNC 110, MSF address 112, MODE 114, MD 116, an error detection code (EDC) 118, a spare field (SPARE) 120, and an error correction code (C3) 122.

[0059] Using portions of the information described above, the method and arrangements in accordance with certain embodiments of the present invention, advantageously decrease the latency associated with storage device 18, and in particular, the latency introduced by buffer management process 50 when transferring frames from transmit queue 60 to host processor 12. These methods and arrangements, which can be embodied in hardware and/or software, basically employ an operational code (opcode) tag 240 (e.g., see FIG. 11), which can be applied early in the process to each new frame 56.

[0060] The opcode tag 240 is used within storage device 18 to speed up subsequent processing of the frame, for example, during transfer to host processor 12. In accordance with certain preferred embodiments of the present invention, opcode tag 240, for example, as graphically depicted in frame 88′ in FIG. 11, takes the form of binary data that is added or otherwise included in spare area 106′. This binary data identifies a particular operation that needs to occur within buffer management process 50.

[0061] FIG. 9 depicts a flow diagram of a process 200 for use in a storage device 18′ (i.e., a modified version of storage device 18 in FIGS. 2 and 3). Process 200 includes an initial step 202 of mounting storage medium 22 in storage 18′. For example, step 202 can include inserting an optical storage disc into a CD drive, DVD Drive, or the like. Next, in step 204, selected portions of the data 70 recorded on storage medium 22 are read and certain information is gathered. For example, the TOC 73 is read to gather information about the number of tracks 74 recorded in data 70 and the relative starting and stopping locations for each track 74. Further, the track descriptor 75 in each track can be read to gather additional information regarding whether the track is a once-written track or either a fixed-length or a variable-length packet-written track. This information, which provides characteristics about the tracks, is then included in a table that is stored, or otherwise maintained, within storage device 18.

[0062] Next, in step 206, storage device 18 waits to receive a read request command from the host processor 12. In response to a read request command, process 200 proceeds to step 208, where the requested block of data, or a subset thereof, is read from storage device 22. At this step, the hardware can be set up for tag definition. As each new frame 56 is read, several validation checks are conducted. For example, a synchronization test is conducted to determine if the read was valid. If the frame passes the synchronization test, then a conventional CRC is conducted. Further, the address of the frame can also be verified as being within an acceptable range of addresses, for example, as determined by the read operation. If the frame fails the address validity processes/tests, then a STOP opcode tag is applied to the frame in steps 210 and 212. The STOP opcode tag essentially identifies that there is a problem with the frame. A STOP opcode is used, for example, for known illegal frames, such as, one having illegal addresses. Compare this to a PAUSE opcode tag, which is used for corrupted data or unknown data, for example. Unlike a STOP opcode tag, for a PAUSE opcode tag, controller 26 is interrupted immediately and may perform a retry operation before being requested by host processor 12.

[0063] Assuming that a frame is found to be valid in step 208, then in step 210, either a SEND, SKIP, or PAUSE opcode tag is applied to the frame, depending on the type of track and frame.

[0064] For a written-once track (e.g., a CD-ROM, or DVD-ROM) a SEND opcode tag will be applied, in step 214, because the frame can be transferred to host processor 12. The frame is determined to be part of either a written-once track or a packet-written track based on information in the table created in step 204.

[0065] For a fixed-length packet-written track, in step 216, there are two opcode tags that can be applied, depending upon the type of frame (i.e., linking area frame or data area frame). The type of frame can be determined using the mode field 114 in the header of the frame, for example, as graphically depicted in FIG. 8. Thus, for example, the first three (3) bits 115 in the byte of data in mode field 114 identify whether the frame is a link area frame or a data area frame. If the frame is a link area frame of a fixed-length packet-written track, then host processor 12 is not to receive the frame. Thus, a SKIP opcode tag is applied to the link area frame and the frame is not transferred to host processor 12. If the frame is a data area frame, then host processor 12 is allowed to receive the frame. Thus, a SEND opcode tag is applied to the data area frame and it is transferred to host processor 12.

[0066] For a variable-length packet-written track, in step 218, there are also two opcode tags that can be applied, depending upon the type of frame (i.e., linking area frame or data area frame). Again, the type of frame can be determined using the mode field 114 in the header of the frame, for example, as graphically depicted in FIG. 8. If the frame is a link area frame, then host processor 12 is allowed to receive the frame. However, there may be a need to perform some additional processing of the frame before it can be transferred to host processor 12. Referring back to FIG. 6, it can be seen that there are seven blocks of data within linking area 84. It is not uncommon, however, for data engine 30 to output eight blocks of data rather than seven blocks of data due to the superposition of data in link block 92. Consequently, this extra block of data, which is typically referred to as a “slip” block, needs to be identified and not transferred to host processor 12. Thus, a PAUSE opcode tag is applied to the link area frame and the frame is not be transferred to host processor 12, but instead is held for further processing, for example, by controller 26. Controller 26 may then update/correct the link blocks and overwrite the opcode tag data with SEND; and may write SKIP tag data to any extra frames. If the frame is a data area frame, then host processor 12 is allowed to receive the frame. Thus, a SEND opcode tag is applied to the data area frame and the frame is transferred to host processor 12.

[0067] If a valid frame cannot be determined to fit one of the above types, then in step 220, a PAUSE opcode tag is applied to allow further processing to be conducted, for example, by controller 26. A PAUSE opcode tag can also be used when there is a detected error correction failure, sync slip, etc. In this manner, the methods and arrangements are intended to support future generations of storage devices, or other unknown/obscure storage medium formats. However, it is recognized that the additional processing required in response to a PAUSE opcode may result in an increase in the latency of the storage device, rather than a decrease.

[0068] In accordance with certain preferred embodiments of the present invention, process 200 is embodied in digital logic within a block decoder, as in FIGS. 2 and/or 3. For example, the synchronization, CRC, and address range, and mode testing and opcode tag generation/application can be conducted within modified versions of data engine interface logic 36 and/or error correction logic 37. Such tests are well known to those skilled in the art, and are found in conventional storage devices. Further, those skilled in the art will recognize that digital logic and/or software/firmware logic can be employed in one or more of the subsystems in a modified version of storage device 18 in practicing the methods and arrangements of the present invention. Thus, for example, the firmware program running on controller 26 can be modified to further support the various steps in process 200.

[0069] FIG. 10 is a flow diagram depicting an additional process 300 for use in a storage device 18′. Process 300 includes a step 302, wherein a transfer buffer counter is loaded to support the transfer of data to host processor 12. The transfer buffer counter can include, for example, the number of frames 88′ already having an associated opcode tag 240, that are in transmit queue 60.

[0070] If opcode tag 240 equals PAUSE, as determined in step 304, then process 300 waits for controller 26 to change the opcode tag to either SEND or SKIP. For example, if frame 88′ is marked as a PAUSE because it was a link area fame from a variable-length packet-written track, then, provided the frame is not later determined to be a slip frame, the opcode tag 240 will be changed to SEND. Conversely, if frame 88′ is later determined to be a slip frame, then opcode tag 240 will be changed to SKIP. If opcode tag 240 equals SKIP, then in step 312, the frame will be placed in empty queue 62 in accord with step 306.

[0071] If the opcode tag is SEND, as determined in step 306, the frame of data is transferred to host processor 12 and the buffer count is decremented, in accord with step 310. Next, the frame or slot is moved to empty queue 62 in step 312.

[0072] In step 314, it is determined if the transfer count is equal to 0. If the transfer count is equal to 0, then process 300 ends. If the transfer count does not equal 0, then there are additional frames of data to be processed and process 300 returns to step 304.

[0073] Referring back to step 306, if the opcode tag is not SEND, then process 300 proceeds to step 308. In step 308, it is determined if the opcode tag is SKIP. If the opcode tag is SKIP, then process 300 proceeds to step 312 and subsequently 314, as decribed above.

[0074] If the opcode tag is not SKIP, but is STOP as determined in step 316, then process 300 ends.

[0075] It is recognized that, if needed for a particular configuration, opcode tag 240 can be removed from frame 88′ prior to transferring frame 88′ to host processor 12. However, in most configurations this is not necessary since the additional information in opcode tag 240 should not adversely affect host processor 12.

[0076] In accordance with certain preferred embodiments of the present invention, process 300 is embodied in digital logic. For example, steps 302, 306 and 312 can be conducted within modified versions of block decoder 32 and/or controller 26, and steps 304, 308 and 310 can be conducted in modified versions of host interface logic 40 and/or controller 26. Those skilled in the art will further recognize that digital logic and/or software/firmware logic can be employed in one or more of the subsystems in a modified version of storage device 18, to practice the methods and arrangements of the present invention. Thus, for example, the firmware program running on controller 26 can be modified to further support the various steps in process 300.

[0077] While this invention has been described in connection with what is presently considered to be the most practical and preferred embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.