Architecture Exploration- Managing Product Lifecycle

admin_mirabilis

Architecture Exploration- Managing Product Lifecycle through Simulation

Abstract

To have a true closed loop design environment, a single executable must be the reference from requirements to after-sale debugging.  This encompasses several stages and each having their own challenges and requirements.  The closed loop will ensure there is accountability and tracking, thus ensuring uniform communication.  The entire process will have a single specification document with no ambiguity in terms of language, location, or knowledge-levels. It is important that the specification is executable, meaning that changes downstream or tests downstream can be fully validated and get the expected values.

Architecture Exploration model is an executable reference that can be used throughout the design flow, from systems engineering to deployment.  Architecture model is a complete, abstracted definition of the hardware, software, and network architecture and is simulated with different use-cases, workloads, traffic, hardware variations, and mapping. The model integrates the requirements, trade-off studies, links to verification, and a closed loop for field testing.  It is the central to keep the entire team on the same specification data, plan for resource and schedule budget, uniform communication across all team members, early marketing material, and ensure changing requirements can be added.  In the present work environment involving distributed development process, procured technology such as Intellectual Property, and work-from-home alternatives; the architecture model forms the template for integration and continuous testing.

Background

Figure 1: Benefits of System Modeling using VisualSim Architect IP Libraries
Figure 1: Benefits of System Modeling using VisualSim Architect IP Libraries

Architecture exploration is a stage that everyone requires but no one wants to deploy.  Historically, architecture exploration has been hard to setup, takes a long time to model, provides questionable or inaccurate results, and teams lack modeling expertise.  A few companies in semiconductors, defense, and aerospace have ventured into this domain as they see the long-term vision and have demonstrated significant advantages. Advantages have been in the form of reduced bugs, higher reliability, a shorter schedule, and faster design wins.

New generation of architecture tools are available as open source and commercial entities such as Ptolemy, VisualSim Architect and SystemC.  For example, VisualSim Architect provides a large library of components that allow for rapid model construction and analysis, thus ensuring all the exploration is completed prior to development.  This means that the user can define new components just as easily as an existing IP from a vendor.  The new generation of architecture exploration is all about System-IP, not so much a simulator or a language.  Also, architecture exploration has transitioned from just integration and virtual prototype to extensive what-if studies that enable global configuration of topology, parameters of each Intellectual Property (IP) block, and memory hierarchy.  For true trade-offs, the pre-built model must accurately represents the timing, power consumed, and functionality.  Also, the models must cover multiple levels of abstraction, ranging from stochastic to cycle-accurate, while providing support for traffic, workflows and use-cases.  The concept of mapping behavior to architecture enables both the use-cases and the architecture model to be reused easily across projects.

Development Stages

Architecture model has different applications at different stages of the design flow. 

  1. During the early systems engineering phase, the goal is to understand how the whole system is connected, the minimal requirements for the execution, communication and storage for each application, and the processing times for each task. 
  2. During the architecture exploration phase, the architecture defines the pipeline, flow control, arbitration in the buses, task, and instruction/task dependent behaviors. It is used for system sizing, fault injection, configuration, and regression testing for all the possible use cases.  The regression becomes important because these translate all the system-level tests for RTL and software verification.
  3. During development, the regression test can simulate with Verilog code or emulator linked to validate the hardware and software implementation for cycle count, functional correctness, and scheduling.
  4. During deployment, the architecture model can be used to detect the faults quickly by recreating the error condition in the model. This is because of the model instrumentation, visibility into logic and buffers, and the statistics.
  5. For certification purposes such as ISO26262, the model can be enhanced to include detection and resolution.  That way the software or hardware code can replace the model, to verify that the single and multiple points of failures are resolved.
Figure 2: Concept to Implementation using VisualSim System Architecture Exploration Methodology
Figure 2: Concept to Implementation using VisualSim System Architecture Exploration Methodology

Product Lifecycle Integration

