11 ms·

Why hardware development is hard, part 1: Verilog is weird (2013)

112 points by yarapavan 10y ago

okket 10y ago
(2013) see https://danluu.com/ https://danluu.com/
petra 10y ago
If Chisel is lower level than SystemC or SystemVerilog, and those two have much more acceptance, why go with Chisel ? Aren't modern systems complex enough to justify abstraction ?
- seldridge 10y ago
  The author doesn't have this correct. Chisel is a domain specific language for hardware written in Scala that emits Verilog in Chisel2 or an intermediate representation of RTL (FRRITL) in Chisel3 which is then compiled in an LLVM-like fashion (passes that transform the FIRRTL) to Verilog. SystemVerilog has all sorts of nice object-oriented features, but you can't use any of them for synthesizable code as you're dependent on the tool vendors supporting useful, yet complex things (e.g., classes, inheritance). Chisel avoids this whole problem by giving you access to extremely useful programming features (e.g., classes, functional programming) while still maintaining compatibility with whatever your ASIC/FPGA toolflow is.
- pjc50 10y ago
  I don't think they do have much adoption. SystemVerilog is still Verilog, and most of the new functions are aimed at simulation and testbench use. SystemC is rather painful as you have to write an artificially constrained subset and style of C. > "Vendors pushing high-level synthesis have a decades long track record of overpromising and under-delivering." Abstraction is important, but in hardware detail matters. In software you can afford to have a less efficient language if it results in faster development. This is absolutely not true of hardware. High-level synthesis has usually held out misleading promises of portability; that you might be able to get some complex application working written by (cheaper, easier to hire) software developers, then just drop it straight onto a chip. That's simply not true because the constraints are different. Chisel looks extremely promising, as it addresses a lot of what I'd say were Verilog pain points: Algebraic construction and wiring Abstract data types and interfaces Bulk connections Hierarchical + object oriented + functional construction
  - tonmoy 10y ago
    SystemVerilog does seem to be used more and more. It is just verilog from the designer's perspective, but you have less chance to make mistakes, easier to write and the synthesis tool has more control over how to optimize the design.
- aninhumer 10y ago
  Chisel has a lower level model, but since it's Scala, it's a much higher level language than SystemC or SystemVerilog. Sure you have to specify things at the gate level, but you have the power to build abstractions on top of that (and indeed most of the ones other HDLs would provide are already there).
- trevortheblack 10y ago
  Chisel is fantastic. And could for a large swath of hw development replace verilog. Hell, Verilog is loaded with problems. But companies won't adopt Chisel because the tools they have now just work. So Chisel is of academic interest, and little else.
CPU_Verif 10y ago
I'll throw in my opinion for this. The author states how its routine for people to be older in the Hardware Industry. I work as a Verification engineer for a CPU project. From what I see, every company in this sector works off of years of experience. Even if you are god's gift to the world of CPU design, the career options available to your are linked to the years you have worked. I recently attended a presentation by ARM, where they boasted of this quote "At ARM, we don't really expect our graduates to be able to do anything until they're about 2 years into their careers, at which point they're expected to be decent at something" And they boasted of it! To a theater full of CS students. And this was a 35 year old line manager making the comment. If you want a career where you can rise based on merit, and not the numbers of years on your CV, don't pick hardware. I've seen it as an insider, the occasional "kid" comment being thrown around(ARM), designers refusing to work with junior verif staff(imagination tech), people who have written a project from scratch over 2 years not given tech lead roles as the project grew, etc. Such an enviroment quite often bleeds younger engineers. It saps desire and motivation. Because there are so few startups, good practices don't matter. Here's some conversations I've had: "We don't need to write tests for our software ISG, its a waste of time" "What is wrong with me writing an extension to the software as a special case? It only executes that code if the username is me" "We don't do training for new people". I routinely see younger engineers with 3-4 years of experience try and spin out of CPU/Hardware and into Software.
- GFK_of_xmaspast 10y ago
  I'm not a HW person but my interpretation of this line: "we don't really expect our graduates to be able to do anything until they're about 2 years into their careers, at which point they're expected to be decent at something" is "there is a lot of specialized knowledge that can only be gained through on-the-job experience".
  - CPU_Verif 10y ago
    In the first 2 years of work, I bounced about quite a lot within my first company, and did the following: Formal proofs and checks for a full unit. RTL design with another bloke on a block. Owner of an testing tool (developer). Owner of a testbench for top level design. Owner of process for bringing up new pieces of RTL(4 blocks, one after the other) into the top level design. All of this was caused because the startup I started in was stupidly undermanned, and there wasn't anyone else about. When I left that company, they had gone and hired about 12 people to do all of those tasks, and I saw myself handing over tasks to more senior people. I had experienced atleast 3-4 different areas of the process, and became really familiar with ARMV8 (what got me my next job). Yet this guy over here is thinking that its gonna take 2 years for someone to be even able to do 1 of those tasks? Could argue a really long time about individual cases, but I think the Hardware industry has a very big problem with arrogance. Most companies and senior people carry an air of "no one else can do what I do" kind of bs, that I experienced in SV quite a bit. They look down on junior devs thinking that they are incapable of doing anything. I asked in my office just now, the reasons for leaving their first jobs: 1. Wasn't allowed to do RTL design work inside the CPU 2. Wasn't given any responsibilities other than manually writing coverage(automating this was not permitted) 3. Ownership of the block that he had written from scratch was given to a more senior person once it came to integrating it to the top level 4. Money I find it extremely common for people(usually at the 2-3 year mark) to leave for greener pastures where they are taken in as experienced engineers, rather than useless babes. It might be a rite of passage, or it might just be the mistakes of an industry entrenched in the past
