SYSTEMS AND METHODS FOR SPECIFYING. MODELING, IMPLEMENTING AND VERIFYING IC DESIGN PROTOCOLS

Abstract

A new approach is proposed that contemplates systems and methods to support a hybrid verification framework (HVF) to design, verify, and implement design protocols for an integrated circuit (IC) chip such as a system-on-chip (SOC) and/or an application-specific integrated circuit (ASIC) chip. The framework creates a plurality of specifications in form of extended state transition tables for different phases of a design flow of the IC chip. The framework integrates and uses the extended state table-based specifications and the templates in all phases in the design flow, resulting in a tight revision loop of debug, verification, and validation across the phases of the design flow.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application No. 61/911,429, filed Dec. 3, 2013, and entitled “A Framework for Specifying, Modeling, Implementation and Verification of SOC Protocols,” and is hereby incorporated herein by reference.

BACKGROUND OF THE INVENTION

A chip design process has a plurality of discrete phases that include but are not limited to conception, architecture design, register-transfer level (RTL) design, physical design, and tape-out. Some of the key metrics to measure success of a chip design project are timeliness, correctness and completeness of the design. One way to enhance timeliness and to reduce time-to-market of the chip design project is to achieve the objectives of completeness and correctness as early in the design process as possible. Since RTL design verification is typically the most time-consuming phase in the chip design process, an approach to accelerate RTL verification will reduce the overall project time.

In practice, multiple chip design projects may overlap in time and different groups in a chip design team may work on different design phases of these projects at the same time. For example, when the RTL design group is taping out one of the projects, the chip design architects may be working on another project. Similarly, when the RTL design group is in the RTL design phase of a project, the verification group may be incorporating new features into the chip verification environment. As such, there is an opportunity for parallelism and pipelining among of the chip design projects that will increase the throughput of the chip design team by automating the transfer and sharing of knowledge among the different groups in the team.

The foregoing examples of the related art and limitations related therewith are intended to be illustrative and not exclusive. Other limitations of the related art will become apparent upon a reading of the specification and a study of the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an example of a system diagram to design, verify and implement protocols for design of an IC chip.

FIG. 2 depicts an example of various components within a formal verification engine.

FIG. 3 depicts an example of four SOCs connected together as a single logical multicore processor via OCI connections.

FIGS. 4A and 4B depict examples of tables for home and remote services provided by the IC design protocol, respectively.

FIG. 5 depicts an example of various components within the dynamic verification engine.

FIG. 6 depicts a flowchart of an example of a process to support design, verify and implement protocols for design of an IC chip.

DETAILED DESCRIPTION OF EMBODIMENTS

The approach is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” or “some” embodiment(s) in this disclosure are not necessarily to the same embodiment, and such references mean at least one.

A new approach is proposed that contemplates systems and methods to support a hybrid verification framework (HVF) to design, verify, and implement design protocols for an integrated circuit (IC) chip such as a system-on-chip (SOC) and/or an application-specific integrated circuit (ASIC) chip. The framework creates a plurality of specifications in the form of extended state transition tables as well as a plurality of templates for different phases of a design flow of the IC chip. The framework integrates and uses the extended state table-based specifications in all phases in the design flow, resulting in a tight revision loop of debug, verification, and validation across the phases of the design flow. The revision loop facilitates any protocol changes to be incorporated in all phases of the design flow and to be validated at all levels within a short time period, which in turn reduces time to market of the IC chip.

The proposed framework speeds up the RTL design and verification process by formally verifying correctness and completeness of the architectural entities of the protocol before a line of the RTL is written and using these formally verified pieces of information throughout the design flow. Such an approach also enables finding of as many bugs as possible in the early stages of the design flow. Moreover, all verification steps are interlocked in that a bug happened and identified at a later phase of the design flow (e.g., at RTL level) can be traced back, replayed, and resolved at the earlier phase of the design flow (e.g., architectural level).

