CN116827349A - Data compression engine - Google Patents

Abstract

The present disclosure relates to data compression engines. Compressing connection state information for a network connection includes: receiving an input bitmap having a bit sequence describing a transmission state and a reception state; dividing an input bitmap into a plurality of equal-sized blocks; dividing each block into a plurality of equally sized sectors; generating a block valid sequence indicating a block having at least one bit set; generating, for each block having at least one set bit, a sector information sequence indicating, for the corresponding block, a sector having the at least one set bit and a coding type for each sector; and generating one or more symbols by encoding each sector having at least one set bit.

Description

Data compression engine

Cross Reference to Related Applications

The present application claims priority from U.S. provisional application No.63/357,326 filed on 6/30 of 2022, the disclosure of which is incorporated herein by reference.

Technical Field

The present disclosure relates to data compression engines.

Background

The network architecture may be connection-oriented. In such an architecture, the state of the connection may be stored in system memory and retrieved from memory as needed. For example, the connection state of a communication between two nodes may be stored to system memory to make room for conflicting connections having priority, and retrieved when the processing of the conflicting connection is complete. However, there is limited system memory bandwidth, and it is therefore desirable to minimize the memory bandwidth necessary for connection state storage and retrieval in order to maximize the memory bandwidth available for other operations.

Disclosure of Invention

It has been recognized that the system memory bandwidth required for connection state storage and retrieval can be minimized by compressing the connection state data prior to storage in memory.

It has been recognized that a system may employ a network on chip (NoC) and have a connection-oriented architecture, and may store and retrieve connection status of system nodes communicating on the NoC. It has further been recognized that nocs may use off-chip memory of a system such as Dynamic Random Access Memory (DRAM) to store connection states, although off-chip memory may be a bottleneck for system performance and thus the NoC-DRAM bandwidth required for storing and retrieving connection states should be minimized.

The presently disclosed technology is provided in view of the desire to minimize the memory bandwidth required for connection status to and from memory storage.

In one aspect, the present technology provides a method for compressing connection state information, comprising: receiving an input bitmap having a bit sequence describing a transmission state and a reception state of a packet in a connection between a first node on the network and a second node on the network, each bit in the bit sequence being set or unset; dividing an input bitmap into a plurality of equal-sized blocks; dividing each block into a plurality of equally sized sectors; generating a block valid sequence indicating a block having at least one bit set; generating, for each block having at least one set bit, a sector information sequence indicating, for the corresponding block, a sector having the at least one set bit and a coding type for each sector; and generating one or more symbols by encoding each sector having at least one set bit according to its encoding type such that each encoded sector corresponds to one of the symbols.

In another aspect, the technology provides a system for compressing connection status information, the system comprising at least one processor for controlling: receiving an input bitmap having a bit sequence describing a transmission state and a reception state of a packet in a connection between a first node on a network and a second node on the network, each bit in the bit sequence being set or unset; dividing an input bitmap into a plurality of equal-sized blocks; dividing each block into a plurality of equally sized sectors; generating a block valid sequence indicating a block having at least one bit set; generating, for each block having at least one set bit, a sector information sequence indicating, for the corresponding block, a sector having the at least one set bit and a coding type for each sector; and generating one or more symbols by encoding each sector having at least one set bit according to its encoding type such that each encoded sector corresponds to one of the symbols.

Drawings

The drawings are not intended to be drawn to scale. Moreover, not every component may be labeled in every drawing for clarity. In the drawings:

fig. 1 is a timing diagram showing an example of the timing of a transmission packet and an acknowledgement packet sent between a transmitter and a receiver of a network.

Fig. 2 is a diagram illustrating an example of a transmission and reception sliding window on which a bitmap of one embodiment is based.

FIG. 3 is a block diagram illustrating a connection cache, compression engine, and decompression engine of an embodiment.

Fig. 4A is a diagram illustrating a block of input vectors according to an embodiment.

Fig. 4B is a diagram illustrating sectors of a block according to an embodiment.

Fig. 5 is a diagram showing a format of a compression vector according to an embodiment.

Fig. 6 shows a flow chart of a compression operation according to an embodiment.

Detailed Description

Examples of systems and methods are described herein. It should be appreciated that the words "example," exemplary, "and" illustrative "are used herein to mean" serving as an example, instance, or illustration. Any embodiment or feature described herein as "example," "exemplary," or "illustrated" is not necessarily to be construed as preferred or advantageous over other embodiments or features. In the following description, reference is made to the accompanying drawings, which form a part hereof. In the drawings, like numerals generally identify like components unless context dictates otherwise. Other embodiments may be utilized, and other changes may be made, without departing from the spirit or scope of the subject matter presented herein.

