I suspect ST only ever tested it with their single PSRAM they intend this mode for. My intent is to use indirect mode and manually poke the peripheral, though DMA will have to happen still.

Back on the PIC32MX platform there was a similar type of bug that doesn't exist anywhere else but to me: If any interrupt fires while the PMP peripheral is doing a DMA, there is a 1 in a million chance that it will silently drop 1 byte. Noticed this because all my accesses were 32bit (4 bytes) and broke horribly at the misalignment. The solution is to disable all interupts while doing DMA.

That devboard is using recycled chips 100 percent. Their cost is almost nothing.

The kintex-7 part in question can probably be bought in volume quantities for around $190. Think 100kEAU.

This kind of price break comes with volume and is common with many other kinds of silicon besides FPGAs. Some product lines have more pricing pressure than others. For example, very popular MCUs may not get as wide of a price break. Some manufacturers price more fairly to distributors, some allow very large discounts.

On the subject of XBUS vs FIFO, I trialled both in a demo I wrote with a variety of loads. Benchmarking revealed that over 3 minutes each method was under a second long or shorter. So in time messing with them I never found XBUS to help with contention. I'm sure in some specific application it might be a bit better than FIFO. By the way, I used a 64k FIFO size, which is huge. I don't know if that gave me better results.

Now, if you enable 2cycle mode, the pipeline will recycle the pixel value back into the pipeline for a second stage, which is used for 2 texture lookups per pixel and some other blending options. Otherwise, the RDP is always outputting 1 pixel per clock at 62.5 mhz. (Though it will be frequently interrupted because of ram contention) There are faster drawing modes but they are for drawing rectangles, not triangles. It's been a long time since I've done benchmarks on the pipeline though.

You're exactly right that the UMA plus high latency murders it. It really does. Enable zbuffer? Now the poor RDP is thrashing read modify writes and you only get 8 pixel chunks at a time. Span caching is minimal. Simply using zbuf will torpedo your effective full rate by 20 to 40 percent. That's why stuff I wrote for it avoided using the zbuffer whenever possible.

The other bandwidth hog was enable anti aliasing. AA processing happened in 2 places: first in the triangle drawing pipeline, for inside polygon edges. Secondly, in the VI when the framebuffer gets displayed, it will apply smoothing to the exterior polygon edges based on coverage information stored in the pixels extra bits.

On average, you get a roughly 15 to 20 percent fillrate boost by turning both those off. If you run only at lowres, it's a bit less since more of your tender time is occupied by triangle setup.

Being able to specify a generic part requirement instead of hunting for a specific part is nice sometimes, but any company that makes more than a couple boards already has this covered with a bom management system.

Adding parts via text is nice and fast, but also glosses over many aspects of the part. Say I use a Diodes Inc buck regulator. It has a valid input voltage range it will accept. It has multiple ways it can be wired depending on the application. Wire for buck, septic, etc. PFM on/auto/off, etc. I don't see control over details like that.

Your About Us page is longer and more extensive than your actual product example page.

I see 4-5 very basic designs that I could bang out in Altium in under a day each. Are you selling to people unable to make PCBs? I look for ways to save time because I wear many hats in my job, only 1 of which is doing a board. However, I would not be able to save any time using this tool, because it would produce an inferior result. Additionally, after only 8 months of paying for this product, someone can already afford a full Altium license.

I want to save time on stuff like breaking out and pin swapping IO on a large FPGA. Handle DDR3 routing for me. These are things that actually take time, because you need to understand the device and read through tons of PDFs. However, I think that might also be the most difficult part to add to your product.

Finally, how does it handle physical constraints like non- square board outlines, mounting hole placement, and 3d STEP integration?

Til then, no way to switch.

I have forever associated Webp with macroblocky, poor colors, and a general ungraceful degradation that doesn't really happen the same way even with old JPEG.

I am gonna go look at the complexity of the JXL decoder vs WebP. Curious if it's even practical to decode on embedded. JPEG is easily decodable, and you can do it in small pieces at a time to work within memory constraints.

Intel missed the boat on low end stuff completely with Altera. Very recently since 2021 they have started to change that. Last year they were soliciting use cases and market research for the agilex 3. From my talks with them they have a pretty good handle on what they need to do for low end.

The presentation today was just fluff mostly about AI which has die space in their agilex 5. They have a use case where AI is run in the chip of a cell station to detect traffic patterns and manage QoS better.

I'm not sure the AI bet is worth all the marketing though. FPGAs almost always are used in hard realtime, embedded applications where the behavior must be deterministic in many ways. How is AI gonna help then?