Virtual Prototyping With Connection to Assembly

Virtual prototyping has become popular both as a way to accelerate software development and to establish a contract between system/software development teams and hardware development and verification. System companies with their tight vertical integration lean naturally to executable contracts to streamline communication within their organizations. Similarly, semiconductor groups increasingly more integrated in automotive system design and validation (for example) are now being asked to collaborate with Tier 1 and OEM partners in a similar way, not just in a contract for behavior with software but also with sensors and complex RF subsystems (5G in all its various incarnations as well as radar, lidar and other sensing technologies).

A challenge however can be that communication between the prototype and hardware assembly/verification may be limited thanks to the gap in abstraction between these models. One way to bridge this gap is through co-design and verification. IP-XACT-based modeling, which always aimed to support this sort of end-to-end platform design covering everything from system-level modeling to implementation assembly, is one possible approach.

Some organizations made significant progress in developing these flows. Philips/NXP and ST were a couple of notable examples who were able to start prototyping and architecture development in SystemC (which the standard supported) and carry this all the way through to back-end design, supporting co-design and co-verification all the way through. While original platform-based design efforts were disrupted by market shifts (the iPhone et al), system markets are now more settled and new drivers have become apparent. Now some of these original approaches are re-emerging, sometimes with the same over-arching goal, sometimes to serve more tactical needs.

In the examples I used to open this blog, virtual prototypes can drive top-down executable requirements; another quickly growing application is in bottom-up system demonstrators: here’s how my proposed solution will perform, you can plug into your system to test how it will interoperate in realistic use-cases and we can iterate on that demonstrator to converge on a solution you find to be acceptable, before I start building the real thing.

In both classes of usage, there is obvious value in the hardware development team being able to connect more than through just this prototype to real assembly – the more comprehensive the connection, the more efficient the flow will be through to final assembly and verification and the less chance there will be for mistakes. This isn’t through automated system synthesis (except perhaps in certain sub-functions). The ideal connection should be a common platform to support co-design/verification starting from a virtual prototype with incremental elaboration of system behaviors into implementation choices. And there should be common points of reference between these views, such as memory/register maps, establishing verifiable behaviors at both levels.

Another especially interesting (and related) application of the virtual prototype is to drive verification of the hardware implementation. Thanks to extensions to UVM, there is now a UVM-System-C interface standard. From what I see at the Accellera website this still seems to be in early stages but I’m sure solution vendors are already helping to bridge gaps. What this enables is a system-based driver for hardware testing, allowing for realistic use-case verification based on tests written at the system level by the system experts, allowing for connection through familiar UVM-based verification platforms but without needing to reconstruct system-level use-cases in UVM.

Magillem has been working in the platform-based design space around IP-XACT since the Spirit days (the standard was originally called Spirit and is now formalized as IEEE-1685) and are pretty much the defacto tool providers in this area. They have been very active since the beginning in development of the standard and have been updating their support along with that evolution, including support for SystemC views, all within in a common platform. Recently they extended their product suite, built around this platform, through the introduction of MVP, the Magillem Virtual Prototype system for the assembly and management of virtual prototypes. MVP does not provide a simulator, though you can manage simulation from within the platform; you can link to your favorite vendor simulator or the freeware OSCI simulator. They are also partnered with Imperas for interoperability in building systems around OVP (open virtual prototype) models.

So you can build and manage virtual prototyping within MVP, but where this becomes especially interesting is in the ability to link between the virtual prototype and increasing elaboration of the design and verification. Magillem provide multiple capabilities; here I’ll touch here on a couple of domains very closely related to the bridge between the virtual prototype and assembly – developing (memory-map) register descriptions and developing register sequence macros. Both have become very complex tasks in large systems – importing legacy descriptions, editing to adapt to a new design, statically checking against assembly constraints and exporting to formats supporting driver development, dynamic verification and documentation. Synchronizing these functions between the virtual prototype and the hardware assembly is critical – and is already tied in to the development flow.

If you’re interested in having this level of linkage between virtual prototyping and hardware assembly, you can learn more about Magillem MVP HERE. I can also recommend a couple of interesting conference papers which get into more depth, one on using virtual prototypes for requirements traceability in embedded systems and another on using a SystemC testbench to drive hardware verification. You will need to request these from Magillem through this link.