The example embodiments described herein are not meant to be limiting. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations, all of which are explicitly contemplated herein.

The presently disclosed technology may be implemented in a packet-based network. Fig. 1 is a timing chart showing an example of timings of transmission packets and acknowledgement packets transmitted between a transmitter 10 and a receiver 20 of a network in which the technology is used. The transmitter 10 may be a physical node of a network and the receiver 20 may be another physical node of the network, although the transmitter and/or receiver need not be a physical node and may take other forms, such as a virtual network node or a logical network node. In any case, when the transmitter 10 and the receiver 20 communicate with each other, they define a connection on the network.

As can be seen from fig. 1, the transmitter 10 may send transmission packets, such as packets 25a, 25b, 25c and 25d, in a sequence to the receiver 20, wherein each packet is associated with a sequence number indicating its position in the sequence. The receipt of received packets, e.g., packets 25a, 25b, and 25d, received by receiver 20 may be acknowledged by acknowledgement signals, e.g., acknowledgement signals 30a, 30b, and 30c, sent from receiver 20 to transmitter 10. As depicted in fig. 1, the transit time for a transmission packet from transmitter 10 to receiver 20 may be different, causing the transmission packet to be received out of order at receiver 20, i.e., in a different sequence than the sequence in which the transmission packet was transmitted. For example, the transmission packet 25a is transmitted before the transmission packet 25b, but the transmission packet 25a is received at the receiver 20 after the transmission packet 25 b. Further, some of the transport packets may be dropped by the network and not received at receiver 20, e.g., transport packet 25c, due to reasons such as network congestion. When a transmission packet is discarded, it may be retransmitted while carrying its original sequence number, e.g., transmission packet 25e, and when the receiver 20 receives the retransmitted packet, the receiver 20 will send an acknowledgement signal, e.g., acknowledgement signal 30d, for the retransmitted packet.

Communications between nodes in a packet network, such as the packet transmissions and acknowledgements shown in fig. 1, may be interleaved at any time with communications between one or more nodes and one or more other nodes in the network, such that transmissions/receptions of packets from several communications or connections need to be handled based on the connection state prior to transmission or reception of a given packet. Furthermore, it is likely that when transmitting/receiving packets for a given connection, it is desirable to store the connection state for later retrieval so that different connections may be serviced. For example, if the connection of fig. 1 is interleaved with communications in another connection, the status of the transmission packet and the acknowledgement packet may be stored in memory for later retrieval. The state of communication over a packet-based network will be referred to as the connection state, and the connection state will be described by one or more bitmaps. The bitmaps each include a series of bits ordered by packet sequence number, i.e., the order in which the packets were transmitted, wherein each bit is set or unset, and wherein a set bit indicates that a packet corresponding to a sequence number has been transmitted or received, and an unset bit indicates that a packet corresponding to a sequence number has not been transmitted or received.

The bitmap is formed from a sliding window that moves along the sliding range of packet sequence numbers. The windows start with a sequence number corresponding to the oldest unacknowledged packet and have an allocated length such that they end with a sequence number offset from the beginning by its allocated length. The length of the allocation may be determined based on, for example, one or more network congestion parameters.

Fig. 2 is a diagram illustrating an example of a transmit sliding window 50 and a receive sliding window 60 upon which a bitmap of an embodiment is based. The bits in the transmission sliding window 50 indicate whether the transmitted packet has been acknowledged by the receiver. The bits in the receive sliding window 60 indicate whether the transmitted packet has been received by the receiver. In the case of fig. 2, the bits in the receive sliding window 60 are the same as the corresponding bits in the transmit sliding window 50, which indicates that the first packet, e.g., the window, was not received by the receiver and, therefore, was not acknowledged by the receiver. In any case, the transmission sliding window 50 moves when the lowest number of unanswered transmission packets is acknowledged, and the reception sliding window 60 moves when the lowest number of unanswered transmission packets is received. For each of the transmit sliding window 50 and the receive sliding window 60, the first bit of the window corresponds to the Base Sequence Number (BSN) of the window.

