Design Data Intelligence

We have an urge to categorize companies, and when our limited perspective is of a company that helps with design, we categorize it as an EDA company. That was my view of Magillem, but I have commented before that my view is changing. I’m now more inclined to see them more as the design equivalent of a business intelligence organization – an Oracle or SAP or SalesForce, something along those lines – kind of a design intelligence company. I’m not suggesting Magillem has the scale or reach of those business organizations but it does seem to have a similar mission, within the world of system design.

I was at the Magillem user group meeting recently to understand where they are headed and what users think of what they are doing. Isabelle Pesquie-Geday, the CEO, opened with a business summary, always useful to check reality is headed in the right direction to support the vision. Last year revenues grew 24%, strategic projects are growing (unsurprising when they are in this line of business), they now have a branch in Shanghai, a subsidiary in Korea and have added staff in the US. Business today is geographically split quite evenly between the US, Europe and Asia and is predominantly today with semiconductor companies, with a smaller component in systems companies and a still smaller component in publishing (remember that one).

Back to technology. To leverage design intelligence, you have to start with a common core format. Magillem is best known for their support of XML-based tools, in the design domain supporting the IEEE-1685 (IP-XACT) standard for design representation. This standard data representation is the core of how they manage linkages between components in a system, certainly for blocks/IPs and the connectivity between these but also between system level dependencies – hardware and software views, different levels of abstraction from requirements to architecture, to implementation, documentation, specifications and traceability.

An important point to understand is that the IEEE standard doesn’t aim to replace existing representations of design (eg RTL) or documentation which are already well-handled in existing formats. Rather the goal is to package and link these representations to support easy interoperability between different levels of abstraction in design data models, connections between hardware and software characteristics and, thanks to an open-standard format, to encourage high levels of automation in assembly and verification / validation of these systems. The standard replaces or encapsulates many of these total system design objectives (otherwise described in proprietary side-files) through standard XML schemas.

So what’s the ground truth; how is the standard working out in active SoC design today? At the user-group meeting there were presentations from NXP, Bosch and Renesas and there were attendees from multiple other companies including, interestingly, a well-known supplier of PCB software. In deference to confidentially expectations at these organizations, I won’t detail who said what but I will mention what for me were some important takeaways.

It should be pretty obvious that there is active use among companies working in automotive supply chains, and it’s not difficult to imagine why they might want to pursue this direction. A common standard, auditable format between suppliers should be appealing to show advantages in certification over suppliers with less structured and proprietary data formats. Also I can imagine traceability above the chip level can be challenging if suppliers aren’t using common formats. Through an open standard it should be easier to demonstrate traceability of requirements and impact of changes. Magillem already has a track-record in working with aerospace organizations in Europe where this type of consideration is extremely important.

For all the presenters, these flows have been in production for multiple years. Usage varies from fast and reliable assembly of the SoC top-level with easy configurability to drive multiple verification flows from simulation to RTL prototypes, register / memory-map validation, document generation and update, all the way to all of these plus configurable modeling with mixed views (TLM, RTL, gate).

These are the “classic” applications of IP-XACT-based flows, but where can this lead next? An obvious next step is into traceability. Magillem has already made progress in this direction with their Magillem Link Tracer (MLT). They continue to evolve their traceability goals, moving closer to bi-directional support for linkages between multiple different “documents” in the system definition from specification and requirements to documentation, design representation and verification / validation views. Here the trick is how many of these linkages must be defined manually and how many can be inferred automatically. The IEEE standard takes care of some of this. Connections to documentation for example are still challenging, but read on.

This is where Magillem’s interest in AI starts. They are quite modest about their goals in this area – to develop assistants to help in the system development task rather than any high-flown “robot designer” kind of vision. Dr. Eric Mazeran (IBM) gave a very good background to this area which I hope to summarize sometime in a separate blog. Eric has been in the AI field for 25 years (largely in AI applications to business intelligence) and, when not working his full-time job with IBM, consults with Magillem. Here I’ll touch on just a couple of Magillem applications areas he introduced with Isabelle.

The first is in support of legal publishing – updating legal documents to reflect daily updates based on decrees and other official sources of changes. This is not even remotely in the design domain but is has an interesting adjacency. Briefly, the legal solution combines natural language processing (NLP), deep learning and a references-indexing engine to tag (eg. insert or edit) required changes, compare this to mountains of legal documents to which these changes might apply, then generate suggested edits to appropriate documents. Note “suggested”. The tool doesn’t make the changes itself; there is still a human editor in the loop to check the proposed changes. The tool acts as an assistant to the editor, solving the massive combinational part of the problems – millions of comparisons – to boil down a limited set of changes the editor must consider.

A similar application could help build links between ad-hoc documents and design representations, which then can be tracked in traceability analyses. Magillem is also exploring decision-tree-based expert systems to capture common types of expert knowledge within an organization. These are often problematic because there are too few experts who need to work with too many product teams and there is significant risk when an expert leaves the company. Eric showed a manufacturing example in his talk where a production supervisor walked through a Q&A with such an assistant to diagnose a problem and explore possible corrective actions. Again, the assistant helped the supervisor to get to a workable set of options, from which she could recommend next actions. You could imagine all kinds of hard-earned expertise in production design flows being captured in a similar way.

Quite an ambitious reach, starting from something as seemingly mundane as an industry-standard XML data format for system integration data. You can learn more about Magillem solutions HERE.