The Power of S2C's C-API
S2C's C-API function allows verification engineers to send/receive large amount of test data in computers to/from designs in FPGA-based prototypes. I have talked with many verification engineers and one common challenge today is the ability to create enough test cases and often the corner cases for validating their design in FPGA-based prototypes thouroughly. While linking their prototypes to target systems enable engineers to access to real world test environment, it is often hard to create corner test cases in real world environment. Therefore, a good design methodology would be to complement the real world test environment with addtitional verification data that can be run from a computer on a FPGA-based prototypes.
S2C's C-API is a good fit for the following purposes:
- Exercise large amount of verification data from PC to designs in FPGA-based prototypes
- Verification corner cases are hard to create in real world target systems, but can be created in simluation or software.
- Real target system interface is too fast to achieve on FPGA-based prototypes and therefore using computers to generate tests at slower speed
- Read and write to memories in FPGA systems such as to load boot codes or to take snape shots of system conditions.
S2C's C-API is an optional feature of S2C Prodigy Player Pro software and requires S2C FPGA-based prototyping hardware that supports the Prodigy VM technology. The following diagram shows a Prodigy Verification Module (VM) which communicates with a computer through a x4 PCIe Gen 2 inteface. The Prodigy VM is then plug on a Quad Stratix-4 820 Prodigy Logic Module (LM) that can hold design up to 32.8M ASIC gates.
C-API versus SCE-MI
SCE-MI is probably the only well-known standard that links test environments in computers to hardware-assisted verification platforms such as emulators and FPGA-based prototypes. While S2C is an advocate for SCE-MI standard and have done a number of customer SCE-MI projects, I personally think that using C-API is a good and easy alternative for most design requirements today. SCE-MI requires strict linking infrastructure and more importantly SCE-MI compliant transactors. Therefore, the cost and time to set up a SCE-MI prototype environment is higher and longer. Of course, some customers indicated that adopting SCE-MI is preferred because it will allow them to support cross software and hardware platform verification in the future. It is a good argument, but I will list the benefit of using S2C's C-API below:
- Easy to use. S2C's hardware-side interface uses OpenCore's Wishbone bus structure where customer can easily adopt to any other bus or link directly to a design block or a memory block. On PC side, we provide a set of C-API routines for read, write and DMA transfers.
- High Performance. Requires very little overhead and can therefore run at almost full 20Gbps data trasnfer rate.
- Low Cost. Only a fraction of SCE-MI set up cost.
- SCE-MI standard has not been widely adopted. There is limited number of SCE-MI transactors avaliable in the market place.
Having the ability to exercise FPGA-based prototypes with large and fast verification data from computers provides engineers a better mean to fully validate their ASIC/SoC designs. Both SCE-MI and C-API can achieve such ability and I recommend the use of C-API if cross software and hardware platform is not a concern today. I will write a blog on SCE-MI next month.