When the connection is active, the bits in the sliding window are updated and the window is moved as needed. If the connection is interrupted, the bit and sequence number of the sliding window at the time of interruption become the bit and sequence number of the bitmap to be stored as the connection state of the interrupted connection. In an embodiment, a sliding window for a connection is maintained in cache memory, e.g., on-chip SRAM of a NoC, when the connection is active, and converted to a bitmap stored in system memory, e.g., off-chip DRAM coupled to the NoC, when the connection is interrupted. To save system memory bandwidth, the bitmap may be compressed before being written to system memory and decompressed after being read from system memory.

It should be noted that the word "break" as used in this disclosure refers to a scenario in which a connection between two nodes is temporarily suspended, and a scenario in which a connection between two nodes transitions from being freely executed to being interleaved with one or more other connections.

With respect to interleaving, it is further noted that a node may communicate simultaneously with a plurality of other nodes in the network. For example, node 0 may communicate simultaneously with node 1, node 2, node 3, node 4. Cndot. Node N, and each such communication may define a connection having a connection state that may be stored/retrieved from system memory. In a more specific example:

connection a=node 0< - > -node 1

Connection b=node 0< - > -node 2

Connection c=node 0< - > -node 3

Connection d=node 0< - > -node 4

...

Connection z=node 0< - > -node N

And packets in the connection may be interleaved as:

time 0-Pkt1 send-connect a

Time 10-Pkt2 receive-connect C

Time 15-Pkt3 send-connect a

Time 18-Pkt4 send-connect Z

Time 20-Pkt5 receive-connect B

Time 21-Pkt6 receive-connect D

The connection state is updated every time a packet is processed for a connection, which requires retrieving the connection state. Furthermore, if there are conflicting connections or higher priority connections that require service, the retrieved connection status will need to be stored back to system memory. That is, since there is limited on-chip memory, only a few connections may be on-chip at the same time, and thus if there is a requirement for a service conflicting connection or a higher priority connection, the connection state of the current on-chip connection must be moved off-chip so that the connection state of the conflicting connection or the higher priority connection may be moved on-chip.

Fig. 3 is a block diagram of a system for managing sliding windows and bitmaps, according to an embodiment. The system comprises: a connection cache 100 for storing sliding windows and forming bitmaps; a compression engine 110 for compressing the bitmap when the bitmap is written from the connection cache 100 to system memory; and a decompression engine 120 for decompressing the bitmap when the bitmap is read from the system memory by the connection cache 100. In the configuration depicted in fig. 3, the connection cache 100, compression engine 110, and decompression engine 120 are integrated on a circuit chip using nocs. Compression engine 110 performs inline compression on bitmaps that are to be stored to on-chip or off-chip DRAM or system-on-chip cache (SLC). The decompression engine 120 performs inline decompression on bitmaps read from the DRAM or SLC.

The compression scheme implemented by compression engine 110 and decompression engine 120 is a lossless compression scheme because connection state information is critical to proper function. The main motivation for compressing bitmaps is to save NoC/DRAM bandwidth, which is a key resource. Another motivation is to reduce the storage costs associated with bitmaps and in the worst case, the storage requirements of compressed bitmaps will be exactly the same as the storage requirements of the original bitmaps. Given a fixed bitmap scheme, the write/read for a connection state will have a variable size based on the respective compression efficiency for the connection state, and will ensure that only the relevant bytes of the bitmap are written and read.

An example of a bitmap approach that may be used to describe the connection state is shown below in table 1.

Bitmap image	Bytes
		RX-request window	8
RX-Ack-data window	16
		RX-receive-data window	16
TX-request window	8
		TX data window	16
Total number of	64

TABLE 1

As can be seen from table 1, the bitmap scheme includes five bitmap types, an 8-byte long receiver request window bitmap (RX-request window), a 16-byte long receiver acknowledgement data window bitmap (RX-acknowledgement-data window), a 16-byte long receiver data window bitmap (RX-receive-data window), an 8-byte long transmitter request window bitmap (TX-request window), and a 16-byte long transmitter data window bitmap (TX-data window). The receiver request window bitmap tracks the request packets that have been received by the receiver from the transmitter. The receiver acknowledgement data window bitmap tracks data packets that have been received by the receiver from the transmitter and acknowledged by the receiver. The receiver data window bitmap tracks data packets that have been received by the receiver from the transmitter. The transmitter request window bitmap tracks the receipt by the transmitter of acknowledgements sent by the receiver in response to request packets sent by the transmitter to the receiver. The transmitter data window bitmap tracks the receipt by the transmitter of acknowledgements sent by the receiver in response to data packets sent by the transmitter to the receiver. Although the bitmap types herein are described with reference to specific bit lengths, it should be understood that the size of each of the bitmap types may vary from example to example.

