---
title: BS-Sparsity-Enabled Two-State Coding (BSTC)
url: https://www.emergentmind.com/topics/bs-sparsity-enabled-two-state-coding-bstc
type: topic
---

# BS-Sparsity-Enabled Two-State Coding (BSTC)

Searching arXiv for the specified paper and closely related accelerator work to ground the article in current literature.
BS-Sparsity-Enabled Two-State Coding (BSTC) is a bit-slice–native weight-compression method introduced as one of the three key innovations in MCBP, a bit-grained compute-memory efficient algorithm-hardware co-design for accelerating large language model inference [2509.10372]. Within MCBP, BSTC targets the weight-access bottleneck in the decoding stage by exploiting significant sparsity in high-order bit-slice weight, rather than operating at the conventional value level. The method compresses each bit-slice independently, uses a two-state code that distinguishes all-zero groups from non-zero groups, and is co-designed with the bit-serial BRCR engine so that compression, decompression, and computation proceed in lockstep with zero realignment overhead [2509.10372].

## 1. Position within MCBP and the decoding bottleneck

MCBP is presented as a memory-compute efficient LLM inference accelerator that addresses three sources of inference latency: inefficiencies in GEMM operations, weight access, and KV cache access [2509.10372]. Its three key innovations are BS-repetitiveness-enabled computation reduction (BRCR), BS-sparsity-enabled two-state coding (BSTC), and Bit-grained progressive prediction (BGPP). BSTC specifically addresses weight access by exploiting significant sparsity in high-order bit-slice weight [2509.10372].

The motivation for BSTC is tied to a limitation of existing Transformer accelerators and prior compression schemes. In the decoding stage, the dominating cost of weight-fetch has traditionally been attacked at the “value level,” including run-length coding, Huffman coding, and sparse-matrix formats, but these schemes leave unexploited sparsity that appears only after decomposing each 8-bit weight into individual bit-planes [2509.10372]. When an LLM is quantized to 8 bits, value-level sparsity is typically only 5–10%. Moreover, value-centric layouts store all eight bits of every weight contiguously, so if a bit-serial GEMM engine needs only the MSB-slice, it must still read all eight bits and then perform bit-reorder in SRAM or logic to construct the 1-bit stream [2509.10372].

Section 2.2 of the source paper profiles Llama-7B and Qwen-7B and reports that MSB slices alone are 70–80% zeros, with empirical sparsity satisfying $SR_i \ge 65\%$ for $i \ge 3$ [2509.10372]. This establishes the central premise of BSTC: a compression scheme designed at the bit-slice level can expose sparsity that value-level coding cannot. The paper further states that BSTC lines up perfectly with the bit-serial compute in the CAM-based BRCR engine, exploits the 60–80% zero-rates found in the high-order bit-slices, and costs almost zero extra reorder logic [2509.10372].

## 2. Bit-slice formulation and two-state mapping

BSTC begins from an 8-bit quantized weight matrix $W \in \mathbb{Z}^{H \times H}$, decomposed into $b = 8$ bit-slices according to

$$
W = \sum_{i=0}^{b-1} 2^i \cdot W_i, \qquad W_i \in \{0,1\}^{H \times H}.
$$

For each bit-slice $W_i$, sparsity is measured as $SR_i = \#\text{zeros} / \#\text{entries}$ [2509.10372]. Empirically, the paper reports $SR_i \ge 65\%$ for $i \ge 3$, and therefore only slices 3 through 7 are encoded, while slices 0, 1, and 2 remain uncompressed [2509.10372].

Within a given bit-slice $W_i$, each column of length $H$ is divided into fixed groups of $m$ rows. Each group is thus an $m$-bit vector $g \in \{0,1\}^m$, with at most $2^m$ possible patterns per column [2509.10372]. BSTC defines a two-state mapping on each such group:

- if $g == 0^m$ then emit code “0”
- else emit code “1” $\Vert$ $g$

where $\Vert$ denotes bit-concatenation [2509.10372].

This definition gives the code its “two-state” character: the header bit indicates either an all-zero group or a non-zero group followed by a literal payload. The decoder therefore consumes a serial stream of 1-bit headers, where a ‘0’ means that the entire group is all zeros and a ‘1’ means that the next $m$ cycles contain literal bits [2509.10372]. No further pointer or index information is needed. The paper states that choosing the same group size $m$ for BSTC as for the BRCR merge engine, with $m = 4$ in the design, allows BSTC de/compression and compute to proceed in lockstep, with zero realignment overhead [2509.10372].

