Thoughts on IC development, EDA, and hardware design languages.

Industry Insights: It is time for EDA to move to Python APIs

Posted by: Brad Quinton | Posted on: March 24th, 2015 | 7 Comments

Share on LinkedIn71Share on Facebook0Tweet about this on Twitter0Share on Google+0Email this to someone

When we started developing Invio we had a few goals we were aiming to hit. We wanted to help push forward EDA innovation by providing a base layer of HDL (Verilog, SystemVerilog, and VHDL) exploration and manipulation that was stable, intuitive, and (most importantly) easy to code to. We knew, as almost every EDA vendor out there knows, that without a Tcl API you might as well just pack your bags and go home. Tcl is just too ingrained in the mindshare of the semiconductor industry for an EDA vendor to not support it. So, we included a Tcl API. But, Tcl has it’s limitations. It’s not really meant for software development but rather it’s strength lies in the end users ability to interact with it. True to its name, Tcl shines when used as a tool control language. So, then we were left with a choice. What language to develop an API used for serious software development? From our experience the answer was obvious: Python.

Part of our bias towards Python was that we had recently, and successfully, used Python in our last EDA startup (Veridae), even though none of the team had prior knowledge of Python. It was a language we were able to ramp up on very quickly and get productive fast. A lot of this is because of the rich set of libraries and strong community support Python has going for it but beyond that, coding in Python felt natural and intuitive with the resultant code readable rather than cryptic (I’m looking at you here Perl…). Exactly the sort of experience we wanted our developers to have when using Invio. Of course, Python is also object-oriented which is a big plus (yes, there is object-oriented Tcl but really? Object-oriented Tcl?…) and dynamically typed which removes a lot of needless clicking on the keyboard. Python code is also dense. Really dense. 5-10X shorter than comparable C++ dense. This allows programmers to develop and debug quickly. Finally, Python has, and continues to, ramp quickly in usage becoming one of the dominant new development languages as per this very interesting graphic from an IEEE report on the Top 10 Programming Languages.

IEEE Top 10 Languages

Now, there are knocks against Python, mostly to do with runtimes. It is slower than very carefully coded C or C++, I think few would doubt that. But the degree of difference is probably up for argument as the Python-native datatypes, iterators, etc. have been implemented “under-the-hood” in very carefully crafted C++. So, with enough time your C/C++ will be faster that Python, but up front it may be the other way around. There are also tools such as PyPy to help out with the interpreted versus compiled runtime hit. As a side note, in the end, many of our Invio APIs are actually C++ implementations under-the-hood as well. We had to suffer so, hopefully, our users won’t!

People also note that Python’s not “close to metal” (that is, you won’t be writing kernel drivers in Python anytime soon) and some say Python over simplifies at the expense of features other languages have. Finally, the upgrade from Python 2 to 3 is taking waaaaaay too long. The libraries are not getting ported, which is a little disconcerting.

In our opinion though, the plusses vastly outweighed any negatives given our goal for our “development” Invio API. Python was a great choice, allowing Invio users to ramp up quickly on the Invio platform and, if needed, on the Python language itself. So far it seems like we chose wisely. But nothing beats real customer feedback. We have recently started a customer engagement, and the first two questions were: Do you support Perl? and Do you support C? We had to say “no”. Yet, once we did, we were pleasantly surprised to see this tweet come in hours later…

A really great endorsement given the customer had to learn not only our API but Python as well! No language is a perfect fit but the trifecta of Python’s rich set of libraries, density and code clarity made it a compelling choice for Invio!

What do you think? Is it time for EDA to move to Python APIs? Have you had any experience with Python, good or bad? Feel compelled to rise to the defence of Tcl or Perl? We’d love to hear about it in the comments below!


Share on LinkedIn71Share on Facebook0Tweet about this on Twitter0Share on Google+0Email this to someone

Comments (7)

  1. Tudor Timi - Reply
    March 24, 2015

    Oh yeah, Python FTW! It also rocks as a scripting language. I’ve finally managed to convince some of my colleagues to dump Perl in favor of Python.

    For getting a lot done in less time, Python is king!

  2. Carlo - Reply
    March 25, 2015

    Any step that will move EDA far from TCL is welcome. As you said TCL is useful as a control tool and suitable for EDA people that have experience with sys admin or scripting but not real software development. As far as Python vs Perl I’m a Perl guy so I’m a bit biased: I agree that probably Python is more readable and so learning the basic of Python or start using the API “by example” is much easier than using Perl. In my opinion Perl is more suitable for “close to the metal” tools dedicated to EDA engineers. So the usage of the two environments is not conflicting and they can be suitable for different tasks.
    However we need to consider that today in the digital world we have a lot more people that know how to write software so the fact that they will feel comfortable with Python doesn’t mean that Python can be considered as the universal language for APIs even for mixed-signal or analog designers: and this is proved by the lack of real APIs for tools dedicated to this community; this problem has not yet a solution and the EDA vendors are not converging. I will endorse Python as soon as I will see a Python API for an analog simulator or a pcell generator…

    • Brad Quinton - Reply
      April 5, 2015

      Thanks for you well reasoned thoughts here. I would tend to agree. And as for a Python API for mixed-signal and analog designers. Keep an eye our a webpage. We will be making a Verilog-AMS announcement very soon that you might find interesting…

  3. Allen Tabbert - Reply
    April 4, 2015

    Great to see an EDA company move to Python! I have been advocating this privately with many of my EDA friends the past three years. Before that I had been using Tcl almost exclusively (for about 17 years). It was okay at first but when trying to do serious development it Tcl it became terrible. Just think what it takes to handle Verilog’s odd escaped names in Tcl. Tcl is just to crude and simplistic.

    • Brad Quinton - Reply
      April 5, 2015

      Thanks for the feedback Allen. Your experience mirrors ours. As ASIC designers we had all used a lot of Tcl experience before trying Python, but we were quickly won over…

  4. Juan Sanchez - Reply
    April 16, 2015

    A key reason for the use of Tcl as an EDA scripting language has been its easy integration with compiled C/C++ and its permissive license.

    Python has both of these features, and is a much easier language to code in. It also has an extensive library of math, visualization, and gui modules available to empower the user to create their own flow.

  5. Pingback: Industry Insights: EDA Development Needs a 10X Productivity Improvement - Invionics - Invionics

Leave a Comment