shubb 10y ago
These objections don't totally match my limited experience (not done this in a long time). When I did a lot of HDL work, I found that the main challenge was to stop thinking of hardware design like programming. This is why dynamic typing (even if it is static type inference) is a bad idea in the hardware world. Embedded software programmers want C style types because they are often flipping bits or packing data into a specified data structure so that some hardware that expects particular bytes in particular places knows where to get it. In HDL, you are fitting your logic into very limited space, and need to constantly keep in mind what hardware the code you are writing is going to synthesize to. Later, I realized that HDLs are often not really used like we'd think. Having written the logic in C or maybe Verilog, a lot of shops figure out what the actual desired hardware is and write verilog to specify that. So in verilog, rather than getting the compiler to infer a flipflop you can specify one and use verlilog to wire it up. Professional shops often basically use verilog to describe a circuit design in text, like a C programmer dropping into assembly. The thing is that, like in the 1980s, you are so much fighting to get the fastest, smallest implementation possible, that like an 80s programmer, many default to assembly - to specifying the logic elements rather than leaving it to a compiler. That means verilog as written many places is not really used like verilog at all - more like using verilog to express a netlist. Verilog is used to wrap vendor specific code so you specify a flipflop rather than a Xilinx flipflop, to make it easier to go to another vendor or to ASIC, but the clever features of verilog are only used for your test harnesses. Part of the reason for this is that FPGAs are full of specific purpose hardware like dual port memories, and the compiler won't always infer them for you. That means you need to explicitly tell it to use them - and once you are explicitly specifying some parts of your system, you tend to do it more and more.
- wolfgke 10y ago
  > Part of the reason for this is that FPGAs are full of specific purpose hardware like dual port memories, and the compiler won't always infer them for you. You can only use a HLL if you can rely on the fact that the compiler will nearly always put out much better code than you would be able to invent in a reasonable amount of time. This is the reason why even in the late 90th for performance-intensive code (games, multimedia) the critical parts were often still written in assembly instead of C/C++. The problem is for FPGAs the bitstream format is very closed - so you can hardly dive into the low-level abyss and "look at the generated assembly code/bistream" to rewrite the generated assembly code/bitstream code until you are satisfied with the result; you have to use the HLL (VHDL/Verilog), where you cannot trust the quality of the generated code.
tonmoy 10y ago
Verilog seems "hard" because people often use it in a similar fashion to a programming language, and in most cases that does not make any sense. The proper way to use it is to design the hardware, then code it up using verilog (which is trivial compared to the actual design). In fact in terms of time spent on design, the actual coding part does not take much time at all. In fact, this very article uses a motivating example that does not make any sense.
- raverbashing 10y ago
  That's like trying to say a certain "high level language" is weird because you need to first write your program in ASM them translate it to this language It makes no sense I don't want to design from the bottom up and then if I'm "lucky" the compiler will give me what I wanted.
  - deleted 10y ago
    [deleted]
  - vvanders 10y ago
    That's more like saying I expect to write highly performant software without knowing about CPU caches or the O(n) of my algorithms. These are tools meant to scale out designs that you already have a good understanding of. Hardware is implicitly bottom up because you're dealing with physics at the bottom. Very few pieces of hardware are lenient to a single cycle of latency much less 10's of milliseconds.
  - jwise0 10y ago
    Well, what you want and the physical realities of synthesis are different :-) In the early days of compilers, of course, you were mostly writing C as a macro language for your system's assembly language. If you wanted your program to perform well, you'd have to write C that was, more or less, a translation of assembly that you'd constructed in your head first. If you wrote bizarre C, you'd either get incorrect results, or if you were lucky, you'd get correct but inefficient results. But that's also Dan's point: Verilog isn't a "high level language". You don't write programs with it, you describe hardware with it. (In fact, that is why it is called a 'hardware description language'!) So if you try to write a program, instead of describing hardware, you'll get something that isn't really either.
