4 ms·

The 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

The 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.

aprdm 12y ago
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 <= input next_state <= multiply_input_by_10 state multiply_input_by_10 => reg_b <= reg_a * 10 next_state <= finish state send_to_output => finish_reg <= '1' and then parallel to that you would have finish_wire <= finish_reg value_wire <= reg_b or something like that, sorry for the bad example but definitely use state machines
- platz 12y ago
  Sounds like flow-based-programming or even FRP (e.g. netwire)
- alain94040 12y ago
  I started writing a (hopefully) better and clearer tutorial of what is HDL for programmers. Feel free to contribute at https://en.wikibooks.org/wiki/Programmable_Logic/Verilog_for_Software_Programmers https://en.wikibooks.org/wiki/Programmable_Logic/Verilog_for...
sliverstorm 12y ago
That might be a barrier to entry, but it's a good thing for your growth as a programmer.
blackguardx 12y ago
I think it is very important to understand that writing Verilog or VHDL isn't like writing code in a programming language. Programming languages provide instructions to a fixed state machine. With hardware description languages (HDL) you are describing the function of hardware. There are no instructions. It is hard to make good designs without understanding the underlying building blocks of hardware designs.
nulldozer 12y ago
That's because hardware description languages are not programming languages. This point was constantly emphasized in my digital systems courses. You do not describe a sequence of instructions using an HDL, you describe the layout of a circuit with registers, wires, and logic blocks. You have to consider the physics of the device to avoid violating timing constraints or driving a signal from two different sources, etc.
- elihu 12y ago
  Hardware description languages are not imperative programming languages (even if they might superficially resemble them). That doesn't mean they aren't programming languages at all -- they just belong to a different category of language. (I suspect that there's a connection between hardware design and functional programming, but I don't have enough hardware design experience to know how closely the two are related.)
  - sklogic 12y ago
    I'd rather classify HDLs as dataflow languages.
  - tel 12y ago
    Conal Elliott, Haskeller of FRP fame, was recently working for a company where he was developing a compiler of functional programming into categorical semantics which is actually quite neatly similar to the layout of a circuit. The company went under, unfortunately, so I'm not sure of the status of his research, but some remarks are available on his blog [0] [1] [2]. Further, there is a notion of a Generalized Arrow [3] which is a useful, advanced functional programming technique which is quite nice for implementing FRP. These are somewhat obviously "wiring diagrams" but are shown to be in correspondence with a more normal "lambda calculus"-like syntax. [0] http://conal.net/blog/posts/haskell-to-hardware-via-cccs http://conal.net/blog/posts/haskell-to-hardware-via-cccs [1] http://conal.net/blog/posts/overloading-lambda http://conal.net/blog/posts/overloading-lambda [2] http://conal.net/blog/posts/optimizing-cccs http://conal.net/blog/posts/optimizing-cccs [3] http://www.megacz.com/berkeley/garrows/ http://www.megacz.com/berkeley/garrows/
jamieiles 12y ago
I have mostly the same experience as a software engineer playing with FPGA's. I don't buy the argument that Verilog isn't a programming language - there are still plenty of software principles that apply to a HDL and we should take advantage of those. There are interesting differences to software - we're used to sequential software being easy and parallelizing it being hard. In a HDL, parallel is easy but sequential logic is much harder requiring state machines. Writing testable software was historically hard, but test cases cheap. It is easy to write a testable Verilog module, but fairly expensive to write test cases compared to software. Software tools are also way ahead of FPGA tools. I'm not sure how folks that develop FPGA designs professionally retain their sanity after using the tools...

aprdm 12y ago

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 <= input next_state <= multiply_input_by_10 state multiply_input_by_10 => reg_b <= reg_a * 10 next_state <= finish state send_to_output => finish_reg <= '1' and then parallel to that you would have finish_wire <= finish_reg value_wire <= reg_b or something like that, sorry for the bad example but definitely use state machines

platz 12y ago
Sounds like flow-based-programming or even FRP (e.g. netwire)
alain94040 12y ago
I started writing a (hopefully) better and clearer tutorial of what is HDL for programmers. Feel free to contribute at https://en.wikibooks.org/wiki/Programmable_Logic/Verilog_for_Software_Programmers https://en.wikibooks.org/wiki/Programmable_Logic/Verilog_for...

sliverstorm 12y ago

That might be a barrier to entry, but it's a good thing for your growth as a programmer.

blackguardx 12y ago

I think it is very important to understand that writing Verilog or VHDL isn't like writing code in a programming language. Programming languages provide instructions to a fixed state machine. With hardware description languages (HDL) you are describing the function of hardware. There are no instructions. It is hard to make good designs without understanding the underlying building blocks of hardware designs.

nulldozer 12y ago

That's because hardware description languages are not programming languages. This point was constantly emphasized in my digital systems courses. You do not describe a sequence of instructions using an HDL, you describe the layout of a circuit with registers, wires, and logic blocks. You have to consider the physics of the device to avoid violating timing constraints or driving a signal from two different sources, etc.

elihu 12y ago
Hardware description languages are not imperative programming languages (even if they might superficially resemble them). That doesn't mean they aren't programming languages at all -- they just belong to a different category of language. (I suspect that there's a connection between hardware design and functional programming, but I don't have enough hardware design experience to know how closely the two are related.)
- sklogic 12y ago
  I'd rather classify HDLs as dataflow languages.
- tel 12y ago
  Conal Elliott, Haskeller of FRP fame, was recently working for a company where he was developing a compiler of functional programming into categorical semantics which is actually quite neatly similar to the layout of a circuit. The company went under, unfortunately, so I'm not sure of the status of his research, but some remarks are available on his blog [0] [1] [2]. Further, there is a notion of a Generalized Arrow [3] which is a useful, advanced functional programming technique which is quite nice for implementing FRP. These are somewhat obviously "wiring diagrams" but are shown to be in correspondence with a more normal "lambda calculus"-like syntax. [0] http://conal.net/blog/posts/haskell-to-hardware-via-cccs http://conal.net/blog/posts/haskell-to-hardware-via-cccs [1] http://conal.net/blog/posts/overloading-lambda http://conal.net/blog/posts/overloading-lambda [2] http://conal.net/blog/posts/optimizing-cccs http://conal.net/blog/posts/optimizing-cccs [3] http://www.megacz.com/berkeley/garrows/ http://www.megacz.com/berkeley/garrows/

jamieiles 12y ago

I have mostly the same experience as a software engineer playing with FPGA's. I don't buy the argument that Verilog isn't a programming language - there are still plenty of software principles that apply to a HDL and we should take advantage of those. There are interesting differences to software - we're used to sequential software being easy and parallelizing it being hard. In a HDL, parallel is easy but sequential logic is much harder requiring state machines. Writing testable software was historically hard, but test cases cheap. It is easy to write a testable Verilog module, but fairly expensive to write test cases compared to software. Software tools are also way ahead of FPGA tools. I'm not sure how folks that develop FPGA designs professionally retain their sanity after using the tools...