When you go to one of the major shows like DAC, you expect to pick up on whatever the latest buzz is. There’s always a topic or two that is on the tip of everyone’s lips, the subject of whispers and gossip and speculation, involving contestants in a “who-can-outshout or -out-outrageous the other guy” competition in a shameless attempt to garner our uninterrupted gaze.
And, in any given year, you can probably guess what the flavors of the year are likely to be. Generally they are a) something completely new, b) a radical improvement in performance of something old, or c) something that’s always been around that for some reason gets elevated to exalted status, like AMS.
Under this top level, things pretty much bubble along, with a mix of obvious things vying for the few remaining breaths of oxygen in the exhibit hall.
And then there are the steady-Eddie technologies that are on display every year: things that aren’t necessarily new but that you can’t do without; things that their purveyors hope to keep somewhere in your mind. Maybe nothing new is happening with the technology, but it hasn’t disappeared yet either; it’s a forget-me-not kind of thing.
This year, what you would have expected to be one of the latter topics managed to promote itself from a simmer to a steady, if not rolling, boil. Even participants in the business were surprised at the new life injected into the space.
And what vibrant industry might be stirring to life? The generally staid “design management” business. Generally referred to as “DM.” Although the name is somewhat over-reaching, since it’s really the hardware equivalent to software configuration management, so “hardware configuration management” might be a better term. Except that it doesn’t really cover all hardware, it’s analog; to these guys, digital (RTL) is basically software. (Except to software guys.)
This is one of those areas where the insiders have their world well-defined, but, to anyone else, we need to do a bit of calibrating. So let’s back up and start from the basics.
With ICs, just as with any commercial design process, a disciplined design workflow is important. This means, in part, making changes to a design, stabilizing a new iteration, and proceeding from there. At various points along the way, options, variants, or other derivative offshoots may be desired, and it’s important that each of those be kept separate from the others and that their respective design information doesn’t get mixed up.
This isn’t rocket science, of course. It’s a system involving perhaps a main trunk of development, with possible branches here and there for variants. The “tree” metaphor is certainly used in the software world, although it’s actually a less appropriate metaphor for software than for hardware. With hardware, you may start with a main trunk and branch, but each branch has to come to an end, as does the trunk itself: at some point you need to tape out and actually build one or more chips.
With software, you’re never done, and the trunk continues. Which kind of makes it not really like a trunk, more like a Bermuda grass rhizome or something. It may branch a lot, but it goes on indefinitely, eventually corrupting the neighbor’s rose garden if you’re not careful.
That difference aside, it would seem that, with hardware, you’re doing the same thing as with software. You need a configuration management system to make sure that you don’t have multiple people making mutually-exclusive changes at the same time, and you need to keep careful track of which version of the design you’re working on at any given time.
With digital hardware, the design files are all text, which is why “hardware” designers consider digital to be software. In other words, you can use a software configuration management system (SCM) just as well on digital hardware as you can on software.
With analog, things are different. Now you’re working with schematics, and there are a variety of files that interplay to give the visual schematic representation that you look at while doing the design. Files get turned into cells and libraries and views. So you don’t have the luxury of a single ASCII text file describing the entirety of a portion of the design; you have a bundle of non-ASCII files instead. And this bundle must be managed as a unit. Hence the existence of hardware design management systems.
The granddaddy of all of these systems is Synchronicity, which is now owned by Dassault and sold under the ENOVIA brand (you can search the site and find references to Synchronicity, but you can’t find it along the standard navigation path – you have to go to the ENOVIA page, then click on the Semiconductor link, and, even there, the venerable old name is pretty much absent). Given the breadth of product lifecycle management (PLM) coverage that Dassault takes on, it’s not a surprise that their specific semiconductor slice of that is pretty quiet.
Next up is ClioSoft, with its own proprietary system. Like Dassault, it manages the various files as objects, making it unnecessary for users to worry about which files to associate together when branching, checking in and out, and other basic operations.
IC Manage took a different approach, deciding to leverage the open source SCM world, putting a hardware layer over Perforce. The logic is obvious: if the SCM foundation is already in place and used by large numbers of software users, then why not bring it into the hardware realm as well and focus development only on the adaptation to hardware. Global Design Platform (GDP) is their offering for managing large IC design projects, with additional Perforce integration tools available for various IT-related tasks.
And, turning up the heat yet more, a new company, Methodics, has now tossed its hat into the ring. They have a VersIC platform that they layer over either Subversion or Perforce (don’t get those first syllables confused…). On top of that they have additional modules, ReviewIC and MergeIC, that can be added (with more planned). ReviewIC is intended for managing design reviews; MergeIC is for finding and managing the differences between two versions of a design.
Everyone targets integration with Cadence, which makes sense, given Cadence’s dominance in the AMS space.
So now there are three pure-play DM companies where there used to be one (that is, after Synchronicity got scooped up). And using SCMs as the basis has put proprietary systems – like Dassault’s and Cliosoft’s – on the defensive. A couple years ago, Cliosoft even found itself the victim of a scathing one of those “anonymous” review posts on a website that heavily moderates what gets posted (meaning that a response post may not – and in this case, did not – make it through). The review was, according to Cliosoft CEO Srinath Anantharaman, not at all an accurate description of their product; he figures it was based on a pre-beta version that had been delivered to deal with a specific tactical situation. But this illustrates the tenor of the times.
The jousting takes place over performance, reliability, and capacity; it detours off into IT territory with respect to where files are kept, how they are transferred, how many versions there are, and other such topics that generally do not fire the imaginations of designers. The real issue here is the fact that the design files are huge, so they take up lots of disk space and memory and take time to copy and shuttle around on the network.
For example, when it comes to storage, apparently Subversion creates two copies of design files, one dirty and one clean, to avoid going back across the network to make comparisons. So performance is improved at the expense of capacity. Cliosoft uses symbolic links instead, which aren’t provided by SCMs.
This more or less gets to the heart of the tussle between the old-school tools and the newcomers. The new open-source guys point to the proprietary nature of the older systems as being a liability: a company like Dassault or Cliosoft has the burden of maintaining the entire software stack, while IC Manage and Methodics have the benefit of a publicly maintained portion of the stack. On the flip-side, a proprietary system can be changed to provide any feature desired (if there’s a good enough reason to); if open source software is used as a basis, then you can do only what’s consistent with that software.
One argument used in support of the open-source approach is that the open source tools are much more broadly used – based on their primary software constituency. But Cliosoft’s Anantharaman says, “By that argument, everyone should be using Windows and no one should be using Linux.”
The decision as to which to use is not trivial and covers a number of considerations. And many of them are in the realm of the IT guy. But they have a real impact on what the designer’s world is like. Given the amount of energy being given to these tools and the increasing number of choices, the decision is likely to get harder before it gets easier.
Links:
Dassault ENOVIA (semiconductors)