alain94040 10y ago
Explaining Verilog to programmers is a recurring topic and the hardware community is not doing a great job at it [yet]. So feel free to contribute to this open book: https://en.wikibooks.org/wiki/Programmable_Logic/Verilog_for_Software_Programmers https://en.wikibooks.org/wiki/Programmable_Logic/Verilog_for...
- wolfgke 10y ago
  I believe I understand the ideas behind Verilog. I see the problem rather in the fact that there are few tutorials available that lead you from beginner to decent "Verilog programmer". The problem begins already in the fact which FPGA board to buy, how to setup and use the environment, what software is freely available, how much does the code depend on the specific board, how to debug the code etc. For programming there is good material for this available, but not for VHDL/Verilog.
noescape 10y ago
Is it impossible to do hardware development in C and automatically convert C to Verilog? https://en.wikipedia.org/wiki/C_to_HDL https://en.wikipedia.org/wiki/C_to_HDL What does one lose if they do this? Why isn't this conversion more common?
- blackguardx 10y ago
  To look at it another way, what does one gain? Hardware is highly parallelizable and HDLs give you that capability by default. Verilog is a really easy language to learn. The hard part is learning how to do hardware design.
  - noescape 10y ago
    One gains not needing to learn another language. I know C, I don't know Verilog or VHDL. I know how to debug C, I don't know how to debug Verilog. If I can write a working C program, why can't I make working hardware?
    - blackguardx 10y ago
      Knowing how to debug C won't help you. There is no state machine running your code. Stepping through instructions doesn't apply. Debugging HDL involves looking at timing waveforms in a simulator.
      - noescape 10y ago
        Could one write a state machine running the code? VMs do.
- GrumpyYoungMan 10y ago
  >Is it impossible to do hardware development in C and automatically convert C to Verilog? Yes, it is. C can be converted to Verilog only if you structure the C code as if it were Verilog. You have to understand that, fundamentally, the CPU is a lie. It is an illusionary abstraction layer fashioned out of bare transistors that pretends to be a von Neumann architecture machine, with a nice set of registers, a instruction pointer, and so forth that chugs dutifully through assembly language instructions, one after another. (Note that nothing about the von Neumann architecture requires binary; for example, the Babbage Analytical Engine computed in decimal.) At the transistor / gate level, _everything_ is parallel until you impose some order on it and build in clocks and flipflops and so forth to impose some sort of structure and chronological ordering on things. Few, if any, high-level languages are equipped to describe that in any sensible way. Verilog, VHDL, and so forth are not "weird". These HDLs, while not without their warts, describes the underlying reality of computing. It is assembly language and the high-level languages that are "weird". (edit: grammar fixes + clarifications)
Raed667 10y ago
We have studied VHDL in school. I can say with a fair certainty that 0% of my class uses it now in their jobs. I wouldn't ever want to touch it again with a ten foot pole.
- monocasa 10y ago
  Really? I'm one of those weird people that like VHDL more than Verilog.
  - user5994461 10y ago
    100% of my class wouldn't touch Verilog with a pole :D Guess that's a classic case of USA vs EU standards.
- kutkloon7 10y ago
  Could you elaborate on why you hate it? I like it, to be honest. Despite its inefficiencies, it feels way more robust. I don't know much about Verilog, but it feels more like a hacky scripting language than a proper engineering tool.
nom 10y ago
Isn't it more appropriate to say that Verilog is weird because of hardware? Once you go down to the lower levels you enter another realm that requires a completely different way of thinking. HW dev is not comparable to software in any way just because Verilog is a language.
jeremycw 10y ago
I remember reading Verilog HDL Synthesis: A Practical Primer by J. Bhasker in University and found it incredibly useful for learning the synthesizable subset of Verilog and all the unwritten rules of how you need to write the code to make it synthesize a certain way. I used that knowledge to write tetris in Verilog that output to VGA which after testing at the wave level in editor worked the first time I actually loaded it onto real hardware.[0] [0] https://github.com/jeremycw/tetris-verilog https://github.com/jeremycw/tetris-verilog
codebook 10y ago
Designing hardware is done by Visio and Excel not Verilog. Verilog is just an implementation. :) Added: Visio is to draw timing diagram, block diagram, and flow chart. Excel is used for designing FSM next state logic / output.
- trevortheblack 10y ago
  In my experience it's visio and Matlab. You need to prove that you can get a certain performance with a matlab algorithm, then you spend a week writing it into verilog. Oh, and as someone whose bread and butter is ICs, I go out of my way to avoid creating FSMs. They're slow, difficult to debug, and hard to pass on to your successor.
  - moftz 10y ago
    Interesting, in my digital design and microcontroller classes, they have been beating FSMs into our heads since day one. I knew there were a few projects where I knew it wasn't totally necessary to do but used a FSM to get the checkbox on the rubric but there were many designs where I had no clue how I could do it without one and without making the code highly complex.
