<story><title>Why hardware development is hard: Verilog is weird</title><url>http://danluu.github.io/blog/2013/09/07/why-hardware-development-is-hard/</url></story><parent_chain><item><author>austinz</author><text>The problem is that Verilog&amp;#x2F;VHDL isn&amp;#x27;t a &amp;quot;programming language&amp;quot; in the sense that C, Lisp, Haskell, or Python are programming languages. So approaching them with a programming language mindset is asking for a lot of pain and misunderstanding.&lt;p&gt;HDLs like Verilog and VHDL describe digital circuits, not algorithms and instructions for manipulating data. If C code is akin to instructions for getting to a grocery store and shopping for vegetables, HDL code is describing the blueprint of a house textually. Maybe the solution is building some ultra high level abstraction that can somehow encompass both problem domains, but given how difficult hardware synthesis with existing HDLs is right now I don&amp;#x27;t know if that&amp;#x27;ll happen anytime soon. And the fact that logic takes so long to synthesize and simulate really has little to do with Verilog&amp;#x27;s deficiencies; if anything it&amp;#x27;s a limitation of the register-transfer level abstraction that&amp;#x27;s currently used to design digital hardware.</text></item></parent_chain><comment><author>jwise0</author><text>The author touches on this, when he says:&lt;p&gt;&amp;quot;To write Verilog that will produce correct hardware, you have to first picture the hardware you want to produce.&amp;quot;&lt;p&gt;I think that&amp;#x27;s the crux of the issue.  Most digital designers &lt;i&gt;do&lt;/i&gt; have a picture of the actual hardware, as a block diagram, in their heads.  When I write RTL, the process is very front-loaded: I spend hours with a pen and paper before I even sit down at the keyboard.  The algorithms in question are only a small part of the work of building functioning hardware; where when designing software, I would let the compiler make decisions about how long it expects certain operations to take, and what to inline where, these are all things that I plot &amp;quot;by hand&amp;quot; when building hardware, before I even open a text editor.&lt;p&gt;I think, then, that the author kind of misses the point when he goes on to say that &amp;quot;you have to figure out how to describe it in this weird C-like [...] language&amp;quot; -- to be honest, that&amp;#x27;s the same for all types of programming: when I go home and write C, I have to take abstract concepts and express them in this weird C-like language, too!  Arcane syntax is irritating, but is not something fundamentally &amp;#x27;hard&amp;#x27; (unless it&amp;#x27;s &lt;i&gt;too&lt;/i&gt; arcane, anyway).&lt;p&gt;By the way -- I also often wondered &amp;quot;why the hell does synthesis take so long?&amp;quot;.  I originally assumed it was because Xilinx&amp;#x27;s (and Synopsys&amp;#x27;s, and ...) software engineers were terrible and had no idea how to write efficient programs.  This might be true, but I now believe is probably not the majority of it; if &amp;quot;why&amp;#x27;s it taking so long?&amp;quot; is a question that interests you, I recommend looking into the VLSI CAD tools class on Coursera.&lt;p&gt;[1] &lt;a href=&quot;https://www.coursera.org/course/vlsicad&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.coursera.org&amp;#x2F;course&amp;#x2F;vlsicad&lt;/a&gt;</text></comment>
<story><title>Why hardware development is hard: Verilog is weird</title><url>http://danluu.github.io/blog/2013/09/07/why-hardware-development-is-hard/</url></story><parent_chain><item><author>austinz</author><text>The problem is that Verilog&amp;#x2F;VHDL isn&amp;#x27;t a &amp;quot;programming language&amp;quot; in the sense that C, Lisp, Haskell, or Python are programming languages. So approaching them with a programming language mindset is asking for a lot of pain and misunderstanding.&lt;p&gt;HDLs like Verilog and VHDL describe digital circuits, not algorithms and instructions for manipulating data. If C code is akin to instructions for getting to a grocery store and shopping for vegetables, HDL code is describing the blueprint of a house textually. Maybe the solution is building some ultra high level abstraction that can somehow encompass both problem domains, but given how difficult hardware synthesis with existing HDLs is right now I don&amp;#x27;t know if that&amp;#x27;ll happen anytime soon. And the fact that logic takes so long to synthesize and simulate really has little to do with Verilog&amp;#x27;s deficiencies; if anything it&amp;#x27;s a limitation of the register-transfer level abstraction that&amp;#x27;s currently used to design digital hardware.</text></item></parent_chain><comment><author>sliverstorm</author><text>&lt;i&gt;given how difficult hardware synthesis with existing HDLs is right now I don&amp;#x27;t know if that&amp;#x27;ll happen anytime soon&lt;/i&gt;&lt;p&gt;Synthesis sometimes feels like a great blind spot in the hierarchy of abstractions. It is hard, critical, and yet appears to be developed only by niche players.&lt;p&gt;&lt;i&gt;the fact that logic takes so long to synthesize and simulate really has little to do with Verilog&amp;#x27;s deficiencies&lt;/i&gt;&lt;p&gt;IMO it has everything to do with the open-ended nature of synthesis. When you compile software, it&amp;#x27;s very procedural. You have a linear chain or network of paths. You construct it. You improve on it where you can. Hardware on the other hand- you have a cloud described in RTL, you construct it. That&amp;#x27;s not hard. But when you get to improving it? It&amp;#x27;s like the packing problem, with N elements, and to make things better every element can be substituted with a variety of different shapes!</text></comment>