4 ms·
Hi, I write HDL for FPGAs in my day job. Programming an FPGA in C seems like a fundamentally bad idea to me. C is a procedural language. Most languages are pro
by rthomas6 12y ago
Hi, I write HDL for FPGAs in my day job. Programming an FPGA in C seems like a fundamentally bad idea to me.
C is a procedural language. Most languages are procedural to some degree, but C is entirely sequential. Digital hardware, unlike a C program, is entirely concurrent. When you write HDL for hardware, you're not really writing a program, you're describing the hardware layout itself. Really it's closer to making a logic gate or circuit diagram. HDL doesn't "run" like a software program. It just exists on the FPGA. That's the design, and it doesn't change once it's programmed on the chip. As such, the only "procedures" in hardware are from causality from something that happened in the past in the same hardware, either from a different part of the circuit, or the same part in a clocked design.
So what would be a good tool to describe hardware? I think (preferably immutable state) functional languages would be much closer, because they're much less procedural. You can more directly describe complex logic that takes some input, and gives some output, in a manner such that sequence of events does not matter. This would be much more powerful when mapped to an FPGA, because everything that didn't rely on a previous result could happen at the exact same time. And THAT much better utilizes the power of hardware. Implementing a long chain of sequential events on hardware is... not the smartest way to design hardware.
- theaeolist 12y agoWhy 'strict'?
- Guvante 12y agoBecause hardware is fundamentally strict, when you read a value you read it.
- theaeolist 12y agoThis is not what 'strict' really means. 'Strictness' means that a function must evaluate its argument. In terms of h/w this would mean (I guess) that a 'strict' circuit must read its inputs, which is not usually required.
- agumonkey 12y agoIs it ? aren't there differential circuits with history that won't activate the subsequent circuitry in case the read value didn't change ?
- Guvante 12y agoThe order of operations is strict, when you specify you want something you grab it. In contrast Haskells evaluation order does not match the definition order necessarily.
- rthomas6 12y agoMy thinking was that completely immutable functions map better to hardware that can't change its own design, but maybe it would be better to allow state sometimes. The problem with state is that it implies sequentialism. Registers, signals, etc. can change values, but you can't change what they do or how they're used. So you can't really have anything like self-modifying code. But I guess allowing state would make sense sometimes as long as you are mindful of what the state is dependent upon. Making lots of independent little state machines would map well to hardware I think.
- theaeolist 12y ago"Strict" and "immutable" are rather different things. Which one did you mean? None of them really are related to self-modifying code though.
- deleted 12y ago[deleted]
- rthomas6 12y agoOh, I meant immutable. Thanks for pointing that out!
- deleted 12y ago[deleted]
- agumonkey 12y agoDifferent sides of the same dice I guess. There's a chapter in SICP dealing with conversion from functional to register machines. Sure, FP maps the electronic dataflow quite nicely. But stateful imperative expression isn't that far from the hardware too. My dream : FP-ish abstrations at any layer (so called hardware would become just another interpreter for a different level of data flow)
- jesuslop 12y agoHi, I understand and agree with what you say and like the functional language suggestion perhaps augmented as in functional-reactive (a hunch), but I can't help pointing at a post from the Xilinx blog yesterday praising a workflow that leaves out HDL in favour of C++, so the world is getting more complex. "Now, although you don’t see any Verilog or VHDL in the above tool flow,..." http://forums.xilinx.com/t5/Xcell-Daily-Blog/SDSoC-development-environment-for-Zynq-SoCs-MPSoCs-says-buh-bye/ba-p/568862 http://forums.xilinx.com/t5/Xcell-Daily-Blog/SDSoC-developme... Though Zynq is ARM+FPGA, in principle one should be able to do the same with a soft processor cum custom coprocessing logic in a fpga-only thing.
- rthomas6 12y agoThat's really cool. It looks like the ARM is doing the heavy lifting, though, and is supplemented by custom hardware (likely Xilinx's many hardware IPs) that the ARM farms things out to. I'm not saying this sort of thing has no place, and I think it's awesome, but you need the ASIC processor for this to be fast. This is perfect for Zynq because of the built-in ARM. You are right that it is also possible with just an FPGA, but FPGA logic is an order of magnitude slower than ASIC. People still do this sort of thing with soft processors though. Probably a lot. The limits of this is you're not making custom IP, but rather using a library of digital logic designs provided by Xilinx. Which works well for a lot of use cases, but it's not on the same abstraction level as actually describing the hardware itself.
- jesuslop 12y agoWell said.
- gergoerdi 12y agoThere are some existing examples of using a pure functional language as an HDL; Bluespec is Haskell-like, and the Lava family of languages is embedded in Haskell. I'm just a hobbyist when it comes to HDLs, but I've had success with the latter (Kansas Lava specifically).
- kjs3 12y agoThe VHDL HDL is based on Ada. Works ok. An FP HDL is an interesting concept.
- rthomas6 12y agoVHDL is what I use at work. It does work fine, but isn't it a bit funny having to ignore/unlearn all the procedural leftovers from Ada? Synthesizable for loops are a good example. In hardware these are synthesized such that they aren't procedural and there is no loop. It's actually much more similar to a map function in FP and it happens concurrently, not iteratively.