AceJohnny2 10y ago
As a SW dev who frequently gets to interact with HW folks (embedded dev FTW), I frequently find their conservatism w.r.t. software tools puzzling. Dan Luu's explanation makes me think they're driven by trauma inflicted by their existing tools. ;) (but really, I figure they have enough trouble dealing with actual HW concerns that they don't have the bandwidth to deal with SW stuff not immediately relevant to their HW concerns.)
- Pica_soO 10y ago
  If it works, dont fix it.
- InitialLastName 10y ago
  The problems you name are true, but another issue is that errors in HW tend to be much more expensive than errors in SW. If, say, my timing analysis tool is wrong and I spin a chip based on its results, I'm out ~$100,000 and a few months of development time. That's also why we're willing to pay $thousands for licenses to proprietary SW; you want to be really confident in your tools.
  - AceJohnny2 10y ago
    Right, except the promise of better tools is a) fewer costly errors and b) faster development time. If cost and time are what you're optimizing for, they'd be a clear better choice. But they're not. So what's missing from the picture?
    - user5994461 10y ago
      > So what's missing from the picture? The hardware tooling suck. IMO: Hardware people suck at writing software so they can't make better. And software people don't want to get there so there is noone to do better.
MichaelBurge 10y ago
I remember taking a course in college on digital logic. I wanted a light to blink on and off, so I toggled it every clock. Of course that's just a dim light, because lights toggle on and off very fast normally when they're on. But how do you then explain the button on my FPGA that was not used in my Verilog anywhere that could switch the light off? I think the answer ended up being that it was switching fast enough that small amounts of leakage current was enough to register as a TRUE value. And that 'undefined behavior' is worse than in C.
- lfowles 10y ago
  There's a (decade old+) paper on using genetic algorithms to design an FPGA for discriminating tones. The final design after hundreds of generations? The input wasn't connected to the output! It relied on physical details and even iirc stopped working as the FPGA temperature rose.
  - rtkwe 10y ago
    I believe this is what you're talking about? https://www.damninteresting.com/on-the-origin-of-circuits/ https://www.damninteresting.com/on-the-origin-of-circuits/ Even funnier was that it wouldn't work on another FPGA. It was exploiting weird defects in that particular FPGA.
    - lfowles 10y ago
      Yes, that's the experiment! Here's a more thorough article: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.9691&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50....
  - milesvp 10y ago
    I've seen a similar paper quoted in one of the books on my shelf talking about a really long chain of logic gates that evolved in an FPGA for some physically situated agent (aka, robot). The chain couldn't be doing anything from a discrete logic point of view, so they got rid of it to "improve the final design". But once they did, the robot couldn't perform it's task anymore. Turned out the chain was being used as an antenna and was pumping RF information into the chip in order to help accomplish it's task. Evolution is a strange, strange thing.
eggie5 10y ago
I designed a Pipelined MIPS processor in Verily during undergrad. It was probably the hardest and most rewarding task I've completed in my life! https://github.com/eggie5/SDSU-COMPE475-SPRING13 https://github.com/eggie5/SDSU-COMPE475-SPRING13
- GrumpyYoungMan 10y ago
  HDLs and FPGAs, such luxury. In my undergraduate days, we had to design a 32-bit processor by laying out individual transistors by hand (n-wells, p-wells, polysilicon gates, and metallization layers) in a 25 micron CMOS process with two metallization layers in very little chip area and then prove that it worked in simulation. It was like Tetris from hell; I'm still proud of the compact barrel shifter design I came up with. We also had the option, which I will forever regret not taking, to have the chip physically fabbed as well, as long as we agreed to do the work to validate it afterward.
  - eggie5 10y ago
    haha, respect.
mars4rp 10y ago
oh Verilog is so pretty, I missed coding it so badly, compare to VHDL it is very easy and has less bug, try nested without else in VHDL !
guard-of-terra 10y ago
Seems like a lousy industry to be in. Lower wages, lower expectations, shooting themself in the foot. Seems that unlike software devs, hardware devs don't have a say, they're merely drones to their managers. In software, lead dev will say that they need this linter, and his superior will have to either provide or argue. But it seems that ib hardware, management will just say "no", end of storg. You're not getting anywhere with this attitude. This can also be so in software dev - in defunct bigcos.
- trevortheblack 10y ago
  It all comes down to the cost. Software can be rewritten and then can be patched with the new functinoality. In hardware, typically, your customer is another group, department, company. And there is usually only one person to represent the go-between. Hardware design is conservative because that one person is responsible for interfacing a project which simply cannot afford to be done incorrectly. so low bandwidth, and high cost. Leads to unbridled conservatism.
- user5994461 10y ago
  > lower expectations I can live with not having to do 60 hours work weeks for tech companies that didn't even give equity.
  - guard-of-terra 10y ago
    Frankly, I'm in software dev and I've never worked more than 45 hours/week.
garbage_stain 10y ago
Verilog has many drawbacks, including no support for structured signals. On the other hand, the other big language, VHDL, is really difficult to use for "modular" projects. Is anyone here familiar with CHDL, a C++ hardware design language? https://github.com/cdkersey/chdl https://github.com/cdkersey/chdl Being a fan of C++ myself, the idea of using template metaprogramming to represent hardware designs is something that I think is very cool.

