Hacker News Reader

Comment by jhallenworld | Hacker News Reader

https://www.theregister.com/2023/06/27/amd_versal_fpga_emula...

77 mm x 77 mm package (a bit larger than my old Pentium Pro).. I'm amazed they have any yield for a chip this large at 7 nm.

18 M LEs. 6864 DSPs. 6865 balls.

How long does place and route take?

$57K for the smaller VP1802..

https://www.digikey.com/en/products/detail/xilinx-inc/XCVP18...

View on HN

Thankfully that's not the real price. The real price is a fraction of this, and any serious outfit will negotiate quantity discounts to a tenth of that price. Assuming Xilinx can even get you the part...

The last generation was pushing 12 hours on some of my computers. I assume that if you pay for a top-of-the-line server, you can get one of these done in 4-6 hours or so.

UltraScale+ you mean? Well, the real question is P&R time at some utilization, right? We were easily doing 14hr P&R times on fairly utilized US+ chips like, 5+ years ago. We probably could have improved this in a number of ways, though.

I'd honestly think that if you just want to throw money at it, those absurdly-overclocked gamer rigs that can hit sustained +5GHz boosting on just a few cores would be better if you want the fastest P&R times? Cloud servers will probably have more RAM and memory bandwidth but you can shove 128GB of RAM in the 13900K, memory requirements are relatively easy to meet IMO. Synthesis can definitely scale with some more cores in Vivado (OOC synth) but P&R never seemed to scale beyond what you can just get in a desktop. YMMV I guess.

Yeah, I meant Virtex UltraScale+ parts. I hear that there is a small cottage industry of people overclocking Threadripper workstations for FPGA synthesis, because the memory bandwidth is actually the primary limiting factor (and the Threadrippers have the same kind of turbo capability as the gaming rigs). I assume that the "x3D" chips help a lot, but I don't know.

Yeah, you often see it come up in lots of discussions among indies or small teams, since people end up just buying One Server that runs all their builds; I didn't think about AMD's V-Cache though, the 7950X3D is packing 144MB of L3 which would be interesting to test. It would also be interesting to see something at sustained high turbo speeds with a nice, wide LPDDR5X bus like Apple has done, too.

This is basically the approach I've used. you want good memory bandwidth and latency as well as good single-threaded performance over lots of ram and lots of cores, which is what server-grade hardware optimises for. The main concern with really pushing it is the risk of transient errors causing faulty output.

What about upload time?

Is it possible to upload just a small bugfix to bitstream?

Programming time isn't exactly instantaneous or fast on these; SRAM cells need to all be programmed to the proper value for every LUT (2^k SRAM cells needed for a single k-LUT; k = 6 in this case), and that typically is either done online (JTAG) or through attached flash which is read on startup and/or specific commands.

If you want to upload a small bugfix without it taking 10+ hours, you need to floorplan your design and use "partial reconfiguration" techniques in order to change only part of the bitstream at a time. This requires a more advanced design flow and a bit more work, but is necessary for things like multi-tenancy or lowering turnaround times.

>How long does place and route take?

If you want to avoid 12 hours builds you have to use floorplanning, incremental synthesis/implementation, and dynamic function eXchange (swappable components). I've been able to incrementally change designs to the scale of ~50K LUTs (look up tables, 50K LUTs is a big change) in about 15 minutes of synthesis and P&R with the rest of the design locked.

(The chip here is about 400x the size of a single 50K LUT change so I imagine you could have a 100 hour builds if not using floor-planning and partitioning)

this is 4 dies in the one package so real die size is likely 1/4 of this

I guess they can afford to have defects since a FPGA a big grid of a many of the same components.

None of these chips have defects. They usually work with chiplets to improve yield. You used to be able to buy defective devices for a discount when you had a design that didn't use those components, but I don't think those were general-purpose.

This is the old notion of what an FPGA is, and if you notice, these new devices aren't even called FPGA's anymore! They're called 'adaptive SoC's'. Only a small portion of the device is FPGA fabric. But still, even previous gen FPGA's wouldn't be shipped with defects.

This would only work in an application where it's acceptable to run a place-and-route pass for every device to account for the different failures. I don't think it's something anyone has bothered to try to do.

Reply on news.ycombinator.com