Janick Bergeron

Stimulus and Response

Model your clock signals in a module. Be careful about time resolution issues, delta cycle alignment and implicit synchronization of asynchronous signals.

Accelerating Concurrent Hardware Design with Behavioural Modelling and System Simulation

This paper describes a functional hardware verification methodology for ASIC intensive products. It spans the ASIC, board, and system level, enabling simulation of the design concurrent with ASIC and board development. The simulation strategy relies on rapid development of behavioural models of ASICs to enable work to proceed in parallel and to achieve the necessary simulation efficiency. The results from a project on which the methodology was used are presented. The process provided early visibility of over 200 issues in the system of which 32 were critical to the successful conformance and timely completion of the project.

What is Verification

Verification is not a testbench, nor is it a series of testbenches. Verification is a process used to demonstrate that the intent of a design is preserved in its implementation. We all perform verification processes throughout our daily lives: balancing a checkbook, tasting a simmering dish, associating landmarks with symbols on a map. These are all verification processes.

Your core— my problem? (panel session): integration and verification of IP

As the popularity of reusing existing designs--or Intellectual Property (IP)--continues to grow, design challenges escalate. The most time-consuming and critical part of IP design and reuse is verifying that it will work as it was designed to and as the user intends. Designers are pushing the limits of IP for new, distinctive and innovative applications. With this innovation come problems that need creative solutions. Product verification, for example, will become more and more important in ensuring the correctness of the design. Over the years, various solutions have come on the market, all seemingly useful, but none reducing the time or manpower it takes to verify the design. With designs becoming increasingly more complex with each new project and verification consuming up to 70 percent of a design cycle, something must be done to alleviate the bottleneck. Most of todays verification techniques rely on old simultion and emulation technologies, combined with add-on products designed to target specific functional items facilitated by the increased importance of the functionality they provide. These environments have led to an overall degrading in productivity, with decrease in tool speed and a sharp rise in learning curve and installation issues. In addition, interaction between add-on products created in isolation lead to further complications, usually discovered as products are incorporated in design flows. An improved verification flow is required to provide high-level productivity improvement over the entire design. The larger and more \ complex the design, the higher probability of errors slipping through the verification process, making System-On-Chip (SOC) devices the most vulnerable. With the integration of entire systems within single chips, the need to test hardware and softeware before the circuitry is produced, within as natural an environment as possible is critical to ensuring design success. The most important aspect in the selection and verification of IP is the collaboration of the vendor and the foundry. Designers need to be able to evaluate the core before a final selection is made. The evaluation should not just use the testbench provided by the vendor, but should provide an indication of the behavior in the intended use environment. In parallel, the designer must look at fabrication option by obtaining its fabrication profile. How many foundries have certified the core? how many times has the core been used in previous designs form each foundry? And, more important, is the core certified by the foundry chosen for the ASIC under development? With the microprocessor or microcontroller IP, the designer might have projected the use of an off-the-shelf RTOS. In this case, it is imperative to make sure that either the IP or RTOS has been used successsfully already, or that the software vendor and the hardware vendor are committed to insure proper integration in a timely manner. Most of this work is tedious and costly because it must take place before final selection and business negotiations can take place. Once the IP has been chosen, user and vendor must work as a team during the verification process. The vendor has an interest in this process, since bugs can be found when a new set of tests and a new use methodology is available. Those who assume that IP commerce is similar to standard parts commerce are mistaken and are apt to encounter serious obstacles to IP integraion. EDA tools implementing formal methods have seen a resurgence in the last year, due to improved user interface as well as algorithms implemented to prove the equivalence between a RTL and a gate-level representation of a system. Emulation is also becoming a more popular method to verify gate-level implementations, although the initial cost of the equipment is still quite high. Panelists, experienced designers and representatives of EDA tools providers, as well as IP providers, wil explore ways to beat the verification bottleneck and to identify the methodology best suited for IP design. They will attempt to answer the question, “What methodology work best for IP design?”

High-Level Modeling

A skilled verification engineer must break the “RTL mindset” that most hardware engineers, out of necessity, have grown into. To efficiently accomplish the verification task, you must be well versed in behavioral (i.e., non-synthesizeable and highly algorithmic) descriptions. To reliably and correctly use the behavioral constructs of any modeling language, it is necessary to understand the side effects of the simulation algorithm and the limitations of the language—and to understand ways to circumvent those side effects and limitations. This understanding was not required to write RTL models successfully.

Advances in low power verification

Summary form only given. Low Power design has traditionally been the area of Implementation engineers. However, with more and more advanced SOCs having to adopt aggressive Power Management techniques, the verification of these architectures has become an explosive problem. This talk will focus on the basic technology shifts required in the arena of verification - in dynanamic, static and formal analysis, in the area of Verification Methodology, Languages and Protocols and in next generation automation flows. The talk will also highlight some of the unsolved problems of todays technology and potential areas for research/collaboration between academia and industry.

The Verification Plan

In this chapter, I describe the verification plan as a specification of the functional verification testcases and of the testbench infrastructure that will be necessary to support them. It is used to define what is first-time success, how a design is verified and which testbenches are written.

Modeling usable & reusable transactors in system Verilog

Summary form only given. Transactors, also known as bus-functional models, have traditionally been modeled using a procedural interface (API). Commands were provided to use every feature available in the transactor. Several commands were often necessary to configure the transactor or to execute the simplest transaction. If the transactor did not provide a feature required by a particular device under test (DUT) or testcase, it had to be modified or rewritten. By using an object-oriented approach for configuration and interfacing, transactors can easily be used out-of-the-box. A few lines are all that is necessary to create valid random stimulus to a DUT or report observed response to a scoreboard. The use of callback methods eliminates the need for a complex and ever-evolving API. Instead of creating yet-another programming language, it leverages the power of system Verilog to extend the functionality of a transactor in ways the original author may not have conceived. Without modification, a transactor can thus be used and reused effectively. Transactors can also be modeled in an extensible fashion. Extensible transactors allow users to define entirely new transactions and commands, should the ones provided by the original implementation prove insufficient. Usability and reusability of transactors does not happen by accident. With careful design and consistent use model, transactors can be written to meet the stringent demands of different testcases on different design under verification. This paper describes how to properly use the object-oriented features of system Verilog to model transactions and transactors that execute them. Designers, used to a procedural programming model, will learn how to approach a transactor modeling problem using the object-oriented approach. Software engineers, used to a traditional object-oriented programming model, will learn how to adapt their methods to the special requirements of constrained-random verification. This paper presents clear and concise guidelines that can be followed to create effective, easy-to-use and reusable transactor models.