Typically, the bitmap will be sparsely populated with set bits (e.g., 1), with most of the bitmap bits unset (e.g., 0). There are two reasons for the small number of set bits. First, bits are set in the bitmap only when a packet is received out of order (OOO), or only when an acknowledgement to the packet is received by OOO; however, OOO receipt of packets/acknowledgements is not a typical scenario for an ordered network in which packets/acknowledgements will be received in order, and the only scenario in which an OOO receives a packet/acknowledgement is because the packet is dropped during a path switch event. Second, the number of bits set in the bitmap is limited by the total number of outstanding/in-flight packets, which limits the total number of bits that can be set in the bitmap across all connections.

In any case, the uncompressed input to compression engine 110 may be a concatenation of bitmaps. For the table 1 scheme, the input vector (or "input bitmap") may be equal to { rx_req_ wdw, rx_ack_data_ wdw, rx_rcv_data_ wdw, tx_req_ wdw, tx_data_ wdw }, and thus will have a length of 512B (64B).

The input vector may be divided into equal sized blocks. This enables a modular design and inline compression/decompression. Thus, for the table 1 scheme, the input vector may be divided into blocks of 64 b. Fig. 4A is a diagram illustrating blocks 200a-200h into which the input vector of the table 1 scheme may be partitioned. The unit for compression/decompression is a block and thus for the table 1 scheme, compression engine 110 and decompression engine 120 will have 8 instances to cover the whole 512b. Each block may have a valid bit to indicate whether any bits are set in the block. Each block may be further divided into equal-sized sectors, and each sector may include a valid bit to indicate whether any bits in the sector are set. Fig. 4B is a diagram illustrating sectors 300a-300d of a block according to the scheme of table 1. In some examples, the input vector is divided directly into groups of sectors, each group including an equal number of sectors. In those examples, a group of sectors may be referred to as a block.

The input vectors and their divisions have been described, the remaining description being provided in the context of the table 1 scheme for the sake of brevity of description. However, after reading this specification, one of ordinary skill in the art will readily understand how the present technology may be applied in other contexts.

In an embodiment, each valid sector may be in a original format or run-length encoding (RLE). For example, when the coding type=1, the fragment is encoded using RLE, and when the coding type=0, the fragment is encoded as original. The two encoded formats may be as shown in tables 2 and 3 below.

RLE

TABLE 2

Original, original

Fields	Width of (L)	Description of the application
			Data	16	This field provides sector data in uncompressed format.

TABLE 3 Table 3

The format of the compression vector may be as shown in fig. 5. Referring to fig. 5, block_valid [7:0] (reference numeral 400) indicates a block having at least a single bit set in an input vector. For each of the blocks with the block valid bit set, there will be additional information. Each block_valid bit has a sector information sequence, sector_info= { sector_valid [3:0], sector_type [3:0] } (reference numeral 410) to indicate a valid sector and coding type. All valid blocks have their sector information attached, and the last encoded symbol (reference number 420) will form the last fragment in compressed format. The code symbol will be 8b for RLE or 16b for original, based on the code type.

The compression vector length may be calculated using the following formula.

Length (byte) =1+/block_valid [7:0]

(∑block_valid[7:0])+ // {sector_valid[3:0],sector_type[3:0]}

Sigma (sector_valid & sector_type)) +/-/RLE segments

(Σ (sector_valid ≡ -sector_type)). Times.2// original fragment

For example, the compressed vector length in bytes may be calculated as 1 plus the sum of the number of blocks with at least one single bit set in the input vector plus twice the sum of valid RLE segments plus the sum of valid original segments. Compression engine 110 may have one or more interfaces for adapting to the signals shown in table 4 below.

TABLE 4 Table 4

Decompression engine 120 may have one or more interfaces for adapting to the signals shown in table 5 below.

TABLE 5

Regarding performance, the compression ratios for several different scenarios are shown in table 6 below. In the table, compression ratio = input vector/compression vector.

TABLE 6

