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

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!

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

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.

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

Previous HN discussion on this article can be found here:

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

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.

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

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.