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.

17 thoughts on “Where is VHDL’s jQuery?”

  1. @all
    Mostly thoughts about the standard posted here go into the void. If you are senior enough to post thoughts or comment on them, then you are senior enough to participate in the VHDL standards effort.

    If you are not already participating in VHDL-201X, then you should be.

    To join the working group reflector, see the following link:

    _Next Meeting_: Thursday March 3 at 8 am Pacific
    This is a phone conference. See reflector for dial-in details.

    _Homework_ due Thursday March 3:
    Post your change requirement list to the reflector.

    _minutes from previous meetings are here_:

    Anyone with a vested interest in VHDL is welcome to join
    the reflector and either observe or participate in the discussion. I would particularly encourage all experienced VHDL design and verification engineers to join.

    The work is done by the IEEE VHDL Analysis and Standardization Group (VASG). The group is currently
    in the preliminary stages of discussing items to be
    considered for the next VHDL standard.

  2. @Stanton
    I don’t think either IEEE or IEEE-SA is a rant you want me starting so I won’t – other than IEEE-SA is not supported by IEEE and as a result IEEE-SA is struggling to understand how to fund themselves.

    I would like to see this type of stuff “standardized” some how. I think Martin has the right idea when he mentioned open source. In fact, you will find my randomization and coverage packages at http://www.synthworks.com/downloads

    Why open source and not IEEE. IEEE wants to own their IP and not users to read it without a $$$$$ fee per standard. Users on the other hand want to see the source. Honestly, I think both parties are to blame. IEEE is a little to stingy. Users don’t need source – in the 80’s we never had Unix source – we had man pages.

  3. @Martin
    I agree the libraries would not need to be synthesizable – they just need to be widely accepted. After all, ieee.std_logic_1164.rising_edge contains coding styles that are not commonly supported by synthesis tools – however it is synthesizable 🙂

  4. I’ve been doing a lot of DSP stuff lately, and I was thinking it’d be great to also have some things like complex waveform generators at the ready. Something like:

    entity complexSinusoidGen is
    generic (SAMPLE_RATE_MHZ : real)
    port (
    sinFreq : in real;
    inphase, quadrature : out real

    Very easy to do.

Leave a Reply

Your email address will not be published. Required fields are marked *