112 points by yarapavan 10y ago

okket 10y ago

(2013) see https://danluu.com/ https://danluu.com/

petra 10y ago

If Chisel is lower level than SystemC or SystemVerilog, and those two have much more acceptance, why go with Chisel ? Aren't modern systems complex enough to justify abstraction ?

seldridge 10y ago
The author doesn't have this correct. Chisel is a domain specific language for hardware written in Scala that emits Verilog in Chisel2 or an intermediate representation of RTL (FRRITL) in Chisel3 which is then compiled in an LLVM-like fashion (passes that transform the FIRRTL) to Verilog. SystemVerilog has all sorts of nice object-oriented features, but you can't use any of them for synthesizable code as you're dependent on the tool vendors supporting useful, yet complex things (e.g., classes, inheritance). Chisel avoids this whole problem by giving you access to extremely useful programming features (e.g., classes, functional programming) while still maintaining compatibility with whatever your ASIC/FPGA toolflow is.
pjc50 10y ago
I don't think they do have much adoption. SystemVerilog is still Verilog, and most of the new functions are aimed at simulation and testbench use. SystemC is rather painful as you have to write an artificially constrained subset and style of C. > "Vendors pushing high-level synthesis have a decades long track record of overpromising and under-delivering." Abstraction is important, but in hardware detail matters. In software you can afford to have a less efficient language if it results in faster development. This is absolutely not true of hardware. High-level synthesis has usually held out misleading promises of portability; that you might be able to get some complex application working written by (cheaper, easier to hire) software developers, then just drop it straight onto a chip. That's simply not true because the constraints are different. Chisel looks extremely promising, as it addresses a lot of what I'd say were Verilog pain points: Algebraic construction and wiring Abstract data types and interfaces Bulk connections Hierarchical + object oriented + functional construction
- tonmoy 10y ago
  SystemVerilog does seem to be used more and more. It is just verilog from the designer's perspective, but you have less chance to make mistakes, easier to write and the synthesis tool has more control over how to optimize the design.
aninhumer 10y ago
Chisel has a lower level model, but since it's Scala, it's a much higher level language than SystemC or SystemVerilog. Sure you have to specify things at the gate level, but you have the power to build abstractions on top of that (and indeed most of the ones other HDLs would provide are already there).
trevortheblack 10y ago
Chisel is fantastic. And could for a large swath of hw development replace verilog. Hell, Verilog is loaded with problems. But companies won't adopt Chisel because the tools they have now just work. So Chisel is of academic interest, and little else.

CPU_Verif 10y ago

I'll throw in my opinion for this. The author states how its routine for people to be older in the Hardware Industry. I work as a Verification engineer for a CPU project. From what I see, every company in this sector works off of years of experience. Even if you are god's gift to the world of CPU design, the career options available to your are linked to the years you have worked. I recently attended a presentation by ARM, where they boasted of this quote "At ARM, we don't really expect our graduates to be able to do anything until they're about 2 years into their careers, at which point they're expected to be decent at something" And they boasted of it! To a theater full of CS students. And this was a 35 year old line manager making the comment. If you want a career where you can rise based on merit, and not the numbers of years on your CV, don't pick hardware. I've seen it as an insider, the occasional "kid" comment being thrown around(ARM), designers refusing to work with junior verif staff(imagination tech), people who have written a project from scratch over 2 years not given tech lead roles as the project grew, etc. Such an enviroment quite often bleeds younger engineers. It saps desire and motivation. Because there are so few startups, good practices don't matter. Here's some conversations I've had: "We don't need to write tests for our software ISG, its a waste of time" "What is wrong with me writing an extension to the software as a special case? It only executes that code if the username is me" "We don't do training for new people". I routinely see younger engineers with 3-4 years of experience try and spin out of CPU/Hardware and into Software.

GFK_of_xmaspast 10y ago
I'm not a HW person but my interpretation of this line: "we don't really expect our graduates to be able to do anything until they're about 2 years into their careers, at which point they're expected to be decent at something" is "there is a lot of specialized knowledge that can only be gained through on-the-job experience".
- CPU_Verif 10y ago
  In the first 2 years of work, I bounced about quite a lot within my first company, and did the following: Formal proofs and checks for a full unit. RTL design with another bloke on a block. Owner of an testing tool (developer). Owner of a testbench for top level design. Owner of process for bringing up new pieces of RTL(4 blocks, one after the other) into the top level design. All of this was caused because the startup I started in was stupidly undermanned, and there wasn't anyone else about. When I left that company, they had gone and hired about 12 people to do all of those tasks, and I saw myself handing over tasks to more senior people. I had experienced atleast 3-4 different areas of the process, and became really familiar with ARMV8 (what got me my next job). Yet this guy over here is thinking that its gonna take 2 years for someone to be even able to do 1 of those tasks? Could argue a really long time about individual cases, but I think the Hardware industry has a very big problem with arrogance. Most companies and senior people carry an air of "no one else can do what I do" kind of bs, that I experienced in SV quite a bit. They look down on junior devs thinking that they are incapable of doing anything. I asked in my office just now, the reasons for leaving their first jobs: 1. Wasn't allowed to do RTL design work inside the CPU 2. Wasn't given any responsibilities other than manually writing coverage(automating this was not permitted) 3. Ownership of the block that he had written from scratch was given to a more senior person once it came to integrating it to the top level 4. Money I find it extremely common for people(usually at the 2-3 year mark) to leave for greener pastures where they are taken in as experienced engineers, rather than useless babes. It might be a rite of passage, or it might just be the mistakes of an industry entrenched in the past

