7 ms·

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

by 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.
  - raverbashing 10y ago
    > 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. Maybe in really old compilers > You don't write programs with it, you describe hardware with it Which is fair enough, but it seems the "hardware description" pretends to be of a higher-level than it really is. If you need the user to describe gates and flip-flops and how they connect then make them describe this.
    - vvanders 10y ago
      > If you need the user to describe gates and flip-flops and how they connect then make them describe this. You're talking about RTL, which is exactly what these languages output. Fundamentally they're not programming languages, unfortunately the initial instinct is to treat them as such and it leads to a ton of confusion.
      - wolfgke 10y ago
        > You're talking about RTL, which is exactly what these languages output. If VHDL/Verilog would output RTL, you could easily analyze it just as you analyze assembly output of your favorite compiler. Unluckily the output is some proprietary bitstream for the FPGA.
        vvanders 10y ago
        It's been a while since I poked around in RTL but last time I was working with FPGAs it was possible to inspect RTL and view the synthesis results.
        k0ngo 10y ago
        Just as a software compilation flow is devided into preprocessing, compilation, assembly, and linking, a HDL flow is divided into synthesis, mapping, place and route, timing analysis and bitstream generation. RTL is the output of the synthesis stage and is readily available to the designer, typically both as code and as a graphical schematic.
- moftz 10y ago
  A lot of times, you can get access to IP blocks. You can view a reference design of what the module does but the actual code is a binary blob owned by the chip manufacturer. You can treat these as functions and build larger designs from them. It's great because you don't have to write really low-level stuff like RTL except for hooking up the different modules. You can then do some more complex combinational logic using always blocks that kind of look like C. It's not super high level like C++ or python but you can get some higher levels of abstraction. Some IDEs have a visual way to write the code using schematics. You connect the logic modules together using wires. It makes HDL a bit easier to understand what's happening but you need to compartmentalize your code as much as possible, essentially making everything a function.
blackguardx 10y ago
I can't upvote this enough. It is imperative to make at least a block diagram before you start typing. Making some timing diagrams for critical sections will save even more headache.
- aninhumer 10y ago
  I feel like this is kind of like saying people shouldn't write imperative software until they've drawn a flowchart for all the logic. Sure there are some cases where it might be a good idea, but if it's a requirement to understand the design, then your language isn't doing its job.
  - theyoungestgun 10y ago
    Psst . . . verilog (not saying the same for systemVerilog) isn't doing its job ;)
  - deleted 10y ago
    [deleted]
  - blackguardx 10y ago
    Drawing a timing diagram is the same as thinking about how a CPU will execute instructions that you write or your compiler spits out. Optimization is important in hardware due to cost, speed, and power implications of hardware design. These tradeoffs are there for software design as well, but to a much less extent.
  - akiselev 10y ago
    It's not the same thing at all. Since modern processors abstract over the physical location/layout of memory, code at any location can access data or call code at any other location. This allows you to just jump in and write your logic without worrying about how the silicon physically moves your bits around. You simply can't do that when designing silicon. All of your transistors have to be physically connected on a 2d plane so you can't abstract over the physical location or layout of your "objects" (logical groups of transistors and how they interconnect in this case). This means that the vast majority of possible Verilog designs are impossible to physically implement because there is only a finite amount of space to route traces from one transistor to another. Writing Verilog before drawing a block diagram is like writing an embedded IoT framework in Ruby before checking whether your target microcontrollers have enough ROM/RAM to run the Ruby interpreter. For example, if you had a stack allocated object containing a queue and you changed it to always heap allocate the queue, it would still do the same thing as before but with a different memory layout. If you did the equivalent in silicon (like move the location of a group of transistors), at best it would break your functionality and at worst it would make the design unsynthesizable. Swapping an interface to point to an implementation with a different size (I.e. switching an IQueue* to an MPSC Queue from a SPSC Queue) is a trivial change with software but when you swap a 100 transistor interface with a 1000 transistor one you have to move the blocks around it, often requiring significant changes to avoid breaking functionality.
mindslight 10y ago
Having done some Verilog professionally, this is my initial reaction too. It is quality advice for anyone needing to use Verilog. Yet if I put on my software cap and think of how things should be, the whole point of a language is to create an abstraction. This allows a designer to think and express their intent at a higher level. If an abstraction is not complete then the designer can never stop thinking in the lower level terms, which nullifies the benefit.
- aninhumer 10y ago
  Yeah, I think the problem here is that Verilog was originally created as a language for simulating hardware, not synthesising it. So its semantic model (which is essentially a bunch of imperative processes running in parallel) is not very appropriate for designing hardware.
