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

Industry Insights: Excel is NOT an EDA tool!

Posted by: Brad Quinton | Posted on: February 25th, 2015 | 13 Comments

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

Nor is it a user interface. Nor is it a database. Excel is an accounting and numerical analysis tool, and a very useful one at that. However, I don’t believe it is ever the right tool in an EDA design or verification flow (unless, of course, you are working on the budget!)

As a former IC project manager, I don’t know how many times I have sat down with a very clever engineer to see how they have automated some painful step in the development process, only to see some “unholy” collection of Perl (or Tcl, or SED) tied to CSV files and one or more manual steps using Excel. And my heart sinks. The engineer is inevitably very intelligent and inevitably he or she has solved an important problem, but I know right away, there will be no simple way to reproduce and scale the hard work throughout the organization. And probably worse, the results will not be maintainable in the long term.

Once you have Excel as a requirement in your design flow, you will have the following issues:

    You will require a human “in the loop” to run your flow (or a whole lot of very complex Visual Basic)

    • there goes automated, repeatable regression flows
    • there goes clear archiving and recording of your design process
    • there goes reusability by other engineers (how do they know what you “clicked and dragged” last time, let alone 6 months from now!)

    You will no longer have clear delineation between your data and your processing

    • Excel formulas are very powerful, but they are also very good at hiding the data sources and dependencies
    • it will be unclear what to revision control and archive, versus what is auto generated
    • copies of your data will proliferate with no tracking

    You need to have Windows (or Mac) computers in the loop (Excel does not run on Linux, the dominant EDA development platform!)

    • here comes the need to copy files between different file systems and OSes
    • there goes the ability to use simple revision control to manage files

    Shared access will be a mess (unlike a database, the only control process is file-based which leads to many issues)

    • files will become “locked” forcing people to create copies
    • merging multiple version will be almost impossible

This is not to put down engineers who are using Excel. I think the use of Excel is a good example of IC engineers being too smart for their own good. They see a problem that clearly needs to be solved and they look around for the tools “at hand”, and because they are so intelligent they manage to fit that square peg into a round hole and make things work. It is just that in the end, they will never be able to keep up. The number of cases they have to cover is just too large. The creativity of design and verification engineers is too high and the need for robustness in large IC design flows is too fundamental.

The good news is there are plenty of open standard, robust, maintainable solutions to cover off the functionality that engineers are usually getting from the Excel step.

If you need to store and manipulate data consider:

If you need a GUI consider:

  • Tk
  • Qt
  • or, even better, try to find a command-line solution that will enable automated regressions

If you need to manipulate, copy, reformat your text:

And, if you need to parse, explore or manipulate your Verilog, SystemVerilog and VHDL design (shameless plug alert!):

I believe that in every case where Excel is used in an IC design flow, there is always a better way that will pay off in the end with more robustness and higher productivity, but I’m sure there are others who will disagree, and I’d love to hear your thoughts. Do you use Excel in your design flow? Have you been burned by it? Or are you happy with it? Do you have other approaches that work? I’d love to hear what you think.


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