shubb 10y ago

These objections don't totally match my limited experience (not done this in a long time). When I did a lot of HDL work, I found that the main challenge was to stop thinking of hardware design like programming. This is why dynamic typing (even if it is static type inference) is a bad idea in the hardware world. Embedded software programmers want C style types because they are often flipping bits or packing data into a specified data structure so that some hardware that expects particular bytes in particular places knows where to get it. In HDL, you are fitting your logic into very limited space, and need to constantly keep in mind what hardware the code you are writing is going to synthesize to. Later, I realized that HDLs are often not really used like we'd think. Having written the logic in C or maybe Verilog, a lot of shops figure out what the actual desired hardware is and write verilog to specify that. So in verilog, rather than getting the compiler to infer a flipflop you can specify one and use verlilog to wire it up. Professional shops often basically use verilog to describe a circuit design in text, like a C programmer dropping into assembly. The thing is that, like in the 1980s, you are so much fighting to get the fastest, smallest implementation possible, that like an 80s programmer, many default to assembly - to specifying the logic elements rather than leaving it to a compiler. That means verilog as written many places is not really used like verilog at all - more like using verilog to express a netlist. Verilog is used to wrap vendor specific code so you specify a flipflop rather than a Xilinx flipflop, to make it easier to go to another vendor or to ASIC, but the clever features of verilog are only used for your test harnesses. Part of the reason for this is that FPGAs are full of specific purpose hardware like dual port memories, and the compiler won't always infer them for you. That means you need to explicitly tell it to use them - and once you are explicitly specifying some parts of your system, you tend to do it more and more.

wolfgke 10y ago
> Part of the reason for this is that FPGAs are full of specific purpose hardware like dual port memories, and the compiler won't always infer them for you. You can only use a HLL if you can rely on the fact that the compiler will nearly always put out much better code than you would be able to invent in a reasonable amount of time. This is the reason why even in the late 90th for performance-intensive code (games, multimedia) the critical parts were often still written in assembly instead of C/C++. The problem is for FPGAs the bitstream format is very closed - so you can hardly dive into the low-level abyss and "look at the generated assembly code/bistream" to rewrite the generated assembly code/bitstream code until you are satisfied with the result; you have to use the HLL (VHDL/Verilog), where you cannot trust the quality of the generated code.

tonmoy 10y ago

Verilog seems "hard" because people often use it in a similar fashion to a programming language, and in most cases that does not make any sense. The proper way to use it is to design the hardware, then code it up using verilog (which is trivial compared to the actual design). In fact in terms of time spent on design, the actual coding part does not take much time at all. In fact, this very article uses a motivating example that does not make any sense.

raverbashing 10y ago
That's like trying to say a certain "high level language" is weird because you need to first write your program in ASM them translate it to this language It makes no sense I don't want to design from the bottom up and then if I'm "lucky" the compiler will give me what I wanted.
- deleted 10y ago
  [deleted]
- vvanders 10y ago
  That's more like saying I expect to write highly performant software without knowing about CPU caches or the O(n) of my algorithms. These are tools meant to scale out designs that you already have a good understanding of. Hardware is implicitly bottom up because you're dealing with physics at the bottom. Very few pieces of hardware are lenient to a single cycle of latency much less 10's of milliseconds.
- jwise0 10y ago
  Well, what you want and the physical realities of synthesis are different :-) In the early days of compilers, of course, you were mostly writing C as a macro language for your system's assembly language. If you wanted your program to perform well, you'd have to write C that was, more or less, a translation of assembly that you'd constructed in your head first. If you wrote bizarre C, you'd either get incorrect results, or if you were lucky, you'd get correct but inefficient results. But that's also Dan's point: Verilog isn't a "high level language". You don't write programs with it, you describe hardware with it. (In fact, that is why it is called a 'hardware description language'!) So if you try to write a program, instead of describing hardware, you'll get something that isn't really either.

alain94040 10y ago

Explaining Verilog to programmers is a recurring topic and the hardware community is not doing a great job at it [yet]. So feel free to contribute to this open book: https://en.wikibooks.org/wiki/Programmable_Logic/Verilog_for_Software_Programmers https://en.wikibooks.org/wiki/Programmable_Logic/Verilog_for...

