You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

  • Simplifying Requirements Tracing

    Requirements traceability is a necessary part of any top-down system specification and design when safety or criticality expectations depend on tightly-defined requirements for subsystems. Traceability in this context means being able to trace from initial documented requirements down through specification and datasheet documents to the design implementation and to the testplan. Standards such as ISO26262, DO-187C and IEC 61508 demand that critical requirements be verified by demonstrating traceability through these documents and design materials.

    Article: EDS Fair: Dateline Yohohama-requirements-tracing-min-jpeg

    This is not so easy. The path to be traced contains in part documents requiring human interpretation, validation and cross-checking and in part design data which lends itself to automating interpretation, validation and cross-checking. The human-dependent part of this tracing is a significant contributor to the cost overhead and incompleteness of requirements tracing efforts. Which raises the obvious question Ė isnít there a better way? You canít get humans out of the loop completely and, for that reason, you canít get documentation out of the loop completely. But can dependence on human review and verification be reduced in some meaningful way?

    Getting there is obviously more difficult if there arenít machine-readable links between specification, design and documentation, a state of affairs that is still common today in many design shops. But it is possible to have quite good links between these components in SoC/subsystem design given an integrated methodology. Magillem call this ISDD Ė integrated specification design and documentation. Unfortunately you canít get there by just adding a tool to whatever unstructured spec/design/doc flow you already have. You must switch to a more structured SoC/subsystem design process incorporating links to specification and documentation.

    Which in this world means IP-XACT. I donít believe anyone will contradict me when I say that Magillem has gone further than any other EDA vendor in delivering commercial products around IP-XACT. I competed with them for several years so I know a little about this area and what they can do. Moving to IP-XACT may require a big switch in methodology which can seem daunting, but I understand tools have evolved significantly to make this much simpler. So letís assume you decide to make that transition Ė what can Magillem do for you in requirements traceability?
    Article: EDS Fair: Dateline Yohohama-magillem-link-tracer-min-jpg

    The mechanism they provide is called Magillem Link Tracer (MLT). This connects interdependencies in specifications, documents and the design through dynamic typed links (I assume connecting to vendor extensions in the IP-XACT schema). Their objective is not simply to push data out to documentation from the IP-XACT database but instead to provide a check and synchronization mechanism between all these views, such that a change in one can be followed through to dependent views, in each of which you can choose to accept or reject a change.

    Article: EDS Fair: Dateline Yohohama-dependency-links-min-jpg

    The tool displays links between dependent documents and design components. Note that here links arenít just back to the design database; there can be links between documents also, allowing for smart reuse of content between different document views.

    Article: EDS Fair: Dateline Yohohama-modified-requirements-reflects-dependencies-min-jpg

    When you change a requirement, impacted resources are flagged and you can drill down to accept/reject changes. For specifications and documentation this can update appropriate fields, under your control since you want to see where changes are implied before you accept them. Of course a requirement change wonít make design changes automatically Ė there you will need to go into Magillem design tools to make the appropriate changes to match the new requirements. Changes donít have to start from the requirements; you might choose to make a change in the IP-XACT design representation, in a register or address map for example, then use the same dependency computation to see where and how that will ripple up.

    This kind of analysis can be a valuable contribution to supporting automated requirements traceability. Of course the scope will be bounded to those parameters understood within IP-XACT and the Magillem tools. You will still need to manage requirements tracing for AC and DC characteristics, among others, through other means. And unlinked text in documents must be checked manually. But disconnects in items you will link (bitfield maps for example) can often be where disconnects between requirements, spec, design and test are most likely to happen. Automating the management and traceability of this data should be a big step forward in traceability support.

    As a sidebar, some readers may note that there are other tools to connect individual parts of the design process to spreadsheet specifications and documentation. Indeed there are. But a meaningful contribution to requirements traceability needs more than a bundle of disconnected mechanisms, each supporting a limited set of individual requirements. The level of contribution needed for safety standards certification is better served by coverage of a significant subset of requirements through an auditable / verifiable standard representation. Thatís what Magillem aims to offer through their MLT solution linked to their extensive range of IP-XACT-based design tools. You can read more HERE.