Verification in the CoreWare suite

Each of the four AHB AMBA bus interfaces to the DDR controller has a sequence agent which consis ts of a Master eVC (Verisity "e" Verification Component), a slave eVC to drive bus conflicts, an "e" AMBA Bus Checker and a clock bus functional model (BFM) to control the frequency of the bus. Versity eVCs are Verisity "e" Reuse Manual (eRM) compliant, an acknowledged standard which makes it easier to work with other third parties. The external memory is a Denali model having built in protocol, sequence and timing checks. An overall master sequencer (also in "e") controls the entire CVE initialization, test set up and test sequences. For additional visibility a scoreboard checker is built into the DDR. This has hooks into the DDR at input, output and intermediate points so that data flows can be tracked against expected outcomes at each stage and errors flagged. This allows errors to be tracked to find the root cause of any bugs.

Using third-party models gives the verification team a head start to building the CVE, but even so generating the directed and constrained random tests is many man-years of effort. Initial development uses the CVE environment in interactive mode allowing frequent and fast changes to the e code. Eventually as regression runs become longer and bugs become sparser the e code is compiled for additional speed. Finally regression testing is run with code coverage added also. Code coverage holes imply an incomplete test bench (or redundant RTL) and allow the test plan to be updated to target them. The result of this flow is the robust, guaranteed, CoreWare IP which LSI Logic delivers to its customers.

Future IP developments may start to use assertion-based and formal methods, but today these tools are still immature and too many differing standards exist to adopt for mainstream ASIC support.

A key requirement in the ASIC world is to deliver integration-friendly IP and allow self-support as much as possible for the end user. One approach now being used is to deliver collections of IP as one block or "CoreWare Subsystem" (CWS). A CWS allows the customer to work at a hig her level of system-level integration, improving the turn-around time and reducing end-user and support costs. CWS correctness is typically proven via both a System Verification Environment (SVE) which typically ensures the blocks are correctly connected and a modular FPGA environment which allows much more exhaustive (near real time) verification.

An example SVE might be the ARM926/DDR CWS. This consists of a complete ARM926 sub-system with AHB & APB busses, all the common APB peripherals, Ethernet MAC and the DDR. Individual IP blocks will already have undergone exhaustive stand-alone IP validation. The verification environment around this is written in Verilog and consists of AHB BFMs, AHB Protocol Checker, memory, monitor block and interrupt controller. The memory model itself is a standard Micron model (simpler and faster than the more complete Denali model), the AHB Protocol checker is Verisity "e" Invisible Specman (which may be used by customers without additional license costs).

This format of SVE is commonly used today and relies on the ARM itself to drive many of the tests. Much of the AMBA/ARM based SVE is reused many times with only minor modifications specific to the peripherals being attached to the AHB. This approach is markedly different than SVEs supplied by many other IP providers who only provide the DDR SVE standalone - rather than as a combined sub-system. The verification environment then typically has to be reworked greatly (indeed often restarted completely) to be applicable at the integrated system level.

The SVE contains all that is required to eventually allow the customer to bring the CWS into their design and verify connectivity, prove basic functionality, an provide example usage and tests (in the form of ARM code) that can be migrated to the customer verification environment. The typical SVE is much simpler than the CVE, with 10-20 basic connectivity checks and a few additional checks at the system level where coverage holes are seen. An example of additional specific directed tests for the DDR are to ensure master lockout so that one master (and only one) on any of the four busses can lockout any other masters on any other bus. This is one of the unique features of the LSI Logic DDR Controller and is a complicated scenario to completely verify.

See related chart