Soft design for cryptographic engine

Soft design for cryptographic engine
By Tuan Hoang, Member of the Technical Staff, Sang Quan, Senior Principal Staff Engineer, Motorola Inc., Austin, Texas, EE Times
September 14, 2001 (2:22 p.m. EST)
URL: http://www.eetimes.com/story/OEG20010913S0065

Driver software for coprocessors is often developed concurrently with the hardware and needs to be validated long before silicon and evaluation platforms are available. Bugs in the hardware found during development of driver software can sometimes be critical enough to force a silicon respin.

Motorola's Networking and Computing Systems Group has designed an ASIC, the MPC190 (code-named Cerberus), for accelerating a set of complex, compute-intensive cryptographic functions. In a typical application, Cerberus connects to a host central processing unit (CPU) via a Peripheral Component Interconnect (PCI) interface.

Cerberus is optimized to accelerate all cryptographic algorithms. Protocols execute on the host CPU, which performs data-packet handling while the cryptographic tasks are offloaded to Cerberus. The MPC190's hardware development schedules forced us to verify the software without the benefit of having the actual hardware.

Th e development of the driver software, consisting of device drivers and a cryptographic tool kit, was contracted to a third-party software company that had no access to hardware simulators or Motorola's internal register-transfer-level (RTL) models. The software developers in this company needed a functionally accurate C model of the Cerberus for driver code integration and verification. Lack of design resources prevented us from building this C model from scratch and maintaining its consistency with the Verilog RTL code throughout the development cycle. The only way to meet this need in a timely manner was to create a functionally accurate C model from the RTL. This model also needed to be easily integrated with a variety of software development platforms such as Windows NT.

Afterburner model
We successfully created such a model using the Afterburner and ASVP Builder tools from Cynergy System Design Inc. (Austin, Texas). The first step was to use Afterburner to convert the design's Verilo g RTL code into RTL-C, which is Cynergy's format for representing hardware in ANSI C with functional, clock and pin accuracy. Afterburner requires the Verilog RTL source to be logic-synthesizable. To meet this requirement, we replaced some modules, such as memories, I/O pads and user-defined primitives (UDPs), with synthesizable versions. We also simplified or commented out components like clock trees, PLLs and oscillators to speed up the model.

ASVP Builder was then used to integrate this model with a custom wrapper to create either a standalone simulator or a shared-object library (depending on whether we included a main function or not). The shared-object library was required to be executed via function calls from the driver software.

To develop this library, we created an adapter (that is, a C wrapper) to interface the driver software with the converted RTL-C model. Functionally, the ada pter models a PCI bridge device that handles PCI bus accesses to and from the RTL-C model. It maps function calls from the driver software to pin-level stimuli at the RTL-C model's interface, using ASVP Builder's application programming interface. This library was delivered to, and linked into, the software development environment. The speed of the shared-object library was adequate for driver code execution.

One significant advantage of models built with ASVP Builder is that they do not require any special compilers or simulators for model compilation and execution, making them very easy for the software team to use.

Initially for our model verification we used the Afterburner tool's built-in verification flow for verifying the accuracy of the RTL-C model with the RTL. Later, as our adapter was integrated with the model, we found that we could reuse our existing Verilog test vectors by converting them to C vectors, stimulating the wrapped RTL-C model and verifying the results at the end of s imulation. Having a verified C model of the hardware derived from the RTL model allowed us to focus our efforts on interface verification issues only.

When the RTL-C was compiled on the Windows NT platform, one modification of the code was needed to work around a Microsoft Visual C++ compiler limitation. We changed lengthy if-else-if statements to switch statements. The Solaris and Red Hat C compilers did not have this problem.

Concurrent development
The resulting model was delivered to the software developer, which allowed it to execute and debug its software drivers as though they were running on actual hardware. In our experience, this is one of the few instances in which a C model of a complex ASIC has been successfully deployed for concurrent software development.

The usefulness of this tool suite is not limited to converting an entire ASIC, as in our case. ASVP Builder can also integrate different types of models (C or C++).