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. Have you heard of the “library of parameterized modules” (LPM)? Actually, you probably have, especially if you have ever used Altera FPGAs. But it’s use and acceptance have been limited in extent. Why? (not a rhetorical question).

    However, maybe a framework as you envisage it is an idea whose time has come, as a way of speeding up the design of “mega-gate” FPGAs.

    And there are some extensions/improvements to VHDL I would love to see, even beyond VHDL-2008.

    1. @RobertI

      It’s been a while but I do recognize the name. It’s sort of the right intention, wrong direction. I looked at some usage examples here. It’s definitely along those lines, but a cursory google search makes me think that nobody ever got around to properly supporting it and it’s just an Altera thing.

      It’s quite easy to infer a RAM for any FPGA architecture in VHDL by simply creating an array of std_logic_vectors and using an index to the array for the address and adding read and write strobes, so something that is FPGA technology agnostic is certainly achievable. LPM seems a bit too closely tied to Altera, unless I am just not spending enough time looking at it? It’s 2am, so I’m sleepy.

    2. Actually, the LPM was a multi-vendor project but Xilinx dropped out early (maybe they were afraid of too much portability?)

  2. Hmmm I think I am going to have to disagree with you. The moment you start trying to abstract away from the intent of VHDL you start to FORGET what the purpose of the language is which is to create a logic circuit. It’s the same where you are getting engineers wanting to convert their C code into logic yet they do not have a CLUE as to what logic will be generated. For example how do you create a pipelined design in C or C++. How do you create parallel logic ?
    The use of the term programmer is a bit of a give away. I am NOT a programmer, programmers think everything happens NOW. I am a designer, a designer understands the idea that this is still an analogue circuit, if you forget that then you are lost.
    I have seen ‘programmers’ VHDL code and despaired of how they ever dreamt it would work for real.
    As to file IO, what kind of stuff are you trying to do ? You can do all kinds of good stuff when you put your mind to it. I’ve whistled up a 10 digit 7 segment display using the file IO available in VHDL87. File IO is just for simulation, if you want to do anything else then use a language like Perl or even C.
    If you think the VHDL File IO is poor then god help you if you want to do anything in Verilog, now that is completely pants.

    1. Your (classical) complaint against a ‘programmers’ VHDL code is a complaint against someone who doesn’t understand his application domain or his compilers. That *never* works, in no programming discipline.

      Obviously you agree that useful abstractions are possible, otherwise you would use Spice instead of VHDL. The point is that many HDL designers are blind for the useful abstractions available to them, because they are still stuck in an old (schematic entry) paradigm.

    2. “Just for simulation”!!! I spend most of my time running simulations. And yes, file IO *is* a pain.

      Regarding abstractions, as Jan also said, it’s just a case of the programmer knowing their tools and targets. I work in the embedded systems domain where software has to meet real-time goals. If you don’t understand the tools you have there, you’ll miss those goals, just like an FPGA programmer will miss their (eg) timing goal, if they don’t understand what they’re doing.

      But operating at really low-level vs high-level is a separate issue to understanding what you’re doing.

  3. I think it is an excellent idea. I also think both synthesisable and non-synthesisable versions will be much appreciated. I am convinced that sometimes you just want a working block, optimal or not. Also, I think the situation will rectify itself with regards to optimal versions.
    Exactly like GNU libc comes with a generic C version, guaranteed to work on all platforms, but for some platforms and some functions it has optimized assembler versions of functions – people will eventually code VHDL versions optimized for their target vendor. I keep hammering on about the road to EDA liberty: http://www.sigasi.com/content/most-needed-eda-innovation#comment-519 where I outline a path to open tools and hardware. But I realize now I missed something in my comparison to the Open Source software world. Something just as important as an Editor, Compiler and Operating System was the Libc, a foundation of commonly used functions for writing C programs. VHDL is very much like what C would have been if it not would have come with a specification for a common C library. So, what VHDL needs is a (de facto) common library. It does not matter if it is not optimized for all vendors. The same arguments was heard against the C library back in the days. It was much better to roll your own, optimized routines, or even use assembly. In the end, libc prevailed and was even optimized where it mattered. Godspeed, I say!

    1. @Jackob

      I totally agree with your sentiment “I am convinced that sometimes you just want a working block, optimal or not”.

      It is probably the hardest, but best rule to follow as an engineer: Get it working first, then optimize.

      Frameworks aren’t a panacea, and they won’t replace good engineers. Hell, jQuery has probably increased the number of web developers and web startups, not decreased them. The truth is, frameworks lower the cost of entry to creative people who otherwise might never have tried doing something. Dev boards are getting cheaper, Software Defined Radio technology is getting relatively cheap (check out some former colleagues of mine! Epic Solutions Bitshark radio platform), and finally we’re getting IDEs for HDL’s. A framework would be great so that people could get a working prototype up and running, and then spend capital optimizing it later.

  4. You make some good points – and that’s a good list of useful elements. If you stick to non-synthesisable implementations of them, it could work out. The problem with making synthesisable versions is the number of architectures you have to optimise for (I reckon no-one will use them if they’re not optimal). You can get some of them from opencores, but my impression is that they not caught on in industry? I guess licensing might be part of the issue there?

    But maybe all we’re lacking is the catchy name 🙂 I’d love to have a library as you describe to call on!

    1. @Martin Thompson:
      I disagree that we should stick to non-synthesizable implementations. Synthesis tools have gotten really quite good at creating good implementations for just about anything you can dream up.

      I recently built a generic interleaver and deinterleaver block that synthesizes into a very small footprint (unfortunately at work, so I cannot share) and would work well on Altera, Xilinx and Actel FPGAs (and standard cell or structured ASIC technologies as well).

      Of most difficulty perhaps would be DSP style blocks, because in those cases you typically have different quirks between DSP blocks on various Xilinx architectures for instance. But it is still achievable, and I’ve seen it done by engineers on my team.

      Truly reusable and architecture-portable code is absolutely possible, it just requires finding the right mixture between RTL, structural code, and wrapping of FPGA or ASIC specific DSP blocks to help coax the synthesis tool into doing precisely what you want. That said, in many cases that even is unnecessary, as synthesis tools are smart enough to infer DSP48A blocks in a Spartan3-DSP if you use the * operator in VHDL.

      With regard to opencores, the problem seems to me that they lack a direction. It seems like its more of a dumping grounds, and there’s no cohesion like coding standards or common documentation. It seems as though the concepts of frameworks found in the SW development community haven’t resonated with the right people yet…at least til now! 🙂

      1. Actually – I agree about the synthesisablity! I’m not entirely sure why I was thinking so restrictively! As Jakob write below “sometimes you just want a working block, optimal or not.” – not a bad mantra 🙂

        “Truly reusable and architecture-portable code is absolutely possible” – is true, but (can be sometimes) a lot of effort.

Leave a Reply

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