Why Hardware Development Is Hard, Part 1: Verilog Is Weird

http://danluu.com/why-hardware-development-is-hard/

by nuriaion • 13 years ago

85 17 13 years ago

tylermac1• 13 years ago

Used Verilog in a digital systems course in college. Didn't think it was too bad but we didn't get too in depth with it.

slacka• 13 years ago

Previous HN discussion on this article can be found here:

https://news.ycombinator.com/item?id=6347848

nuriaion• 13 years ago

Sorry didn't found the old discussion in my (extremely short) search.

Aardwolf• 13 years ago

Don't worry, it's not better in Europe, VHDL is also weird.

swah• 13 years ago

Why is it weird? I find it quite elegant... But I'd write in RTL level thinking about the FPGA.

pjc50• 13 years ago

Yes, it is; and hardware development companies are _very_ conservative, so there's little room to launch a disruptive "Ruby for hardware" new language.

I have some ideas myself on what a better language would look like, but for the moment they're at the back of the ideas drawer.

ginty2• 13 years ago

Sorry to hi-jack this comment thread but I don't see many topics on h/ware design and whatever h/ware engineers are around here are likely to be reading this thread.

I'm a design/test engineer for Freescale Semiconductor and I definitely agree with this piece. In my group we have developed something that could be loosely described as 'Ruby on Rails for Semiconductors' and we use this to pre-compile our RTL where it gets marked up with ERB. It was definitely interesting to read here that other companies embed a scripting language in their Verilog - aside from being conservative h/ware companies definitely don't tend to share such information as freely as their s/ware counterparts do!

So thanks to the OP and I will definitely be keeping an eye on his blog.

Anyway with our tool, which we call RGen, we have our design team maintain Ruby models of the h/ware modules, this contains all meta-data about what makes each design unique - feature availability, bug presence, register and memory map information, etc. The marked up RTL can then be compiled against the different design models to generate derivative specific designs - this generally provides a much more structured and powerful approach to design management than anything offered by native Verilog.

What's really neat though is that this meta-data lives in what we call an RGen plugin (kind of like a Ruby gem) and so we can plug these models into downstream environments to generate design-specific documentation, test patterns, test program, bench code, etc. This means that all IP that is dependent on a design can be generated against a design-owned description of it which is very light weight and whihc doesn't require introducing a massive Verilog/testbench dependency into downstream environments.

In terms of test the framework provides Ruby APIs to generate pattern and test programs and basically wraps the ATE test platform in the same way as Rails' ActiveRecord wraps a database - so it provides a credible way to maintain your test IP in a way that is vendor-independent.

Now I feel that other companies are probably solving these problems in their own way, and particularly where test engineering is concerned all of the power currently lies with the vendors who have no incentive to drive standardization and to make it easy for companies to switch platforms. This is fueled by h/ware companies' general mindset of not sharing and collaborating across company boundaries.

Myself and all of the key RGen developers would like to make it open source and we are currently having these discussions with our management team, however as you might imagine the idea of this does not come easy to the semiconductor establishment and it will take quite some convincing to get a go ahead for it. The biggest spectre is the concern that we release it and one of our competitors takes it, get's an advantage, continues to develop it internally and never gives back to the community. I think we can assume that this will almost certainly happen in some cases, but it would help if I could get an idea if companies are out there that would in principle agree to supporting such a development model - basically the idea is that all of our source code and documentation development would move into the open where it would be run like Rails or one of the other main web s/ware frameworks and over time the core team would evolve to contain engineers from outside of Freescale.

So if any h/ware engineers are reading this, does this sound like something you can imagine using and more importantly contribute to?

If so would you mind disclosing who you work for?

Also if anyone knows of any large open source projects in the semi-conductor space that I could cite as examples to my management please provide details.

Thanks!

dchester195• 13 years ago

I'd also be interested in open-source projects in either VHDL/Verilog, the best i've seen is opencores but it seems to have died a little.

dominicgs• 13 years ago

I'm not sure what sort of project you're interested in, but we're currently building open source network taps using PHY ICs and an FPGA. As part of the project a USB 3.0 core is being developed to move captured data to a host system.

https://github.com/mossmann/daisho

whoopsatwork• 13 years ago

Hi! I'm the author of the article but not the person who posted it. Sorry, this is a throwaway account because I don't have my password manager on my work machine and I don't know my password offhand.

