This is the first of a two part series. The second article will appear shortly.
To close the gaps in systems development across distributed design and verification teams it will become necessary to plan, design, and verify embedded software closer in-line with the way we currently design and verify hardware. In the past, embedded software development, or more specifically verification, has taken a back seat when compared to the hardware. In other words, as long as the perception remains that software can be relatively "easily" changed and firmware updates and patches can be made available, it will not be given the same level of focus, overall planning, or effort as the hardware.
This oversight or lack of planning in the area of hardware-software co-development has resulted in a situation where less investment and methodology development are budgeted for comprehensive "Enterprise" System-Level solutions. The increasing number of consumer products with embedded processors and embedded software, combined with time-to-market and system-level quality pressures, forced many system companies to re-think their design and verification strategy. The main area being overlooked includes hardware and software verification methods and tools that work together in a much more efficient, measured and managed way.
In order to make this leap into the world of hardware-software co-verification at the system level, companies will require new ways of thinking holistically. They will need to manage the various technologies, engines, verification IP, and methodologies for multi-specialist teams across the entire project (hardware and software). This broader awareness will address serious product lifecycle concerns and market pressures for those developing advanced SoCs and systems, which will in turn open up opportunities for EDA companies developing innovative enterprise-wide, system-level solutions.
The Past and Present State of ESL
The two original goals of ESL back in the 90's were:
- Optimize the process of making architectural decisions for specific system characteristics
- Verify system-level functionity, including all hardware-software interfaces, before commiting to silicon
Over time, the definition of ESL has changed somewhat, but these goals have remained relatively unchanged. Recently, we've seen a big push in the market to create a suite of tools that addresses higher levels of abstraction, potentially leading to sign-off. Through these distractions and the pursuit of the "perfect suite of ESL tools," we've lost sight of the original goals of ESL, and we've become much too rigid about the need to move from RTL to higher-level of abstraction (i.e., SystemC, C++ etc.). For various reasons, such as technology adoption barriers, modeling issues, legacy code and lack of process automation, the move into a complete sign-off with full design and verification at high-level of abstraction has been slow.
The majority of block and chip design and verification engineers are still spending most of their time writing and verifying RTL code, but the majority of system engineers are writing and verifying their code using high levels of abstraction, such as C, C++, or SystemC. There are some exceptions where RTL and higher-level abstractions are well connected, but in most companies they are still isolated. Today, one continues to see cases where the need to essentially re-create the design code, the verification environment, and the various forms of verification IP and models across the various teams causes a huge amount of redundancy. Therefore, the fragmentation remains and some companies provide tools and flows to system engineers (mostly using C or SystemC) while other companies provide solutions only to verification engineers (mostly using RTL).
Looking Deeper at the Current Situation in ESL
Let's take a closer look at some of the specific reasons that ESL solutions have seen very little traction in the market.
- High abstraction level solutions tend to be very resource intensive, with model development challenges addressing only a portion of what needs to be tested in system architectures. The designs that these tools have been applied to are those with healthy budgets and relatively low market timing pressures which has led to limited success.
- Most design teams currently tackle rising complexities one way when it comes to verification of hardware and software within a system. The general feeling is that by increasing the total number of verification engineers, they will be able to keep up with the required verification bandwidth to verify the hardware and software. They tend to throw use cases to design engineers hoping that this will provide the full system coverage needed. This approach is risky, can be expensive, and just does not hold up any longer.
- The synthesis tools from SystemC/C to RTL are not mature yet and address very small portions of designs and design structures. As long as we don't have coordinated and proven sign-off process at this level it will be difficult to convince the majority of designers and verification engineers to change.
- There has been a lot of ambiguity in the definition of detailed design structures. For example, in order to describe the design and its components in a level that can be understood by all tools, you need to define it in a structural level. This definition might take much longer as compared to RTL coding, which in turn may lead to a loss of all the performance advantages.
- While it may change in the future, today when additional system-level validation is required at RTL, it is being done solely with acceleration, emulation and/or FPGA prototyping.
Where Should We Go From Here? Extending System-level Solutions to the Enterprise
We should first acknowledge that it takes time for the market and the underlying technologies and methodologies to move to higher levels of abstraction. In addition, we should recognize that ESL includes both RTL and SystemC/C++ needs, and combine the flows to support full enterprise-wide demands. We should get reacquainted with the original goals of providing a solution for all specialists to verify and validate their full system, including hardware and embedded software, early in the design phase. This is more important than focusing on any one specific language or specific level of abstraction. In order to provide predictable system-level quality, we need to leverage the tools with the proven methods that have been applied successfully to hardware and apply them into a system-level flow. In other words, we should tweak the current ESL definition to include full "Enterprise" System-Level solutions.
Enterprise System-Level solutions bring together design and verification from initial plan to full system-level closure, which means that design engineers have the ability to get involved much earlier in the process with the verification teams, as the verification plans and system-level architectures are initially developed. Enterprise solutions that lower the bar for design teams to get involved and participate early in verification planning, especially across an entire SoC, will lower overall barriers for adoption and eliminate many of the redundant verification tasks thus slashing the overall project development time.
|
