HW/SW co-verification basics: Part 4 - Co-verification metrics

Jason Andrews

May 24, 2011

Jason Andrews

Verification Accuracy
While performance issues are the number one objection to co-verification from software engineers, accuracy is the number one concern of hardware engineers. Some common questions to think about when evaluating co-verification accuracy are listed here. The key to successful hardware/software co-verification is the microprocessor model.

1) How is the model verified to guarantee it behaves identically to the device silicon?
Software models can be verified by using manufacturing test vectors from the microprocessor vendor or running a side-by-side comparison with the microprocessor RTL design database. Metrics such as code coverage can also provide information about software model testing. Alternatively, not all co-verification techniques rely on separately developed models.

Techniques based on RTL code for the CPU can eliminate this question altogether. Make sure the model comes with a documented verification plan. Anybody can make a model, but the effort required to make a good model should not be underestimated.

2) Does the model contain complete functionality, including all peripherals?
Using bus functional models was a feasible modeling method before so many peripherals were integrated with the microprocessor. For chips with high integration. it becomes very difficult to model all of the peripherals. Even if a device appears to have no integrated peripherals, look for things like cache controllers and write buffers.

3) Is the model cycle accurate?
Do all parts of the model take into account the internal clock of the microprocessor? This includes things such as the microprocessor pipeline timing and the correlation of bus transaction times with instruction execution. This may or may not be necessary depending on the goals of co-verification. A noncycle accurate model can run at a higher speed and more may be more suitable for software development.

4) Are all featue of the bus protocol modeled?
Many microprocessors use more complex bus protocols to improve performance. Techniques such as bus pipelining, bursting, out-of-order transaction completion, write posting, and write reordering are usually a source of design errors.

Simple read and write transactions by themselves rarely bring out hardware design errors. It is the sequence of many transactions of different types that bring out most design errors. There is nothing more frustrating than trying to use a model for a CPU that has multiple modes of operation only to find out that the mode that is used by the design suffers from the most dreaded word in modeling, "unsupported."

I once worked on a project involving a design with the ARM920T CPU. This core uses separate clocks for the bus clock (BCLK) and the internal core clock (FCLK). The clocking has three modes of operation:

FastBus Mode: The internal CPU is clocked directly from the bus clock (BCLK) and FCLK is not used.
Synchronous Mode: The internal CPU is clocked from FCLK, which must be faster and a synchronous integer multiple of the bus clock (BCLK).
Asynchronous Mode: The internal CPU is clocked from FCLK, which can be totally asynchronous to BCLK as long as it is faster than BCLK.

As you can probably guess the asynchronous mode caused this particular problem. The ARM920T starts off using FastBUS mode after reset until which time software can change a bit in coprocessor 15 to switch to one of the other clocking modes to get higher performance.

When the appropriate bit in cpl5 was changed to enable asynchronous mode, a mysterious message comes out: "Set to Asynch mode, WARNING this is not supported." It is quite disheartening to learn this information only after a long campaign to convince the project team that co-verification is useful.