Referring now to fig. 6, a flowchart of a compression operation according to an embodiment is shown. As can be seen from the figure, the method for compressing connection status information may begin with receiving an input bitmap (step 500). The input bitmap may include a sequence of bits describing a transmission state and a reception state of a packet in a connection between a first node on the network and a second node on the network, each bit in the sequence of bits being set or unset. The input bitmap is divided into a plurality of equally sized blocks (step 510), and each block is divided into a plurality of equally sized sectors (step 520). Next, a block valid sequence is generated (step 530), the block valid sequence indicating a block having at least one bit set. Further, for each block having at least one bit set, a sector information sequence is generated (step 540). The sector information sequence indicates a sector having at least one bit set and a coding type of each sector for a corresponding block. One or more symbols are then generated by encoding each sector having at least one bit set according to its encoding type (step 550), such that each encoded sector corresponds to one of the symbols. The symbols are included in a compressed vector, such as the compressed vector depicted in fig. 5.

Embodiments of the present technology include, but are not limited to, the following.

(1) A method for compressing connection state information, comprising receiving an input bitmap having a sequence of bits describing a transmission state and a reception state of a packet in a connection between a first node on a network and a second node on the network, each bit in the sequence of bits being set or unset; dividing the input bitmap into a plurality of equally sized blocks; dividing each of the blocks into a plurality of equally sized sectors; generating a block valid sequence indicating the block having at least one bit set; generating, for each block having at least one set bit, a sector information sequence indicating, for the corresponding block, the sector having the at least one set bit and a coding type of each sector; and generating one or more symbols by encoding each sector having at least one set bit according to the encoding type of the sector such that each encoded sector corresponds to one of the symbols.

(2) The method of (1), wherein the coding type of each sector is one of an original type or a run-length coding type.

(3) The method of (2), wherein the coding type of a sector is the run-length coding type only when there is a single run of bits set in the sector.

(4) The method of (3), wherein when a sector is encoded according to the run-length encoding type, a symbol of the encoded sector includes a start offset indicating a bit position of a first bit of the single run and an end offset indicating a bit position of a last bit of the single run.

(5) The method of (1), wherein the input bitmap is a concatenation of multiple bitmaps.

(6) The method of (5), wherein the plurality of bitmaps includes a transmitter request window bitmap, a transmitter data window bitmap, a receiver request window bitmap, a receiver data receive window bitmap, and a receiver data receive and response window bitmap.

(7) The method of (1), further comprising the step of forming a compressed vector by concatenating the block valid sequence, the sector information sequence, and the symbol.

(8) The method of (7) further comprising storing the compressed vector.

(9) A system for compressing connection status information, comprising at least one processor for controlling: receiving an input bitmap having a sequence of bits describing a transmission state and a reception state of a packet in a connection between a first node on a network and a second node on the network, each bit in the sequence of bits being set or unset; dividing the input bitmap into a plurality of equally sized blocks; dividing each of the blocks into a plurality of equally sized sectors; generating a block valid sequence indicating a block having at least one bit set; generating, for each block having at least one set bit, a sector information sequence indicating, for the corresponding block, the sector having the at least one set bit and a coding type of each sector; and generating one or more symbols by encoding each sector having at least one set bit according to the encoding type of the sector such that each encoded sector corresponds to one of the symbols.

(10) The system of (9), wherein the coding type of each sector is one of an original type or a run-length coding type.

(11) The system of (10), wherein the coding type of a sector is the run-length coding type only if there is a single run of bits set in the sector.

(12) The system of (11), wherein when a sector is encoded according to the run-length encoding type, a symbol of the encoded sector includes a start offset indicating a bit position of a first bit of the single run and an end offset indicating a bit position of a last bit of the single run.

(13) The system of (9), wherein the input bitmap is a concatenation of multiple bitmaps.

(14) The system of (13), wherein the plurality of bitmaps includes a transmitter request window bitmap, a transmitter data window bitmap, a receiver request window bitmap, a receiver data receive window bitmap, and a receiver data receive and response window bitmap.

(15) The system of (9), wherein the at least one processor is further operable to control forming a compression vector by concatenating the block valid sequence, the sector information sequence, and the symbol.

(16) The system of (15), wherein the at least one processor is further operable to control storage of the compression vector.

(17) The system of (9), further comprising a compression interface for receiving the input bitmap and for receiving an indication that the input bitmap is valid.

(18) The system of (9), further comprising an interface for receiving the input bitmap and for providing an indication of a total number of bits in the symbol.

(19) The system of (9), wherein the at least one processor is further operable to perform decompression on the symbols.

(20) The system of (19), the at least one processor further operable to control forming a compression vector by concatenating the block valid sequence, the sector information sequence, and the symbol, and the system further comprising a decompression interface for outputting the compression vector and an indication that the compression vector is valid.

