4 ms·

Would someone kindly explain what paradigms do HDL's like VHDL & Verilog fall into? Has anyone done the enumeration of these paradigms, including a study of the

Would someone kindly explain what paradigms do HDL's like VHDL & Verilog fall into? Has anyone done the enumeration of these paradigms, including a study of the deficiencies in programming caused by discouragement of unsupported paradigms? Any pointers would be highly appreciated. Thanks :)

AlphaSite 9y ago
My understanding is that traditional verily is declarative in the same sense that SQL is. Systems Verilog is that but also can be written as if it were C-like. Then the whole thing also has C++ templates bolted on as well. Its a complicated and messy language.
- perlgeek 9y ago
  It's also more of a hardware design language than a programming language, so the paradigms of classical programming languages might simply not apply all that well.
banachtarski 9y ago
Think about composing a song (an orchestral piece to be exact). You have beats and there are measures. The entire work has parts that are played by various instruments. The functions you write are melodic lines that are played by individual instruments. However, they all need to be timed in such a way that the whole thing occurs in concert with each other. HDL programming has functional elements (combinatorial logic) that are reasonably declarative in nature. Given this combination of logic bits, produce this set of logical bits as output. There is also a timing sensitive imperative portion alluded to above. This would mirror your standard C programming (routines, finite state machines) but with additional constraints that timing must be accounted for. Imagine concurrent/parallel programming but instead of mutexes, you can control the program flow at a lower level to avoid read/write hazards as appropriate. Of course, verification/testbench software helps validate that the whole thing will operate well on various pieces of hardware (and even take things like temperature into account). There is a bit of knowledge regarding the underlying transistor logic that is helpful but not mandatory (for example, it would explain what metastability is or why a floating impedance consumes more power). It's a bit much for some, but I like it from a pure hobbyist standpoint.
anewhnaccount2 9y ago
They belong to the category of synchronous programming languages. The terms synchronous dataflow, dataflow, and synchronous reactive are also variously used. See: https://en.wikipedia.org/wiki/Synchronous_programming_language https://en.wikipedia.org/wiki/Synchronous_programming_langua... . This paradigm has also been used in a embedded and real time software. The recently deceased Eve programming language combined the synchronous and relational paradigms. I think it's a neglected approach to concurrency, and I was sad to see Eve run out of money because it seemed like the first time a synchronous programming language for software and "for the masses" was being developed. If you want a detailed systematic account of programming paradigms, (without detailed study of what applications they are good and bad for I'm afraid) I would highly recommend Concepts, Techniques, and Models of Computer Programming by Roy and Haridi (this book leans towards dataflow oriented paradigms, explaining a few other paradigms using the idea).
- pgt 9y ago
  By “recently deceased Eve programming language,” are you referring to witheve.com? Where do you see it has been abandoned? Edit: Ah, found it. https://groups.google.com/forum/m/#!topic/eve-talk/YFguOGkNrBo https://groups.google.com/forum/m/#!topic/eve-talk/YFguOGkNr...
  - def- 9y ago
    https://groups.google.com/forum/#!topic/eve-talk/YFguOGkNrBo https://groups.google.com/forum/#!topic/eve-talk/YFguOGkNrBo
    - nielsbot 9y ago
      Too bad. I had high hopes for these guys... Seems like selling programming paradigms is a tough business...
      - mpweiher 9y ago
        I think one of the issues is that most sellers of "new" programming paradigms try to sell theirs as "the one". As Floyd pointed out, there's tons, and putting on my conservative hat, there is probably a reason, at least partially good, that the currently dominant paradigm became dominant. In fact, if I only had one paradigm to play with, I'd probably also want the current one, despite its limitations. So what we then do is take the current paradigm and try to conservatively extend it. That also doesn't seem to work because you can't just bolt paradigms on top of each other. So putting on my revolutionary hat, we have to blow it all up. I think the solution is generalization ("refactor to abstract superclass"): do something more general, then reproduce the dominant as well as other paradigms from within that generalization.
