efinix bit stream question

I can power my boxes from USB +5. The Pi takes +5 and switches to 3.3, and makes enough of that available to power the FPGA i/o banks. A cute little TI switcher can make +1 from +5, for the core supply. Maybe even a linear +1 reg, if the FPGA isn't working very hard. I think we have some apps where the T20 core needs 10s of mA.

I can use a cute little dc/dc brick, like a CUI PDS1, to make +- 12 or whatever for analog stuff.

People here have suggested buying the parts you mention, but we can get all that on a tiny board, tested and done, for less than the parts cost. $4 for the Pi Pico, $10 for the one you suggested.

I love this early stage of product architecture when anything is possible. I think it's important to stay confused for a while.

If anyone is wondering why Larkin is having to "get" bitstreams from people, it's because Efinix does not give out their software unless you buy hardware. Yeah, one of the greatest promotional tools ever, is being able to offer the supporting software for a hardware product, so you can test drive it. Efinix has decided to ignore that and require you to go through purchasing to buy a board that you will likely never use, just to obtain the software, required to work with their devices.

Maybe there's a licensing issue involved, but that sounds remote. I'm guessing it's more to do with a royalty that has to be paid.

I see that my description of the configuration data is pretty accurate. I'm glad that you concur that the encoding the long runs of zeros would offer a very adequate compression, with a minimum of effort in all respects.

It's not like compressing FPGA bit streams is a new idea. I believe some vendors will decompress a compressed bit stream within the FPGA. That save the time required to configure the part, as this is often an important issue.

There is structure at every level. In a less populated design there may be blocks that are totally unused. Are "nulls" bits, or bytes? The compression may work better at the bit level, but if you are seeing such large structures, maybe not. I wonder if you would see more of these repeating structures at the bit level? If they are not aligned to the bytes, they would not appear in a byte level analysis in the same way.

I would speculate that a 20x compression would not be useful, because of the differences in final size based on the utilization of the part, or even just random factors, such as layout of the same exact design. Move logic around and it can change the empty blocks.

Yes, I expect that is correct.

It may be a repeated element with a size that is not a multiple of 8.

I have no idea why. The FPGA has elements of logic and routing. Within those structures are other structures. Few of them will even be a multiple of 8 in length, much less a power of 2.

I recall using gear that looked for repetitions in data by using a waterfall display. Framing bits would stand out as columns of 1s, 0s or even checkerboard patterns. The device I sell uses a three bit framing pattern, if I recall correctly. Because it doesn't vary, it would stand out like a sore thumb once you guess the length of the message right.

In configuration files, I don't think they use framing bits, but the contents will be more obvious when you find the right size for the particular element. Trouble is, there are many, many, different elements.

Not Efinix yet, but people have reverse engineered FPGA configuration files. This is how we have open source tools. When you have small devices, this is easier to do.

You are thinking only of the logic. Logic is a small fraction of the bit stream. It is the routing that takes up the bulk of it. That is much less likely to fit repeated patterns because it contains multiple levels of routing in the same region. But I don't know the structure details. I haven't reverse engineered any FPGAs... yet.

I think some thoughtful analysis of the matter, or even simply researching the issue, would be much more productive. In fact, this would be a great project for a student, part time, while at school. Find out what the other 512,976 FPGA designers are using for compression. Oh, that's what Larkin is doing by posting here. And he doesn't have to pay anyone!

Talk about low paid lackeys!

Or, you can ask in appropriate forums where you can find people who actually work with Efinix. Or maybe call Efinix and ask them about compression. Just a thought, but maybe they know a little bit about it?

There are many carefully-optimized algorithms, developed when computers were tiny. Here is one:

.

Joe Gwinn

I hope Waveshare did a better job with the board layout than they did with the pictures on the web site. Several of the pin allocations seem to disagree with the board silkscreen...!

I don't think an FPGA bitstream is anything remotely like random data. The vast majority of the bytes are zeroes (70%), then bytes with 1 bit set ~2% each, 2 bits set <0.7%. It depends how hard you are prepared to work. Bytes with more than 3 bits set are comparatively rare.

In your example the bytes 8A, A7, BF, DB, ED all appeared just once and the token BE did not occur at all.

In principle for this application you can afford to use insane amounts of CPU power to encode if it makes the decoder simpler and faster. My instinct is that it is only worth compressing enough to make room for whatever code has to fit into the same space.

I recall way back jumping through endless hoops to fit slightly more firmware code into 8k ROMs back in the days when 64k was a lot of ram.

I used to have a university sandwich student for a year and sometimes a student over the long vacation and give them projects that were interesting and otherwise wouldn't get done. The occasional one turned out to be exceptionally good. The rest did an OK job. It is only worth doing if they can finish a project that you don't have the time to do.

Usually something that involves taking a lot of raw data and looking to see if there is anything interesting going on.

Judging by the way it looks to my correlator I would expect LHA type algorithms to do rather well on it. There is an inordinate amount of block duplication. A few simple subs will easily get you under 250k.

What stops you from having one? But you will get more use out of one that is paid the going rate.

Just kidding. We pay very well.

If we do a product line around raspberry pi, we could piggyback on the enormous physical and people culture. I've never seen anything like it.

We might sponsor 5 or 10 smart poor high school or college kids, steer their paths a bit, give them summer projects or jobs, hire a couple of the best when they graduate.

Pi has enormous momentum so should be around for a while.

Momentum isn't the correct model for something that can become nonexistent. The persistent availability of Broadcom SOC chips is not like the mass of a juggernaut. It is not a physical constant.

Where is a second source? Banana pi, anyone?

The Pi that JL is using isn't based on Broadcom. Its a really nice ARM M0+ dual core microcontroller, the RP2040 with some excellent i/o capabilities.

"Obsolescence statement Raspberry Pi understands the value to customers of long term availability of product and therefore aims to continue supply for as long as practically possible. We expect RP2040 to remain in production until at least January 2041."

The board that JL is looking at is the Pico, a small pcb with the RP2040 processor, flash memory and a USB interface. There is a version which also has WiFi. Multiple suppliers are making boards which are either clones or in the general spirit of the Pico. JL has already pointed out that he could make his own board if necessary.

I am planning to use an RP2040 for switching power supply management among other things. Availability is excellent and its a really nice micro-controller at a good price.

John

Broadcom is involved somehow.

Who manufactures the RP2040? That's not obvious.

The culture and infrastructure around Pi is unprecedented. A million kids must be using it. Schools center courses on it.

I was looking at an Analog Devices RF synthesizer chip. The eval kit uses a Pi.

I don't think there is any connection between the RP2040 and Broadcom. The chips are designed by Pi and made by TSMC. All other Raspberry Pi products do use Broadcom chips. The RP2040 is a very different animal however.

From this article:

"However, Upton assures people with microcontroller projects that the RP2040 shouldn't suffer the same shortages, with enough wafers to make 20 million chips.  RP2040 is built on a more modern semiconductor process (TSMC 40LP) than most other microcontrollers. As a result, it makes extremely efficient use of scarce silicon wafer supply: each die occupies just 2mm2, and each 300mm wafer yields roughly 21,000 dice. We have sufficient wafer stock on hand to produce 20 million chips, with more on the way," says Upton.  If you want to build your product on a microcontroller you can actually buy in 2022, RP2040 is your friend."

John