- akiselev 10y ago
  The problem is that programming abstractions are fundamentally different from those in hardware description languages. Whereas programming abstracts away arbitrary manipulation of memory with variables, pointers, and functions, Verilog abstracts away transistor topology and the NP-hard routing problem inherent in FPGA/ASIC design. The former is an abstraction for telling a precisely defined system what to do while the latter describes the system of equations for a (possibly nondeterministic) linear constraint solver. Hardware description languages can never be as abstract as programming languages for the same reason that we can't create a single unifying abstraction for imperative multi and single threaded code: synchronization. Since each algorithm or data structure can have unique memory access/sync patterns, especially once optimized, there is no way to abstract away parallelization so we're forced to work with a large number of low level primitives like queues, locks, etc. In silicon, not only is everything running in parallel but each abstract unit of functionality has many more "degrees of freedom" like synchronization points, clock speeds, and physical location. It's simply impossible to cleanly abstract over all of the little tweaks you have to do in the implementation phase to get your blocks of transistors to synchronize properly.
  - aninhumer 10y ago
robotjosh 10y ago
I did some verilog in college. For many years I worked with a guy who only knew verilog and hardware design until he started coding late in his career. It was very interesting to work with his code. He used bitfields everywhere like in verilog. His functions tended to do a very small specific thing. He liked state machines and enums with long names. His style reminded me of verilog. I have not seen this coding style before or since.
- CapacitorSet 10y ago
  I wonder if such a "low-level" coding style, based on bitfields and state machines, generally leads to better performance than more abstract patterns. While the former is close to how a human would design hardware for that task, the latter can be better optimised by the compiler.
  - robotjosh 10y ago
    It depends on if your state machine scheme is concise and makes human sense. Too many flags and state machines can become difficult to debug or work with.
  - r_smart 10y ago
    In general, the consideration for bit fields is that your program will run slower but consume less memory. It's usually my opinion that we want to run as fast as possible while not running out of memory, so I'd say in general bit fields are less performant. If you can afford the memory, using a whole word for booleans will yield the fastest results, but will obviously consume way more memory. I'm a fan of state machines, but I don't think they're necessarily more performant. There's nothing about them that keeps you from doing anything crazy that will bog your program down, but I find them easy to reason about. I think they're a stylistic thing, and the only real advantage I can think of is in maybe helping the design of the program. Having to define your states and how you will move between them is usually a good idea.
    - petra 10y ago
      With regards to state machines , there's the idea of "hierarchical state machines" which basically add hierarchy and abstraction to state machines - and they are used in some safety-critical systems and supposed to greatly help with bug prevention.
romaniv 10y ago
>Verilog seems "hard" because people often use it in a similar fashion to a programming language You mean typing random stuff into the editor without understanding what any of it does and hoping for the best? Because all of the online examples I've seen of "HDL done like programming" involved exactly that. In my experience, HDL design is very similar to functional programming (minus recursion) and the principles that work in one translate well to the other.
- tonmoy 10y ago
  I was thinking more in terms of realizing signals are actual electrical nodes, not location in memory, separating the design in combinations and sequential parts and choosing the right size of buffer going from one clock domain to another and stuff like that. When I see examples of verilog online, it seems like most people have no concept of these core things
mrlambchop 10y ago
I found a niche in a ASIC startup environment back in 2005 (5 years post CS degree and work experience to that date mostly being C/C++) as being "the guy that didn't want to work on the CPU" and where verilog engineers were thin on the ground (also I had an awesome boss who encouraged me to jump into the fray). A littler bartering and I ended up owning display controllers, camera input peripherals, interrupt controllers and other such fun for 65nm and 40nm ASICs - mostly verilog (and, sigh.. TCL for test benches). I found a singular insight got me all the way from zero to tapeout for all sorts of peripherals and infrastructure without any real support from other RTL peers in the team - design everything around a single clock (inc crossing all async signals into this singular domain as fast as possible) and then explicit pipelining of the peripherals functionality using a judgement of the process/clock speed to guesstimate how much complexity/gate density each pipeline stage could support before starting a new stage. As I recall, my peripherals were marginally bigger than they needed to be but were extremely easy to push through the back end as the constraints were simple to define and synthesize. I miss those days - the pressure to tape out a singular piece of art was a great way to focus the brain and the chip bring-up was exhilarating.