FIG. 1 shows an example of a system diagram to design, verify and implement protocols for design of an IC chip. Although the diagrams depict components as functionally separate, such depiction is merely for illustrative purposes. It will be apparent that the components portrayed in this figure can be arbitrarily combined or divided into separate software, firmware and/or hardware components. Furthermore, it will also be apparent that such components, regardless of how they are combined or divided, can execute on the same host or multiple hosts, and wherein the multiple hosts can be connected by one or more networks.

In the example of FIG. 1, the system 100 includes a formal verification engine 102, a protocol checking engine 104, a micro architect/RTL engine 106 and a dynamic verification (DV) engine 108. As used herein, the term engine refers to software, firmware, hardware, or other component that is used to effectuate a purpose. The engine will typically include software instructions that are stored in non-volatile memory (also referred to as secondary memory). When the software instructions are executed, at least a subset of the software instructions is loaded into memory (also referred to as primary memory) by a processor. The processor then executes the software instructions in memory. The processor may be a shared processor, a dedicated processor, or a combination of shared or dedicated processors. A typical program will include calls to hardware components (such as I/O devices), which typically requires the execution of drivers. The drivers may or may not be considered part of the engine, but the distinction is not critical.

In the example of FIG. 1, each of the engines can run on one or more hosting devices (hosts). Here, a host can be a computing device, a communication device, a storage device, or any electronic device capable of running a software component. For non-limiting examples, a computing device can be but is not limited to a laptop PC, a desktop PC, a tablet PC, or a server machine. A storage device can be but is not limited to a hard disk drive, a flash memory drive, or any portable storage device. A communication device can be but is not limited to a mobile phone.

Formal Verification

In the example of FIG. 1, formal verification engine 102 is configured to automatically generate and formally verify a reference specification/model that includes a plurality of extended state tables as part of a design protocol for an IC chip (the terms reference specification and reference model are used interchangeably in the discussions below). Since the protocol may be under constant revision during the IC design process, the formal verification engine 102 automatically incorporates and validates any incremental changes to the protocol quickly during the design flow in order to support maintainability of the protocol.

As referred to hereinafter, the IC design protocol (or protocol in short) describes details of an IC design at various levels. Specifically, the protocol describes various components in the IC design project, the relationships, connections, and interactions among these components, and the interfaces between these components and external components outside of the IC chip. The protocol includes at least the reference model used for formal verification of the protocol at the architectural level and a synthesizable package used for implementation of the protocol at the micro-architectural or RTL level as discussed below. In some embodiments, the reference specification of the protocol can be regarded as “golden” as any changes to the protocol in all phases of the IC design process, for a non-limiting example, at the RTL level, can be propagated to and maintained at the architectural level of the protocol in the reference specification. In addition to information typically included in state tables for a finite state machine (FSM), each of the extended state tables of the reference model further includes additional information related to the implementation of the IC design protocol that is shared among various phases of the IC design process as shown by the examples depicted in FIGS. 4A and 4B discussed below.

As shown in the example depicted in FIG. 2, formal verification engine 102 includes at least a reference specification generation component 112, a formal verification model generation component 114, and a formal verification component (formal verifier) 116. During the operation of formal verification engine 102, the reference specification generation component 112 accepts inputs from an architect of the IC design protocol and automatically generates the golden reference specification/model in ASCII formatted state tables as well as additional role/service tables as discussed in details below. Here, the reference specification generation component 112 manages the protocol in a programmable way and provides a uniform consistent output of the reference specification for any changes to the protocol. The formal verification model generation component 114 then creates a formal verification (FV) specification/model by merging the tables from the golden reference model with templates and instrumentations generated for verification. In some embodiments, the formal verification model generation component 114 uses the templates as wrappers around the protocol tables and there is one template per protocol service/role table. The instrumentations include but are not limited to, model assumptions, reduction constraints, completeness properties, and correctness properties. The FV model is a formally verifiable set of files, generated as a composition of the roles/services tables, templates, and instrumentations. The formal verification component 116 utilizes the FV model to formally verify the golden reference specification for the IC design protocol.