At my old company, I could definitely imagine three people (and they were three of our best people) who would be willing to contribute. The biggest issue there is that there's an existing thing that works well, so there's a good chance people wouldn't want to switch. At the new place, I'm still trying to get the lay of the land, so I don't have a very strong answer. I can't see the email in your profile (the email field isn't public), but, if you want to discuss the possibility further, feel free to shoot me an email (it's just the domain name of my blog @gmail or @google).

To respond to your other comment, my last company and my current one have pretty flexible ideas about what it means to use company sponsored time. Time spent working on tools to make you more productive is considering time well spent, both companies have (effectively) infinite book budgets for you to pick up whatever you think you need to learn, etc., so it was on company time.

jck3• 13 years ago

You might be interested in cocotb, which is a "coroutine based cosimulation testbench environment for testing VHDL/Verilog RTL using Python".

cocotb is developed in part by Solarflare communications.

jck3• 13 years ago

Shameless promotion: MyHDL(Python library for hardware description) is well designed and feature rich. I recently pushed support for using class instances to group together signals/ports. So, class instances can be used as Interfaces. This is really cool since Verilog/VHDL don't support this feature natively but MyHDLs conversion creates synthesizable Verilog/VHDL. Although system verilog has Interfaces, I'm not sure if synthesis tools support it(Quartus doesn't)

Also, I'm currently working on uhdl, which simplifies a lot of things about using MyHDL such as CoSimulating with icarus/modelsim.

links:

http://myhdl.org

https://github.com/jck/uhdl

ginty2• 13 years ago

Thanks for sharing, looks interesting.

Would you mind commenting on the development model for something like this? Do you do this on your own time or company sponsored time?

I mentioned in another comment that I have a framework along similar lines that has been developed within the company that I work for (Freescale Semiconductor) and I am looking for examples of other semiconductor-related open source projects that I can cite in discussions with management about releasing it.

If this was something that you developed within a company could you comment on how you went about open sourcing it?

jck3• 13 years ago

oops, I guess that comment insinuates that I'm the creator of MyHDL. The creator of MyHDL is actually Jan Decaluwe(Sigasi, Easics). I just implemented the interfaces feature and develop uhdl.

Rgen looks really interesting. I hope you do manage to get it opensourced so that I can play with it!

jhallenworld• 13 years ago

Hardware engineer here, answering the blogger: this code is bad news to me: only constants should be on the right side of the assigns in the reset branch, so the tools should definitely be complaining.

Second, on the combinatorial always block. The rule is simple: unless you want latches to be inferred (which is usually never), use "always @(*)" so that the block is executed on changes to any of the right-hand-side signals. This is less tedious and error prone than listing each of the signals (there could be 100s in a large block).

VHDL and Verilog are semantically equivalent, so no particular advantage to either one (I prefer Verilog since its syntax is a bit more C like, and a bit less Ada like). I've seen many attempts over the years to make languages which make it easier for programmers to do chip designs, but they've all failed. (Most recent is openCL, but it's not a complete chip design language).

The coder really has to have some idea about the physical correspondence between his code and the chip. For example, you can easily fill even the largest FPGA with just a few lines of Verilog:

reg [10000000:0] foo; always @(posedge clk) foo <= foo + 1'd1;

(10 M flops.. will not fit).

diydsp• 13 years ago

Welcome to HN, Joe! (p.s. for anyone who didn't know, jhallenworld is the author of the classic lightweight, multiplatform editor "joe")

nptime• 13 years ago

Im an electrical engineer with 10 years FPGA and circuit design experience which includes teaching a few new-hires how to do hardware development.

The key to getting a synthesizer to produce a good circuit from any HDL, especially Verilog, is to understand that there is a synthesizeable subset of the language that should be used to describe the RTL (Register Transer Level) of abstraction. The rest of the language's constructs should be limited to simulation only.

Here are a couple of quickly googled sources just to cement the point: http://users.ece.cmu.edu/~jhoe/course/ece447/handouts/LV.pdf http://en.wikipedia.org/wiki/VHDL#Synthesizable_constructs_a...

The synthesizable subset tends to be a very small number of constructs and once you know and understand them you will be one big step closer to much "easier" hardware development.

One should strive to understand RTL as a level of abstraction first though IMHO. I have some thoughts on how best to do that if anyone cares I can continue.

Why Hardware Development Is Hard, Part 1: Verilog Is Weird

Related Stories