The foregoing alternative examples are not mutually exclusive, but may be implemented in various combinations to achieve unique advantages, unless otherwise specified. As these and other variations and combinations of the above-described features may be utilized without departing from the subject matter defined by the appended claims, the foregoing description should be taken by way of illustration rather than by way of limitation.

Claims (20)

1. A method of compressing connection state information, comprising:

receiving an input bitmap comprising a sequence of bits describing a transmission state and a reception state of a packet in a connection between a first node on a network and a second node on the network, each bit in the sequence of bits being set or unset;

dividing the input bitmap into a plurality of equally sized blocks;

dividing each of the plurality of equal-sized blocks into a plurality of equal-sized sectors;

generating a block valid sequence indicating a block having at least one bit set;

generating, for each block having at least one set bit, a sector information sequence indicating, for the block, a sector having the at least one set bit and a coding type of each sector; and

one or more symbols are generated by encoding each sector having at least one set bit according to the encoding type of the sector such that each encoded sector corresponds to one of the one or more symbols.

2. The method of claim 1, wherein the coding type of each sector is one of an original type or a run-length coding type.

3. The method of claim 2, wherein the code type of a sector is the run-length code type only if there are single run bits set in the sector.

4. A method as claimed in claim 3, wherein when a sector is encoded according to the run length encoding type, the sign of the encoded sector comprises a start offset indicating the bit position of a first bit of the bits of the single run and an end offset indicating the bit position of a last bit of the bits of the single run.

5. The method of claim 1, wherein the input bitmap is a concatenation of multiple bitmaps.

6. The method of claim 5, wherein the plurality of bitmaps comprises a transmitter request window bitmap, a transmitter data window bitmap, a receiver request window bitmap, a receiver data receive window bitmap, and a receiver data receive and response window bitmap.

7. The method of claim 1, further comprising: a compressed vector is formed by concatenating the block valid sequence, the corresponding sector information sequence for each block having at least one set bit, and the one or more symbols.

8. The method of claim 7, further comprising storing the compression vector.

9. A system for compressing connection status information, comprising:

at least one processor;

a memory storing instructions that, when executed, cause the at least one processor to perform operations comprising:

receiving an input bitmap comprising a sequence of bits describing a transmission state and a reception state of a packet in a connection between a first node on a network and a second node on the network, each bit in the sequence of bits being set or unset;

dividing the input bitmap into a plurality of equally sized blocks;

dividing each of the plurality of equal-sized blocks into a plurality of equal-sized sectors;

generating a block valid sequence indicating a block having at least one bit set;

generating, for each block having at least one set bit, a sector information sequence indicating, for the block, a sector having the at least one set bit and a coding type of each sector; and

one or more symbols are generated by encoding each sector having at least one set bit according to the encoding type of the sector such that each encoded sector corresponds to one of the one or more symbols.

10. The system of claim 9, wherein the coding type of each sector is one of an original type or a run-length coding type.

11. The system of claim 10, wherein the code type of a sector is the run-length code type only if there are single run bits set in the sector.

12. The system of claim 11, wherein when a sector is encoded according to the run-length encoding type, a symbol of the encoded sector includes a start offset indicating a bit position of a first bit of the bits of the single run, and an end offset indicating a bit position of a last bit of the bits of the single run.

13. The system of claim 9, wherein the input bitmap is a concatenation of multiple bitmaps.

14. The system of claim 13, wherein the plurality of bitmaps comprises a transmitter request window bitmap, a transmitter data window bitmap, a receiver request window bitmap, a receiver data receive window bitmap, and a receiver data receive and response window bitmap.

15. The system of claim 9, wherein the operations further comprise: a compressed vector is formed by concatenating the block valid sequence, the corresponding sector information sequence for each block having at least one set bit, and the one or more symbols.

16. The system of claim 15, wherein the operations further comprise: storing the compression vector.

17. The system of claim 9, further comprising a compression interface to receive the input bitmap and to receive an indication that the input bitmap is valid.

18. The system of claim 9, further comprising an interface to receive the input bitmap and to provide an indication of a total number of bits in the one or more symbols.

19. The system of claim 9, wherein the operations further comprise: decompression is performed on the one or more symbols.

20. The system of claim 19, wherein,

the operations further comprise: forming a compressed vector by concatenating the block valid sequence, the corresponding sector information sequence for each block having at least one set bit, and the one or more symbols, an

The system further includes a decompression interface for outputting the compression vector and an indication that the compression vector is valid.