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

How much is that home-grown Perl/Tcl script costing you?

Posted by: Brad Quinton | Posted on: December 2nd, 2014 | 14 Comments

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

It always starts out so innocently. You run into a roadblock in your design/verification process and you say to yourself: “I could write a quick script to fix that…”. And so you do. It goes pretty well at first, but there are a few bugs and you need to spend a little time on StackOverflow. You then find a few special cases in your Verilog that costs you some time but you still manage to get it done by noon. (Cost: 1/2 day). Now you are feeling pretty good. “Software is easy”, you say to yourself, “this is going to save me a bunch of time.”

At lunch you mention your exploits to your co-workers, and they are impressed. “That sounds great. Can I use that script?”. “Sure”, you say, feeling good that others are going to benefit from your proactive approach. After lunch you sit down with your first “customer” and walk him or her through the paces. “Got it, thanks”. (Cost: 1.5 hours).

Time to get some work done! You put on your headphones and get down to it. Just as you are getting into the groove, you get an e-mail: “I’m having an issue with your script.” “No problem”, you say, “I’ll take a look”. “Ah!”, you say, “You are using ANSI-style port declarations in your design, I’ll add that to the script.” You put your head down, do some good work, stay a little late, and bang!, finished: ANSI-style port naming covered. (Cost: 1/2 day).

You get to work the next day, and you are a bit behind having lost a day, but your flow is working great. With your new script you are hopeful of making up time. And, for a few days, you start to catch-up. Then you get another e-mail, this time from the Chip Lead, “Bob gave me the script you wrote, works great, but…it doesn’t handle Verilog generates. We’d all save time if you were able to fix it up.” “Hmmm… “, you say to yourself. “This is getting to be a bit more work than I imagined, but that’s OK, it will save the project a lot of time”. You sit down with the Chip Lead to understand the new requirement (Cost: 2 hours). And you agree to add the new support. By the end of the week, its finally done. (Cost: 4 days).

“It’s there” you proudly e-mail the Chip Lead. “OK, back to work!”. Off you go, but now the e-mails really start coming in “Does this script handle Verilog gates?”, “I’ve got VHDL black-boxes”, “I’m getting incorrect Verilog syntax”, “Did you know that Joe in the San Jose office has a similar script, you should talk to him…”. Gotta put out these fires (Cost: 2 days).

Now you are really falling behind, you talk to your manager and he says “This is taking too much time. Better pass this off to CAD”. Which seems reasonable. Big meeting with internal CAD, you walk everyone through the issues and the script, and start to pass it off to a new hire in CAD. (Cost: 3 days).

You have escaped, but the CAD group hasn’t. Now, they get “What about arrays of instances?”, “What about positional port naming?”, “what about implicit wire declarations?”. It is time for that new hire to make his mark, so he goes for it and starts to really expand the scope of the script. (Cost: 3 weeks). As with every reasonably sized software project there is now ongoing maintenance. (Cost: 1 day/week).

And then it finally happens, your company acquires a new product line, and they REQUIRE SystemVerilog support. (Projected Cost: 6 months+). Now what?

Time to take stock of the costs of that home-grown Perl scipt:

Development cost (Verilog only): ~5 weeks fully loaded cost (in North America): ~$24K
Support cost (Verilog only): 1 day/week fully loaded cost (in North America): ~$50K
Update to SysteVerilog: 6 months+ fully loaded cost (in North America): ~$125K

$24K already in; $50k/year in on-going support; and the potential for another $125K in costs! Things are getting expensive. But what’s the solution? In the end, that script really helped the IC Development process. It may have shaved a week off the time-to-market, making a meaningful impact on revenue, not to mention the highly valuable time saved by all the designers. At Invionics, we strongly believe that internal innovation like this is an important part of delivering competitive and timely silicon. And we want to help!

Our platform, Invio, includes a full parser and elaborator for Verilog, SystemVerilog, and VHDL. Invio also has intuitive Python and Tcl APIs enabling you to rapidly develop internal tools that are robust, high performance and complete. AND, best of all, we provide the support!

To see the power of developing internal applications with full parsers and intuitive, high-level APIs, check out our 5 minutes to flop detect tutorial.

What are your experiences with home-grown scripts? Do they resonate with ours? Do you have any scripts that grew out-of-control in your past? We’d love to hear about them…


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

