Does this mean we can develop using some not-Xilinx proprietary crapware?
You can always use third-party EDA tools if you have the money rather than the vendor bundled free software. Eg Cadence, Mentor Graphics, etc.
Intel Gears Up for FPGA Push
91–100 of 112 posts
Re: Intel Gears Up for FPGA Push
#92Earlier quoted context omitted.
Raptor Computing Systems will sell you a 4 core POWER9 CPU for $340 each [1]. A desktop mobo with the kinds of features discussed shouldn't be more than a few hundred dollars if slimmed down to one socket and a reasonable but limited set of peripherals (the Talos mobos go a bit over the top with features and hence are >$1k). Someone just has to design one, which is not easy or inexpensive, then hope that developers a…
It's a few hundred dollars if you have the market volume to sell it at that price. IBM have the volume (presumably mostly for servers) so they can do it. You can't spend the amount it costs to make a new SoC based only on the "hope" that people buy it; you need a business plan that says where the volume will come from, and there aren't enough customers for a developer box alone to provide that volume, so the dev box…
I think you're the only one in this thread asking for a new SoC. Other people are asking for affordable developer boards for existing SoCs.
Re: Intel Gears Up for FPGA Push
#93In the case of Lisp and Smalltalk and other highly dynamic languages, would these on-die FPGAs open new compiler optimisation opportunities?
I have worked on this in the case of Smalltalk and the opportunities are there but there are significant problems. The opportunity is in the form of adaptive compilation where you initially use a simple compiler (or even an interpreter for the very first execution) and then collect profiling information and call a much better compiler to generate code for the "hot spots". A key optimization is inlining which greatly increases the size of a basic block. You could add a third step for the really, really hot spots and compile to hardware.
With commercial FPGAs you have a problem that you can't generate the bits yourself but have to use the vendor tools. These are pretty simplistic and will take minutes or hours to compile non trivial circuits. What I mean by this is that they flatten the netlist at some point so compilation time grows non linearly with circuit size. So if your design has five identical blocks, adding a sixth might make it take twice as long to compile.
A second problem is that it takes a while to load the bits into the FPGA. The old XC6000 could be accessed as RAM and quickly rewritten but all other models serially shift in the configuration bits. Xilinx allows partial reconfiguration where you can load the bits to one part of the FPGA while the rest continues to work but that is pretty hard to use and the competitors don't even offer this option.
Re: Intel Gears Up for FPGA Push
#94The biggest problem with reconfigurable computing is it's either an afterthought, tools are too narrow/proprietary or an extra add-in card. Add a million LUTs and several thousand special-purpose blocks (ALUs, CAM, SRAM, DSPs, etc.) on CPU die that can be reconfigured within a few 10k cycles (ie process context), and then future AI-enabled optimizing compilers could incrementally profile and accelerate applications w…
There needs to be a marrying of software and hardware -- and processor instructions to support that. This is hierarchical reconfigurable cache-based architecture I designed a while ago at Intel; I doubt they have touched it but they do own it. https://www.google.com/patents/US20170153892
Transmeta code-morphing? VLIW?
Re: Intel Gears Up for FPGA Push
#95The biggest problem with reconfigurable computing is it's either an afterthought, tools are too narrow/proprietary or an extra add-in card. Add a million LUTs and several thousand special-purpose blocks (ALUs, CAM, SRAM, DSPs, etc.) on CPU die that can be reconfigured within a few 10k cycles (ie process context), and then future AI-enabled optimizing compilers could incrementally profile and accelerate applications w…
Intel do have ARM+FPGA products already from Altera, as do Xilinx. It will be interesting to see if Intel replaces the ARM CPU with a variant of x86.
Yes, I've evaluated some of them too (great for some projects that need like a RPi but with custom digital / DSP logic), they're just not exactly mainstream as Xeon processors.
Re: Intel Gears Up for FPGA Push
#96Earlier quoted context omitted.
It's a few hundred dollars if you have the market volume to sell it at that price. IBM have the volume (presumably mostly for servers) so they can do it. You can't spend the amount it costs to make a new SoC based only on the "hope" that people buy it; you need a business plan that says where the volume will come from, and there aren't enough customers for a developer box alone to provide that volume, so the dev box…
I think you're the only one in this thread asking for a new SoC. Other people are asking for affordable developer boards for existing SoCs.
You can get lots of dev boards for existing SoCs. They have the problems of no PCIe, no SATA, etc that the n^parent was complaining about. If you want those features you first have to identify an SoC that has those; my claim is essentially that such pre-existing SoCs with the kind of features you want in a "developer box" are so thin on the ground as to be pretty nearly nonexistent. "Use a preexisting SoC" is what my classes 2 and 3 are.
Re: Intel Gears Up for FPGA Push
#97In the case of Lisp and Smalltalk and other highly dynamic languages, would these on-die FPGAs open new compiler optimisation opportunities?
I have worked on this in the case of Smalltalk and the opportunities are there but there are significant problems. The opportunity is in the form of adaptive compilation where you initially use a simple compiler (or even an interpreter for the very first execution) and then collect profiling information and call a much better compiler to generate code for the "hot spots". A key optimization is inlining which greatly…
This was very interesting, thank you!
I'm sure I missed something in your first paragraph though, because the process that you described sounds very much like a normal modern JIT compiler. In V8 and SpiderMonkey for example, the engine starts with the first tier, which is a baseline interpreter that collects type information on each function call, and then if a function is invoked enough times, it compiles the function to machine code using the type information collected in the first tier. There are more tiers up the chain, slower to compile and faster to run, where dataflow analysis is done on the hottest functions, which get optimisations such as inline caching, etc.
All that is done on the CPU of course, so I'm curious how an FPGA could help in this process?
Re: Intel Gears Up for FPGA Push
#98Earlier quoted context omitted.
I dream of a GCC/LLVM for FPGAs. I'm not holding my breath for Intel to help with that though.
There are some people working on that, for example: http://www.clash-lang.org/
Last time I checked out Christiaan Baaji's CLASH, it was a Haskell DSL for generating RTL. That is neat, but it doesn't involve any LLVM-like abstraction of FPGA primitives for synthesis.
That would be more than neat, revolutionary really. But it would require buy-in from the major vendors, in the form of publishing many low-level device details.
Re: Intel Gears Up for FPGA Push
#99Earlier quoted context omitted.
That is pretty much the ARM and POWER problem too, they think they can grow in new markets with these hugely expensive machines in quantities of ten racks. Both would have significantly more traction if they offered a reasonable desktop class machine, but they don't seem to be able to do it. For some reason there are dozens of RPi type devices but making a $200-$300 device with a reasonable set of expansion ports (sa…
The underlying problem here is that the cost of making an SoC is enormous. So to make, say, an ARM desktop class machine you have only a few choices: 1) Make your own SoC designed for the purpose. You can tailor it to meet your requirements precisely, but given the low volumes you'll be selling, your system will be at least $10,000 a box, likely more. 2) Use a designed-for-mobile SoC. This will hit your $200-$300 pri…
Nah, the problem is the SOC mental model where you don't provide a generic IO bus. What ARM/etc really needs is a device with a decent memory and PCIe interface. Random board manufactures can then glue on the ethernet/sata/USB for a few bucks a function utilizing 3rd party chips that can be found on boards frequently costing less than $10.
That way instead of spending millions designing a SOC for each tier of devices you design a "generic" device and sell the ones with busted cores/cache/ram channels/whatever as low end developer machines after fusing the broken functionality off.
Re: Intel Gears Up for FPGA Push
#100What I am interested in is a programmable vector fabric that I can reconfigure fast (in say L2/L3 access times). right now there are 100s of AVX2 instructions & as the number of HPC applications grow it is only going to explode. My problem is that when you are using one vector instruction the silicon for the rest is just sitting around when it could be perhaps used to make a much wider SIMD unit for just the instructions I'll be using. If they can get just that right IMO it'll be a huge success.
IMO the problem with FPGA or even silicon dev is mostly tooling. I often say this, the biggest contribution to Open SOurce movement is not of linus/linux ..its gcc. just imagine if 'they' could tangle up every bit of open source code in IP litigation emerging from proprietary compilers.