Where is VHDL’s jQuery?

VHDL is a semi-broken language. Now, I definitely agree with Jan Decaluwe’s blog post that VHDL’s handling of determinism is a huge asset (see: Verilog’s Major Flaw). But from a programmer’s perspective the language is obnoxious to use. Some of it’s features are barely passable-like file i/o-and it takes a programmer far more brain function than it should to do things.

Why is this? It’s always seemed like the language was a bit schizophrenic. Judging by the steering committee’s history with shared variables, this might be because hardware engineers resisted software-like concepts early on. And from what I can tell, the IEEE has done a fairly poor job shepherding the language in the 3 decades since it was created. Why it was never open-sourced, I’ll never understand. I actually asked (who, I can’t remember) during a webinar Q&A on VHDL-2008 whether they’d consider open-sourcing the language, and was told that it “didn’t sound like a good idea.” Hmm. Maybe traditional EDA companies are to blame?

That said, VHDL isn’t the only language like this. The fact that a site like wtfjs exists is proof of that. Yet Javascript is widely used all across the web. You might argue that that’s simply because it’s gotten better over the years, and there’s likely some truth to that. I’ll argue, however, that one of the bigger reasons Javascript is so widely used today is that people innovated around the language’s faults by providing frameworks: jQuery, MooTools, YUICappuccino…the list goes on and on. These frameworks help to hide the obnoxious tasks from the programmer, and even provide commonly used programming patterns and widgets to prevent wheel reinvention.

If I had more free time, I’d start writing one by myself. In fact, I almost did. I got so far as to write down what I would put into it. That list is reproduced here:

Serial to parallel
Parallel to serial
Shift register
Synchronous & Asynchronous FIFOs
Stacks, Queues
CAM Memory
Data Packetizer/Depacketizers (data marshaling)
DSP blocks
Processor Bus Interfaces
SPI Interfaces
I2C Interfaces
A/D, D/A Converter Interfaces
GPS Interfaces
Camera Interfaces
Ethernet Phy/MAC

All of these should be easily customized through generics, and contain self-verifying unit testbenches and documentation.

Some might argue that there’s no need for many of these because there’s already purchasable as IP. In my experience, IP always requires more of your own engineering than you expect, despite having paid for it, and support is pretty terrible. The strength of an open-source framework is that it gets the most sets of eyes on the code and documentation to catch errors and continually improve the quality. Often times, purchased IP you can’t even look at the source code to find out what’s wrong! I’ve been burned by this before.

So now all we need is a catchy sounding name and to grab the domain.

If we build it, they will come.