Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Verilog Is Weird

danluu.com

Post reply on HN
Print view View original

121–130 of 131 posts

Re: Verilog Is Weird

#121

Post by rowanG077 »

magicalhippo wrote: post #110
rowanG077 wrote: post #97

Earlier quoted context omitted.

Here is a simple 64 bit shift register: https://replit.com/@RowanGoemans/AlarmedNutritiousVisitors#m... Runnable using replit. To make it as simple as possible I didn't use Clash and used types available in prelude Haskell (Bool instead of bit, 64 bit integer as register state etc. Every single element in the list represent a value coming out of the register on the rising edge of a clock cycle. You can easily extend…

Much appreciated. I think I get the gist of it, even though it looks very complex compared to the Verilog counterpart. To be fair, my lack of Haskell knowledge doesn't help. But it's really helpful to get a feel for the different approach.

I mean Haskell is definitely and acquired taste if you haven't used other languages in the same style before. Also note that writing this in actual Clash would be a one liner. Because stuff like registers and shifts are available as part of the standard library.

Re: Verilog Is Weird

#122

Post by jgeada »

ghettoimp wrote: post #108
jgeada wrote: post #99

This article starts out by assuming that understanding sequential programming is sufficient to understand hardware. Yes, Verilog is a simulation description language, and yes, it can be compiled to hardware. But it is a specific subset that translates to hardware, not the whole language. Large parts of Verilog/SystemVerilog exist to drive stimulus into the model hardware and to observe the results; those parts don't…

Counter-opinion: industry simply has no plausible alternative to Verilog/SystemVerilog and succeeds in producing chips only in spite of the language's glaring flaws. I worked for several years at a world class company verifying CPU designs. Even into the late 2010s, designers were afraid to use basic features like structs because who knows what tool might not support it correctly. They emulated structures using piles…

The industry is extremely conservative. Costs of designing and taping out a modern chip range from $100M to $1B; these are the type of costs that will kill most companies if it goes wrong and very few companies can afford to have it go wrong more than once.

Tried and true approaches, small incremental developments are the only way things get done in this space. And the technological moat has many sources, not just Verilog etc. Process technology is continuously evolving and tools need to adapt to all the new physical rules and constraints. What gates are most efficient depends on the problem and the process and even by what the team means by efficient (least power? least energy? most mips/sec? least time to solve a problem? ...)

Everyone loves to complain about the tools though, that is universal. They'll just never adopt a new tool that hasn't survived the test of time and had enough successful designs "by someone else" that it doesn't make them nervous about being the first.

Re: Verilog Is Weird

#123

Post by Taniwha »

Taniwha wrote: post #115
magicalhippo wrote: post #112

Earlier quoted context omitted.

But if the result is a flipflop, where is the loop?

Always implies an outer loop, when you reach the bottom of the loop you go back to the top and do the original event wait again, but not until you've waited for the intermediate event waits In simulation this is easy to implement, but in synthesis the synthesis tool needs to rewrite it as some hidden flops for state and a top level case statement

I'll add these examples of how to make a clock from the Verilog 2k standard:

    always #half_period areg = ~areg;

    always c = #5 ~c;
the @() portion is not intrinsically part of the always - it's just usually used there for synthesisable code

Re: Verilog Is Weird

#124

Post by magicalhippo »

Taniwha wrote: post #123
Taniwha wrote: post #115

Earlier quoted context omitted.

Always implies an outer loop, when you reach the bottom of the loop you go back to the top and do the original event wait again, but not until you've waited for the intermediate event waits In simulation this is easy to implement, but in synthesis the synthesis tool needs to rewrite it as some hidden flops for state and a top level case statement

I'll add these examples of how to make a clock from the Verilog 2k standard: always #half_period areg = ~areg; always c = #5 ~c; the @() portion is not intrinsically part of the always - it's just usually used there for synthesisable code

So you're explicitly restricting yourself to simulators only?

If not, where in this shift register[1], when synthesized to an FPGA, is the loop waiting for posedge clk or posedge reset?