A concise summary of the coding rule is as follows.

| Element | Definition |
|---|---|
| Weight decomposition | $W = \sum_{i=0}^{7} 2^i \cdot W_i$ |
| Encoded slices | $W_3, W_4, W_5, W_6, W_7$ |
| Group structure | Column-wise groups of $m$ rows |
| Zero group | Emit “0” |
| Non-zero group | Emit “1” $\Vert$ $g$ |
| Design group size | $m = 4$ |

This design directly couples the coding format to the bit-serial datapath. A plausible implication is that the format is not merely a compression layer but a representational choice intended to eliminate the conventional boundary between memory layout and compute layout.

## 3. Encoding and decoding procedure

The source presents high-level pseudocode for BSTC encoding and decoding on one bit-slice [2509.10372]. Encoding processes the bit-slice in row-major chunks of $m$. For each row block and each column, it extracts the corresponding $m$-bit column group $g$. If $g$ is equal to $0^m$, it appends a single header bit 0; otherwise it appends a header bit 1 followed by the literal bits of $g$ [2509.10372].

Decoding reconstructs a bit-slice $\hat{W}_i$ by scanning the input bitstream in the same row-block and column order. For each group, the decoder reads one header bit. If the header is 0, the corresponding group in $\hat{W}_i$ remains $0^m$; if the header is 1, the decoder reads the next $m$ bits and writes them into the group [2509.10372].

Two implementation properties are emphasized. First, there are no pointers or variable-length integer codes: every group yields exactly 1 or $(1+m)$ bits [2509.10372]. Second, the decoder can therefore be simple, clocked at one header per cycle with an $m$-bit shift-register to collect the next $m$ bits [2509.10372]. This distinguishes BSTC from value-level schemes that require explicit indexing or arbitrary-byte pattern handling.

Because the method encodes slices independently and groups are fixed-size, the representation remains structurally regular despite being variable-length at the group level. This regularity is central to the claim that the compressed stream is itself aligned to the single-bit serial datapath [2509.10372].

## 4. Hardware realization and parallel decompression

The hardware realization described for MCBP places BSTC within an SRAM-banked architecture. Figure 15(c) is described as showing an on-chip SRAM layout in which the $H \times H$ bit-slice is partitioned along the hidden dimension into $K$ sub-matrices, one per SRAM bank [2509.10372]. During offline weight-load, the controller writes each sub-matrix’s compressed stream into its bank at a known row address, and the start-addresses are stored in a tiny “address area” consisting of 3 SRAM rows [2509.10372].

At decode time, the controller performs four steps [2509.10372]:

1. Reads start-address for bank $k$.
2. Reads one SRAM row, 64 bits wide, per cycle.
3. Feeds each bit into a lightweight “two-state” decoder:
   - A 1-bit comparator checks for header == 0 versus header == 1.
   - On a ‘1’, a small serial-in parallel-out (SIPO) of width $m$ collects the next $m$ bits.
   - On a ‘0’, it simply outputs $m$ zeros.
4. Steers the decoder’s $m$-bit output into the bit-slice register file row\_block.

The paper states that because every bank and every row block is aligned, all 20 decoders can run fully in parallel; for $m = 4$ this corresponds to 20 banks $\times$ 4 rows/bank = 80 rows total [2509.10372]. Under this organization, the entire $H \times H$ bit-slice can be decompressed in $H/m$ cycles [2509.10372].

The architectural significance of this realization is that decompression is not treated as an off-critical-path preprocessing stage. Instead, it is integrated into the operating rhythm of the bit-serial engine. The paper explicitly attributes to BSTC nearly zero extra reorder logic and zero realignment overhead, both of which are consequences of the shared group granularity between coding and compute [2509.10372].

## 5. Quantitative effects on weight access and decoding latency

The paper reports several quantitative effects for BSTC in Section 6.2 and Figure 17 [2509.10372]. Applying BSTC to the MSB slices, specifically $i = 3 \ldots 7$, achieves on average a 2.7× reduction in DRAM bandwidth for weights in the decoding stage, compared to an uncompressed bit-serial design [2509.10372].

For the 3rd–7th slices, the reported sparsity is approximately 70–75%, and the average size per group under the two-state code is given as

$$
CR_i = \frac{1 \cdot SR_i + (1+m)\cdot(1-SR_i)}{m+1}
$$

