5 ms·

> While this may look like code in a normal programming language, it operates entirely differently. So happy to see this called out up-front. One of the hardes

> While this may look like code in a normal programming language, it operates entirely differently. So happy to see this called out up-front. One of the hardest things with FPGAs as a developer is understanding that you're reconfiguring hardware instead of a series of serial asm/opcodes. They look superficially the same but have very different requirements and constraints under the hood.

katastic 9y ago
Think of it more like SQL, where you're describing a model, then a series of steps.
- nickpsecurity 9y ago
  Maybe more like dataflow or flow-based programming. Let them play with those a while. Then, make the black boxes FSM's with serious constraints about size or execution time. They'll start getting the idea. Messing with a synchronous or time-oriented language might help, too, in terms of a metaphor for clocks.
pjmlp 9y ago
It depends very much where we as developers come from. My CS degree had quite a few sections of electronic lectures. In fact, one way I always looked at function composition in FP languages was to think of them as digital circuit modules.
- vvanders 9y ago
  That's still an impartial model because each layer of abstraction can introduce path delay and resource usage. Functional programming doesn't encapsulate interfacing across different clock domains or one hot vs binary state representation. Trying to bring those abstraction models to HDL you'll find a significant impedance mismatch.
  - pjmlp 9y ago
    True, still it is easier than trying to think in imperative programming when doing FPGA programming. There are quite a few books using LP and FP for modelling of digital circuits. You can also introduce signal propagation modeling on them.
    - vvanders 9y ago
      I think you're missing my point ;). You shouldn't be trying to think in imperative or functional programming because fundamentally FPGAs/HDL isn't programming. You should be thinking in terms of state machines, pipelines, routing, delay & setup+hold constraints. HDLs are just a high-powered blueprint languages. At the end of the day you're still just laying out physical blocks.
      - pjmlp 9y ago
        And you missed mine, as I mentioned that we had electronic lectures. I am not talking out of thin air and wild guesses how things should be, rather about my personal experience how we learned digital circuit design and how later, already with that skill, we applied the ideas to FP. That was the goal of my initial comment, Hardware Design Ideas -> Help understating FP function combinations as if they were ICs, not how to design hardware from FP concepts.
        vvanders 9y ago
        Didn't miss it, just don't think they're equivalent. I appreciate functional programming and block diagrams/black box design are great tools for that space. However they don't capture the nuance of circuit design that goes into FPGA development. You can't capture pipeline depth, SRAM usage, thermal envelope/clock gating that have significant real world impacts on your design.
        deleted 9y ago
        [deleted]
      - 9y ago
- FPGAhacker 9y ago
  I think there are many parallels between functional programs and electronic circuits. Many design concepts and disciplines of software can be applied to digital design. The idea of actors and message passing very naturally applies itself to digital design. Combinational logic is functional as long as you keep feedback loops out of it. For a given input, you will always get a particular output. Eventually. Time is a factor. Unlike software, this bit of functional logic is "on" or "active" all the time though. At any given moment, there is something at the input and something at the output. It's like a pair of sunglasses. They are always sunglassing, light is going through them and being filtered, whether you are using them or not. Adding state is necessary for anything but the most trivial designs. And like software, state makes things more complicated. We call the logic that implements state "sequential" logic. By that token, instead of Combinational, we could call it Concurrent logic. Actors could be a logical grouping of combinational and sequential logic. Pure functions and state. With ports for messaging.
