Getting ready for this event allowed me to reminiscence on how I came by SystemC and how it proves to be a useful tool in the modeling armory of a Simulation developer.
I would like to touch upon my experience/observation of over a decade in Simulation Team in a leading Semiconductor MNC. In-house modeling methodology (based on C/C++) was used to model IPs/SoCs geared towards:
- Architecture Exploration
- Pre-silicon software development
- Verification and Validation
Typically there were two model variants – functional and cycle-accurate, depending on the use case. The majority of the models were functional (with no/limited timing information) and the remaining cycle-accurate. The functional/cycle-accurate models were not plug-n-play due to differing interfaces, especially on the memory-bus front. This arrangement seemingly worked well and was tailored towards the specific needs of the company.
Modeling helped cut project risks by front loading concerns on system performance, specification ambiguity as well as provided an early software development platform - that allowed software to be ready even before the SoC was available in board form. It was also considerably cheaper and faster as compared to hardware emulators. Every software developer had their own simulation platform for development on their humble laptop; and the suite of tools available for tracing, profiling and debugging - aided quicker development and debugging cycles.
Roadblocks for Scaling
As the benefits of modeling started spreading, many business-units wanted to begin and/or leverage modeling for their projects. So what options were evaluated for modeling?
Start their own modeling team
- Typically their engineers are domain experts and not necessarily modeling experts.
- Good familiarity with C but not so with other modeling languages like C++.
- Need to be trained on modeling methodology/processes.
- Modeling may not be a full time activity to justify costs of setting up an internal team.
Delegate modeling to Specialized Modeling Team (our team) within the company
- Good modeling expertise but lack of good domain knowledge.
- Stretched resources constrain accepting too many projects and taking multiple priority-calls.
- Resources need to be pulled out of existing projects to train engineers in other departments/contractors on proprietary modeling methodology and this affects existing project schedules.
Service model with third party contractor
- Need to be trained on proprietary internal simulation methodology. Since training materials are sparse and typically not up to date - hand holding is required.
- Since this knowledge is typically non-transferable for projects from other companies the billing rates are higher.
- Need to be provided comprehensive documentation/training on the IP specifics, typically not available so early in the cycle. Hence they need to work closely with the engineers.
- Even commonly used IPs cannot be bought and plugged-in as they need to be adapted or wrapped with proprietary APIs to talk to other existing models.
Outsource modeling development to tool vendors
- Least effort model but carry high costs – both upfront and licensing.
- Use their own proprietary modeling technology. Every change request needs to be routed through them and turnaround times may not be as fast as in either of the above models.
- Typically provide binary and do not share source code. Hence difficult to change vendors without reinvesting time/money for re-development with another vendor.
SystemC has been around since around 2000 but didn’t interest us as the internal simulation technology was considered to be superior to SystemC in terms of both speed and functionality. But things began to change at a rapid clip around 2007-2008 when SystemC v2.2 was released along with ground breaking TLM2.0 (Transaction Level Modeling) methodology for memory-mapped bus modeling. The feature set and flexibility offered by this combination in terms of modeling abstraction and communication proved to be a game changer. Developed as a C++ class library, all it required was humble C++ compiler to get started – No costly tools/licenses.
What started as a trickle quickly gushed forth as a stream and quickly engulfed the modeling world. The best of companies from the EDA, Semiconductor and Services world joined hands to develop this standard further.
- C++ is a multi-paradigm language and has been used to provide the basic blocks required to model simulation semantics. The free Accellera SystemC reference implementation and a simple C++ compiler is all it requires to get started.
- TLM2.x provides a very flexible communication methodology for IPs to talk to each other. The TLM2.x semantics spans the spectrum from Untimed to Cycle Accurate Synthesizable models. One can start with an Untimed TLM2.x model and progressively refine it to make it synthesizable.
- Since SystemC/TLM2.x is now also standardized as IEEE-1666, it is widely known and standard trainings and text books are available. Hence the need for internal training is greatly reduced.
- IP models compliant with TLM2.x are widely interoperable and buy/plug-n-play are much easier now.
- The big EDA vendors following the maxim – ‘Cooperate on Standards – Compete on implementation', now offer SystemC/TLM2.x compliant models that are interoperable. They compete on features like providing faster implementation (using multi-threading etc.), greater visibility of transactions through traces/visualization and user-friendly debugging features like breaking on threads/processes, code-coverage, rewinding through simulation etc.
- The service companies are also more productive as they do not have to spend time ramping up on proprietary simulation APIs, and are able to become productive much faster with quicker turnaround times for projects’ completion; and are able to leverage their knowledge across multiple projects more easily.
- SystemC follows a cooperative multi-tasking method for process control. While this is great for reproducing and debugging issues, this degrades simulation speed that it may otherwise attain. Jacking up simulation speed and allowing SystemC kernel to take advantage of multiple cores of the host platform are active research topics.
- The template laden C++ syntax is a put off initially for some beginners. Once they overcome this syntactical bump, it is smooth sailing thereof.
- While TLM has unified the mythical Babel of communication between IP models, it still encompasses a wide spectrum that must be ascertained before binding them together.
For the first time it is now possible to use a single language (SystemC) to design all the way from Architecture Evaluation stage to Verification and Synthesis. This greatly enhances the productivity of the engineering teams involved in the semiconductor food chain.
SystemC is taking early steps in synthesis of IP designs coded in SystemC rather than the more traditional Verilog/VHDL.
SystemC with UVM is slowing emerging as a contender in the Verification/Validation space. The ability to reuse TLM test cases used for Virtual Platforms for Synthesis designs is a productivity booster.
SystemC-AMS is filling the gap in terms of Analog modeling and Mixed-signal design space. A strong start has been made and we’ll have to see what direction it takes from here.
IPXACT (IEEE-1685) XML standard for describing IPs (registers, memory maps, interfaces etc.) has been leveraged from System Integration IDEs to automated code and test case generators and has resulted in higher productivity and interoperability of IP models.
Further standardization in the tool space is happening with the SystemC-CCI (Configuration, Control and Inspection) space by providing a standardized interface to configure SystemC IP models. The Configuration section has made considerable progress. Control and Inspection aspects are expected to follow suit.
ISCUG to DVCon
ISCUG 2012 (Bangalore) and ISCUG 2013 (Noida) provided a great meeting place for companies invested in modeling and to share notes and listen to leading voices in the ESL domain. Henceforth ISCUG has been integrated as one of the two tracks at DVCon India (Bangalore), the other being Design-Verification.
As a member of the Technical Program Committee, it was heartening to see the high quality of papers submitted and the wide range of problems that are being tackled using SystemC. Apart from paper presentations, Panel Discussions on topics highly relevant to the participants are being planned. Invited talks from industry leaders, multiple tutorials on Accellera standards and Poster presentations are also in the cards.
As monsoon recedes and winter peeps its head, the cool Bangalore weather welcomes you to come and explore its many wonders including DVCon.in. Looking forward to seeing you there!