Although table-based specifications have been around for a long time and have been used in various phases of a chip design, they are generally written for the purpose of being used with one signal objective/task in minds. In addition, these specifications usually contain a lot of hidden state information such as transitional states, which requires a leap of faith between the architect, the implementer and the verifier of the chip design team.

In some embodiments, the golden reference specification/model created by reference specification generation component 112 of the formal verification engine 102 is in parsable ASCII format. The reference model includes sufficient information for the automatic generation of formal verification, RTL verification, dynamic verification, and coverage collaterals. The reference model does not have any hidden states or assumptions, redundancy, or dead-ends, and is readable and can be understood and consumed by all relevant parties at all phases in the IC design process. As such, the golden reference removes the need for an abstract map, which is very time consuming and error prone, and thus enhances maintainability of the specification and greatly reduces the time-to-market of the IC design project.

In some embodiments, the golden reference model is an enhanced state table-based specification comprising a plurality of tables that serve common protocol knowledge to be shared among the various phases of the IC design flow. Specifically, the reference model captures the protocol concept of the architect and is utilized by the formal verification engine 102 to prove the correctness of the protocol. The reference model is also utilized by the micro architect/RTL engine 106 to implement the protocol and by the dynamic verification engine 108 to verify the implementation of the protocol by the micro architect/RTL engine 106. Since all of the above parties in the design process consume the same information in the tables of the reference model and collaborate to deliver the IC design, the tables of the reference model need to have enough information to satisfy the demands of all these parties and at the same time keep visual clarity by avoiding any redundancy.

In some embodiments, the IC design protocol used for the design process of an IC is a directory-based cache coherence protocol, which implements write operation coherency across various components of the IC chip including cores, memory, network, I/O, and coprocessor of the chip, meaning only one write operation is to be performed to a memory or cache of the chip at any time to maintain consistency and sanity of the data. For a non-limiting example, such directory-based cache coherence protocol can be but is not limited to an OCTEON Coherent Interconnect (OCI). FIG. 3 depicts an example of two to four OCTEON III SOCs (Socket 0, . . . , Socket 3) connected together as a single logical multicore processor via OCI connections among them. Such OCI-based architecture eliminates unnecessary memory copies in the design.

In some embodiments, each connection under the cache coherence protocol implements plurality types of virtual channels for cache coherent memory traffic among the SOCs of the chip, wherein the channels are used for submitting requests, receiving responses and forwarding data traffic. In some embodiments, the protocol is out-of-order not just across these virtual channels but also within each of the virtual channels where messages may not be received in the order they are sent.

In some embodiments, each address of a top-level SOC under the cache coherence protocol is mapped to a unique socket as shown in FIG. 3, which represents the address's home node. Since the address space is shared among a plurality of nodes, each representing a chip (e.g., SOC), any of the nodes may request data or ownership from any datum in the address space. If the datum falls in the requester's own domain, it will be a local request otherwise it will be a remote request. If a home node needs a datum, currently held by a remote node, it will issue a forwarding request to the remote node. In terms of service, the cache coherence protocol provides a plurality of services, some by the remote node and some by home node. The following are some non-limiting examples of the services provided by the cache coherence protocol:

• • Local address request: a core/processor in a home node requests an address. The home node provides the datum if it owns it or sends a forwarding request to a remote node that owns it.
  • Remote address request: a core in a remote node requests an address.
  • Home receive request: a home node receives a request from a remote node and sends back a response.
  • Remote receive response: a remote node receives the requested data/address ownership.
  • Remote receives forwarding request: a home node or another node needs data and a remote node forwards the data.
  • Home receives response: a home node gets back a response as a result of a forward or eviction.

In some embodiments, roles (home or remote) and services tables corresponding to the services listed above are automatically generated by the reference specification generation component 112 from the golden reference model. In some embodiments, the cache coherence protocol is implemented for full out-of-order transmission over the connections and their virtual channels in order to maximize transaction performance and minimize transaction latency.