by tonmoy 10y ago

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.
- raverbashing 10y ago
  > 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. Maybe in really old compilers > You don't write programs with it, you describe hardware with it Which is fair enough, but it seems the "hardware description" pretends to be of a higher-level than it really is. If you need the user to describe gates and flip-flops and how they connect then make them describe this.
  - vvanders 10y ago
    > If you need the user to describe gates and flip-flops and how they connect then make them describe this. You're talking about RTL, which is exactly what these languages output. Fundamentally they're not programming languages, unfortunately the initial instinct is to treat them as such and it leads to a ton of confusion.
    - wolfgke 10y ago
      > You're talking about RTL, which is exactly what these languages output. If VHDL/Verilog would output RTL, you could easily analyze it just as you analyze assembly output of your favorite compiler. Unluckily the output is some proprietary bitstream for the FPGA.
      - vvanders 10y ago
        It's been a while since I poked around in RTL but last time I was working with FPGAs it was possible to inspect RTL and view the synthesis results.
      - k0ngo 10y ago
        Just as a software compilation flow is devided into preprocessing, compilation, assembly, and linking, a HDL flow is divided into synthesis, mapping, place and route, timing analysis and bitstream generation. RTL is the output of the synthesis stage and is readily available to the designer, typically both as code and as a graphical schematic.
moftz 10y ago
A lot of times, you can get access to IP blocks. You can view a reference design of what the module does but the actual code is a binary blob owned by the chip manufacturer. You can treat these as functions and build larger designs from them. It's great because you don't have to write really low-level stuff like RTL except for hooking up the different modules. You can then do some more complex combinational logic using always blocks that kind of look like C. It's not super high level like C++ or python but you can get some higher levels of abstraction. Some IDEs have a visual way to write the code using schematics. You connect the logic modules together using wires. It makes HDL a bit easier to understand what's happening but you need to compartmentalize your code as much as possible, essentially making everything a function.

blackguardx 10y ago

I can't upvote this enough. It is imperative to make at least a block diagram before you start typing. Making some timing diagrams for critical sections will save even more headache.

aninhumer 10y ago
I feel like this is kind of like saying people shouldn't write imperative software until they've drawn a flowchart for all the logic. Sure there are some cases where it might be a good idea, but if it's a requirement to understand the design, then your language isn't doing its job.
- theyoungestgun 10y ago
  Psst . . . verilog (not saying the same for systemVerilog) isn't doing its job ;)
- deleted 10y ago
  [deleted]
- blackguardx 10y ago
  Drawing a timing diagram is the same as thinking about how a CPU will execute instructions that you write or your compiler spits out. Optimization is important in hardware due to cost, speed, and power implications of hardware design. These tradeoffs are there for software design as well, but to a much less extent.
- akiselev 10y ago
  It's not the same thing at all. Since modern processors abstract over the physical location/layout of memory, code at any location can access data or call code at any other location. This allows you to just jump in and write your logic without worrying about how the silicon physically moves your bits around. You simply can't do that when designing silicon. All of your transistors have to be physically connected on a 2d plane so you can't abstract over the physical location or layout of your "objects" (logical groups of transistors and how they interconnect in this case). This means that the vast majority of possible Verilog designs are impossible to physically implement because there is only a finite amount of space to route traces from one transistor to another. Writing Verilog before drawing a block diagram is like writing an embedded IoT framework in Ruby before checking whether your target microcontrollers have enough ROM/RAM to run the Ruby interpreter. For example, if you had a stack allocated object containing a queue and you changed it to always heap allocate the queue, it would still do the same thing as before but with a different memory layout. If you did the equivalent in silicon (like move the location of a group of transistors), at best it would break your functionality and at worst it would make the design unsynthesizable. Swapping an interface to point to an implementation with a different size (I.e. switching an IQueue* to an MPSC Queue from a SPSC Queue) is a trivial change with software but when you swap a 100 transistor interface with a 1000 transistor one you have to move the blocks around it, often requiring significant changes to avoid breaking functionality.

mindslight 10y ago

Having done some Verilog professionally, this is my initial reaction too. It is quality advice for anyone needing to use Verilog. Yet if I put on my software cap and think of how things should be, the whole point of a language is to create an abstraction. This allows a designer to think and express their intent at a higher level. If an abstraction is not complete then the designer can never stop thinking in the lower level terms, which nullifies the benefit.

