Why hardware development is hard: Verilog is weird • Hacker News Board

Re: Why hardware development is hard: Verilog is weird

#51

Post by nhaehnle » Mon, Sep 09, 2013, 8:23 AM UTC

csense wrote: post #41

> not because of deficiencies in [Haskell], but because it’s politically difficult to get people to use a Haskell based language I know tons of languages, but I've never really been able to understand Haskell. The whole monad thing is just...weird. I've read several descriptions, and had it explained to me multiple times on HN, but I still just Don't Get It. And I feel like I should Get It, because I have a degree in…

I agree, except that I think Haskell would be pretty big in an alternative universe where everybody already learns programming with Haskell. That is, in the dynamic system of software development, default-to-imperative and default-to-pure-functional are both stable equilibria.

As far as monads go, the things that helped me was (1) think of writing in monads not as programming in an imperative language, but as writing a functional program that returns an imperative program (as a value in a rather opaque type), and (2) forget about do-notations and learn about using the arrow-like operators directly.

Re: Why hardware development is hard: Verilog is weird

#52

Post by morrad » Mon, Sep 09, 2013, 5:11 PM UTC

shubb wrote: post #29

Chip vendors often give you a way to instantiate on chip hardware (memories, latches, etc). I found the path of least resistance (and highest performance) was to figure out what circuit I wanted, then basically use Verilog to wire these primitives together to make it. By causing verilog to use an actual memory block, rather than a stack of flipflops, you would yield a nice performance increase also. The trouble is th…

I'm late to this discussion, but as a "real pro" VHDL coder, I can at least sate your curiosity.

At my company, we abstract the vendor specific implementations to have a common interface that we can then use to keep the rest of our code vendor neutral.

For example, within the "Dual Port RAM" section of our revision control system, we have separate files that instanciate memory control blocks for Xilinx Spartan and Altera's Cyclone FPGAs, and generalize the interfaces so that all I see when creating a design is a vendor agnostic "dpram" component interface. When I need to use one in our design, I just need to import the correct file into my build corresponding to the actual FPGA that will be used. Migrating to another vendor involves changing which file gets during synthesis.

Cheers.

Re: Why hardware development is hard: Verilog is weird

#53

Post by patrickwiseman » Wed, Sep 11, 2013, 4:47 AM UTC

austinz wrote: post #2

The problem is that Verilog/VHDL isn't a "programming language" in the sense that C, Lisp, Haskell, or Python are programming languages. So approaching them with a programming language mindset is asking for a lot of pain and misunderstanding. HDLs like Verilog and VHDL describe digital circuits, not algorithms and instructions for manipulating data. If C code is akin to instructions for getting to a grocery store and…

Much agreed. Verilog/VHDL are simply not programming languages. They are Hardware Description Languages. They describe parallel components that will actually be "wired" together.

My advice if you are a programmer or computer scientist and you get tasked with writing Verilog of VHDL "code" you need to be able to explain the difference -- You've just been offered a job as a hardware designer and engineer. Having spent 5 years doing hardware engineering and a lot longer doing software consulting I can say it's an entirely different set of skills if not an entirely different career path.

Re: Why hardware development is hard: Verilog is weird

#54

Post by cgore » Fri, Sep 13, 2013, 3:37 PM UTC

gngeal wrote: post #31

cgore wrote: post #11

Earlier quoted context omitted.

Just chiming in with the standard Lisp response: HDL's can be done in Lisp, and have been done in Lisp. You just define a DSL for it.

At least since the 1980's, see AIM-953.

Just read over it. That was pretty interesting, thanks.

Take a look at the work of John Koza. His systems were used to automatically generate electrical circuits:

http://www.genetic-programming.com/johnkoza.html

I looked at his stuff a lot when I was trying to pick my path for my MS thesis. I ended up going down a completely different route though.