HW/SW Co-Verification at Alcatel
By Gjalt de JongAlcatel Bell, Antwerp, Belgium
Over the last year, Alcatel has adopted and deployed Mentor's Seamless™ tools on our new generation access product family for telecommunication networks covering residential and small markets, and based on a passive optical network architecture.
System Overview
Alcatel used hardware (HW)/software (SW) co-verification to help design an Asynchronous Transfer Mode (ATM) passive optical network connecting different services, such as online narrow-band services to the home, e.g., via ADSL and POTS. The overall system architecture is illustrated in the following figure:
The optical network connects a single Line Termination (LT) module (at the central-office side) with multiple Network Termination (NT) modules (at the end-user side). A second LT module is always on stand-by for fault-tolerance purposes. NT clients can be added and removed on the fly without interrupting the rest of the system operation.
An embedded ARM7TDMI processor runs the transport protocol software. The code running on this processor is responsible for the initialization of the communication set-up, re-configuration of the network and some network management tasks. For the software, the LT module serves as the master, to which all the NTs are clients. The system is defined in such a way that a single ASIC implements both the NT and the LT functionality. The personality of the ASIC is handled by software configuration. The design also contains an MPC860 processor for the overall system control. This processor also interfaces with the ASIC.
For the HW/SW co-verification, this complete multi-processor environment (including the analog and mixed-signal parts of the design) is modeled and verified. For the ARM7TDMI, the operational software was run. For the MPC860, only the offline diagnostic software was co-verified.
Why Co-Verification?
Alcatel already uses advanced in-house system simulation strategies with some HW/SW co-verification facilities.
Adding a commercial tool into the design environment enabled up-front integration and debug of the HW and SW. The system integration work normally done on the prototype late in the project was done in parallel with the HW and SW design, while the HW design was still described at the behavioral and RTL levels. This capability resulted in direct time savings in the overall project plan.
The Alcatel in-house HW/SW co-simulation environment was deemed to be insufficient for this project. These tools supported Host Code Execution (HCE) mode, but were not suitable for the Instruction Set Model (ISM) mode of operation.
The integration of the ARM7TDMI in this project required ISM capabilities to execute the object code directly. The MPC860 processor was used in HCE mode (at the start of the project, this model was only available in beta for CVE, so we modeled it using the HCE facilities).
An important feature of CVE HCE mode is that lock-step synchronization (as well as free-running and controlled-ratio synchronization) with the hardware is possible. The Mentor CVE tools give the user full control over the synchronization between the software and the hardware.
Alcatel's findings are that these simulation modes and synchronization features are required for an effective and efficient use of co-verification. Specifically, they are required for this type of real-time systems development.
Approach
In this project, the introduction of co-verification had the following goal: debug the diagnostic and operations software up-front to speed up the effective system integration test, yielding an overall lead time reduction.
Co-verification started early enough in the design flow to highlight both conceptual problems and identify the "normal" mismatches that are always found when the HW and SW are first integrated.
This allowed the debugging of both diagnostic and operational SW. The idea was to perform as much system-level co-verification "up-front" as possible. By moving system integration up-front, the number of VHDL top-level simulations could be reduced.
In fact, this up-front capability meant that we were simultaneously running, almost continuously, up to 8 co-verifications.
Experiences
For the ARM7TDMI, a HW simulation model already existed, so it was important to identify where the CVE model would add the most benefits, and where the original simulation model was still required.
The HW simulation model was required for final sign-off with the ASIC vendor, and was also used to test the In-Circuit Emulation (ICE) debug facilities.
However, the simulation model did not have any of the debugger facilities required for full SW development, so the co-verification model was used for the other simulations.
The verification of test software was built up in layers, first to test register access, and then adding basic mechanisms, module tests and system functionality. On the ARM7TDMI model, boot and halt tests, exhaustive memory, peripheral and interface tests were all executed.
For the analog parts of the design, behavior models have been written. The exact modeling and level of accuracy has been determined by the system scenarios to be simulated. For example, the noise aspects have not been considered.
Compared with our previous design experiences, use of co-verification has meant that many fewer module tests and VHDL top-level simulations have had to been run. Co-verification of the ASIC and subparts of the ASIC have been used instead.
Although this could be considered overkill for module tests, there are several advantages to such a practice. For example, writing the tests is much easier in C. Running the tests on the processor, more aspects are verified at the same time. The tests are reusable and serve multiple purposes as they are part of the normal operation. For instance, the diagnostic software already covers the operational software to a large extent. This software is already debugged before system integration tests on the target will be run.
The classical errors like signal inversions, unconnected and wrongly connected pins, and incorrect data orderings have all been detected during co-verification for the hardware. These are also identified with the usual module and VHDL top-level simulations. They are, in both cases, easy to detect and solve.
Similarly, some examples of found bugs for the software include reads and writes on the wrong address, incorrect loop bounds and initialization values.
Much more importantly, architectural issues have been uncovered, including throughput problems due to scheduling, fifo sizing, protocol conversions, and incorrect implementation due to misinterpretations of specifications. These errors would otherwise have been found during final system integration tests. Detecting and identifying such causes in the lab is much more time-consuming. The costs associated with correcting these problems were greatly reduced because of their early detection and diagnosis.
Even given Alcatel's advanced system debugging methodologies, co-verification yielded a much greater observability and controllability of the system.
From the start of the project, we had the following question: was RTL-level VHDL simulation performance sufficient for system-level co-verification, or would we have to develop RT-level C models?
In the cycle-accurate mode, we were seeing performance statistics of up to 1.5 microseconds of simulation time being executed in 1 second of real time.
At this stage in the project, the optimizations available to speed up the overall system simulation were not required. As more operational SW is layered on, it is likely that much more use will be made of the optimizations [see breakout box]. We are currently running experiments to establish the level of performance increase here.
Lessons Learned
Our approach of first defining the scenarios to verify, and then identifying the required modules of the system and their level of abstraction, has proven to be the key factor to success. A clear verification strategy is required for each project, identifying which parts of the system are being verified at each stage and how.
It is not feasible to verify the functionality, implementation and timing in a single simulation. Full coverage may have to be guaranteed by a combination of different co-verification-based simulations, each verifying a particular aspect of the design.
In this project, a bottleneck in the planning was the availability of the complete HW/SW interface specified in VHDL. Parts of the system were first co-verified with incomplete specifications.
The module and top-level design of the system should be aligned with the verification strategy defined at the start of the project. This includes hardware and software components.
The most effective use of co-verification will require changes to the project organization to ensure that the key SW components are available for integration and testing. The project plan should reflect the integrated design and verification flow, which we followed successfully.
Although we have replaced many module test and top-level simulations with HW/SW co-verification, both remain complementary. For example, corner case testing of modules is harder when co-verifying the complete system than a single module. A level of confidence and quality has to be achieved before a component or group of functionality is to be included
Using HW/SW co-verification as part of testbenches written in C and using the NCS model are easy and effective means for module and functional system testing. Reuse of code is another great benefit.
We felt that the most significant area where co-verification tools might be improved is its ability to take a snapshot of the HW, SW and synchronization. The ability to restore this snapshot rather than having to re-simulate to reach would greatly reduce the simulation times.
Conclusions
Our experiences so far have positively answered the main questions relating to the feasibility of HW/SW co-verification.
The overall simulation performance allows us to run system simulations earlier in the design cycle. The HW/SW co-verification methodology has seamlessly been integrated into our design flow.
The key to success has been the up-front definition of a clear verification strategy during the entire design. There is still room for improvement, but it is clear that the success of this project is leading to the implementation of the full methodology.
As a result, co-verification tools will be more extensively used in future projects.