Fixed-Token Data Compression for FPGA and ASIC Throughput

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing lossless compression techniques, such as LZ77 and LZ78, are not optimized for hardware-friendly implementations on Field Programmable Gate Arrays (FPGAs) or Application Specific Integrated Circuits (ASICs), as they prioritize compression ratio over speed or vice versa, lacking efficiency in these specific hardware environments.

Innovation Solution

A lossless compression method that interleaves literal length fields with literal fields, match length fields, and repeat length fields to efficiently compress data by copying literal segments and replacing matched segments with references, using a data packager, hash calculator, hash table, match position searcher, and output assembler to generate compressed data blocks suitable for FPGA or ASIC implementation.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of substance

If LZ77 or LZ78 compression schemes are used to achieve higher compression ratio, then data compression efficiency is improved, but processing speed and hardware implementation efficiency deteriorate

Engineering Contradiction:
Improvedata sizeVSAvoidprocessing speed
Core Design Contradiction:
Loss of substanceVSProductivity

Solution Approach 1:

The patent segments the compressed data stream into distinct token types (literal tokens, match tokens, repeat tokens) with fixed-length encoding. Each token is processed independently through dedicated hardware modules, enabling parallel processing and eliminating the sequential bottlenecks present in traditional LZ algorithms. This segmentation allows the system to achieve high compression ratios while maintaining constant-time processing for each token.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent changes the fundamental parameters of the compression algorithm by using fixed-length token encoding instead of variable-length encoding, and by introducing a minimum match length parameter (minMatch) that optimizes the balance between compression ratio and processing speed. These parameter changes enable the algorithm to be efficiently implemented in hardware with predictable timing characteristics.

Inventive Principle:
Principle #35Parameter changes

2Adaptability or versatility

If general-purpose CPU is used for data compression, then algorithm flexibility is maintained, but hardware efficiency and processing speed deteriorate

Engineering Contradiction:
Improvealgorithm flexibilityVSAvoidhardware efficiency
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent replaces the mechanical system of general-purpose CPU execution with a dedicated hardware architecture implemented in FPGA or ASIC. The compression algorithm is hardwired into the hardware logic, with dedicated modules for hash calculation, match searching, token generation, and output assembly. This substitution eliminates the overhead of instruction fetching, decoding, and control flow management, achieving significant speedups while maintaining algorithmic flexibility through configurable parameters.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Solution Approach 2:

The patent creates a universal hardware compression engine that can handle various data types and compression requirements through configurable parameters such as hash table size, minMatch length, and token encoding format. The same hardware architecture can be adapted to different applications by adjusting these parameters, providing both hardware efficiency and algorithmic versatility.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Loss of substance

If variable-length encoding is used for compression tokens, then compression ratio is improved, but decoding complexity and processing time increase

Engineering Contradiction:
Improvedata sizeVSAvoiddecoding complexity
Core Design Contradiction:
Loss of substanceVSDevice complexity

Solution Approach 1:

The patent segments the encoding into fixed-length tokens where each token type (literal, match, repeat) has a predetermined bit length. This segmentation eliminates the need for variable-length decoding logic, allowing the decoder to simply read fixed-number-of-bits tokens in sequence and reconstruct the original data without complex parsing or state management.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Instead of using variable-length encoding to achieve compression (where longer sequences require more bits), the patent inverts the approach by using fixed-length encoding where each token represents a fixed amount of information. The compression is achieved not through variable-length representation but through the statistical frequency of different token types and the efficiency of the fixed-length representation in capturing data redundancy.

Inventive Principle:
Principle #13The other way round (Inversion)

Data Source

PatentUS10476518B1Hardware friendly data compression
Publication Date: 2019.11.12 INNOGRIT TECH CO LTD
  • US10476518B1 patent drawing
  • US10476518B1 patent drawing
  • US10476518B1 patent drawing

AI summary

Systems, apparatus and methods are provided for compressing data. An exemplary method may comprise interleaving one or more literal length fields with one or more literal fields to an output. The literal fields may contain a first data segment literally copied to the output, and each of the one or more literal length fields may contain a value representing a length of a succeeding literal field. The method may further comprise determining a second data segment being matched to a previously literally copied sequence of data and a match position and writing to the output one or more match length fields and a match position field containing the match position. The literal length fields may contain a total length of the first data segment and the match length fields may contain a total length of the second data segment.