6 ms·

I think that really the hard part of learning to design chip stuff really is other stuff - understanding where/how to use storage (flops) and combinatorial logi

I think that really the hard part of learning to design chip stuff really is other stuff - understanding where/how to use storage (flops) and combinatorial logic - and simultaneity: how to handle things that happen at the same time. Initially you really need a strong understanding of digital logic (not a language), in particular pipelines. Once you have that stuff in your head you can turn to verilog (or vhdl or whatever) and learn how to map these ideas into the language In System Verilog it's easy this is the only way to reliably make synthesisable flops: bit a, b; always @(posedge clk) a <= b; And you can make combinatorial logic 2 ways: wire c; bit d; assign c = a&b; always @(*) d = a&b; They'll make the same gates, notice the use of = vs <=, you typically use the always when you want something more complex "always X" just means loop waiting for X, '*' means "anything important changes" That's it, the most important concepts you have to get your head around, everything else is just this at scale - also please ignore the async reset in the "Verilog is Weird" example - they tend to be timing nightmares in the real world, use a synchronous reset instead. One more thing - Verilog is an early object oriented language - modules are objects - but they are static, the entire design can be elaborated at compile (or synthesis) time - why? because you can't new or malloc more gates on the fly on a real chip - almost everything in verilog is static by design (it does support local variables in functions but anything that's vaguely recursive wont make gates in synthesis)

pjc50 5y ago
> Once you have that stuff in your head you can turn to verilog (or vhdl or whatever) and learn how to map these ideas into the language Yes, and per the other comment this is a huge limitation of them - you don't have Javascript authors saying "you need to work out what you want in this other paradigm and then translate it". You occasionally see people writing C this way though, by working out what they want from the assembly and working backwards, which tends to get wrecked by UB or the optimizer at some security-critical point. If the main point of the language is to generate flops, flops should be an explicit primitive! > Verilog is an early object oriented language - modules are objects Maybe, but IMO a more useful place to apply object orientation would be interfaces, which are nets not modules. I should be able to instantiate "AXI bus" somewhere and connect things to it.
- gswdh 5y ago
  > "you need to work out what you want in this other paradigm and then translate it" Not really. You wouldn't expect good programs from someone who has no idea how a computer works. The language is the knobs and dials. You need to know what the knobs and dials do in the machine.
  - stdbrouw 5y ago
    > Not really. You wouldn't expect good programs from someone who has no idea how a computer works. I wouldn't expect them to write a good operating system, but for the vast majority of code that is being written you can get pretty far with "your cpu is faster than your memory" as the only bit of knowledge about how computers work.
    - _0ffh 5y ago
      I've once read a blog entry from a developer who was hired to speed up some piece of software. He achieved a few hundred fold speed up. Not primarily because he is so good (though he is), but because the original developer had a large matrix of numbers stored as a 2d-array of strings and converted them back and forth whenever he had to do an operation on that matrix. You simply can't make up the shit that some people will do.
- FPGAhacker 5y ago
  The main point of verilog is to simulate digital logic, of which flip flops are just one part. As to the second point, you can do exactly what you said, instantiate a SystemVerilog “AXI bus” interface and connect things to it. With the interface being a single line item in the port map. This comes with its own set of headaches and I’m not always sure it’s worth it.
  - tsmi 5y ago
    > The main point of verilog is to simulate digital logic I disagree. A HDL, which verilog is an instance of, provides a precise description of a digital machine. Once you have that description, many things can be done with it. For example you can simulate the machine which is to be produced. The problem is HDL looks like an algorithm, because it is. But it’s not a precise description of a computation, it’s a description of an object. Most people who I’ve observed program verilog badly do so because they confuse the two. Kinda like confusing giving directions with giving instructions to make a map. Directions and maps are highly related, but they’re not the same thing.
jstanley 5y ago
> "always X" just means loop waiting for X I think this is actually not right. There's not any kind of loop that is running, it's triggered by signal edges. That's the fundamental difference between hardware and software that makes hardware difficult for software people. Everything happens simultaneously.
- tails4e 5y ago
  I think the loop term is OK, it's just gated by the event sensitivity list for each iteration. If you have an always without a sensitivity list then it is a while(1) equivalent.
  - buildbot 5y ago
    This is not exactly true, because the event you expect in software, the loop ticking over, can itself happen at any time. posedge(*) will trigger on _any_ change in the always block, and those changes can happen at the same, slightly different, or much different times.
    - tails4e 5y ago
      always( * ) is not the same as always, I was referring to the latter. always( * ) is gated by the sensitivity list, always is not.
- tsmi 5y ago
  That’s not exactly the right way to think about it. In HDL, you’re writing an algorithm, but the algorithm produces a physical device, not a computation. It’s like programming a machine to make a watch. At the end you have a watch. Would you say the gears execute in parallel while it measures time? In some sense it’s right, but in another it’s missing the point.
- Taniwha 5y ago
  A little background - I've written a couple of Verilog compilers - you can have always statements with multiple events, protocol state machines a bit like: always @(posedge clk) begin do some stuff if (condition) begin @(posedge clk); do some more stuff end else begin @(posedge clk); do some different stuff end ...... end Synopsis will happily synthesise this, generating the implied state variable. There really is a loop in there. In fact 'always' is exactly 'initial #0 forever'
tsss 5y ago
No, the problem with Verilog is that it tries to be a procedural language like C when digital circuits are inherently parallel and declarative (sequential circuits just being special cases with feedback). VHDL is better, but still pretty bad. Learning digital circuit design on FPGAs would be so much easier if there was a well supported hardware description language that isn't stuck in the 1980s.
- gswdh 5y ago
  It doesn't. Just because it shares some syntax with C does not make it 'want to be procedural'. I think that comes from the programmers bias from first learning a procedural language. I learnt C then Verilog, I am fluent in Verilog. The mindset for designing digital logic is completely different to programming computers, it literally is a completely different skill. The problem is, people think just because they can type a (procedural) programming language they can program anything that is programmed with a code which is where peoples initial distaste for Verilog and VHDL comes from. When you learn how to do it, I think designing logic is refreshing compared to writing software, there's so much baggage with software.
  - tsmi 5y ago
    I do totally agree with the comment, and even upvoted it, but in some sense an HDL does 'want to be procedural'. For example: Procedure to make brick wall: For brick in wheel-barrow do To brick, apply mortar, place it, pound it with trowel (Apologies to all masons. I think you can tell my training is electrical engineering.) I've thought for some time that the main problem with Verilog is that it looks really close, visually, to C and that gives people the wrong impression.
    - bsder 5y ago
      Except that's not how you do it. My go-to example for this is the Carry-skip Adder. (https://en.wikipedia.org/wiki/Carry-skip_adder https://en.wikipedia.org/wiki/Carry-skip_adder) Things are happening simultaneously in time and space. The ripples are happening while the skips are happening. The skips go stable because the ripple goes stable or the carry will skip so the ripple has "extra time" to go stable. This is the simplest add faster than naive ripple carry. Note that it has no clocks. This is a purely combinatoric problem. And most "digital designers" will get it wrong. Hardware design is NOT software design. Good digital designers are always thinking about how to interleave things in time and space like this.
phkahler 5y ago
>> always @(posedge clk) Is there an option for bothedge clk?
- sguav 5y ago
  always @(posedge clk or negedge clk)
  - acadiasprings 5y ago
    This is the correct syntax, though many FPGA architectures don't support double edge registers
    - sguav 5y ago
      True, I directly answered the syntax-related question, but talking about implementation this would be a bad description - be it FPGA or ASIC. As the parent's-parent comment said in other words, think circuit first.
- nrclark 5y ago
  It's not synthesizable, but you could say "always @(clk)" as well.
bsder 5y ago
And yet, for all the pissing and moaning about HDLs from software guys, I can't express a state machine in any current mainstream computer language. For example, the current big advance in "modern" languages is "async". Which "just" instantiates an implicit state machine that you can't control.
anamax 5y ago
When digital designers talk to each other about state, they draw logic clouds and a box, with a clock input, that holds state. The logic clouds are disjoint - there's always a box between them. Yes, there are two kinds of boxes (flip-flops and latches) and how the clock works varies (and there are often multiple clocks, and the clocks may be driven by logic). More to the point, I'd argue that the hardware designers job is to manage state and logic so a language which makes them explicit is a good thing. It's possible to design a language that works exactly like that. The simulator is easy to make very fast and is easily parallelizable. (The logic clouds are acyclic. Moreover, everything that needs to be evaluated at a given clock event or combination thereof can be determined AND partitioned statically.) The synthesis is also easy. Note that SystemC is NOT such a language.

pjc50 5y ago

> Once you have that stuff in your head you can turn to verilog (or vhdl or whatever) and learn how to map these ideas into the language Yes, and per the other comment this is a huge limitation of them - you don't have Javascript authors saying "you need to work out what you want in this other paradigm and then translate it". You occasionally see people writing C this way though, by working out what they want from the assembly and working backwards, which tends to get wrecked by UB or the optimizer at some security-critical point. If the main point of the language is to generate flops, flops should be an explicit primitive! > Verilog is an early object oriented language - modules are objects Maybe, but IMO a more useful place to apply object orientation would be interfaces, which are nets not modules. I should be able to instantiate "AXI bus" somewhere and connect things to it.

gswdh 5y ago
> "you need to work out what you want in this other paradigm and then translate it" Not really. You wouldn't expect good programs from someone who has no idea how a computer works. The language is the knobs and dials. You need to know what the knobs and dials do in the machine.
- stdbrouw 5y ago
  > Not really. You wouldn't expect good programs from someone who has no idea how a computer works. I wouldn't expect them to write a good operating system, but for the vast majority of code that is being written you can get pretty far with "your cpu is faster than your memory" as the only bit of knowledge about how computers work.
  - _0ffh 5y ago
    I've once read a blog entry from a developer who was hired to speed up some piece of software. He achieved a few hundred fold speed up. Not primarily because he is so good (though he is), but because the original developer had a large matrix of numbers stored as a 2d-array of strings and converted them back and forth whenever he had to do an operation on that matrix. You simply can't make up the shit that some people will do.
FPGAhacker 5y ago
The main point of verilog is to simulate digital logic, of which flip flops are just one part. As to the second point, you can do exactly what you said, instantiate a SystemVerilog “AXI bus” interface and connect things to it. With the interface being a single line item in the port map. This comes with its own set of headaches and I’m not always sure it’s worth it.
- tsmi 5y ago
  > The main point of verilog is to simulate digital logic I disagree. A HDL, which verilog is an instance of, provides a precise description of a digital machine. Once you have that description, many things can be done with it. For example you can simulate the machine which is to be produced. The problem is HDL looks like an algorithm, because it is. But it’s not a precise description of a computation, it’s a description of an object. Most people who I’ve observed program verilog badly do so because they confuse the two. Kinda like confusing giving directions with giving instructions to make a map. Directions and maps are highly related, but they’re not the same thing.

jstanley 5y ago

> "always X" just means loop waiting for X I think this is actually not right. There's not any kind of loop that is running, it's triggered by signal edges. That's the fundamental difference between hardware and software that makes hardware difficult for software people. Everything happens simultaneously.

tails4e 5y ago
I think the loop term is OK, it's just gated by the event sensitivity list for each iteration. If you have an always without a sensitivity list then it is a while(1) equivalent.
- buildbot 5y ago
  This is not exactly true, because the event you expect in software, the loop ticking over, can itself happen at any time. posedge(*) will trigger on _any_ change in the always block, and those changes can happen at the same, slightly different, or much different times.
  - tails4e 5y ago
    always( * ) is not the same as always, I was referring to the latter. always( * ) is gated by the sensitivity list, always is not.
tsmi 5y ago
That’s not exactly the right way to think about it. In HDL, you’re writing an algorithm, but the algorithm produces a physical device, not a computation. It’s like programming a machine to make a watch. At the end you have a watch. Would you say the gears execute in parallel while it measures time? In some sense it’s right, but in another it’s missing the point.
Taniwha 5y ago
A little background - I've written a couple of Verilog compilers - you can have always statements with multiple events, protocol state machines a bit like: always @(posedge clk) begin do some stuff if (condition) begin @(posedge clk); do some more stuff end else begin @(posedge clk); do some different stuff end ...... end Synopsis will happily synthesise this, generating the implied state variable. There really is a loop in there. In fact 'always' is exactly 'initial #0 forever'

tsss 5y ago

No, the problem with Verilog is that it tries to be a procedural language like C when digital circuits are inherently parallel and declarative (sequential circuits just being special cases with feedback). VHDL is better, but still pretty bad. Learning digital circuit design on FPGAs would be so much easier if there was a well supported hardware description language that isn't stuck in the 1980s.

gswdh 5y ago
It doesn't. Just because it shares some syntax with C does not make it 'want to be procedural'. I think that comes from the programmers bias from first learning a procedural language. I learnt C then Verilog, I am fluent in Verilog. The mindset for designing digital logic is completely different to programming computers, it literally is a completely different skill. The problem is, people think just because they can type a (procedural) programming language they can program anything that is programmed with a code which is where peoples initial distaste for Verilog and VHDL comes from. When you learn how to do it, I think designing logic is refreshing compared to writing software, there's so much baggage with software.
- tsmi 5y ago
  I do totally agree with the comment, and even upvoted it, but in some sense an HDL does 'want to be procedural'. For example: Procedure to make brick wall: For brick in wheel-barrow do To brick, apply mortar, place it, pound it with trowel (Apologies to all masons. I think you can tell my training is electrical engineering.) I've thought for some time that the main problem with Verilog is that it looks really close, visually, to C and that gives people the wrong impression.
  - bsder 5y ago
    Except that's not how you do it. My go-to example for this is the Carry-skip Adder. (https://en.wikipedia.org/wiki/Carry-skip_adder https://en.wikipedia.org/wiki/Carry-skip_adder) Things are happening simultaneously in time and space. The ripples are happening while the skips are happening. The skips go stable because the ripple goes stable or the carry will skip so the ripple has "extra time" to go stable. This is the simplest add faster than naive ripple carry. Note that it has no clocks. This is a purely combinatoric problem. And most "digital designers" will get it wrong. Hardware design is NOT software design. Good digital designers are always thinking about how to interleave things in time and space like this.

phkahler 5y ago

>> always @(posedge clk) Is there an option for bothedge clk?

sguav 5y ago
always @(posedge clk or negedge clk)
- acadiasprings 5y ago
  This is the correct syntax, though many FPGA architectures don't support double edge registers
  - sguav 5y ago
    True, I directly answered the syntax-related question, but talking about implementation this would be a bad description - be it FPGA or ASIC. As the parent's-parent comment said in other words, think circuit first.
nrclark 5y ago
It's not synthesizable, but you could say "always @(clk)" as well.

bsder 5y ago

And yet, for all the pissing and moaning about HDLs from software guys, I can't express a state machine in any current mainstream computer language. For example, the current big advance in "modern" languages is "async". Which "just" instantiates an implicit state machine that you can't control.

anamax 5y ago

When digital designers talk to each other about state, they draw logic clouds and a box, with a clock input, that holds state. The logic clouds are disjoint - there's always a box between them. Yes, there are two kinds of boxes (flip-flops and latches) and how the clock works varies (and there are often multiple clocks, and the clocks may be driven by logic). More to the point, I'd argue that the hardware designers job is to manage state and logic so a language which makes them explicit is a good thing. It's possible to design a language that works exactly like that. The simulator is easy to make very fast and is easily parallelizable. (The logic clouds are acyclic. Moreover, everything that needs to be evaluated at a given clock event or combination thereof can be determined AND partitioned statically.) The synthesis is also easy. Note that SystemC is NOT such a language.