bits per $m$-bit group, yielding $CR_i \approx 0.35$–$0.4$ for $m = 4$ [2509.10372]. End-to-end across all compressed slices, this yields a 2.5–3× reduction in weight bits fetched [2509.10372]. In the full-model end-to-end decoding latency study, BSTC alone cuts weight traffic by 44% and total decoding time by 35–40% [2509.10372]. The paper also states, with reference to Table 9, that BSTC’s overall weight-access reduction across 26 benchmarks is 44% on average, translating to 2.7× lower DRAM bandwidth from weight fetch alone [2509.10372].

The following table organizes the principal reported metrics.

| Quantity | Reported value |
|---|---|
| MSB-slice zero-rates | 70–80% zeros |
| Empirical sparsity for encoded slices | $SR_i \ge 65\%$ for $i \ge 3$ |
| Encoded slices | 3rd–7th slices |
| Average DRAM bandwidth reduction | 2.7× |
| Reduction in weight bits fetched | 2.5–3× |
| Weight traffic reduction in full-model study | 44% |
| Total decoding time reduction from BSTC alone | 35–40% |

These measurements are reported specifically for the role of BSTC within the MCBP design rather than as isolated software-only compression ratios. This suggests that the relevant performance criterion is not only compressed size but also whether the compressed representation can be consumed at the pace required by the bit-serial accelerator.

## 6. Relation to prior weight-compression schemes

The source contrasts BSTC with value-level compression methods such as RLE, Huffman, and CSC/CSR [2509.10372]. These methods see only 5–10% zeros in full bytes and must either leave the lower 6 bits uncompressed or carry $\log_2(H)$ plus pointer overhead when compressing arbitrary byte-patterns [2509.10372]. As described in the paper, they therefore cannot exploit the 70–80% zero-rates of high-order bit-planes without substantial index traffic [2509.10372].

By contrast, BSTC is characterized in the source as having four specific advantages [2509.10372]:

- It works at the bit-plane level, so it captures every zero in the MSB.
- It uses only a 1-bit “non-zero” marker, with no full pointers, amortized across $m = 4$ bits.
- It needs no data reorder hardware, because the same bit-serial datapath processes headers and literals.
- It decompresses at DRAM bandwidth, not at compute-side reorder buffers.

Taken together, the paper states that BSTC delivers an order-of-magnitude better sparsity exploitation, described as 70% versus 7%, with less than 10% area overhead for en/decoders, and integrates seamlessly into the BRCR group compute [2509.10372]. The formulation “70% vs. 7%” reflects the comparison between bit-plane-level sparsity and value-level sparsity reported in the source, rather than a universal sparsity law.

The comparison also clarifies a common misconception: the relevant sparsity for bit-serial inference is not necessarily the sparsity of quantized byte values as stored in conventional layouts. BSTC is based on the observation that sparsity emerges asymmetrically across bit-slices, particularly in high-order slices, and that exploiting this structure requires both a different coding unit and a different storage layout [2509.10372].

## 7. Significance, constraints, and interpretation

BSTC is described in the source as the first weight-compression that is natively bit-slice aware, aligns perfectly with bit-serial compute, and mines the high MSB zero-rates of quantized LLMs for nearly 3× weight-access reduction with tiny decoder logic and zero reorder overhead [2509.10372]. Within MCBP, this role is specifically complementary to BRCR, which reduces redundant GEMM computations, and BGPP, which reduces KV cache access [2509.10372]. The result is a design in which weight access is not optimized independently of compute, but through an algorithm-hardware co-design that couples representation, decoder structure, banking, and execution granularity.

At the system level, the source reports that extensive experiments on 26 benchmarks show MCBP achieves 9.43× speed up and 31.1× higher energy efficiency than Nvidia A100 GPU, and 35×, 5.2×, and 3.2× energy saving than Spatten, FACT, and SOFA, respectively [2509.10372]. These are properties of MCBP as a whole, not BSTC in isolation. A careful interpretation is therefore that BSTC should be understood as the weight-access component of a larger accelerator architecture rather than as a standalone compression codec.

The design also has explicit scope conditions. Only slices 3 through 7 are encoded, while slices 0 through 2 remain uncompressed [2509.10372]. The paper’s implementation uses the same group size as the BRCR merge engine, with $m = 4$ [2509.10372]. This suggests that BSTC’s benefits depend on the presence of significant high-order bit-slice sparsity and on architectural compatibility with bit-serial processing. The paper’s central claim is not merely that compressed representation saves bandwidth, but that the representation can be decoded in parallel, at the required throughput, with negligible alignment cost [2509.10372].

Source: https://www.emergentmind.com/topics/bs-sparsity-enabled-two-state-coding-bstc