wolfgke 10y ago
I believe I understand the ideas behind Verilog. I see the problem rather in the fact that there are few tutorials available that lead you from beginner to decent "Verilog programmer". The problem begins already in the fact which FPGA board to buy, how to setup and use the environment, what software is freely available, how much does the code depend on the specific board, how to debug the code etc. For programming there is good material for this available, but not for VHDL/Verilog.

noescape 10y ago

Is it impossible to do hardware development in C and automatically convert C to Verilog? https://en.wikipedia.org/wiki/C_to_HDL https://en.wikipedia.org/wiki/C_to_HDL What does one lose if they do this? Why isn't this conversion more common?

blackguardx 10y ago
To look at it another way, what does one gain? Hardware is highly parallelizable and HDLs give you that capability by default. Verilog is a really easy language to learn. The hard part is learning how to do hardware design.
- noescape 10y ago
  One gains not needing to learn another language. I know C, I don't know Verilog or VHDL. I know how to debug C, I don't know how to debug Verilog. If I can write a working C program, why can't I make working hardware?
  - blackguardx 10y ago
    Knowing how to debug C won't help you. There is no state machine running your code. Stepping through instructions doesn't apply. Debugging HDL involves looking at timing waveforms in a simulator.
    - noescape 10y ago
      Could one write a state machine running the code? VMs do.
GrumpyYoungMan 10y ago
>Is it impossible to do hardware development in C and automatically convert C to Verilog? Yes, it is. C can be converted to Verilog only if you structure the C code as if it were Verilog. You have to understand that, fundamentally, the CPU is a lie. It is an illusionary abstraction layer fashioned out of bare transistors that pretends to be a von Neumann architecture machine, with a nice set of registers, a instruction pointer, and so forth that chugs dutifully through assembly language instructions, one after another. (Note that nothing about the von Neumann architecture requires binary; for example, the Babbage Analytical Engine computed in decimal.) At the transistor / gate level, _everything_ is parallel until you impose some order on it and build in clocks and flipflops and so forth to impose some sort of structure and chronological ordering on things. Few, if any, high-level languages are equipped to describe that in any sensible way. Verilog, VHDL, and so forth are not "weird". These HDLs, while not without their warts, describes the underlying reality of computing. It is assembly language and the high-level languages that are "weird". (edit: grammar fixes + clarifications)

Raed667 10y ago

We have studied VHDL in school. I can say with a fair certainty that 0% of my class uses it now in their jobs. I wouldn't ever want to touch it again with a ten foot pole.

monocasa 10y ago
Really? I'm one of those weird people that like VHDL more than Verilog.
- user5994461 10y ago
  100% of my class wouldn't touch Verilog with a pole :D Guess that's a classic case of USA vs EU standards.
kutkloon7 10y ago
Could you elaborate on why you hate it? I like it, to be honest. Despite its inefficiencies, it feels way more robust. I don't know much about Verilog, but it feels more like a hacky scripting language than a proper engineering tool.

nom 10y ago

Isn't it more appropriate to say that Verilog is weird because of hardware? Once you go down to the lower levels you enter another realm that requires a completely different way of thinking. HW dev is not comparable to software in any way just because Verilog is a language.

jeremycw 10y ago

I remember reading Verilog HDL Synthesis: A Practical Primer by J. Bhasker in University and found it incredibly useful for learning the synthesizable subset of Verilog and all the unwritten rules of how you need to write the code to make it synthesize a certain way. I used that knowledge to write tetris in Verilog that output to VGA which after testing at the wave level in editor worked the first time I actually loaded it onto real hardware.[0] [0] https://github.com/jeremycw/tetris-verilog https://github.com/jeremycw/tetris-verilog

codebook 10y ago

Designing hardware is done by Visio and Excel not Verilog. Verilog is just an implementation. :) Added: Visio is to draw timing diagram, block diagram, and flow chart. Excel is used for designing FSM next state logic / output.

trevortheblack 10y ago
In my experience it's visio and Matlab. You need to prove that you can get a certain performance with a matlab algorithm, then you spend a week writing it into verilog. Oh, and as someone whose bread and butter is ICs, I go out of my way to avoid creating FSMs. They're slow, difficult to debug, and hard to pass on to your successor.
- moftz 10y ago
  Interesting, in my digital design and microcontroller classes, they have been beating FSMs into our heads since day one. I knew there were a few projects where I knew it wasn't totally necessary to do but used a FSM to get the checkbox on the rubric but there were many designs where I had no clue how I could do it without one and without making the code highly complex.

AceJohnny2 10y ago