[1]: https://asic4u.wordpress.com/2016/03/28/verilog-1-delay-in-r...

Re: Verilog Is Weird

#125

Post by Taniwha »

magicalhippo wrote: post #124
Taniwha wrote: post #123

Earlier quoted context omitted.

I'll add these examples of how to make a clock from the Verilog 2k standard: always #half_period areg = ~areg; always c = #5 ~c; the @() portion is not intrinsically part of the always - it's just usually used there for synthesisable code

So you're explicitly restricting yourself to simulators only? If not, where in this shift register[1], when synthesized to an FPGA, is the loop waiting for posedge clk or posedge reset? [1]: https://asic4u.wordpress.com/2016/03/28/verilog-1-delay-in-r...

No - the example I gave above with multiple @(posedge clk) in the single always statement is synthesisable (by synopsys at least, I don't know about others) and contains an embedded loop - it's arguably a higher level way to make logic than the traditional always/case/state state machine. Maybe a simpler example will do:

    always begin
        @(posedge clk) v
is identical to:

    always @(posedge clk) begin
        v
both can be synthesised and make the same logic

Re: Verilog Is Weird

#126

Post by Taniwha »

magicalhippo wrote: post #124
Taniwha wrote: post #123

Earlier quoted context omitted.

I'll add these examples of how to make a clock from the Verilog 2k standard: always #half_period areg = ~areg; always c = #5 ~c; the @() portion is not intrinsically part of the always - it's just usually used there for synthesisable code

So you're explicitly restricting yourself to simulators only? If not, where in this shift register[1], when synthesized to an FPGA, is the loop waiting for posedge clk or posedge reset? [1]: https://asic4u.wordpress.com/2016/03/28/verilog-1-delay-in-r...

the shift register example you give would normally be synthesised to something with a synchronous clock and an async reset - during simulation the loop is waiting for either

Re: Verilog Is Weird

#127

Post by magicalhippo »

Taniwha wrote: post #126
magicalhippo wrote: post #124

Earlier quoted context omitted.

So you're explicitly restricting yourself to simulators only? If not, where in this shift register[1], when synthesized to an FPGA, is the loop waiting for posedge clk or posedge reset? [1]: https://asic4u.wordpress.com/2016/03/28/verilog-1-delay-in-r...

the shift register example you give would normally be synthesised to something with a synchronous clock and an async reset - during simulation the loop is waiting for either

> during simulation the loop is waiting for either

Ok, then we agree. Of course a simulator will have an implicit loop, that's not contentious.

However you did not mention this in your initial statement, and I've read and been told explicitly not to think of it like this because there's no loop in hardware.

Re: Verilog Is Weird

#128

Post by magicalhippo »

rowanG077 wrote: post #121
magicalhippo wrote: post #110

Earlier quoted context omitted.

Much appreciated. I think I get the gist of it, even though it looks very complex compared to the Verilog counterpart. To be fair, my lack of Haskell knowledge doesn't help. But it's really helpful to get a feel for the different approach.

I mean Haskell is definitely and acquired taste if you haven't used other languages in the same style before. Also note that writing this in actual Clash would be a one liner. Because stuff like registers and shifts are available as part of the standard library.

I've tried to get into Haskell, and while I don't have a huge problem with the overall concepts most of the time, although a bit alien at times, my brain just can't seem to handle the syntax.

I've found myself thinking differently about code and using a lot more functional-ish concepts when writing my "normal" code though, so I do like the exposure.

Re: Verilog Is Weird

#129

Post by tsss »

sguav wrote: post #71
tsss wrote: post #52

Earlier quoted context omitted.

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.

You have high-level-synthesis tools on many FPGA vendors tools, using C/C++ or even Python for hardware description. I personally don't think they are superior than typical HDLs, the thing that makes the difference is to think about the circuit you ought to describe, the language you use then is not as important IMHO.

I don't mean high-level synthesis. In fact, using C++ or Python is even worse because there is even more mismatch in the abstraction.

Re: Verilog Is Weird

#130

Post by anamax »

Taniwha wrote: post #24

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 what…

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.

Post reply on HN