Integration of ASIC FPGA

Today’s ASIC designs have become huge in comparison to the early days making the process of verification extremely complicated. This is the reason that RTL simulation is used only early in the process, mostly for single module verification, since it is simply too slow.The size of the IC being developed makes even usage of FPGA prototyping boards an issue, since porting designs of 100+ million gates takes months and requires boards that include least several programmable devices. In spite of the fact that FPGAs are getting bigger and bigger in terms of capacity and I/O, SoC projects are growing much faster. In the end, even a very large prototyping board may not be sufficient.

To add further complication, parts of modern SoCs, like processor subsystems, are developed using virtual platforms with the ability to exchange different processor models depending on the application requirements. Verifying all of the elements within such a complicated system takes massive amounts of time and resources – engineering, software and hardware tools.

ASIC/SoC verification was less integrated and the separation among verification stages, tools, and engineering teams was more obvious. At that time the verification process started using simulation, especially for the development phase of the hardware using relatively short test cases. As the design progressed more advanced tests became necessary the move to using emulation was quite natural. This was especially true with the availability of emulators with debugging capabilities that enabled running longer tests in shorter time and debugging issues as they arose.

The last stage of this methodology was usually prototyping, when the highest execution speed was required coupled with less need for debugging. Of course, with the overhead of circuit setup, this took longer and was more complicated.Considering design size and sophistication, even modular verification becomes a non-so-trivial task, especially during final testing and SoC firmware verification.In order to reach the maximum productivity and decrease development cost the team must integrate as early as possible to be able to test not only at the module level, but also at the SoC level. Resolution unfortunately is not that simple. Let’s consider two test cases.

The requirement is to reuse the UVM testbench, but the design needs to run at MHz speed, part of it connected using a physical interface running at speed.To fulfill such requirements the project team needs an emulator supporting SystemVerilog DPI-C and SCE-MI Function based in order to connect the UVM testbench and DUT. Since part of the design needs to communicate with a physical interface such emulator needs to support a special adapter module to synchronize the emulator speed with a faster physical interface The result is that the UVM testbench in a simulator can still be reused, since the main design is running at MHz speed on the emulator and communicating through an external interface that is running at speed – thanks to a speed adapter – with the testbench.

SoC design partially developed in virtual platform, and partially written in RTL HDL language. Here the requirements are to reuse the virtual platform and to synchronize it with the rest of the hardware system running at MHz speed. This approach also requires that part of the design was already optimized to run in prototyping mode.

Since virtual platforms usually interface with external tools using TLM, the natural way is to connect the platform with a transaction level emulator equipped with SCE-MI API that also provides the required MHz speed. To connect the part of the design optimized for prototyping, most likely running at a higher speed than the main emulator clock, it is required to use a speed adapter as in the case already discussed. If it is possible to connect the virtual platform with an emulator running at two speeds (main emulation clock and higher prototyping clock) the result is that design parts already tested separately can now be tested together as one SoC with the benefit that both software and hardware teams are working on the same DUT.In both cases we have different tools integrated together testbench simulated in RTL simulator or in the form of virtual platform is connected with an emulator via SCE-MI API providing integration between software and hardware tools.