Comments (13)

  1. Shawna Quinton - Reply
    February 25, 2015

    You could blog for years about the misuse of excel! I used it in all the wrong places in my previous job. I realize this blog is mostly read by hardware developers but how does someone who is not a programmer get away from it?

    • Brad Quinton - Reply
      February 26, 2015

      @Shawna, it is true! There are many misuses of Excel! I think that is because most people fundamentally know that computers can help them with certain tasks, and for most people Excel is that only “programmable” software they have easy access to. One of the biggest take aways I would give to non-programmer on how to use Excel (if that is all they have), is pay very close attention to the what constitutes data inputs to your spreadsheet, and what is calculated data. Then keep the as separate as possible. In computer science there is a famous quote: “Algorithms + Data Structures = Programs”. It really emphasizes that in your computer program you have data, then you write algorithms to manipulate that data, and that these are separate things. Excel blurs the lines between these two concepts, which leads to spreadsheets that are completely unmaintainable because you can’t figure out of the a cell is a input our output of the spreadsheet.

  2. Paul - Reply
    February 26, 2015

    As one of my colleagues pointed out, there are perl modules that can read excel sheets directly. Of course, OpenOffice can also save in excel format and it does run on linux – so spreadsheets can be integrated into a proper unix flow, all the other problems notwithstanding.

    • Brad Quinton - Reply
      February 26, 2015

      True. And OpenOffice certainly runs on Linux, so it is possible to make a Linux based flow, but that does not save you from the fact that someone, somewhere has to create the first spreadsheet manually. It can all be done. It is just questionable as to why when there are so many great alternatives that are now available.

  3. Srini - Reply
    February 26, 2015

    Nice blog entry indeed. In the pre-IPXCT days many customers preferred custom XL formats for Register specification and we have developed several PERL scripts to parse and spit out VMM/OVM RAL/RGM code from them. But as the article correctly points such scripts tend to be very specific to that team/project and requires constant maintenance. XML (IP-XACT) did solve that issue. Then comes the Verification Management part – something that still is done by and large via XL as managers (with Windows) like it. The other paradigm where customers use XL is interconnect specification for large SoCs. Recently Cadence has an IWB product to automate it beyond XL I guess, but for wider users this is still not available. So I see XL still alive.

    What are your thoughts on how these could be avoided please?


    • Brad Quinton - Reply
      February 26, 2015

      @Srini. Thanks for the positive feedback. I agree IP-XACT is much preferable to Excel for register definitions. I have also spent a lot of time trying to maintain Perl scripts that extract data from Excel to create Verilog registers… and as you say, it is a constant maintenance burden!

      Verification Management is an interesting issue, and probably a better use of Excel, but many modern project management software packages (especially the ones designed for Agile development) use true database backends. For example we use Jira from Atlassian at Invionics, and I have also used Agilo from Agilo Software. The great thing about using a database backed system for project management is that it is really easy to create new “views” and make changes. Often excel based systems work OK at first and then breakdown as project requirements, deadline and resources change. They are also much easier to extend to generate e-mail, automatically create charts, etc.

      On the interconnect issue, I really don’t think Excel is the right tool. There are a few tools from the major EDA vendors that can handle some of the tasks, and a number of our customers have been creating their own “RTL Assembly” applications using Invio. So far the results are impressive as far as time to implement and on-going maintenance support.

  4. Steve - Reply
    February 26, 2015

    Perl can process excel spreadsheets directly. The spreadsheet can be treated as a source file and checked in and revision controlled with one of the many config management tools that are common to Windows, OSX, and Linux.

    With this flow you don’t need a human in the loop and you don’t need a Mac or PC in the loop (although you need one at the beginning), and you don’t need shared access.

    You are correct about the loss of distinction between data and processing, however humans also write bad RTL, bad directed tests, etc.

    • Brad Quinton - Reply
      February 26, 2015

      @Steve. I agree that humans write bad RTL too. We’ve all seen lots of it, but Excel almost forces you down an bad path, even when you know better! It seems like a real shame to start with something like Excel, when there are great alternatives around and as highly technical people we have the ability to use them.

  5. Evgeni Stavinov - Reply
    February 26, 2015

    A few years ago I created an online tool ( ReportXplorer: ) to solve the problem of dealing with lots of FPGA reports from multiple builds. I still use the tool, but don’t actively maintain it.

    In my current job as FPGA designer, I routinely write small Perl/Python scripts to parse tool logs and reports, and dump the information into Excel tables and charts. But what I see is most of FPGA developers don’t have good script writing skills.

  6. John Eaton - Reply
    February 27, 2015

    You should also mention Visio as another horrible EDA tool. We used to enter our IC designs using a schematic capture system until the 90′s when designs outgrew the tools and we switched to RTL-Synthesys.

    While this helped all the leaf-cell designers it was a problem for all the system Architects who used to use the top level schmematics to create the block diagrams and documentation.

    With no more Schematic capture tools available the Architects turned to visio to do their work. The problem was the actual design was no longer generated from the documentation. Syncing them became a error prone manual process.

    John Eaton

    • Brad Quinton - Reply
      March 4, 2015

      I agree John. It seems a real shame to use a general purpose drawing tool to describe hardware when there are well understood solutions for creating, and checking schematics which would do the job *and* allow for better automation.

  7. Paddy3118 - Reply
    March 31, 2015

    Sometimes you have to go with a spreadsheet as it is a pre-built GUI for easy editing of tabular data that must be manually maintained.

    So, rather than build a QT GUI that will be less performant, unknown to the users, and a big delta on the maintenance you can:
    1. Stipulate saving in xlsx standard format (Or the openoffice one).
    2. Stipulate no formulas in the saved file, and that if it wouldn’t be in an exported CSV then it shouldn’t be in the xlsx.
    3. Check for no formulas as well as checking the data when reading the xlsx using Perl/Python xlsx readers.

    As others have said, You can use OpenOffice as well as Excel if you need Linux access, but this only works if the data you read from Excel does not need functions, (although functions can be saved on otherwise unused sheets and copy-pasted as necessary then the functions replaced by their value).

    I don’t underestimate the maintenance task of adding a GUI tool into what would otherwise be a command-line flow. I hate having to maintain GUI code that is X times larger than the logic behind it and which everyone wants to “improve” the layout just because it is something they think they can have an opinion on.

  8. Anday - Reply
    February 21, 2016

    Такс все снес и заново переустановил изначально файл ini вот такой Что здесь изменить???user-loginlog ..\..\log\olap_server.loghttp 7921verbose infosplash-limit 1000 500 100goalseek-limit 1000goalseek-timeout 10000cache-barrier 100000clear-cache-cells 10000

Leave a Comment