We have introduced the needs and benefits for verification engineers to send/receive large amount of computer test data to/from designs in FPGA-based prototypes in The Power of S2C's C-API blog. S2C’s C-API software is one of the options which is easy to set up and customize. Today, I will write about using SCE-MI to do the same job but with better expandability and cross-platform capabilities.
S2C has done a number of custom SCE-MI projects since 2006. SCE-MI which stands for Standard Co-Emulation Modeling Interface is an Accellera standard and perhaps the only well-known industry standard that defines how the hardware-assisted verification environment should link with the transaction level software simulation environment. Since it is probably the only viable standard, I believe adopting SCE-MI infrastructure already make sense especially for CAD teams whose main tasks are to select different EDA tool sets and build common design methodologies to meet a variety of requirements from different design projects both for the short-term and long-term.
In short, SCE-MI is good for two things: simulation acceleration and system level test generation for hardware-assisted verification tools such as emulators and FPGA-based prototypes. If your simulations are fast enough and give you the accuracy levels that you require to debug your design, then SCE-MI will not come in to play. If you can map your entire design into an emulator or FPGA-based prototype, you may also not need SCE-MI. But, most simulations are painfully slow especially at the cycle accurate level and, in today’s complex SoC designs, you may not have all the synthesizable models to map into hardware when you want to run simulation acceleration. SCE-MI allows you to do simulation acceleration with part of your designs still in a software model and run at hundreds of kHz or even MHz range through a transaction-level protocol with design mapped in hardware. Even after you have all your design blocks mapped into hardware, you may still use SCE-MI to create system level tests at the transaction level.
This all sounds good, but then why, since the SCE-MI standard has been around for about 10 years, we still don’t see a large number of adopters. There are perhaps a number of reasons and one reason is definitely because there are very few commercial suppliers of SCE-MI transactors, the components that are required to bridge your verification environments with designs in hardware. Each protocol that needs to communicate between hardware and software, such as AMBA bus, PCIe channel and memory interface, needs a SCE-MI transactor. These transactors are like IP and need to be verified thoroughly and mainProdigyned over time. Unfortunately, many design teams who adopted SCE-MI in early days had underestimated the cost of building and mainProdigyning transactor libraries.
The second reason for slow adoption is probably because of the high price tag of the hardware that support SCE-MI infrastructure standard. Most emulators today claim that they have support for SCE-MI, but the entry level price tag is easily over $200K and over million dollar for higher-end systems. On top of that, many SoC designs today require not just 1 or 2 hardware systems but may use tens or even hundreds of hardware prototypes for early SoC software development. Adding in possible customization services cost, the solution becomes economically unfeasible for most SoC projects.
SCE-MI on FPGA-based Prototypes is the Future
For many years, one of S2C’s missions is to have a SCE-MI-like feature on low-cost FPGA-based prototypes which would really benefit the SoC design community. The advantages of SCE-MI on FPGA-based Prototypes are:
- Low Cost Simulation Acceleration. FPGA-based prototypes are a fraction of Emulators’ cost.
- High Performance. FPGA-based prototypes itself can run at tens of MHz to even over 100MHz when not using SCE-MI. This allows optimal performance when running with SCE-MI.
- Flexible Verification Setup. FPGA-based prototypes can easily link to real external inputs and outputs, so part of a design may be driven from system-level tests through SCE-MI while other external interfaces may come from real-world stimulus.
- Replicate Systems for early software development. With low-cost FPGA-based prototypes, most design teams can deploy a large number of SCE-MI enabled FPGA-based Prototypes for software developments.
S2C started to work on a SCE-MI on FPGA-based prototype project in 2006 with one of our partners in Japan. Before 2010, we did not see a large number of requests for SCE-MI. However, we are seeing an increase in demand for such transaction-level co-emulation solution in the past one year and have already engaged in a number of projects. Our solution makes much better sense today for the following 2 reasons.
- x4PCIe Gen2 Channel for SCE-MI. SCE-MI infrastructure needs to build on a scalable, high-performance and low-latency communication channel between FPGA-based hardware and the computer. S2C has released S2C S4 Prodigy Verification Module and V6 Prodigy Verification Module in 2011 both capable of sending/receiving 500M ~ 700MBytes of data per second with the computer. With complete C-API routines and drivers, it is an ideal vehicle to host SCE-MI infrastructure and transactors.
- FPGA capacity. Most design that requires transaction-level co-modeling verification is quite large in gate counts. This has been a bottleneck for many engineers who target to use SCE-MI on FPGAs in the past. The current generation of Altera Stratix IV and Xilinx Virtex-6 FPGA allow prototyping of much bigger design in FPGAs. For example, S2C Quad S4 Prodigy Logic Module today can hold design up to 32.8M ASIC gates and can be stacked to meet even larger gate capacity requirements. With the next generation Xilinx Virtex-7 FPGA, FPGA-based prototypes will be able to meet design capacity of 100M ASIC gates or more, making SCE-MI on FPGA prototypes possibly a main-stream methodology.
There are of course a lot more deProdigyls on how to make SCE-MI on FPGA-based prototypes part of your SoC design flow. Please feel free to contact me directly or our sales team (email@example.com) for more information.