How FPGAs work, and why you'll buy one (2013)
1–10 of 110 posts
Re: How FPGAs work, and why you'll buy one (2013)
#2A sequel is in the making, titled "Why you won't buy an FPGA"
Did the followup article ever get written? I didn't find anything with a search for the proposed title on either his site or Google.
Re: How FPGAs work, and why you'll buy one (2013)
#3Is there a possibility to use just-in-time compilers to port software to FPGAs? I can see how that could be used to accelerate applications written on bytecode languages (i.e. mostly everything in your mobile phone) to near-assembly speeds.
Re: How FPGAs work, and why you'll buy one (2013)
#4(2013)
Re: How FPGAs work, and why you'll buy one (2013)
#5Is there a possibility to use just-in-time compilers to port software to FPGAs? I can see how that could be used to accelerate applications written on bytecode languages (i.e. mostly everything in your mobile phone) to near-assembly speeds.
porting regular software to FPGA's is certainly an interesting idea and many people have worked on it (google C to FPGA). Unfortunately, these solutions aren't quite what you would think, because the programming model of a microprocessor (serial execution of instructions) is very different from that of an FPGA (parallel evaluation of gates, non-uniform state access/routing -- you cannot just access any variable in Verilog anywhere, you have to make sure it is possible to efficiently lay out your algorithm on a 2D structure of gates).
As for JIT-ing, compilation times for FPGAs are often in the hours, and the software involved is unfortunately proprietary (and not easily integrated with). There are some field-reconfiguration libraries, but I am not sure to what extent real-world applications compile new Verilog on the fly..
Re: How FPGAs work, and why you'll buy one (2013)
#6A sequel is in the making, titled "Why you won't buy an FPGA" Did the followup article ever get written? I didn't find anything with a search for the proposed title on either his site or Google.
The reason is because GPUs gained more general-purpose capabilities. GPUs are the new FPGA, for all practical purposes.
Re: How FPGAs work, and why you'll buy one (2013)
#7The trouble I had with FPGAs is how radically different languages like Verilog and VHDL are when compared to languages like Java, Python, or C++.
Writing code that is concurrent by default is a massive paradigm shift when all I had been exposed to at that point were procedural languages.
Re: How FPGAs work, and why you'll buy one (2013)
#8I think one issue here is that to achieve the great gains in performance FPGAs can provide you do need to treat it like a proper HW design. C to RTL exists but to get the best out of it you're basically using C as a syntactic sugar for verilog/VHDL.
So the overhead for programmability is higher than a DSP/GPU if you want to gain over and above them.
I do wonder if there's a sweet spot in here somewhere that's basically a sea of DSP or GPU (maybe better to call them stream processing units) with programmable wiring and some specialised ALUs/FP units mixed in that can also use the wiring allowing you to create special one-cycle fixed function ops?
Re: How FPGAs work, and why you'll buy one (2013)
#9The trouble I had with FPGAs is how radically different languages like Verilog and VHDL are when compared to languages like Java, Python, or C++. Writing code that is concurrent by default is a massive paradigm shift when all I had been exposed to at that point were procedural languages.
Try to start modeling your problem as a state machine.
Separate the combinational and the sequential part in two state machines.
The flow becomes quite similar to regular embedded system software (that can be programmed using state machine pattern as well).
Say
e.g:
state read_input =>
reg_a reg_b finish_reg finish_wire Re: How FPGAs work, and why you'll buy one (2013)
#10The trouble I had with FPGAs is how radically different languages like Verilog and VHDL are when compared to languages like Java, Python, or C++. Writing code that is concurrent by default is a massive paradigm shift when all I had been exposed to at that point were procedural languages.
That might be a barrier to entry, but it's a good thing for your growth as a programmer.