Since a transaction to a remote address only needs to lookup the local cache directory, while a request to a local address (from either a home node or a remote node) needs to lookup both the local cache as well as the protocol directory of protocol, the cache coherence protocol of the golden reference model can be broken up into at least two tables in ASCII format—a home table for local address transactions as shown by the example depicted in FIG. 4A, and a remote table for remote addresses transactions as shown by the example depicted in FIG. 4B, wherein each row in the tables represents a role-based service. In some embodiments, this set of extended state tables can be used by the reference specification/model to fully describe the cache coherency protocol in terms of state transitions and protocol commands for each service provided.

In some embodiments, each of the extended state tables contains one line for every combination of a valid state and input, providing what the next state should be, and what are the protocol commands to issue to each of the nodes (also referred to as the output). For the home table depicted by the example in FIG. 4A, each state in the line includes “Cmd,” which represents the request being processed, the state of the node's cache directory (H for home), and the state of each of the other nodes in the protocol directory (N1, N2, N3). The remote table depicted by the example in FIG. 4B has a similar current/next state, but only one directory state “St,” which is the state of its cache directory. Here, the output includes a command (request or response) that is sent to the home node, and a column for the possible response that can be also sent to the other remote nodes.

Protocol Checking

As shown in the example of FIG. 1, protocol checking engine 104 validates the protocol generated by the formal verification engine 102 by automatically verifying the logical consistency of the formal specification of the protocol irrespective of its implementations. The requirements for protocol validation include protocol completeness and protocol correctness. Since a protocol specification includes a set of interacting finite state machines, which are essentially a set of transitions between a given state and next state for a given input, protocol checking engine 104 checks the reference specification to verify that the following problems are avoided in the specification based on the set of transitions for protocol completeness:

• • Under-Specification: any missing transitions in the specification will cause the design flow to enter dead-end states.
  • Over-Specification: any redundant transition in the specification will cause false errors in coverage collection at all levels of the design flow.
  • Missing/hidden assumptions: any missing or hidden assumption of machine initial states in the specification will cause false errors.

The requirements for protocol correctness typically arise from two sources—structure of the protocol and functionality of the protocol. According to these sources, protocol checking engine 104 checks the protocol specification to verify that the following problems are avoided:

• • Deadlock/livelock freedom: multiple interacting state machines always have the potential of having deadlocks or livelocks, which can be identified by the protocol checking engine 104 based on the structural property of the protocol.
  • Cache Coherence: which requires that only one node at one time have writing-rights to datum. Cache coherence can be identified by the protocol checking engine 104 based on the functional property of the protocol.
  • Data Consistency: which requires that the data in a given memory location is prorogated correctly. Data consistency can be identified by the protocol checking engine 104 based on the functional property of the protocol.

Most of the checks listed above are automatically generated from tables in the formal specification while others can be manually crafted. For every revision of the protocol, the protocol checking engine 104 verifies the formal verification model of the protocol for protocol completeness and correctness against all of these checks.

RTL Implementation

Even with the extended state tables in the reference specification in an ASCII parsable format, it still requires tremendous effort to understand all the internal states and transition subtleties and perform an accurate implementation according to the intent of the architect of the protocol. Because of the complexity of the protocol, numerous bugs could easily be inserted during the IC chip design process. In some embodiments, reference specification generation component 112 of formal verification engine 102 automatically generates a System Verilog (SV) package that includes state transitions at the RTL level for RTL implementation of the chip using the same underlying protocol representation in the reference specification for formal verification to further reduce chances of introduction of new errors during the RTL implementation. The SV package captures the behaviors, functions, and interactions among the gates and transistors within each high level components in the reference specification at the architectural level. The SV package is synthesizable in the sense that RTL level implementation of the chip design can be directly synthesized by the micro architect/RTL engine 106 from the package (vs. for a non-limiting example, a class-based specification or model that has to be run as a computer program first).

There are several significant benefits of implementing the protocol at the RTL level using the SV package generated by the reference specification generation component 112:

• • Automatic Formal Verification: any protocol bugs found at either level of verification can be fixed in the underlying representation by the reference specification generation component 112, which immediately produces new formal verification inputs.
  • Rapid Design Iteration: similarly, the same fix by the reference specification generation component 112 produces a new SV package for immediate implementation.
  • Opaque State: using the SV package, protocol implementation is unaffected by the details of the state required to implement the protocol. The package need only to provide the size of the vector required to be provided between function calls.
  • Parallelization of Effort: using the SV package, the protocol definition and formal verification can start before protocol implementation and continue after the implementation has started, meaning that the initial implementation of the protocol can be very confident in the stability and accuracy of the protocol from the beginning of the implementation and can thus focus solely on the details of implementing the protocol constraints specified by the architect.

In some embodiments, the SV package provides struct and enum definitions for communication between the RTL implementation and the package as well as one or more SV functions that provide the actual logic required to implement the IC design protocol. When a new protocol message arrives, the RTL implementation provides the message and current protocol state to the SV functions and receives as output the next protocol state and what messages (if any) are required to be sent to correctly maintain cache coherence under the protocol.

In some embodiments, the architect of the IC design also defines through the formal verification engine 102 certain constraints required for the implementation of the protocol beyond the logic required for implementation to ensure that all of the assumptions the architect made during protocol definition are valid. One of the most common examples is the architect's definition of virtual channels for the protocol connections. The formal verification engine 102 specifies protocol constraints that require the implementation to guarantee that lower priority channels do not block higher priority channels.

In the example of FIG. 1, the micro architect/RTL engine 106 implements the IC design protocol at the micro-architectural or RTL level using the SV package created by the reference specification generation component 112. During the RTL implementation, the micro architect engine 106 creates and utilizes its own protocols at the micro-architectural level, which on one end implements architectural definitions received from the formal verification engine 102 and on the other end interacts with other architectural protocols and implementation details, creating constraints on both. The top-level definition of the micro-architectural protocol often requires that an implementation performs multiple actions to maintain protocol consistency and cache coherence.

As multiple protocols interact with each other, they always have the potential of creating deadlocks, over-allocating resources, or conflicts. In addition to the benefits of using the SV package described above, utilizing the SV package at the micro-architectural level offers a few significant additions:

• • Additional Formal Verification: with the low-level details incorporated into the underlying protocol definition, the formal verification inputs can be augmented with this information. This exposes previously unavailable details to the potential for formal verification. As time permits, formal verification engine 102 can expand the formal verification effort to cover as many properties of the action bits as possible.
  • Explicit Constraints: the micro-architectural protocol constraints defined by the architect as described below can be directly used and checked for during RTL verification.
  • Tight Integration of Low-Level Details: the simple act of reviewing the low-level implementation can lead to significant simplifications (of both the protocol and the implementation); performance improvements, and better use and allocation of resources.

In some embodiments, the constraints on the protocol that must be enforced at the micro-architectural level are defined by the architect via micro architect engine 106 to ensure no assumption of the IC design protocol is violated. For a non-limiting example, if a message arrives and the protocol requires that the memory location be removed from all caches in the local node, the micro architect engine 106 may accept and enforce a constraint that the implementation does not send its protocol messages until the removal is past the point of visibility to the rest of the system.

In some embodiments, implementation at the micro-architectural level by the micro architect engine 106 imposes its own constraints on the IC design protocol at the top level (e.g., architectural level), wherein resource sharing, datapath details, and physical implementation details are just a few non-limiting examples of such constraints that can cause deviation from the design goals. Incorporating as many of these constraints as possible into the top-level protocol is vitally important.