xelxebar 9y ago
> under the hood Surely, we don't have to work with raw quantum electrodynamics when designing an FPGA, even though that's what's going on "under the hood". Thinking that way, gets me wondering about different layers of abstraction along with the benefits and drawbacks of each. With FPGA programming, what levels of abstraction are available and what simplifying assumptions does each model make? I've got in mind things like Kirchhoff's laws, where we assume perfectly conducting wires, discrete elements, a conservative ambient B field, and essentially DC current over the size of circuit elements. When those assumptions start breaking down, then we can drop down a layer of abstraction.
- vvanders 9y ago
  I think most HDLs are approaching the diminishing returns of abstraction already. Most of the electrical characteristics are already captured in routing, setup and hold times so while you may not directly interact with them anything more than the most trivial design will be constrained by them. By "under the hood" I was referring to the constraints you have on what you design. In the software space we are mostly constrained by memory(huge), network speed(blazing fast), CPU time(tasks running long normally don't break things). In FPGA/ASIC land those constraints are much, much smaller(kB vs gB) and there are many more(thermals, power, hard cycle requirements, etc).
  - slededit 9y ago
    > I think most HDLs are approaching the diminishing returns of abstraction already. System Verilog goes a lot of the way, but there are many good abstractions missing in HDL. Structs were my biggest complaint before System Verilog.
- FPGAhacker 9y ago
  Don’t know why you are downvoted right now. A major abstraction, absolutely huge, is “Digital.” It’s all analog, and outside of the sanitizing Digital abstraction, it’s not pretty. But the digital abstraction allowed for astronomically complex designs to be implemented.
- simcop2387 9y ago

katastic 9y ago

Think of it more like SQL, where you're describing a model, then a series of steps.

nickpsecurity 9y ago
Maybe more like dataflow or flow-based programming. Let them play with those a while. Then, make the black boxes FSM's with serious constraints about size or execution time. They'll start getting the idea. Messing with a synchronous or time-oriented language might help, too, in terms of a metaphor for clocks.

pjmlp 9y ago

It depends very much where we as developers come from. My CS degree had quite a few sections of electronic lectures. In fact, one way I always looked at function composition in FP languages was to think of them as digital circuit modules.

vvanders 9y ago
That's still an impartial model because each layer of abstraction can introduce path delay and resource usage. Functional programming doesn't encapsulate interfacing across different clock domains or one hot vs binary state representation. Trying to bring those abstraction models to HDL you'll find a significant impedance mismatch.
- pjmlp 9y ago
  True, still it is easier than trying to think in imperative programming when doing FPGA programming. There are quite a few books using LP and FP for modelling of digital circuits. You can also introduce signal propagation modeling on them.
  - vvanders 9y ago
    I think you're missing my point ;). You shouldn't be trying to think in imperative or functional programming because fundamentally FPGAs/HDL isn't programming. You should be thinking in terms of state machines, pipelines, routing, delay & setup+hold constraints. HDLs are just a high-powered blueprint languages. At the end of the day you're still just laying out physical blocks.
    - pjmlp 9y ago
      And you missed mine, as I mentioned that we had electronic lectures. I am not talking out of thin air and wild guesses how things should be, rather about my personal experience how we learned digital circuit design and how later, already with that skill, we applied the ideas to FP. That was the goal of my initial comment, Hardware Design Ideas -> Help understating FP function combinations as if they were ICs, not how to design hardware from FP concepts.
      - vvanders 9y ago
        Didn't miss it, just don't think they're equivalent. I appreciate functional programming and block diagrams/black box design are great tools for that space. However they don't capture the nuance of circuit design that goes into FPGA development. You can't capture pipeline depth, SRAM usage, thermal envelope/clock gating that have significant real world impacts on your design.
        deleted 9y ago
        [deleted]
    - 9y ago
FPGAhacker 9y ago
I think there are many parallels between functional programs and electronic circuits. Many design concepts and disciplines of software can be applied to digital design. The idea of actors and message passing very naturally applies itself to digital design. Combinational logic is functional as long as you keep feedback loops out of it. For a given input, you will always get a particular output. Eventually. Time is a factor. Unlike software, this bit of functional logic is "on" or "active" all the time though. At any given moment, there is something at the input and something at the output. It's like a pair of sunglasses. They are always sunglassing, light is going through them and being filtered, whether you are using them or not. Adding state is necessary for anything but the most trivial designs. And like software, state makes things more complicated. We call the logic that implements state "sequential" logic. By that token, instead of Combinational, we could call it Concurrent logic. Actors could be a logical grouping of combinational and sequential logic. Pure functions and state. With ports for messaging.

xelxebar 9y ago

> under the hood Surely, we don't have to work with raw quantum electrodynamics when designing an FPGA, even though that's what's going on "under the hood". Thinking that way, gets me wondering about different layers of abstraction along with the benefits and drawbacks of each. With FPGA programming, what levels of abstraction are available and what simplifying assumptions does each model make? I've got in mind things like Kirchhoff's laws, where we assume perfectly conducting wires, discrete elements, a conservative ambient B field, and essentially DC current over the size of circuit elements. When those assumptions start breaking down, then we can drop down a layer of abstraction.

vvanders 9y ago
I think most HDLs are approaching the diminishing returns of abstraction already. Most of the electrical characteristics are already captured in routing, setup and hold times so while you may not directly interact with them anything more than the most trivial design will be constrained by them. By "under the hood" I was referring to the constraints you have on what you design. In the software space we are mostly constrained by memory(huge), network speed(blazing fast), CPU time(tasks running long normally don't break things). In FPGA/ASIC land those constraints are much, much smaller(kB vs gB) and there are many more(thermals, power, hard cycle requirements, etc).
- slededit 9y ago
  > I think most HDLs are approaching the diminishing returns of abstraction already. System Verilog goes a lot of the way, but there are many good abstractions missing in HDL. Structs were my biggest complaint before System Verilog.
FPGAhacker 9y ago
Don’t know why you are downvoted right now. A major abstraction, absolutely huge, is “Digital.” It’s all analog, and outside of the sanitizing Digital abstraction, it’s not pretty. But the digital abstraction allowed for astronomically complex designs to be implemented.
simcop2387 9y ago