aninhumer 10y ago
Yeah, I think the problem here is that Verilog was originally created as a language for simulating hardware, not synthesising it. So its semantic model (which is essentially a bunch of imperative processes running in parallel) is not very appropriate for designing hardware.
akiselev 10y ago
The problem is that programming abstractions are fundamentally different from those in hardware description languages. Whereas programming abstracts away arbitrary manipulation of memory with variables, pointers, and functions, Verilog abstracts away transistor topology and the NP-hard routing problem inherent in FPGA/ASIC design. The former is an abstraction for telling a precisely defined system what to do while the latter describes the system of equations for a (possibly nondeterministic) linear constraint solver. Hardware description languages can never be as abstract as programming languages for the same reason that we can't create a single unifying abstraction for imperative multi and single threaded code: synchronization. Since each algorithm or data structure can have unique memory access/sync patterns, especially once optimized, there is no way to abstract away parallelization so we're forced to work with a large number of low level primitives like queues, locks, etc. In silicon, not only is everything running in parallel but each abstract unit of functionality has many more "degrees of freedom" like synchronization points, clock speeds, and physical location. It's simply impossible to cleanly abstract over all of the little tweaks you have to do in the implementation phase to get your blocks of transistors to synchronize properly.
- aninhumer 10y ago

robotjosh 10y ago

I did some verilog in college. For many years I worked with a guy who only knew verilog and hardware design until he started coding late in his career. It was very interesting to work with his code. He used bitfields everywhere like in verilog. His functions tended to do a very small specific thing. He liked state machines and enums with long names. His style reminded me of verilog. I have not seen this coding style before or since.

CapacitorSet 10y ago
I wonder if such a "low-level" coding style, based on bitfields and state machines, generally leads to better performance than more abstract patterns. While the former is close to how a human would design hardware for that task, the latter can be better optimised by the compiler.
- robotjosh 10y ago
  It depends on if your state machine scheme is concise and makes human sense. Too many flags and state machines can become difficult to debug or work with.
- r_smart 10y ago
  In general, the consideration for bit fields is that your program will run slower but consume less memory. It's usually my opinion that we want to run as fast as possible while not running out of memory, so I'd say in general bit fields are less performant. If you can afford the memory, using a whole word for booleans will yield the fastest results, but will obviously consume way more memory. I'm a fan of state machines, but I don't think they're necessarily more performant. There's nothing about them that keeps you from doing anything crazy that will bog your program down, but I find them easy to reason about. I think they're a stylistic thing, and the only real advantage I can think of is in maybe helping the design of the program. Having to define your states and how you will move between them is usually a good idea.
  - petra 10y ago
    With regards to state machines , there's the idea of "hierarchical state machines" which basically add hierarchy and abstraction to state machines - and they are used in some safety-critical systems and supposed to greatly help with bug prevention.

romaniv 10y ago

>Verilog seems "hard" because people often use it in a similar fashion to a programming language You mean typing random stuff into the editor without understanding what any of it does and hoping for the best? Because all of the online examples I've seen of "HDL done like programming" involved exactly that. In my experience, HDL design is very similar to functional programming (minus recursion) and the principles that work in one translate well to the other.

tonmoy 10y ago
I was thinking more in terms of realizing signals are actual electrical nodes, not location in memory, separating the design in combinations and sequential parts and choosing the right size of buffer going from one clock domain to another and stuff like that. When I see examples of verilog online, it seems like most people have no concept of these core things

mrlambchop 10y ago

I found a niche in a ASIC startup environment back in 2005 (5 years post CS degree and work experience to that date mostly being C/C++) as being "the guy that didn't want to work on the CPU" and where verilog engineers were thin on the ground (also I had an awesome boss who encouraged me to jump into the fray). A littler bartering and I ended up owning display controllers, camera input peripherals, interrupt controllers and other such fun for 65nm and 40nm ASICs - mostly verilog (and, sigh.. TCL for test benches). I found a singular insight got me all the way from zero to tapeout for all sorts of peripherals and infrastructure without any real support from other RTL peers in the team - design everything around a single clock (inc crossing all async signals into this singular domain as fast as possible) and then explicit pipelining of the peripherals functionality using a judgement of the process/clock speed to guesstimate how much complexity/gate density each pipeline stage could support before starting a new stage. As I recall, my peripherals were marginally bigger than they needed to be but were extremely easy to push through the back end as the constraints were simple to define and synthesize. I miss those days - the pressure to tape out a singular piece of art was a great way to focus the brain and the chip bring-up was exhilarating.