As a SW dev who frequently gets to interact with HW folks (embedded dev FTW), I frequently find their conservatism w.r.t. software tools puzzling. Dan Luu's explanation makes me think they're driven by trauma inflicted by their existing tools. ;) (but really, I figure they have enough trouble dealing with actual HW concerns that they don't have the bandwidth to deal with SW stuff not immediately relevant to their HW concerns.)

Pica_soO 10y ago
If it works, dont fix it.
InitialLastName 10y ago
The problems you name are true, but another issue is that errors in HW tend to be much more expensive than errors in SW. If, say, my timing analysis tool is wrong and I spin a chip based on its results, I'm out ~$100,000 and a few months of development time. That's also why we're willing to pay $thousands for licenses to proprietary SW; you want to be really confident in your tools.
- AceJohnny2 10y ago
  Right, except the promise of better tools is a) fewer costly errors and b) faster development time. If cost and time are what you're optimizing for, they'd be a clear better choice. But they're not. So what's missing from the picture?
  - user5994461 10y ago
    > So what's missing from the picture? The hardware tooling suck. IMO: Hardware people suck at writing software so they can't make better. And software people don't want to get there so there is noone to do better.

MichaelBurge 10y ago

I remember taking a course in college on digital logic. I wanted a light to blink on and off, so I toggled it every clock. Of course that's just a dim light, because lights toggle on and off very fast normally when they're on. But how do you then explain the button on my FPGA that was not used in my Verilog anywhere that could switch the light off? I think the answer ended up being that it was switching fast enough that small amounts of leakage current was enough to register as a TRUE value. And that 'undefined behavior' is worse than in C.

lfowles 10y ago
There's a (decade old+) paper on using genetic algorithms to design an FPGA for discriminating tones. The final design after hundreds of generations? The input wasn't connected to the output! It relied on physical details and even iirc stopped working as the FPGA temperature rose.
- rtkwe 10y ago
  I believe this is what you're talking about? https://www.damninteresting.com/on-the-origin-of-circuits/ https://www.damninteresting.com/on-the-origin-of-circuits/ Even funnier was that it wouldn't work on another FPGA. It was exploiting weird defects in that particular FPGA.
  - lfowles 10y ago
    Yes, that's the experiment! Here's a more thorough article: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.9691&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50....
- milesvp 10y ago
  I've seen a similar paper quoted in one of the books on my shelf talking about a really long chain of logic gates that evolved in an FPGA for some physically situated agent (aka, robot). The chain couldn't be doing anything from a discrete logic point of view, so they got rid of it to "improve the final design". But once they did, the robot couldn't perform it's task anymore. Turned out the chain was being used as an antenna and was pumping RF information into the chip in order to help accomplish it's task. Evolution is a strange, strange thing.

eggie5 10y ago

I designed a Pipelined MIPS processor in Verily during undergrad. It was probably the hardest and most rewarding task I've completed in my life! https://github.com/eggie5/SDSU-COMPE475-SPRING13 https://github.com/eggie5/SDSU-COMPE475-SPRING13

GrumpyYoungMan 10y ago
HDLs and FPGAs, such luxury. In my undergraduate days, we had to design a 32-bit processor by laying out individual transistors by hand (n-wells, p-wells, polysilicon gates, and metallization layers) in a 25 micron CMOS process with two metallization layers in very little chip area and then prove that it worked in simulation. It was like Tetris from hell; I'm still proud of the compact barrel shifter design I came up with. We also had the option, which I will forever regret not taking, to have the chip physically fabbed as well, as long as we agreed to do the work to validate it afterward.
- eggie5 10y ago
  haha, respect.

mars4rp 10y ago

oh Verilog is so pretty, I missed coding it so badly, compare to VHDL it is very easy and has less bug, try nested without else in VHDL !

guard-of-terra 10y ago

Seems like a lousy industry to be in. Lower wages, lower expectations, shooting themself in the foot. Seems that unlike software devs, hardware devs don't have a say, they're merely drones to their managers. In software, lead dev will say that they need this linter, and his superior will have to either provide or argue. But it seems that ib hardware, management will just say "no", end of storg. You're not getting anywhere with this attitude. This can also be so in software dev - in defunct bigcos.

trevortheblack 10y ago
It all comes down to the cost. Software can be rewritten and then can be patched with the new functinoality. In hardware, typically, your customer is another group, department, company. And there is usually only one person to represent the go-between. Hardware design is conservative because that one person is responsible for interfacing a project which simply cannot afford to be done incorrectly. so low bandwidth, and high cost. Leads to unbridled conservatism.
user5994461 10y ago
> lower expectations I can live with not having to do 60 hours work weeks for tech companies that didn't even give equity.
- guard-of-terra 10y ago
  Frankly, I'm in software dev and I've never worked more than 45 hours/week.

garbage_stain 10y ago

Verilog has many drawbacks, including no support for structured signals. On the other hand, the other big language, VHDL, is really difficult to use for "modular" projects. Is anyone here familiar with CHDL, a C++ hardware design language? https://github.com/cdkersey/chdl https://github.com/cdkersey/chdl Being a fan of C++ myself, the idea of using template metaprogramming to represent hardware designs is something that I think is very cool.