FPGA Central

References: <474ecfeb$0$27127$[email protected]>
In-Reply-To: <474ecfeb$0$27127$[email protected]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Original-NNTP-Posting-Host: 121-72-33-128.dsl.telstraclear.net
Message-ID: <474f7088$[email protected]>
X-Original-Trace: 30 Nov 2007 15:08:08 +1300, 121-72-33-128.dsl.telstraclear.net
Organization: CLEAR Net New Zealand http://www.clear.net.nz - Complaints [email protected]
Lines: 28
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 203.97.37.6
X-AuthenticatedUsername: news10531
X-Trace: sv3-5uJcaIIptyby8bkAKAPtv1OC/BUekegEsOpsQFglNibnrmqghaDiBni0B76aUFxkKjyazHDTBvz LiJz!vSJ5s8Hozv6K1p+LopGVpm/cV2CMYvkn5gkZn2RhYzrs87PlpA35b9hnqw==
X-Complaints-To: [email protected]
X-DMCA-Complaints-To: [email protected]
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.36
Bytes: 2976
Xref: number1.nntp.dca.giganews.com comp.arch.embedded:267370 comp.arch.fpga:138660 comp.compression:78989 comp.lang.vhdl:67777 sci.electronics.design:862567

Denkedran Joe wrote:
> Hi all,
>
> I'm working on a hardware implementation (FPGA) of a lossless compression
> algorithm for a real-time application. The data will be fed in to the
> system, will then be compressed on-the-fly and then transmitted further.
>
> The average compression ratio is 3:1, so I'm gonna use some FIFOs of a
> certain size and start reading data out of the FIFO after a fixed
> startup-time. The readout rate will be 1/3 of the input data rate The size
> of the FIFOs is determined by the experimental variance of the mean
> compression ratio. Nonetheless there are possible circumstances in which no
> compression can be achieved. Since the overall system does not support
> variable bitrates a faster transmission is no solution here.
>
> So my idea was to put the question to all of you what to do in case of
> uncompressibility? Any ideas?

If you have cast this in concrete : "The readout rate will be 1/3 of the
input data rate" and you hit any compression case above 33.33%, then
you are dead in the water : something HAS to give - either discard data,
or take longer.
You can tolerate 'errant peaks' in the data compression,
by using larger buffers, but the _average_ must remain under 33.33% over
the buffer size.

-jg