Comments (14)

  1. Tudor Timi - Reply
    December 3, 2014

    Another point I’d like to add is that often times, people in hardware companies don’t have the discipline required to maintain an internal tool throughout its life-cycle: no documentation and only ad-hoc support processes, no bug tracking, etc.

    • Brad Quinton - Reply
      December 3, 2014

      Its true. I have seen exactly that at hardware companies I have worked for. In many ways it is surprising, given the intense discipline required for successful hardware design. (There is a probably a few blog posts just on that topic alone!) It may be that the problem is one of ownership. If you have a hardware designer you “own” you hardware design, but the Perl script you wrote is something extra, and often something you have to deal with “after hours”, not your *real* job. In any case it is something that should not be ignored. In the end I believe there is huge potential in internal, custom development if it can be managed correctly.

  2. Charlie Baron - Reply
    December 3, 2014

    No idea what you’re talking about Brad :) The whole elephant on a tricycle act.

    There is little motivation to get this stuff right and it gets little acknowledgement in the companies I’ve worked for.

    The worst is when you have many designers as authors, each adding their ‘value’ to the same flow. Chaos.

    Important/useful flows for a process have to be identified and planned carefully as early as possible. In your example – the chip lead should have recognized that the script was useful enough to invest in its standardization.

    Still scripts/flows generally morph into something that was unexpected and having a tools to manage that is a good idea.

    • Brad Quinton - Reply
      December 4, 2014

      Totally agree Charlie. We’ve all been there. Working hard to try to help build something really useful, and often without the tools and support we need. AND often no support from management! Some long fustrating nights…

      I think that recognizing that these scripts are *real* applications that provide *real* value, and putting the tools in place (like a platform with a real HDL parser) to do them right is a big step. In the end everyone is trying to get their chips out the door faster using whatever means necessary. Home-grown automation is part of that, so why not support it properly?

      Thanks for again for the great feedback! Keep it coming.

  3. vesselin kavalov - Reply
    December 3, 2014

    Writing ‘a script’ to deal with human-written Verilog code (as if Verilog as a language doesn’t suck enough) is a mistake every single time – reminds me of the ‘Sirens’ from the Oddysey’s journey – so appealing and so deadly. Unfortunately, due to the highly sucky nature of Verilog, every major EDA company supports some subset/dialect and until and unless your parser is compatible with their crippled version and interpretation of the language – U R fighting a loosing battle. I believe that’s why the EDA industry will NOT agree to use a single source parser – that’s how they hold U hostage. I spent nearly half of my professional life working for various EDA companies and all of them suck in their own way. The other half I worked for various ASIC design companies either as an employee or a consultant, mostly writing scripts to make sure I can get a working flow when piping together a half-a-dozen crippled-in-their-own-way EDA tools. This is a black magic very much needed and very much appreciated by ASIC companies. I hope that U guys came up with a useable parser. Verific wanted to be ‘DA ONE’, but it requires the user to be almost half a parser-developer in order to get something practical working

    • Brad Quinton - Reply
      December 4, 2014

      You nailed it on the head Vesselin “so appealing and so deadly”. If you don’t have a high quality, robust parser as the basis for your Verilog, SystemVerilog or VHDL tool/script, you are doomed to a downward spiral of support.

      And your point about the various EDA interpretations of the languages is correct to. It is a hassle, but one that we anticipated (based on hard-won experience) and are able to manage. We have a very simple API to allow our users full control to downgrade (or upgrade) all parsing ERROR, WARNING, and INFO checks. Using this you can upgrade or downgrade each check to match you other tools particular interpretation of the language (this is critical right now in SystemVerilog, given itself complexity and immatruity). Then we take this a step further by providing “compatibility modes” that upgrade/downgrade groups of ERRORs and WARNINGS to match the particular interpretation of a given mainstream tool, like Design Compiler, or Questa, etc.

      Finally, full disclosure, we use Verific’s parser libraries “under the hood”. That’s why we are so confident we can take on FULL language support for Verilog, SystemVerilog and VHDL. Verific’s libraries are very high quality and heavily tested, but as you say they can be very difficult to use without a deep understanding of low-level EDA development. Our vision for Invio is a true development platform for internal EDA that includes a the parsers you need, but doesn’t force you to interact with them, unless you need to. To use Invio you do not need to be a parser or C++ expert. Basic Tcl or Python is all you need to create high quality, high performance tools.

      If you have time, Vesselin, I’d encourage you to take it for a spin… Get Invio

  4. John Eaton - Reply
    December 9, 2014

    Brooks said it best 40 years ago in the Mythical Man Month. Every team needs a “Toolsmith” who’s sole job is to make sure that all the design team’s tool needs are met. This is not a CAD department that sits over in another building and mainly downloads tools and runs the license servers. If you have a problem with running verilog then all they do is to make sure that it comes up with a command line prompt, the rest is up to you. They are also not hardware engineers who know a little perl. They are a real ™ Software Engineers. They aren’t a R+D engineers either. They are Manufacturing Engineers. Todays IC’s have grown to the point where IC design is no longer an R+D problem, it is also a manufacturing one as well and the solution requires modern manufacturing thinking.

    The Toolsmith is embedded in the design team and can make the “make vs buy” decisions for the team.

    The best solution is to leverage the success of open sourced projects like linux or gnu. If all design teams were to work together and create open sourced rtl design tools then we can benefit while sharing the workload.

    • Brad Quinton - Reply
      December 9, 2014

      Exactly, John, we are very much targeting the “Toolsmith” with our Invio platform, to give him or her the core tools needed to maximize the design team’s productivity. In my experience, these Toolsmiths do sometimes live in CAD, but as you say they can often be embedded (to good effect) in the design team. I’ve also seen the emergence of “Methodology” Engineers that work with multiple design teams to maximize productivity. And, I bet, they have a lot in common with manufacturing engineers….

      Open source is also a powerful concept, but I’m not convinced that it could work in areas like SystemVerilog or VHDL parsing, because of the huge development and support effort required coupled with the quite small user base. In most of the successful open source projects only a tiny fraction of a percent of the users actually develop, but because the deployment is so large, it works. I don’t see the economics working here. The development and support effort is so large, and someone has to pay those salaries.

      Thanks for your feedback. We really appreciate your thoughts!

  5. John Eaton - Reply
    December 9, 2014

    Hi Brad,

    I spent most of my career in asic test/synthesys and verification and I can see how your tool would be a great help in dealing with hand crafted rtl code from a designers with a wide range of skills. But the future is not to deal this code but rather to replace these coders with higher level languages that don’t make stupid mistakes.

    You should be looking at “correct-by-construction” tools to generate code that doesn’t need a tool like yours to ensure that it matches the spec. It matches the spec because the tool was designed to read the spec and follow it.

    Human designers tend to have problems with following directions, tools don’t.

    • Brad Quinton - Reply
      December 9, 2014

      John, I would tend to agree, higher level tools that are both more abstract and “correct-by-construction” would be a a huge step for the industry, but we still have to get from where we are today to that new ideal. And, I think that a platform like Invio that lets you work with SystemVerilog at a more abstract level could help build the bridge to that new tool. Remember, Invio can create SystemVerilog as well as read it, so you could create tools with Invio where SystemVerilog is the bridge (under-the-hood) to the traditional tools while creating a new paradigm top. Eventually the tools would support the new design definition paradigm directly (much like schematics and netlists have fallen away in favor of RTL…)

  6. Michael Back - Reply
    December 14, 2014


    Thank you for your article about the modern need for and dilemma of integrating automation in our day to day work… But, I took something more out of your article than you might have intended.

    My thought is that building tools for automation is now part of the job. It is a skill set that is in demand and has moved from being something that the wizard of the office did to something everyone is expected to be able to do.

    What I see in your article is a broken/non-existant development process, and likely use of a language that is not well suited to task (I can’t read my own perl after even 1 hour of leaving it aside) and 0 time spent in documentation. The problem exacerbates because the one-off tool’s scope expands and as it is built on a shaky foundation. The tool is useful and saving people time, but management seemingly does not reapportion tasks appropriately given the new productivity improvement.

    But… This is not really the whole story. The world of scripting is now a much better place with more polished languages like Go, Python, and Rust. Revision control is now mainstream with git and github. Documentation is still an issue — as is management expectation.

    Automation is now something that we just need to – it’s expected. We need to start thinking about our tools development in a way that we aren’t just writing one-offs for ourselves any more, but that from the get go we take a disciplined approach – using the correct tools for the job and building them wit the attitude that it is going to be used by thousands of people into the future with 0 time for support from the author.


    • Brad Quinton - Reply
      December 15, 2014

      Thanks for the comments, Michael. It is a good point you make. There really is the possibility of delivering high-quality internal tools, in fact we are counting on it ;-), but as you say, it is not just because of our platform. Python, especially, has found a great middle-ground between being easy to learn and use, and yet, powerful enough for real development. To anyone still using Perl, I highly recommend Python as a better place to be.

      That and the great cloud-based revision control systems out there, really can make a huge difference in the support burden.

  7. Robert Heller - Reply
    December 15, 2014

    The problem is not the script itself, but whether or not to let the script become a project in and of itself. Maybe this means that if you write a special purpose script, for a specific task, you don’t share it. Or if you do, you do so with the provision that you are not going to add features (since you have better things to do with your time). If someone else wants to use your script as the basis of a script to do something else, then that someone else can ‘fork’ it for their own purposes. It should be noted that this really applies to any piece of software — feeping creaturism is often something to avoid, even though it might seem harsh and unfriendly to some end-users.

    • Brad Quinton - Reply
      December 16, 2014

      @Robert, agreed, definitely not the script itself that is the problem, but I think that the prevalence of scripts in the IC development process today is a demonstration of a larger need in IC design. To get your chips your the door, and remain competitive, you need to create innovative design flows, so there is a pressure to create something you can share with everyone. Once you have that need to share, I’m arguing you need to build an proper infrastructure to support that development.

Leave a Comment