This chip is for other chip designers - basically when doing chip design you want to make a product that works first time (or explain to your boss why he should spend hi 6 figures on a spin) - so you test test test ... what this is for is that a chip team will take their verilog design, compile it into luts and load it up here, it will likely run at ~10% of your designed speed - the alternative is compiling your verilog to code and have it run at 0.1% - 100x more testing
> It is the first fpga really designed with emulation in focus.
Not really. In each generation of devices, Xilinx had one focused on emulation for while now: huge number of LUTs, huge number of general purpose IOs, relatively few DSP elements, a moderate amount of block RAM. Before this monster, it was the Virtex Ultrascale+ VU19P, and before that, the Virtex Ultrascale XCVU440, and before that, the Virtex 7 XC7V2000T.
Since so many people are asking what "emulation" is, I'm going to respond to the parent comment instead:
"Emulation" refers to emulation of chip designs. When a chip has billions of transistors that are all connected to each other to perform higher level functions, you need to test out designs in order to make sure those higher level functions actually do what you expect them to. Most modern chip designs (at least the digital portions of them) are designed using what's called a Hardware Description Language or "HDL" such as System Verilog or VHDL. It's somewhat similar to traditional programming, except threads are nonexistent, so it's essentially an unholy bastardization of a markup language and a programming language. But I digress... These functions are then synthesized into their low level building blocks such as buses, gates, and registers, and are placed and laid out on a chip.
Going back to the part about billions of transistors; as you might imagine, testing of such designs must be rigorous and thorough. Only problem is that it's really, really computationally intensive. There are 2 ways of doing it: Simulation (CPU Based) and Emulation (FPGA Based) Simulation is slower, but yields more data like waveforms and whatnot (though you can get waveforms with emulation, but there are more limits.) Also, simulation takes less time to compile, since there's no place and route step.
I should also point out that there are 4 key simulation levels: Simulation Model (usually compiled C code) RTL Simulation (Functional level simulation) Gate level Simulation (simulating the individual gates) and physical simulation (where the transistors and trace routing are all accounted for.) Each level being roughly an order of magnitude more computationally intensive than the previous. Most time and engineering effort is spent on RTL level simulation, which is what can, and is often emulated on an FPGA, and why this product is so relevant to hardware designers.
To add some extra context, usually when a hardware designer is testing something on an FPGA they'll be testing just one specific IP core (a reusable unit of logic, cell, or integrated circuit layout design that is the intellectual property of the company). Let say, an Ethernet MAC for example. You don't necessarily need a chip like the one in the article to test that. You basically validate what all the inputs and outputs of said IP are going to be; you know that some signals are going to the PCS/PHY and some to a processing core/memory, and provided everything is done correctly then you should be able to slot the IP into your final chip design and everything works. That's not always the case though, which is why some companies end up have many stepping's (revisions of the semiconductor photomasks used to pattern an integrated cirucit). Many companies, my own included, make a business out of designing and selling these IPs to other companies without ever really knowing what the end customer wants to do with it. We just tell them what signals to put in, and what to expect out.
With some of the larger FPGAs, you can connect many multiple IPs together and emulate the whole IC, but it depends on scale. You can easily emulate a whole Intel 4004 chip, but you're not fitting a whole Apple M1 design on a single device. With the chip in the article though, we're a step closer to that. Generally you might have 16+ FPGAs on a single PCB to test that scale of functionality. Even that's not a "true" test of a whole IC though, because of the delay in chip-to-chip communication. You might send your design to the foundry and find you've failed on timing. An Agilex 7 M-Series, one of the larger FPGAs in the Intel portfolio, has 3.9M LEs. This chip has what looks to be 18.5M. It's not a 1:1 comparison because they have different architectures, but you get a rough idea of the jump in scale here. This Versal Premium chip will be a massive boon to the likes of Apple, Tesla, NVIDIA, etcetera, because they can potentially emulate the entire chip function on a single die, meaning less steppings to get production quality silicon.
For context, "emulation" here is not referring to emulation for video game systems, but for SoC Designers. It could potentially be used for that though if the cost wasn't likely very prohibitive like most FPGAs (and frankly, the VP1902 price tag is likely to be enormous).
I did my final year project using a Xilinx FPGA back around 1992. We put some image processing algorithms for fingerprint processing onto it for adaptive thresholding and line thinning. There was a lecturer who was very into hardware software co-design but had got quite disillusioned with it as general purpose CPUs just kept getting faster and faster.
So is this a successor to the DE-10 Nano (the board the MiSTERFPGA project is based on)?
(after looking at corescore probably not, as it'd be way too expensive. that being said, the DE-10 Nano is getting old, are there any potential successors coming)?
Nothing is really comparable to the DE-10 Nano's combination of capacity, embedded ARM cores, memory, HDMI scaler, and (most importantly) price. The ZedBoard fails the last test: it is a fair bit more expensive than the Nano.
I am keen on the MiSTex project though. The plan is to come up with something that is more flexible than MiSTer to support different targets. So for example, you might be able to target a simpler core to a simpler device and vice versa.
These boards are amazing for the price. About 1/3 as expensive as a Zedboard and way more capable. It's confusing, but real. I use both for work & personal projects.
This thing probably costs more than your car. So, no, it is not a successor in any meaningful sense. There are a lot of alternatives right now that would be an acceptable choice; it's mostly that the DE10-Nano has all the mindshare and the Mister community behind it.
But, in better news, it looks like Intel is finally getting off their asses and actually expanding their newest Agilex series to meet their customers across the spectrum, and finally offer new alternatives to their Cyclone series, which is used in the Nano.
Sometime later this year they are planning to announce the "Agilex 3" line, and that -- or the already announced "Agilex 5" -- will likely be what you will see in the successor to the DE10-Nano. It will still take work to target this chip and get it into a board people can readily buy.
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.
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.
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.
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...
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)
So question: my understanding was th atat one point the cadence hardware emulators weren't FPGA based at their core, but instead custom chips with a sea of little one bit processors that only knew about logic ops (with some FPGAs for interchip routing). Is Cadence using FPGAs for logic now too?
"Palladium Z2 emulation based on a new custom emulation processor offers fastest, most predictable compiles and most comprehensive pre-silicon hardware debug capabilities
Protium X2 prototyping based on latest Xilinx UltraScale+ VU19P FPGAs offers highest performance and fastest bring-up times for pre-silicon software validation of billion-gate designs"
Finally! I've waited 25 years for something like this, which totally derailed the career I had envisioned for myself. I might even lose the option of making fun of all new chips for providing marginal performance increases for exponentially growing complexity, and have to find a new shtick.
A few predictions/concerns:
* I can't find a price, so I'm predicting that it will be over $1,000 which will prevent it from going mainstream (and also be ~10 times more expensive than it should be).
* There will be poison pill(s). Maybe flash memory that can only be written 1000 times, preventing its use for evolutionary hardware and genetic algorithms. Maybe the place-and-route software won't be good enough to prevent short circuits, so certain configurations will burn up. Maybe some aspect of the software will be proprietary and/or encumbered by patents, preventing hobbyists from thinking outside the box and "getting real work done".
* Any dedicated hardware like memories, ALUs, etc may be misaligned for various use-cases. I just want an array of RISC-V, Arm, DEC Alpha, PowerPC 601/603, something like that, starting with 2 and topping 100 or 1000 cores eventually. So where I'll need memories near CPUs, something in the FPGA will lack the interconnect to allow that.
I hope I'm wrong about any or all of these. Price I can live with, as long as economies of scale or competition kick in and eventually deliver something under $1,000. The rest of it.. eh, I'm not holding my breath. I've been underwhelmed by all previous FPGAs, but maybe they didn't count. Maybe this is something new that finally manifests the original vision of what FPGAs could be.
> I can't find a price, so I'm predicting that it will be over $1,000
Try 50x to 100x that at quantity=1. This is not a hobbyist device: this FPGA is the largest you can get on, and it's tailored to the needs of companies that spend 7-9 figures on the verification and validation of their ASIC projects.
> Maybe this is something new that finally manifests the original vision of what FPGAs could be.
Even small to mid-sized modern FPGAs have far surpassed the "original vision of what FPGAs could be".
You're right, and in fairness I haven't used an FPGA or VHDL since the 90s. I spent the 2000s in destitution and the 2010s catching up, getting the rug pulled out from under me every 10 years or so like everyone else as wealth inequality reached unbelievable levels. Even $1000 for a testing rig felt out of reach.
I should probably start with an open source setup, but last I heard, pretty much all FPGAs had a proprietary layer like GPU drivers on Linux, which was such a huge turnoff that I never bothered proceeding further. If that's changed, I'm all ears!
> I've been underwhelmed by all previous FPGAs, but maybe they didn't count. Maybe this is something new that finally manifests the original vision of what FPGAs could be.
It sounds like you're frustrated with hardware manufacturers for a slight against supporting your use case. But I think that on closer inspection, you're really frustrated with economics, physics, and the nature of the universe.
It's part of the nature of semiconductor manufacturing that manufacturing a custom ASIC (or massively-general-purpose IC?) especially a large and complex one, is going to be very expensive. There are huge non-recurring costs that can get amortized over each unit, plus economies of scale that kick in, when your masks can be used for production runs of thousands or millions of chips. It's not 10x more expensive than it should be so they can make 90% profit when you compare it per unit of silicon area against the millions of Zen3 chiplets that AMD has sold, it's 10x more expensive because it has fixed costs and they're only going to sell a few thousand of them.
As a result of that, you want to spend as little as possible to make a product that's usable by as many people as possible. If a thousand companies can use this FPGA with flash/EEPROM/fuses that have relatively low write endurance, but it's more expensive and difficult (or eliminates thousands of use cases!) to use SRAM with huge write endurance for settings that will typically be written once and, on dev units, a few dozen to a few hundred times, that's not an intentional poison pill sabotaging your career but just reasonable economics and good sense. Plus, if you're trying to recover NRE, an obvious avenue for recovery of some of those funds that you spend writing the software is to make the software proprietary so you can sell Vivado licenses to each of those customers.
On a 2-dimensional planar die, you can add a few layers, but you can't change the mathematics of graph theory to get 3D or 4D or infinite connectivity. Interconnect is just plain expensive. It's always going to be an engineering tradeoff between power dissipation and speed, so they make a best guess as to where the most applications will need interconnect, and build that. The fundamental software gates that are used to build them are always going to be slower than dedicated hardware gates, because it takes additional transistors to run a signal through them. That's why memories, ALUs, CPU cores, and peripherals on an FPGA SOC are hard-coded into the chip. They're hardcoded in ways that allow you to flexibly make use of them with custom logic, but they're burned into the die because that's better performance for their users.
You can't physically call into being a few cubic nanometers of doped silicon to form a new gate when you downlonew bitstream to an FPGA - and putting P or N doped silicon in just the right spot is critical to designing a chip, so how in the world do FPGAs actually work? They cheat, instead of building actual logic gates they just move charges to build the same truth-table out of generic SRAM-based look-up table, which means working at a layer of abstraction several steps ad a up the stack. The idealized, oversimplified, conceptual model of an FPGA as identical to a mask-programmable integrated circuit, except field-programmable, doesn't exist.
Ya good points. I feel like they mostly touch on the current state of FPGAs and their limitations. And you're right about the lack of a market. It's hard for me to envision a market for reprogrammable GPUs, because most people are consumers who just want to run games as fast and cheap as possible.
I tried to address some of your concersn about scaling in my response to imtringued.
AMD CPUs see major performance increases every generation. The 7700XT is more than 100% faster than the 2700X and that is at the same core count. Higher core counts beyond 8 cores have become much more accessible.
Having thousands of dumb cores is pointless unless you want to work with sparse data. An out of order core isn't bottlenecked by compute, it is mostly bottlenecked by memory access latency and also bandwidth if you do end up using vector instructions.
This means most of your core will be memory and your thousand core chip will turn back into a dozen core chip. If you need a dumb accelerator, then GPUs already exist and you don't need a custom chip.
So the only remaining usecase is sparse data. The expectation is that you are going to get cache misses all the time anyway, so the benefit of a large cache is negated by the fact that the same data is rarely accessed again. The problem with this idea is that sparse workloads are pretty rare. The only usecase that could possibly benefit from a custom chip is sublinear machine learning (SLIDE) which basically does nothing but predict which neurons are activating and ignore everything else.
Oh also I am already assuming you want to tape out your chip and that the FPGA is just a stepping stone. If all you do is insist on running softcore processors with no special architecture (e.g. the Reduceron) on an FPGA then the whole exercise is meaningless.
Hey I don't disagree. You bring up some good points, so let me address them individually:
AMD CPUs see major performance increases every generation. The 7700XT is more than 100% faster than the 2700X and that is at the same core count. Higher core counts beyond 8 cores have become much more accessible.
You can check my math, but single-threaded performance has only increased by a factor of about 3 since 2000. So a modern 8 core machine would be about 24 times faster than say a MIPS or PowerPC 601 at the same clock speed, when CPUs had 4 pipeline stages and didn't suffer the kinds of cache miss penalties we see today, so didn't need excessively complex branch prediction. A 16 core machine would be 48 times faster. But if you look at transistor count, CPUs in 2000 had 1-10 million transistors, while today they have 1-10 billion and GPUs have 10-100 billion. So CPUs should have 1,000-10,000 times the performance, not 24 or 48. There's simply no way for traditional CPUs to scale to the level I'm talking about, which I realized in the late 90s while getting my computer engineering degree from UIUC.
Having thousands of dumb cores is pointless unless you want to work with sparse data. An out of order core isn't bottlenecked by compute, it is mostly bottlenecked by memory access latency and also bandwidth if you do end up using vector instructions.
I agree, so the chip I'm envisioning would have an array of local memories (one in or beside/above each CPU) which negates this argument. Then the problem becomes one of orchestrating those memories to appear as one coherent address space. I want to use a content-addressable memory with copy-on-write, so that the memory works like a hash tree (BitTorrent). A cyclic redundancy check (CRC) or similar could be used for the hashing, with a fallback to lower clash hash like SHA when a block clashes. This would all be encapsulated in an abstraction below the level of the code, following the same principles as cache coherence. We'd mainly use auto-parallelizing higher-order methods along the lines of map-reduce and scatter-gather arrays within a runtime similar to Go/Erlang, Octave/MATLAB or Haskell/Julia (or vanilla C or Lisp even) to make it appear that we are programming a single synchronous-blocking thread of execution. I've had this approach fully-formed in my head since about 2010, with the original idea coming from when I was programming games back in the 90s and Apple crippled its memory busses for cost reasons and to prevent competition between its entry-level machines and its flagship lines, so I saw that the memory bus is the only real bottleneck in computers today.
You do touch on one major limitation though: there would be a 10-100x overhead to build my design on FPGA with multiplexers and LUTs, then another 10-100x for the hash memory, and at least 50% of the die lost to local memories. So I might need 4 orders of magnitude more transistors to achieve existing performance. Then the hashing could add 10-100x the latency, putting us at 6 orders of magnitude worse performance in the worst case. I'd plan to get around that by de-prioritizing latency and optimizing the best case (sort of the non-branch prediction miss or cache miss case) and then throw hardware at it. It's much simpler to just increase the die size by 10-100x on a side than develop the next architecture or VLSI design rules. So at scale, this new chip simply wouldn't face the linear speed increase limitations that all processors today face. It might be as simple as just plugging in another chip on a PCI bus to get another 1000+ cores under the same hash memory, just like how we program the web with hash id caching at the edges with stuff like CloudFlare.
So the only remaining usecase is sparse data. The expectation is that you are go...
Not for these chips. The Vivado licensing is kinda complex these days because it's basically segregated by the chip series rather than actual software features. But it can basically be summed up as "Free for low/mid-range devices with all features, free for people using Alveo accelerators and specific UltraScale SKUs, and pay us money for anything else."
If you can afford to buy this chip, you wouldn't be worried about the price of tools. But still the situation is much better now than it was in the past. For medium or smaller devices, Ultrascale or Zynq, everything is free, and you don't even need a license. Just install and go. AMD/Xilinx has moved towards a more standard programming environment, Github, open source embedded Linux, etc. Much less of a headache.
54 comments
[ 2.8 ms ] story [ 88.5 ms ] threadNot really. In each generation of devices, Xilinx had one focused on emulation for while now: huge number of LUTs, huge number of general purpose IOs, relatively few DSP elements, a moderate amount of block RAM. Before this monster, it was the Virtex Ultrascale+ VU19P, and before that, the Virtex Ultrascale XCVU440, and before that, the Virtex 7 XC7V2000T.
"Emulation" refers to emulation of chip designs. When a chip has billions of transistors that are all connected to each other to perform higher level functions, you need to test out designs in order to make sure those higher level functions actually do what you expect them to. Most modern chip designs (at least the digital portions of them) are designed using what's called a Hardware Description Language or "HDL" such as System Verilog or VHDL. It's somewhat similar to traditional programming, except threads are nonexistent, so it's essentially an unholy bastardization of a markup language and a programming language. But I digress... These functions are then synthesized into their low level building blocks such as buses, gates, and registers, and are placed and laid out on a chip.
Going back to the part about billions of transistors; as you might imagine, testing of such designs must be rigorous and thorough. Only problem is that it's really, really computationally intensive. There are 2 ways of doing it: Simulation (CPU Based) and Emulation (FPGA Based) Simulation is slower, but yields more data like waveforms and whatnot (though you can get waveforms with emulation, but there are more limits.) Also, simulation takes less time to compile, since there's no place and route step.
I should also point out that there are 4 key simulation levels: Simulation Model (usually compiled C code) RTL Simulation (Functional level simulation) Gate level Simulation (simulating the individual gates) and physical simulation (where the transistors and trace routing are all accounted for.) Each level being roughly an order of magnitude more computationally intensive than the previous. Most time and engineering effort is spent on RTL level simulation, which is what can, and is often emulated on an FPGA, and why this product is so relevant to hardware designers.
If you're a software engineer interested in the hardware side of things, there's a great article for explaining the difference between the programming methodologies: https://nandland.com/lesson-7-what-every-software-programmer...
To add some extra context, usually when a hardware designer is testing something on an FPGA they'll be testing just one specific IP core (a reusable unit of logic, cell, or integrated circuit layout design that is the intellectual property of the company). Let say, an Ethernet MAC for example. You don't necessarily need a chip like the one in the article to test that. You basically validate what all the inputs and outputs of said IP are going to be; you know that some signals are going to the PCS/PHY and some to a processing core/memory, and provided everything is done correctly then you should be able to slot the IP into your final chip design and everything works. That's not always the case though, which is why some companies end up have many stepping's (revisions of the semiconductor photomasks used to pattern an integrated cirucit). Many companies, my own included, make a business out of designing and selling these IPs to other companies without ever really knowing what the end customer wants to do with it. We just tell them what signals to put in, and what to expect out.
With some of the larger FPGAs, you can connect many multiple IPs together and emulate the whole IC, but it depends on scale. You can easily emulate a whole Intel 4004 chip, but you're not fitting a whole Apple M1 design on a single device. With the chip in the article though, we're a step closer to that. Generally you might have 16+ FPGAs on a single PCB to test that scale of functionality. Even that's not a "true" test of a whole IC though, because of the delay in chip-to-chip communication. You might send your design to the foundry and find you've failed on timing. An Agilex 7 M-Series, one of the larger FPGAs in the Intel portfolio, has 3.9M LEs. This chip has what looks to be 18.5M. It's not a 1:1 comparison because they have different architectures, but you get a rough idea of the jump in scale here. This Versal Premium chip will be a massive boon to the likes of Apple, Tesla, NVIDIA, etcetera, because they can potentially emulate the entire chip function on a single die, meaning less steppings to get production quality silicon.
It is essentially an FPGA packed together with some ARM cores and interconnects into a single chip.
This isn't "FPGA in your CPU" sort of thing but rather just a generational improvement on existing products.
https://www.xilinx.com/products/silicon-devices/acap/versal-...
Seems there's still a relative dearth of 3rd party articles, but probably will see at least some more fairly quickly (w/ lifting of embargo etc.).
(after looking at corescore probably not, as it'd be way too expensive. that being said, the DE-10 Nano is getting old, are there any potential successors coming)?
I am keen on the MiSTex project though. The plan is to come up with something that is more flexible than MiSTer to support different targets. So for example, you might be able to target a simpler core to a simpler device and vice versa.
https://github.com/MiSTeX-devel
https://github.com/enjoy-digital/litex
… OP didn’t mention they were optimizing for price.
Some might say it makes sense to optimize for availability, recent updates to hardware software stack, etc.
https://www.digikey.com/en/products/detail/amd/SK-KV260-G/13...
The price is very good for Ultrascale+.
I think something could made cheaper using an Efinix Titanium chip, someone should do it. Their own dev. board is too expensive:
https://www.efinixinc.com/products-devkits-titaniumti180m484...
But, in better news, it looks like Intel is finally getting off their asses and actually expanding their newest Agilex series to meet their customers across the spectrum, and finally offer new alternatives to their Cyclone series, which is used in the Nano.
Sometime later this year they are planning to announce the "Agilex 3" line, and that -- or the already announced "Agilex 5" -- will likely be what you will see in the successor to the DE10-Nano. It will still take work to target this chip and get it into a board people can readily buy.
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...
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.
Is it possible to upload just a small bugfix to bitstream?
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.
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)
"Palladium Z2 emulation based on a new custom emulation processor offers fastest, most predictable compiles and most comprehensive pre-silicon hardware debug capabilities
Protium X2 prototyping based on latest Xilinx UltraScale+ VU19P FPGAs offers highest performance and fastest bring-up times for pre-silicon software validation of billion-gate designs"
https://www.cadence.com/en_US/home/company/newsroom/press-re...
A few predictions/concerns:
* I can't find a price, so I'm predicting that it will be over $1,000 which will prevent it from going mainstream (and also be ~10 times more expensive than it should be).
* There will be poison pill(s). Maybe flash memory that can only be written 1000 times, preventing its use for evolutionary hardware and genetic algorithms. Maybe the place-and-route software won't be good enough to prevent short circuits, so certain configurations will burn up. Maybe some aspect of the software will be proprietary and/or encumbered by patents, preventing hobbyists from thinking outside the box and "getting real work done".
* Any dedicated hardware like memories, ALUs, etc may be misaligned for various use-cases. I just want an array of RISC-V, Arm, DEC Alpha, PowerPC 601/603, something like that, starting with 2 and topping 100 or 1000 cores eventually. So where I'll need memories near CPUs, something in the FPGA will lack the interconnect to allow that.
I hope I'm wrong about any or all of these. Price I can live with, as long as economies of scale or competition kick in and eventually deliver something under $1,000. The rest of it.. eh, I'm not holding my breath. I've been underwhelmed by all previous FPGAs, but maybe they didn't count. Maybe this is something new that finally manifests the original vision of what FPGAs could be.
Try 50x to 100x that at quantity=1. This is not a hobbyist device: this FPGA is the largest you can get on, and it's tailored to the needs of companies that spend 7-9 figures on the verification and validation of their ASIC projects.
> Maybe this is something new that finally manifests the original vision of what FPGAs could be.
Even small to mid-sized modern FPGAs have far surpassed the "original vision of what FPGAs could be".
I should probably start with an open source setup, but last I heard, pretty much all FPGAs had a proprietary layer like GPU drivers on Linux, which was such a huge turnoff that I never bothered proceeding further. If that's changed, I'm all ears!
It sounds like you're frustrated with hardware manufacturers for a slight against supporting your use case. But I think that on closer inspection, you're really frustrated with economics, physics, and the nature of the universe.
It's part of the nature of semiconductor manufacturing that manufacturing a custom ASIC (or massively-general-purpose IC?) especially a large and complex one, is going to be very expensive. There are huge non-recurring costs that can get amortized over each unit, plus economies of scale that kick in, when your masks can be used for production runs of thousands or millions of chips. It's not 10x more expensive than it should be so they can make 90% profit when you compare it per unit of silicon area against the millions of Zen3 chiplets that AMD has sold, it's 10x more expensive because it has fixed costs and they're only going to sell a few thousand of them.
As a result of that, you want to spend as little as possible to make a product that's usable by as many people as possible. If a thousand companies can use this FPGA with flash/EEPROM/fuses that have relatively low write endurance, but it's more expensive and difficult (or eliminates thousands of use cases!) to use SRAM with huge write endurance for settings that will typically be written once and, on dev units, a few dozen to a few hundred times, that's not an intentional poison pill sabotaging your career but just reasonable economics and good sense. Plus, if you're trying to recover NRE, an obvious avenue for recovery of some of those funds that you spend writing the software is to make the software proprietary so you can sell Vivado licenses to each of those customers.
On a 2-dimensional planar die, you can add a few layers, but you can't change the mathematics of graph theory to get 3D or 4D or infinite connectivity. Interconnect is just plain expensive. It's always going to be an engineering tradeoff between power dissipation and speed, so they make a best guess as to where the most applications will need interconnect, and build that. The fundamental software gates that are used to build them are always going to be slower than dedicated hardware gates, because it takes additional transistors to run a signal through them. That's why memories, ALUs, CPU cores, and peripherals on an FPGA SOC are hard-coded into the chip. They're hardcoded in ways that allow you to flexibly make use of them with custom logic, but they're burned into the die because that's better performance for their users.
You can't physically call into being a few cubic nanometers of doped silicon to form a new gate when you downlonew bitstream to an FPGA - and putting P or N doped silicon in just the right spot is critical to designing a chip, so how in the world do FPGAs actually work? They cheat, instead of building actual logic gates they just move charges to build the same truth-table out of generic SRAM-based look-up table, which means working at a layer of abstraction several steps ad a up the stack. The idealized, oversimplified, conceptual model of an FPGA as identical to a mask-programmable integrated circuit, except field-programmable, doesn't exist.
I tried to address some of your concersn about scaling in my response to imtringued.
Having thousands of dumb cores is pointless unless you want to work with sparse data. An out of order core isn't bottlenecked by compute, it is mostly bottlenecked by memory access latency and also bandwidth if you do end up using vector instructions. This means most of your core will be memory and your thousand core chip will turn back into a dozen core chip. If you need a dumb accelerator, then GPUs already exist and you don't need a custom chip.
So the only remaining usecase is sparse data. The expectation is that you are going to get cache misses all the time anyway, so the benefit of a large cache is negated by the fact that the same data is rarely accessed again. The problem with this idea is that sparse workloads are pretty rare. The only usecase that could possibly benefit from a custom chip is sublinear machine learning (SLIDE) which basically does nothing but predict which neurons are activating and ignore everything else.
Oh also I am already assuming you want to tape out your chip and that the FPGA is just a stepping stone. If all you do is insist on running softcore processors with no special architecture (e.g. the Reduceron) on an FPGA then the whole exercise is meaningless.
AMD CPUs see major performance increases every generation. The 7700XT is more than 100% faster than the 2700X and that is at the same core count. Higher core counts beyond 8 cores have become much more accessible.
You can check my math, but single-threaded performance has only increased by a factor of about 3 since 2000. So a modern 8 core machine would be about 24 times faster than say a MIPS or PowerPC 601 at the same clock speed, when CPUs had 4 pipeline stages and didn't suffer the kinds of cache miss penalties we see today, so didn't need excessively complex branch prediction. A 16 core machine would be 48 times faster. But if you look at transistor count, CPUs in 2000 had 1-10 million transistors, while today they have 1-10 billion and GPUs have 10-100 billion. So CPUs should have 1,000-10,000 times the performance, not 24 or 48. There's simply no way for traditional CPUs to scale to the level I'm talking about, which I realized in the late 90s while getting my computer engineering degree from UIUC.
https://en.wikipedia.org/wiki/Transistor_count
Having thousands of dumb cores is pointless unless you want to work with sparse data. An out of order core isn't bottlenecked by compute, it is mostly bottlenecked by memory access latency and also bandwidth if you do end up using vector instructions.
I agree, so the chip I'm envisioning would have an array of local memories (one in or beside/above each CPU) which negates this argument. Then the problem becomes one of orchestrating those memories to appear as one coherent address space. I want to use a content-addressable memory with copy-on-write, so that the memory works like a hash tree (BitTorrent). A cyclic redundancy check (CRC) or similar could be used for the hashing, with a fallback to lower clash hash like SHA when a block clashes. This would all be encapsulated in an abstraction below the level of the code, following the same principles as cache coherence. We'd mainly use auto-parallelizing higher-order methods along the lines of map-reduce and scatter-gather arrays within a runtime similar to Go/Erlang, Octave/MATLAB or Haskell/Julia (or vanilla C or Lisp even) to make it appear that we are programming a single synchronous-blocking thread of execution. I've had this approach fully-formed in my head since about 2010, with the original idea coming from when I was programming games back in the 90s and Apple crippled its memory busses for cost reasons and to prevent competition between its entry-level machines and its flagship lines, so I saw that the memory bus is the only real bottleneck in computers today.
You do touch on one major limitation though: there would be a 10-100x overhead to build my design on FPGA with multiplexers and LUTs, then another 10-100x for the hash memory, and at least 50% of the die lost to local memories. So I might need 4 orders of magnitude more transistors to achieve existing performance. Then the hashing could add 10-100x the latency, putting us at 6 orders of magnitude worse performance in the worst case. I'd plan to get around that by de-prioritizing latency and optimizing the best case (sort of the non-branch prediction miss or cache miss case) and then throw hardware at it. It's much simpler to just increase the die size by 10-100x on a side than develop the next architecture or VLSI design rules. So at scale, this new chip simply wouldn't face the linear speed increase limitations that all processors today face. It might be as simple as just plugging in another chip on a PCI bus to get another 1000+ cores under the same hash memory, just like how we program the web with hash id caching at the edges with stuff like CloudFlare.
So the only remaining usecase is sparse data. The expectation is that you are go...