Designers urged to put logic check into code

Designers urged to put logic check into code
By Chris Edwards, EE Times UK
March 20, 2002 (4:35 a.m. EST)
URL: http://www.eetimes.com/story/OEG20020320S0001

Checking logic embedded into the code that describes hardware is set to become a mainstream part of design.

The Virtual Socket Interface Alliance (VSIA) is underway with an effort that will recommend that designers put logic and protocol checks into their code and two companies have donated a set of language extensions to standards body Accellera that will put extra support for embedded checkers into the Verilog language.

Co-Design Automation and Real Intent have teamed up to offer an assertions language that will extend the next-generation Verilog being developed by Accellera and which is based largely on Co-Design's Superlog language.

The move is separate to Accellera's ongoing effort to define a larger assertions based language to drive formal verification and simulation tools.

Dave Kelf, vice-president of marketing for Co-Design, said: "Real Intent brings notions from the static verification side, things we didn't have in Super log.

"The assertions are tied into the HDL, capturing the designer's intent when the IP [intellectual property] is created."

Kelf said the language does not conflict with the Open Verification Library (OVL) donated to Accellera by Verplex.

"This is an assertions language and OVL is an assertions library that can be built on the language."

Kelf says the current assertions language submission is tied to Verilog but that the work can be readily extended to VHDL.

Larry Rosenberg, vice-president of engineering for VSIA, said the move to adopt hardware checkers is providing new impetus to the functional verification development working group (DWG): "It is a group that had trouble getting traction."

Hardware checkers could prove vital to intellectual property (IP) core developers as they will help technical support teams understand how cores are being used in a design and debug any problems that result.

Tom Anderson, co-chair of the functional verification D WG and vice-president of applications engineering at 0-In Automation, said: "Having protocol monitors on all the interfaces of a VC [virtual component] is very important, because the monitors are so useful in SoC designs.

"Monitors can tell you, is the customer stimulating the VC correctly? Users may not know what is going on when the checker fires but that is better than going to silicon with a problem."

What are hardware checkers?

Hardware checkers are pieces of verification code that get embedded in the actual design instead of sitting in an external testbench.

The idea behind a checker is that it watches events in a core, typically those on buses or interfaces, to see whether there are any events that can cause protocol violations.

The checkers are generally marked as not being synthesisable but are translated so that they can be understood by conventional simulators. Companies such as 0-In Automation have defined constructs that ensure the checking code is igno red by Synopsys's Design Compiler and other synthesis tools.

Tom Anderson, vice-president of applications engineering at 0-In Automation, said: "Checkers sit in the RTL and potentially travel with the RTL. It tends to be less efficient to write checkers outside the RTL."

When the checker detects a violation, it will generally fire off a message to the console or write the event to a log file that is then analysed offline by a verification tool. Transeda's recently launched VN-Property uses the event logs to work out whether simulation runs fully exercise a bus or core.

Checkers are not intended to replace testbenches. Instead they act as 'white box' tests created by designers as a core is put together to complement the 'black box' tests built by verification engineers against a system's specification.