Sometimes things just fall into place in a quirky way. Like when you learn a bit of slang one day, just in time to be in the know the next day when somebody uses the phrase in a conversation and you're saved the embarrassment of asking what the heck we're all talking about. Terms like “sweet” or “sick” or “game” are ones best learned today, lest you not know tomorrow what the heck everybody's talking about.
So it is in the lingo that surrounds technology. One day, some word or phrase is just a term; the next day, it's in common usage and everybody's banding it about around the coffee machine and you're trying to figure out (without asking outright) what the heck we're all talking about.
That's why what you're about to read is going to prove useful. Things are happening in the world of phrases, lingo, slang, and lexicon, and you should be taking notice. The following disparate items - a couple of press releases and a letter from a reader - are all linked. If you read them, you'll be (closer to being) in the know and you'll avoid potential embarrassment next week or next month when somebody throws out something related to all of this. You won't be struggling (quite as much) to figure out what the heck they're all talking about. Sweet.
Press Release I - Platform Based Design Taxonomy v1.0
VSIA (Virtual Socket Interface Alliance) announced the Platform Based Design (PBD) Taxonomy 1.0 has entered Member Review. This is the first document brought to Member Review from the PBD Development Working Group (DWG), created in June 2002. The PBD taxonomy document defines appropriate terminology for the fundamental concepts in platform-based design and classifies platforms with respect to their levels of complexity and three basic design approaches. The overall goal of the PBD DWG is to allow both the platform-architecture developer and the design teams creating platform-derivative products to evaluate and select platform architectures and differentiating Virtual Components that are best
for their application. PBD Taxonomy 1.0 will be in Member Review through December 12, 2003 and VSIA members are encouraged to download, review and comment on the document.
The PBD Taxonomy provides definitions of common terms and concepts used by platform developers and users. This taxonomy classifies platforms according to their complexity, as well as three platform design styles:
- Bottom-up (or technology-driven) (e.g., an FPGA plus a processor core)
- Middle-out (or architecture-driven) (e.g., a processor core plus an on-chip bus)
- Top-down (or application-driven) such as a domain-specific family of SoCs (e.g. MXC, Nexperia, or OMAP)
The PBD Taxonomy also introduces the notion that platform-based products are designed in two phases. This leads to two basic design-team interfaces for platform-based design: “Platform Interface” between the basic component building blocks such as buses and Virtual Components (also known as IP) and the “Architecture Platform” - and the “Derivative Interface” between the “Architecture Platform” and its “Application Derivatives”
Additionally, the Interface definitions set the stage for the next and critical contribution from the PBD DWG: Deliverables from the platform architecture developer to the platform derivative developer.
Per Bob Altizer, PBD Chair and President, BASYS Consulting: “In order to define platform classes and provide a common language, VSIA brought together some of the best engineering minds from key companies in the industry including Alcatel, ARM, Cadence, Infineon, Nokia, ST Microelectronics, Synopsys and Toshiba, among others. The result of the past year's work is a sound foundation upon which to develop vital specifications and standards.”
Press Release II - Hardware-dependent Software Taxonomy v1.0
VSIA released Hardware-dependent Software Taxonomy Version 1.0 (HdS 1 1.0). This is the first document released from the HdS Development Working Group (DWG), which was created September 2001. The purpose of this document is to define and put into perspective common terms important in the HdS context - thereby improving the relationship and communications between SoC hardware and embedded software engineers. The longer-term goal of the HdS DWG is to improve intra-company and inter-company software “virtual component” re-use by specifying an "HdS API."
The HdS Taxonomy defines key silicon-hardware terms and concepts for an embedded-software-engineer audience and similarly defines key embedded-software terms and concepts for hardware-and-platform-development engineers. It also establishes an HdS Taxonomy focused on HdS product development and support in terms of life cycle; hardware and embedded-software-architecture; and platform-design axes. This Hardware-dependent-Software Taxonomy is intended for and includes the contributions of SoC-IP providers, system integrators, EDA tool providers, and OS providers.
Per Frank Pospiech of Alcatel and Chair of the VSIA HdS DWG: “Companies such as ARM, Nokia, Toshiba, Alcatel, Mentor Graphics, Cadence and Beach Solutions have all helped create this taxonomy document, highlighting the fact that there is an industry-wide interest in solving this issue. The release of this taxonomy document is the first step to creating the HdS-API standard, which will help drive SoC productivity by lessening the design gap between hardware and software layers.”
A Letter to the Editor - Ontologies for Electronic Systems
The complexities in electronic systems design are creating technical challenges not only for the EDA tools and methodologies, but also for the information infrastructure required to support the entire design chain from concept to finished product. The infrastructure requirements also extend into the product's lifecycle support. Most companies today are relying on a plethora of IT products to help manage the design, development, testing and support activities related to products. Unfortunately, it's not uncommon to have duplicate data, out of date data, wrongly classified data, and overall general chaos due to the absence of uniform processes for data handling. The problems are particularly
intense as project management attempts to track design flow, and crucial library and silicon IP data.
Although many companies deploy piecemeal solutions to address these problems, very little is being done to understand how such solutions contribute towards the overall improvements needed to facilitate IP reuse, shorten the design cycle, or meet other quality goals. Companies need to realize that improvements in quality come about as a consequence of effective sharing and reuse of knowledge across its workforce. Such sharing and reuse can be facilitated by integrating the various infrastructure solutions through development of metadata standards, ontologies and ontology reuse.
An ontology is a vocabulary of entities, classes, properties, functions and their relationships. Ontologies are meant to provide an understanding of the static domain knowledge that facilitates knowledge sharing and reuse. Among the ontologies identified by Fensel in his 2001 article, “Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce” are:
1) Domain ontologies, representing a target domain, such as engineering, medicine, etc.
2) Generic or Common Sense ontologies, capturing general knowledge about time, space, events, etc.
3) Metadata ontologies, describing the content of information sources. Metadata describes data - it is definitional data that provides information about other data managed within an application. For example, metadata could document data about:
- Attributes: clocks, signals, size, signal type
- Data structures: timing (rise time, fall time, etc.) and test requirements
- Data: where it is located, how it is associated
Being able to describe data is essential for data interchange.
Metadata as part of a dataset allows the dataset to be “self-describing”, so that an application can adjust its handling of that dataset according to the values of the metadata. Of course, users must adopt standard conventions within their own systems as to what constitutes metadata. No matter how metadata is defined, however, self-description is the critical feature in transporting data between different tools, tools that have different models or conventions for handling data. The metadata, thus, provides a guide for converting the data between the different conventions.
Work has been done on Generic ontologies (cyc, SUO, GO, etc.), Metadata ontologies (Dublin Core, LOM, etc.) and Domain ontologies. The recently announced SPIRIT consortium has said that it will work toward developing a standard IP metadata ontology that aims to capture all the IP design, test and integration information and views needed to transfer and exchange IP between companies, so IP users don't have to waste time trying to characterize IP to fit it into their design flows.
Additionally, many generic ontologies have been contributed to the public domain at the daml.org website and there are many other new ones being published. However, when it comes to domain ontologies dealing with electronics and the SoC design value chain, I have only been able to locate a handful.