Architecture models have the intent clearly defined and are directly linked to the requirements, either in the selection of the components, or during the regression simulation.  Any changes occurring during development or integration can be verified against the reference.  Architecture models produce several different types of output.  Each output has relevance for a particular stage of the design flow.  For example, the throughput helps in selecting the memory controller.  Similarly, the cycle count helps the designer validate the Verilog code.  The generated trace file in VCD provides the traffic patterns for stimulating the Verilog code and emulation. The regression runs provide the list of different tests that must be completed to sign off on the system correctness.  The Debug messages provide information on the corner cases that must be simulated during verification.

The most common outputs from the architecture model are,

  1. The system specification
  2. Demonstration platform for customers
  3. Early architecture platform for customers
  4. Exploration platform for future changes
  5. List of test cases or scenarios
  6. Test patterns in the form of a trace
  7. Platform model to test Verilog, FPGA board and emulator
  8. Virtual platform for early software development
  9. Debug errors from field testing and post-sales failures using traces and scenario settings
  10. Executable specifications are used for communication with development teams, management, partners, and customers

Yesterday, Today and Tomorrow

In the past, architecture exploration models had a short lifespan for system trade-offs.  The multiple reasons and causes include: these models have been constructed for a very specific purpose, cannot be integrated in to any flow, variable levels of abstraction, stochastic in nature, or extremely detailed making it very slow, and contain complicated interfaces.  The new generation of architecture models have well-defined interfaces, most are polymorphic in behavior, have functional, timing and power details, and can be simulated quickly.  Also, there is a lot of automation in the simulation models.

Figure 3: Example of integrating the end-to-end design flow using VisualSim Architect
Figure 3: Example of integrating the end-to-end design flow using VisualSim Architect

The development of Architecture models is a formal process that must be well-planned.  VisualSim Architect from Mirabilis Design provides a complete solution that formalizes the approach with interfaces, libraries, generators, and co-simulations.  This ensures the reusability of the architecture model and provides consistency, commonality from site to site, and uniform communication.  The process starts with linking to systems engineering- the first stage of product development. 

VisualSim enables the import of the block diagram from SysML tools, creation of a graphical view, and mapping to an architecture platform.  This ensures that the task definition remains in SysML but the model provides insight on the connection, scalability, metrics, quality, safety, and security. VisualSim also features the ability to import requirements from an existing database or spreadsheets.  The requirements form a valuable part of debugging at all stages of the pipeline and provide the input for regression analysis.

To make all models consistent, ensure interoperability between users and companies, and provide equal understanding, VisualSim contains library blocks that cover the system definition, SoC IP blocks, algorithms, protocols, traffic models, use-cases, and workloads.  The test environment generates faults, traffic variations, parameter settings, topologies, configurations and different use-cases.  During the run, statistics are automatically generated, the insight engine monitors the intermediate results against the requirements to report causes of failures and debug-statements are produced for a detailed understanding of the behavior.

At the end of the architecture exploration, VisualSim generates an executable documentation and a run-time simulation model.  The standalone document displays the hierarchical details, the parameter setting for each component, the expected output values for this setting and the connectivity in the model. This can be transported and viewed by all the team members, partners, and customers.  The run-time simulation can be used by integration engineers to try variations detected during development, software development teams to evaluate the timing and functionality of the software code, and to integrate with Verilog and Emulators for system verification.  The functional safety tests in the run-time version can be used for ISO26262 compliance testing of the semiconductor and software, in the context of the application.

Conclusion

Architecture models are critical to the delivery of the right product.  VisualSim Architect is the first solution that delivers an architecture modeling environment that provides capabilities to cover the entire product development process. This methodology has shown to save over 25% of development time, reduce the number of iterations and ensure everyone is aware of the detailed specification prior to development.  Architecture models are relevant for all applications that utilize electronics, and applicable for embedded systems, semiconductors, software and IP.