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

91–100 of 131 posts

Re: Verilog Is Weird

#91

Post by _0ffh »

stdbrouw wrote: post #65
gswdh wrote: post #53

Earlier quoted context omitted.

> "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.

> 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.

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.

Re: Verilog Is Weird

#92

Post by magicalhippo »

rowanG077 wrote: post #87
magicalhippo wrote: post #75

Earlier quoted context omitted.

What I was thinking of was more like a linear shift feedback register. It has zero inputs and outputs random bits, thanks to its non-trivial internal state. Or as we were saying, a register. Could for example be a function which takes a read/write flag and a value, writes the value to the internal state if write flag is set, and returns the internal value. edit: In my softcore I have a function to read/write register…

You are seeing a single invocation as running your circuit for a single clock cycle after an arbitrary amount of clock cycles. That's the wrong approach. A single invocation of a circuit takes a stream of values and produces a stream of values. Every invocation start from clock cycle 0. So yes if your circuit depends on external signals driven by registers living in a different circuit you need to pass those in as in…

I think I get what you're getting at.

Still, I would be very interested to see how one would implement a shift register, lets say something like the 74HC165, so I can see how the pure functions interact with the register state.

Re: Verilog Is Weird

#93

Post by Taniwha »

jstanley wrote: post #32
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…

> "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.

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'

Re: Verilog Is Weird

#94

Post by shadowgovt »

jwilk wrote: post #5

> maybe try copy+pasting that URL That doesn't work either, because the generator dropped the underscore. http://en.wikipedia.org/wiki/Flip-flop_(electronics) Hugo would normally handle such links fine, but earlier on there's an unescaped underscore in "d_out", which makes it go off the rails.

And hugo is technically correct (the best kind of correct) in that parens are in the sub-delims reserved set of characters for HTML (https://www.ietf.org/rfc/rfc3986.txt section 2.2), and since they're being used in a context where the enclosing language considers parens to have special meaning, they should be octet-encoded in the hugo file.

(In practice, my experience with hugo is that it will generally get them right if you use them anyway, but it risks mis-parsing).

Re: Verilog Is Weird

#95

Post by FullyFunctional »

gchadwick wrote: post #20
anyfoo wrote: post #6

Oh boy, this is a sore subject for me. It's pretty obvious that Verilog and VHDL, modeled after C and Ada respectively, both imperative languages, follow a drastically mismatched paradigm for hardware design, where circuits are combined and "everything happens in parallel". It becomes even more obvious when you have tried a functional alternative, for example Clash (which is essentially a Haskell subset that compiles…

Verilog definitely sucks but I think the problem with new HDLs (Clash, Bluespec, Chisel etc) is they don't necessarily make the hard bits of hardware design easier, they just help with the tedious stuff that whilst annoying ultimately doesn't take up much of your time. For example a good type system definitely makes module interfaces cleaner, saves you having to dig through warnings/lint reports to find stupid errors…

Do you have a pointer to Bluespec Classic (not the "modern" Bluespec)?

I would make a distinction between "generator HDLs" like Verilog, Lava, Chisel, MyHDL, nMigen, etc and languages that actually are interpreted as logic (Verilog, Bluespec, Clash, Silice, Handel-C, ...). Yes, Verilog can do both and is a ghastly language. The former class doesn't really raise the abstraction, it just makes generators easier to write.

As I've been saying for decades, I really want a language in which it is as easy to write an implementation as it is to write a [timing] software model; ideally I can use the same language for both! I know it can be done and I have been trying to scratch that itch a few times.

Re: Verilog Is Weird

#96

Post by dmix »

anyfoo wrote: post #6

Oh boy, this is a sore subject for me. It's pretty obvious that Verilog and VHDL, modeled after C and Ada respectively, both imperative languages, follow a drastically mismatched paradigm for hardware design, where circuits are combined and "everything happens in parallel". It becomes even more obvious when you have tried a functional alternative, for example Clash (which is essentially a Haskell subset that compiles…

> Yet Haskell proved me very wrong on that, so much that it was almost like re-learning programming. The reward is immense, but you have to really want to learn it.

I've given it 3 attempts and each time I get closer to understanding how to use Haskell IRL, instead of toy things. Turning it into reality with all the different... styles or paradigms?.

Looking forward to my 4th attempt, I think I'll get it next time! Just need the spurt of motivation.

Re: Verilog Is Weird

#97

Post by rowanG077 »

magicalhippo wrote: post #92
rowanG077 wrote: post #87

Earlier quoted context omitted.

You are seeing a single invocation as running your circuit for a single clock cycle after an arbitrary amount of clock cycles. That's the wrong approach. A single invocation of a circuit takes a stream of values and produces a stream of values. Every invocation start from clock cycle 0. So yes if your circuit depends on external signals driven by registers living in a different circuit you need to pass those in as in…

I think I get what you're getting at. Still, I would be very interested to see how one would implement a shift register, lets say something like the 74HC165, so I can see how the pure functions interact with the register state.

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 it if you want latches, enables etc. But that doesn't really change the core point of the code.

Re: Verilog Is Weird

#98

Post by bsder »

tsmi wrote: post #90
gswdh wrote: post #54

Earlier quoted context omitted.

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…

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

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)

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.

Re: Verilog Is Weird

#99

Post by jgeada »

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 have any sensible mapping to hardware.

The problem with all these articles is that they start from wrong assumptions and keep going. In practice, industry has no problem using these languages to produce chips with billions of transistors that largely work the first time, with the expected performance and power. As others have mentioned, this industry is conservative, and if there isn't a problem to fix it will remain with the tried and tested.

(I'm one of the people named in the Verilog/SystemVerilog standards, worked with Phil Moorby and once upon a time was responsible for chunks of ncsim and vcs)

Re: Verilog Is Weird

#100

Post by bsder »

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…

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.

Post reply on HN