In some embodiments, reference specification generation component 112 of the formal verification engine 102 incorporates lower (RTL) level implementation details by the micro architect engine 106 into the tables of the reference model to reflect the implementation requirements/constraints at the RTL level as well as the understanding of the IC design protocol. Specifically, the reference specification generation component 112 extracts a set of action items/bits and incorporates them into the tables of the reference model based on detailed description of datapath for all coherency states in the protocol. After inclusion of these details, the same function call which provided protocol transition information now also provides the set of action bits which are used by the micro architect engine 106 to coordinate the datapath and control of the low-level RTL implementation. For non-limiting examples, such actions include but are not limited to, which (if any) caches to invalidate, when to send a store commit; where to read data from, which data buffers to read into, which data buffers to provide data to the protocol message when sent, and whether to allow the requester to place the data into its cache. The micro architect engine 106 enforces all of these details and action bits to operate in concert with the full IC design protocol to maintain its integrity within the parameters of the chosen design implementation.

Dynamic Verification

In the example of FIG. 1, the dynamic verification engine 108 dynamically verifies the RTL implementation of the IC design generated by the micro architect engine 106 in real time. As shown in the example of FIG. 5, the dynamic verification engine 108 includes verification collaterals that include but are not limited to, a first bus agent 122, which takes a stimulus sequence as its input and drives and monitors the input bus. The dynamic verification engine 108 further includes a second bus agent 126, which monitor the output bus, and a predictor 124, which computes the expected responses from the input sequence and compares them against responses observed by the output bus monitor of second bus agent 126.

In some embodiments, the dynamic verification engine 106 utilizes an industry standard methodology to enable reuse of the components from past (accomplished) IC design projects and creation of reusable components for future IC design projects. Here, the industry standard methodology can be but is not limited to, Universal Verification Methodology (UVM), which is a standardized methodology for verifying integrated circuit designs.

Since the IC design protocol supports numerous requests and has a large amount of state that needs to be tracked, there are thousands of legally defined sequences, resulting in a high likelihood that verification bugs may be introduced into the predictor 124 of the dynamic verification engine 108. Additionally the predictor 124 would be very time consuming to code.

In some embodiments, dynamic verification engine 108 utilizes a separate DV reference model 128 derived from the formally verified tables in the reference model by the reference specification generation component 112 for dynamic verification of the protocol, wherein the DV reference model 128 is class-based, which includes programmable classes that provide many orders of magnitude speedup in simulations as compared to synthesizable models such as the SV package and can take advantage of all simulation runs. In some embodiments, the DV reference model is created using System Verilog classes to reduce human error and time to completion. In some embodiments, an address object of the DV reference model is instantiated for each active address, wherein the address object maintains the status of the address. Once all references to the address disappear, the corresponding address object is cleaned up.

In some embodiments, the predictor 124 of the dynamic verification engine 108 makes a function call to the DV reference model instead of using a hand-coded expected responses from a human verifier. A message for the function call is passed to the DV reference model, which returns an object containing one or more of the current state, next state, dirty masks, and the expected response. The DV reference model also indicates an error if it were an illegal time to receive the new message. This knowledge of what messages are legal at the current time is also used by the dynamic verification engine 108 to constrain the stimulus sequence so that only legal messages are produced.

Since the DV reference model is machine-generated automatically by the dynamic verification engine 108 from the tables of the reference specification formally verified by the formal verification engine 102, there is less opportunity for human error. Additionally, changes to the protocol can be reflected in the predictor 124 as soon as they are added to the reference specification and be run through the formal verification engine 102 again.

In some embodiments, dynamic verification engine 108 utilizes the DV reference model created for prediction purposes to machine-generate coverage points, which are simulation sampling points in the thousands of legally defined and/or illegal sequences in the IC design protocol. These machine-generated coverage points share the same benefits as the generated DV reference model in that they reduce human error, drastically decrease the time required to code, and can rapidly incorporate and propagate any changes to the protocol in all phases of the IC design process. Such automatic generation of coverage points eliminates the need for manual generation of coverage points as well as manual exclusion of the illegal sequences. Moreover, the machine-generated coverage points contribute to generate more interesting functional coverage points, which include but are not limited to, event cross-coverage across home and remote nodes, transition coverage of all the legal transitions, and transaction coverage of all legal transactions as a sequence of legal transitions.

