| |
 | |  | | | | | ESL — Bridging the Gap Between Design and Architectural Development
An interview with Mark Barry
Silicon & Software Systems | |
| |  | |  |
What is causing the drive to system level modeling? Why are traditional methods of architectural validation no longer sufficient?
With decreasing time-to-market windows there is an increasing overlap between the design and architecture phase of a program. Combine this with the greater risk of a re-spin in nanometer technologies and you find that a high confidence in the system performance is required earlier.
The increasing complexity of SOCs in nanometer technologies and integration of embedded SW, mixed-signal and RF on a single die also fuels the need to simulate many use-case scenarios. Older methods of architectural analysis such as using spreadsheets are not adequate to model complex block inter-action and temporal dependencies such as dynamic task allocation, while RTL based simulation is simply too slow and happens too late in the design cycle.
Electronic System Level (ESL) methodologies using abstract virtual prototypes allow robust system level design before RTL is available. Virtual prototyping offers almost the same speed benefits as hardware prototyping but with much decreased cost and the ability to have different geographically located teams sharing the same prototype with no usage conflicts. In addition there is increased flexibility from being able to easily probe internal signals and make architectural changes which are instantly reflected in simulations allowing extensive early architecture analysis on the desktop.
How much of your software are you actually able to verify using system level models? What is the biggest benefit of early HW/SW verification: debugging the HW with the SW test cases, or debugging the SW itself?
In one product we were able to develop the boot-code, hardware abstraction-layer, port the OS and test the complete communication protocol plus user interface software all running on an abstract model of the hardware. The important point to note is that this was done in advance of any hardware being available, allowing SW development to begin months earlier and saving significant time in the overall product development.
As well as the architecture team being able to debug the SoC architecture and verify the system performance, the RTL block designer can use the model to check SW-HW interaction such as the memory mapped registers of a new peripheral or to write specific directed tests in SW. Since we are also seeing a lot more peripheral re-use and IP verification suites traveling with the IP in the form of SW based tests, the system level co-simulation environment can be effectively re-used to run these tests and verify the integration of hardware IP.
What makes SystemC better than C++ for architectural modeling and verification? How difficult is it for someone to migrate from C or C++ to a SystemC environment?
Firstly SystemC has pre-defined constructs such as FIFOs, modules and signals that make it easy to create system models. Also SystemC allows the modeling of concurrent processes, similar to an HDL, that work with a simulation kernel having a concept of time. Unlike C++, Transaction Level Modelling (TLM) in SystemC has been standardized allowing for consistent application of best-practices even across different companies and IP providors. For verification SystemC has the additional SystemC Verification (SCV) Library which allows efficient transaction recording and constrained random stimulus generation.
By leveraging all of the above pre-defined features and libraries, a user has a much richer starting point and an easier entry into architectural modeling and verification than with pure C++. For example, we used SystemC to model a wire-speed network processing traffic manager. Using SystemC allowed rapid modeling of the concurrent processes and communications functions, which would have been much more difficult with pure C++.
However it is important to note that SystemC is a C++ library. Effectively SystemC is C++ and anyone currently using C++ will have a very easy ramp-up on SystemC, potentially even re-using parts of the legacy C++ in the new environment.
There is no good general purpose path from SystemC models automatically to HDL implementation. Until we finally, if ever, have real working architectural synthesis tools available this means that any system level model will be thrown away since the design will have to be coded in an HDL at some point. How much extra effort is it to create both a system model and an RTL model? Do the results really justify the extra effort?
Some people are using behavioural synthesis tools with great success at the moment, particularly in datapath dominated designs. However whether you go for an automatic path to gates or through a standard RTL coding phase a good methodology will re-use the system model for RTL verification. The system model can be used to generate stimuli for the RTL and / or as a golden reference model for the device under test, offering a time-to-market and risk mitigation advantage.
A SystemC model normally has 5-100X lines of code less than it's RTL counterpart depending on the application or level of abstraction and writing a system model incurs an additional effort of probably 5-25% over just RTL. In many cases these models can be re-used in derivative or similar designs if sufficient consideration of re-use is applied, reducing the effort next time around. For small simple designs, the main benefits are having a second reference for the functionality to check against RTL.
However for large complex designs the system model can be used as an executable specification shared between SW, architecture and RTL design teams to reduce the risk of specification misinterpretation as well as allowing robust architecture level design and early confidence in the performance. We all know the statistics for failed devices due to functional bugs or missing performance targets, so if spending a reasonable amount of time creating a system model can help avoiding expensive re-spins or even worse missing market windows it more than pays for itself.
How do you insure that the RTL models created in an HDL do, in fact, match the system models that you have been using?
We advocate using the system model as a golden reference for the RTL. Both the RTL and the system model of the device under test are driven by the same stimuli and the outputs are compared to ensure that the functionality matches. As with any abstract model there may be deviations in behaviour, for example if the system model is not cycle accurate and the RTL has some cycle dependencies. There are workarounds to this such as making parts of the model cycle-aware when necessary, or making the testbench clever enough to identify and categorize the mismatches due to certain events. The best approach is understanding where these mismatches may occur up front and design both the RTL and the model to certain guidelines and try to avoid them.
Once you start coding in HDLs at the RTL level you will probably find some more bugs or often have last minute functionality added or changed. Do you go back and make these changes to the system models as well? How to you guarantee that they stay in sync?
Yes, if there are functional changes they are made to both the RTL and the system model to ensure that they are always synchronized. We would usually re-run a regression suite of algorithm and architecture tests to make sure that nothing is broken there. In addition we would have a regression suite re-checking the model versus the RTL, with the golden vectors generated automatically. An RTL regression would need to be re-run in any case, but the advantage with having a system model is that we can guarantee system performance, even with last-minute changes.
We do a similar thing for Analog blocks where we re-calibrate our Verilog-AMS system models versus the transistor level implementation when it has changed significantly. This re-calibrated model is fed back into system simulations ensuring the highest confidence in all system level simulations even re-checking the signal processing feedback loops between digital and analog.
How accurate has your system level verification results been so far? If there were results that didn't ultimately match the end design, what caused the problem or mis-match?
For one multimedia processing IC we used a system model to design the algorithms and check system performance of a memory controller for external SDRAM access. We gradually refined parts of the system down to RTL using the rest of the model as a test harness. When we swapped in the RTL for part of the controller, we found that it did not match its equivalent system model and did not meet certain performance targets. However when we examined this, it only occurred during certain cases where the system model testbench was overly pessimistic and produced an input to the RTL which could never happen in reality.
A mismatch with the RTL is quite common and not necessarily a bad thing, once the issue is understood, resolved and any useful information is fed back to the architects. In the SDRAM case, we could update the system model to closer reflect reality and once the system performance regression was re-run, all performance targets were met with even higher confidence.
We use this approach of a closed loop verification strategy as well as outlining early in the project what to run at system level and what to verify at RTL level. Each time we have worked with a system model there have been mismatches and lessons learned which provide guidelines for future designs, but having this closed loop strategy ensures we deal effectively with any mismatches specific to a particular design.
Note: Mark presented the paper "Architectural Analysis of an eDRAM arbitration scheme using Transaction Level Modeling in SystemC" at the Cadence CDNLive event Sept 12-14, 2005. As a paid attendee at the 2005 CDNLive event, you are able to access Mark’s paper, # 1197 in the Functional Verification zip file.
| 
About the author
Mark Barry is a Principal IC Architect in the System IC business unit of Silicon & Software Systems where he is involved in SOC design from specification and algorithm development through to front-end design. Previously he was cross-functional team leader with Lucent Bell Laboratories responsible for 3G wireless ASIC developments and department head with NewLogic Technologies in Austria. His current research and development interests are in complex SoC architectures and low power design. |
| |
This content has been rated 4 out of 5 by other users |
|
|
|
|
|
|
|