If you get the results you need using it why not. The more trivial RLE is not too resource hungry and easy to implement, IIRC (have done it last over a decade ago, our VNC (RFB) server does it all the time during framebuffer transfers).
Well you *could* do that but if the sample file you posted a while back is any guide to their contents you might want to investigate the run length N of consecutive zero bits that gives maximum compression.
My instinct is that it may be somewhere near 120000. Since there are entire blocks of 15k zero bytes in the test file.
0 bit counts with N = 5,6,7, 8, 16, 32, 64 ... might also be worth investigating and stop when it no longer yields additional compression.
Your sample file was 70% 00000000 and 20% with a single bit set. Its natural word length appears to be the 8 bit byte.
My preference would be to encode it as 8 bit words and use the symbols which never occur or occur just once in the entire file to represent the following (not necessarily in this order).
If N=16, the compression gain for data=0 words is 16:1, and the penalty on top of nonzero words is 6%. That's not bad for a simple decoder.
0.4 file size ratio is pretty good. I like simple and done. I can explain this to a smart intern in minutes.
I'll run my little Basic program on some more complex FPGA bit streams, as soon as we make some. The current project has a serial flash chip per FPGA so doesn't need compression, but a new Pi-based product line might benefit from compression. I expect the FPGA designs to be fairly simple or absurdly simple. We will use the T20 chips because we could get them and bought a bucket full for $10 each.
Clocked slow and not working hard, no PLLs, the 1.25 volt core power is milliamps. A tiny linear regulator from +5 will work fine.
My guys say that compared to the big-guy FPGAs, the efinix design suite looks like garage-level engineering. That's a feature, not a defect. A lot of the suite is in plain-sight Python and there's no FlexLM horrors to fight.
I think you worry a bit too much about decompression complexity. Decompression is much simpler/less computationally intensive than compression, even if you do something like LZW. Probably you won't need anything like that of course but if you do it won't be a killer.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.