FIG. 6 depicts a flowchart of an example of a process to support design, verify and implement protocols for design of an IC chip. Although this figure depicts functional steps in a particular order for purposes of illustration, the process is not limited to any particular order or arrangement of steps. One skilled in the relevant art will appreciate that the various steps portrayed in this figure could be omitted, rearranged, combined and/or adapted in various ways.

In the example of FIG. 6, the flowchart 600 starts at block 602, where a reference specification including a plurality of extended state tables for an integrated circuit (IC) design protocol is automatically generated and formally verified at architectural level. The flowchart 600 continues to block 604, where completeness and correctness of the reference specification are checked and validated. The flowchart 600 continues to block 606, where the IC design protocol is implemented at the micro-architectural level using a synthesizable package generated from the formally verified reference specification. The flowchart 600 end at block 608 where the implementation of the IC design protocol is dynamically verified at the micro-architectural level and incorporates all incremental changes to the IC design protocol in real time based on a DV reference model generated from the synthesizable package.

One embodiment may be implemented using a conventional general purpose or a specialized digital computer or microprocessor(s) programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.

One embodiment includes a computer program product which is a machine readable medium (media) having instructions stored thereon/in which can be used to program one or more hosts to perform any of the features presented herein. The machine readable medium can include, but is not limited to, one or more types of disks including floppy disks, optical discs, DVD, CD-ROMs, micro drive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data. Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human viewer or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, execution environments/containers, and applications.

The foregoing description of various embodiments of the claimed subject matter has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the claimed subject matter to the precise forms disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. Particularly, while the concept “component” is used in the embodiments of the systems and methods described above, it will be evident that such concept can be interchangeably used with equivalent concepts such as, class, method, type, interface, module, object model, and other suitable concepts. Embodiments were chosen and described in order to best describe the principles of the invention and its practical application, thereby enabling others skilled in the relevant art to understand the claimed subject matter, the various embodiments and with various modifications that are suited to the particular use contemplated.

Claims

1. 1. A system, comprising:

a formal verification engine running on a host, which in operation, automatically generates and formally verifies a reference specification that includes a plurality of extended state tables for an integrated circuit (IC) design protocol of a chip at architectural level;

a protocol checking engine running on a host, which in operation, checks and validates completeness and correctness of the reference specification;

a micro architect engine running on a host, which in operation, implements the IC design protocol at the micro-architectural level using a synthesizable package generated from the formally verified reference specification;

a dynamic verification (DV) engine running on a host, which in operation, dynamically verifies the implementation of the IC design protocol at the micro-architectural level and incorporates all incremental changes to the IC design protocol in real time based on a DV reference model generated from the extended state tables of the reference specification.

2. The system of claim 1, wherein:

the IC design protocol includes the reference specification used for formal verification of the protocol at the architectural level and the synthesizable package used for implementation of the protocol at the micro-architectural level.

3. The system of claim 1, wherein:

each of the extended state tables of the reference specification includes information related to the implementation of the IC design protocol that is shared among various phases of an IC design process.

4. The system of claim 1, wherein:

each of the extended state tables of the reference specification is in parsable ASCII format without having any hidden states, assumptions, redundancy, or dead-ends.

5. The system of claim 1, wherein:

the IC design protocol is a directory-based cache coherence protocol, which connects a plurality of System-on-Chips (SOCs) as a single multicore processor via connections among the SOCs.

6. The system of claim 5, wherein:

each connection under the cache coherence protocol implements a plurality types of virtual channels for cache coherent memory traffic among the SOCs of the chip.

7. The system of claim 5, wherein:

the formal verification engine generates a plurality of role and service tables from the reference specification, wherein the role and service tables represent services provided under the cache coherence protocol for communication requests among the SOCs of the chip.

8. The system of claim 1, wherein:

the formal verification engine automatically incorporates and validates incremental changes to the protocol to support maintainability of the protocol.

9. The system of claim 8, wherein:

the formal verification engine manages the protocol in a programmable way and provides a uniform consistent output of the reference specification for the incremental changes to the protocol.

10. The system of claim 1, wherein:

