Design Automation

An Evolution in System Design and Verification

New tools allow better interaction between hardware and software design.

by Gregor Zach and John Wilson

The design group at Siemens Automation in Nuremberg, Germany had a major problem on their hands; they had to build a 486-based system in which a custom ASIC played a key part in providing data from external sources to the software. As with many projects of this nature, scheduling pressures were quite significant.

The ASIC had two main functions: (1) initializing the hardware system at power-up time using a plug-and-play paradigm, and (2) high-speed data handling between a local bus and the main system processor bus. The ASIC also implemented a number of system features including timing generators, system interrupt functionality in conjunction with an I8259 interrupt controller, and the system EEPROM interface.

The hardware design group was responsible for the system design and the VHDL RTL ASIC description, which was then given to another group for the implementation. Ensuring that the software and the ASIC worked well together was especially critical because the software was used to set up and configure the system. A failure at this level would have prevented any meaningful system operation.

Because of the critical nature of the hardware/software interaction, the Siemens design team decided to take a new approach to verification of the hardware with the software. In previous systems, this verification was done after a hardware prototype of the system had been built. This required the ASICs to be manufactured then mounted on a board with the microprocessor (in this case a 486). The software was then downloaded onto the processor, and verification began.

In the new design, the design team decided to begin the verification process before hardware prototypes were built. They linked their hardware simulation environment ( Viewlogic's Vantage) and their VHDL ASIC description to their C++ code development environment by using a tool from Eagle Design Automation of Beaverton, OR (see Figure 1). Eagle also provided a high-performance model of the 486 processor.

Siemens Automation used a pre-release version of the Eagle system. Some of the features that are now available in the Eagle product were not implemented. One of these features was the provision for networking so that the hardware simulation could run on a UNIX workstation, while software development could be run on a PC and be networked in, as Siemens currently does it. The newly released Eagle system has this feature.

The hardware system description was run in the Vantage VHDL simulator. Some of the peripheral devices were implemented using the hardware modeler interface into the simulator. At first, each of the sub-blocks were simulated independently to make sure that they were functional and to correct any low-level errors. Experience indicated that performance using hardware simulation would be a problem, but when the new approach was tried, performance came in at over 1,500 instructions per second--more than sufficient for the job.

Figure 1. The Siemens approach allowed the linkage of software with VHDL descriptions of the hardware and a processor model to simulate the system.

The software programs, written in C++, were run under the Sun SparcWorks environment. Software programmers had already implemented a set of driver functions, which were recoded to work with the HDL description, to access the hardware.

For example, to do a read 8, instead of the normal C or C++ function call, users insert an Eagle function call (see Listing 1).

The original driver functions were quite similar to the functions used in the system simulation tests. The main differences were related to how the driver functions handled errors. There were no technical reasons for the differences. The error-handling conditions were not required for the system simulation tests, and other tasks had a higher priority.

Four programs were used to test the operation and interaction with the ASIC. The program runtimes were quite short. To execute 25ms of simulator clock time required about 30 minutes of simulation on a Sun Sparc workstation. Each of these programs had relatively high I/O densities.

One of the key features of the new integration technology is that, as larger applications programs are layered on top of these lower-level driver tests, the overall runtime does not increase significantly. In fact, the best relative performances are achieved with the largest software programs.

Each of the test programs checked one aspect of the board functionality on which the ASIC resided. These tests included memory checks, verifying the correct operation of the I/O (both serial and SCSI controllers), access to the interrupt controller, and verification that all the programmable systems parameters could be set up correctly.

The Eagle approach changed several aspects of system verification as the design team had known it in the past:

* The linking of software and ASIC hardware with synchronization allowed errors to be coordinated between the software developer and the hardware designer--as a opposed to the "it's your problem" approach (see Figure 2). Communications between the teams became very specific--the problems became demonstrable, to both teams in their own semantic.

* The availability of full hardware and software debug tools on-line allowed breakpoints to be set in both the VHDL descriptions and the software to flush out status in the debug process. For example, a specific line of VHDL code could be flagged to stop simulation of the hardware. This flagged code could also stop the software at the exact place in the C++ code, either causing or handling a hardware interrupt. At this point, the software could be single stepped to determine how it was handling hardware status and information.

* The software debug tools provided complete visibility to the source code and indicated what instructions were running at the time of a failure. The advantage of testing the system this way was that the SPARCWorks tool suite could be used to diagnose errors in the software programs. In previous prototype board tests, much of the software debug visibility had to be sacrificed.

* Through the use of watchdogs, status could be checked while the system was still running.

* The hardware debug tools allowed hardware designers to see the VHDL source code as it was running and to have waveform windows for all signals. These are synchronized with software status.

* At a failure, both the software and hardware designers could see the status of their particular parts of the design at the same time. In fact, the design could be single stepped, with both hardware and software debug windows active, to show simultaneous interaction.

Figure 2. Hardware-software linking. One significant change was the ability to link hardware debug tools with software debug tools during system simulation.

The changes to the normal design flow were actually quite minimal. No real changes were made to the toolset for the hardware design portion. The software design was developed in the normal manner. The inclusion of the SPARCworks debug environment was a change, in that previous prototype boards did not allow use of software debuggers.

The real change was in getting hardware designers together with the software much earlier in the design process. For Siemens, the normal experience is that final hardware is only available for use in testing when the prototype boards come back from manufacturing. This puts most of the burden of fixing problems on the software group. In the new approach, problems could be fixed in either hardware or software because the hardware was not yet in silicon. This required conversations between the two groups about what the optimal solution would be. These conversations were almost irrelevant when prototype boards were being used for integration.

During the system simulations, problems (both in hardware and software) were detected that had not been detected by the conventional simulations:

* An error in the ASIC specification was detected during the system simulation. The error, if undetected, would have required an ASIC iteration. Conventional simulation would not have detected the error because the RTL description conformed to the specification.

* A second problem detected was the result of a misinterpretation of the EEPROM serial interface protocol, resulting in a dead-lock condition when special access conditions occurred. In fact, when writing the test software for the EEPROMs, the wrong status bits in the ASIC were being polled, resulting in a complete system hang-up. This problem could be fixed in software, but it was detected and corrected much earlier in the design cycle than was possible using conventional techniques.

* A third problem involved configuring the data bus sizes of the local bus for the different data channels attached to the ASIC. When the software program configured the data bus for 16-bit transfers, every second byte had a data mismatch. This problem was easily diagnosed and corrected during the system simulations.

An interesting feature of all the problems is that they showed up when the software and the hardware would interact. Testing the software alone or the hardware alone would not have been sufficient to detect these problems. Of course, the problems would have been detected during the system integration phase--after the ASICs and board had been fabricated. The ASIC and board are now back and working within the system. There were no bugs in either the ASIC or the board.

One of the interesting side effects of diagnosing and correcting the problems early in the design cycle was that the high-level software group had not planned for, nor expected, the hardware to be fully functional so quickly. By starting the high level software earlier, additional time savings could have been made in the overall project schedule.

The overall result was an environment where both hardware and software problems could be diagnosed, debugged, and corrected at the earliest possible stage of the system design process. Many of the problems that are normally detected during system integration could now be detected even before the detailed hardware design was complete. In essence, the new approach provided virtual system integration.

The discovery of system-level prolems early in the design and integration process allowed Siemens Automation to avoid the excessive cost of solving each problem in software. Furthermore, the early problem detection saved one ASIC spin, which can cost tens of thousands of dollars and weeks or months in market time. In the end, Siemens did, in fact, prototype the system after the simulated integration; the result was "quite boring, no problems, no pain." *

Gregor Zach has worked for Siemens Automation for four years specializing in system simulation and CAE tool support. Previously he worked at Siemens Semiconduc-tor for five years, specializing in the design of high-speed CPU boards for real-time operating systems.

John Wilson works for Eagle Design Automation in their UK office. He worked for Vantage and Viewlogic for five years, specializing in VHDL and system simulation.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@asic.com.

integrated system design  March 1996