Tool Trends Highlight an Industry Trend for AMS designs

Archaeologists often use tools found in digs as a major indicator of trends in civilizations. The same could be said for trends in design, though we don’t have to reconstruct these design trends – we tend to see them ahead of us.

The trend in this case is the growing importance of sensors in designs and there’s no better example of that trend than in the evolution of smart cars. The use of sensor technology has now become an integral part of the nervous system of many automobiles. Almost all of these smart cars depend on sensing behavior and surroundings and have found application in demanding areas such as dashboards, brakes, vehicular response, increased safety, comfort etc. One common thread in all those systems is the usage of analog/mixed signal designs (AMS), often with a mechanical or micro-mechanical front-end.

The usage of AMS is what is driving this important tool trend. AMS designs typically have few overlaps with tools used in digital design but one area where design needs are starting to overlap is in design data management (DDM). Historically, small AMS design teams building more or less from scratch would see little value in DDM. But now even these small co-located design teams can see the merits of using design management for AMS designs. For medium to large design companies, with AMS designs becoming more complex and distributed, design flows are growing more involved, ignoring DM solutions is no longer an option. With analog design modules being integrated with digital and RF components, the need to have an underlying data management solution is inevitable. In the automotive space, quality and reliability is an exceedingly important criterion. With the sensors expected to last the life span of the vehicle, it becomes important for companies to know which revision of designs was used for the sensor along with the fixes made.

One can always argue that the data management for the design of sensors and SoCs could be done by using the traditional tools for digital SoCs. But the needs of the AMS designs, are quite different from digital designs. Digital design data prior to implementation is textual, and consequently rely on the same kinds of DDM tools used in software development. However AMS design data is done using schematics and layout in binary format. This has several consequences, which does not fit well with conventional software based DDM:

• Since AMS designs are saved as binaries, branching and merging versions are very complex operations. Comparing two schematics or layout views require specialized tools which cannot be done by software based DDM often used for digital design as well. To ensure parallel development of designs, it becomes necessary to incorporate strict locking mechanisms. Checkout must lock an object for further checkouts, even by the designer who did the current checkout (until they have checked it back in).
• Hierarchy and view dependencies are trickier. A cell view has multiple files, which need to be checked in and out as an atomic unit and hierarchical dependencies to other design objects (in other files) can’t be discovered easily without in-depth understanding of the implementation tool vendor’s database. This point alone explains why conventional DDM tools are probably never going to support AMS design.
• The binary representation of design objects also requires more space on the file system than text based data. Since every user has his own personal copy of the project state this data must be stored and moved frequently, which creates additional costs and may become a performance bottle-neck for remote sites. A DDM should consider mechanisms that reduce the amount of traffic with remote sites.

But despite these restrictions, AMS designers still need the capabilities that digital designers expect: checkin and checkout control, ability to work with a local copy (isolating you from in-process changes in other areas), tagging at checkpoints and so on. An important factor for user acceptance is how well the DDM is integrated with the design tools. Unlike software developers, who are used to working with their favorite text editor command line tools, analog/mixed-signal designers work in a GUI environment and are expecting (a) a graphical visualization and (b) not having to switch between tools to handle and modify the design data.

ClioSoft’s SOS design management platform is one solution designed to meet these expanding needs. With over 200 customers developing a wide spectrum of SoCs, their robust solution is easily customizable to meet the requirements of any company. Moreover, with partnerships with all major EDA vendors, ClioSoft’s SOS is the only solution which can manage the design data for all types of designs – analog, digital and RF. What’s telling is their adoption stats, particularly in Europe which is the center of gravity for a pretty significant percentage of automotive electronic development. Among others, SOS has already been adopted in companies such as Infineon, Elmos, Creative Chip and Micronas.

Elmos recently drafted a very informative white paper on why they chose ClioSoft SOS for their DDM solution. They highlighted support for local cache servers as an important differentiator, allowing for very responsive access to all files being used at that site without requiring huge amounts of disk space. The white paper also has some pretty interesting discussion on how they managed co-development of analog and digital design in the same hierarchy, where the digital design is managed by SubVersion. They also talk about using SOS to manage tool configuration across all users and to manage tapeout.

Perhaps this is all ho-hum to digital designers but is has become essential in the world of sensor design and that’s driving a pretty significant shift in what is important for AMS design data management. You can request the Elmos white paper HERE.

Also Read

Managing International Design Collaboration

Making your AMS Simulators Faster (webinar)

3 small-team design productivity challenges managed