the protocol checking engine checks the reference specification for one or more of under-specification, over-specification, and missing or hidden assumptions in the specification.

11. The system of claim 1, wherein:

the protocol checking engine checks the reference specification for one or more of deadlocks, cache coherence, and data consistency.

12. The system of claim 1, wherein:

the synthesizable package captures behaviors, functions, and interactions among gates and transistors within each components in the reference specification at the architectural level.

13. The system of claim 1, wherein:

the synthesizable package includes state transitions at the micro-architectural level for resistor-transistor level (RTL) implementation of the chip using the same underlying protocol representation in the reference specification used for formal verification to reduce chances of introduction of new errors during the RTL implementation.

14. The system of claim 1, wherein:

the micro architect engine enforces a plurality of implementation constraints at the micro architect level to ensure no assumption of the protocol is violated.

15. The system of claim 14, wherein:

the formal verification engine incorporates micro architect level implementation details into the tables of the reference specification to reflect the implementation constraints at the micro architect level.

16. The system of claim 1, wherein:

the dynamic verification engine utilizes an industry standard methodology to enable reuse of components from past IC design projects and creation of reusable components for future IC design projects.

17. The system of claim 1, wherein:

the DV reference model is class-based, which includes programmable classes reduces human error and time to completion.

18. The system of claim 1, wherein:

the dynamic verification engine utilizes the DV reference model for prediction purposes to automatically generate coverage points, which are simulation sampling points in sequences in the IC design protocol.

19. A computer-implemented method, comprising:

automatically generating and formally verifying a reference specification that includes a plurality of extended state tables for an integrated circuit (IC) design protocol at architectural level;

checking and validating completeness and correctness of the reference specification;

implementing the IC design protocol at the micro-architectural level using a synthesizable package generated from the formally verified reference specification;

implementing the IC design protocol at the micro-architectural level using the synthesizable package;

dynamically verifying the implementation of the IC design protocol at the micro-architectural level and incorporates all incremental changes to the IC design protocol in real time based on a dynamic verification (DV) reference model generated from the extended state tables of the reference specification.

20. The method of claim 19, further comprising:

generating a plurality of role and service tables from the reference specification, wherein the role and service tables represent services provided under the protocol for communication requests among a plurality of System-on-Chips (SOCs) of the chip.

21. The method of claim 19, further comprising:

automatically incorporating and validating incremental changes to the protocol to support maintainability of the protocol.

22. The method of claim 21, further comprising:

managing the protocol in a programmable way and providing a uniform consistent output of the reference specification for the incremental changes to the protocol.

23. The method of claim 19, further comprising:

checking the reference specification for one or more of under-specification, over-specification, and missing or hidden assumptions in the specification.

24. The method of claim 19, further comprising:

checking the reference specification for one or more of deadlocks, cache coherence, and data consistency.

25. The method of claim 19, further comprising:

enforcing a plurality of implementation constraints at the micro architect level to ensure no assumption of the protocol is violated.

26. The method of claim 25, further comprising:

incorporating micro architect level implementation details into the tables of the reference specification to reflect the implementation constraints at the micro architect level.

27. The method of claim 19, further comprising:

utilizing an industry standard methodology to enable reuse of components from past IC design projects and creation of reusable components for future IC design projects.

28. The method of claim 19, further comprising:

utilizing the DV reference model for prediction purposes to automatically generate coverage points, which are simulation sampling points in sequences in the IC design protocol.

29. A non-transitory storage medium having software instructions stored thereon that when executed cause a system to:

automatically generate and formally verifying a reference specification that includes a plurality of extended state tables for an integrated circuit (IC) design protocol at architectural level;

check and validate completeness and correctness of the reference specification;

implement the IC design protocol at the micro-architectural level using a synthesizable package generated from the formally verified reference specification;

dynamically verify the implementation of the IC design protocol at the micro-architectural level and incorporates all incremental changes to the IC design protocol in real time based on a dynamic verification (DV) reference model generated from the extended state tables of the reference specification.