TuringTest 9y ago
For a more general analysis of programming paradigms, see the work of Peter Van Roy [2], which decomposes paradigms in the individual components [1] that are used or avoided in each particular paradigm. [1] https://commons.wikimedia.org/wiki/File:Programming_paradigms.svg https://commons.wikimedia.org/wiki/File:Programming_paradigm... [2] http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf

AlphaSite 9y ago

My understanding is that traditional verily is declarative in the same sense that SQL is. Systems Verilog is that but also can be written as if it were C-like. Then the whole thing also has C++ templates bolted on as well. Its a complicated and messy language.

perlgeek 9y ago
It's also more of a hardware design language than a programming language, so the paradigms of classical programming languages might simply not apply all that well.

banachtarski 9y ago

Think about composing a song (an orchestral piece to be exact). You have beats and there are measures. The entire work has parts that are played by various instruments. The functions you write are melodic lines that are played by individual instruments. However, they all need to be timed in such a way that the whole thing occurs in concert with each other. HDL programming has functional elements (combinatorial logic) that are reasonably declarative in nature. Given this combination of logic bits, produce this set of logical bits as output. There is also a timing sensitive imperative portion alluded to above. This would mirror your standard C programming (routines, finite state machines) but with additional constraints that timing must be accounted for. Imagine concurrent/parallel programming but instead of mutexes, you can control the program flow at a lower level to avoid read/write hazards as appropriate. Of course, verification/testbench software helps validate that the whole thing will operate well on various pieces of hardware (and even take things like temperature into account). There is a bit of knowledge regarding the underlying transistor logic that is helpful but not mandatory (for example, it would explain what metastability is or why a floating impedance consumes more power). It's a bit much for some, but I like it from a pure hobbyist standpoint.

anewhnaccount2 9y ago

They belong to the category of synchronous programming languages. The terms synchronous dataflow, dataflow, and synchronous reactive are also variously used. See: https://en.wikipedia.org/wiki/Synchronous_programming_language https://en.wikipedia.org/wiki/Synchronous_programming_langua... . This paradigm has also been used in a embedded and real time software. The recently deceased Eve programming language combined the synchronous and relational paradigms. I think it's a neglected approach to concurrency, and I was sad to see Eve run out of money because it seemed like the first time a synchronous programming language for software and "for the masses" was being developed. If you want a detailed systematic account of programming paradigms, (without detailed study of what applications they are good and bad for I'm afraid) I would highly recommend Concepts, Techniques, and Models of Computer Programming by Roy and Haridi (this book leans towards dataflow oriented paradigms, explaining a few other paradigms using the idea).

pgt 9y ago
By “recently deceased Eve programming language,” are you referring to witheve.com? Where do you see it has been abandoned? Edit: Ah, found it. https://groups.google.com/forum/m/#!topic/eve-talk/YFguOGkNrBo https://groups.google.com/forum/m/#!topic/eve-talk/YFguOGkNr...
- def- 9y ago
  https://groups.google.com/forum/#!topic/eve-talk/YFguOGkNrBo https://groups.google.com/forum/#!topic/eve-talk/YFguOGkNrBo
  - nielsbot 9y ago
    Too bad. I had high hopes for these guys... Seems like selling programming paradigms is a tough business...
    - mpweiher 9y ago
      I think one of the issues is that most sellers of "new" programming paradigms try to sell theirs as "the one". As Floyd pointed out, there's tons, and putting on my conservative hat, there is probably a reason, at least partially good, that the currently dominant paradigm became dominant. In fact, if I only had one paradigm to play with, I'd probably also want the current one, despite its limitations. So what we then do is take the current paradigm and try to conservatively extend it. That also doesn't seem to work because you can't just bolt paradigms on top of each other. So putting on my revolutionary hat, we have to blow it all up. I think the solution is generalization ("refactor to abstract superclass"): do something more general, then reproduce the dominant as well as other paradigms from within that generalization.

TuringTest 9y ago

For a more general analysis of programming paradigms, see the work of Peter Van Roy [2], which decomposes paradigms in the individual components [1] that are used or avoided in each particular paradigm. [1] https://commons.wikimedia.org/wiki/File:Programming_paradigms.svg https://commons.wikimedia.org/wiki/File:Programming_paradigm... [2] http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf